Presented by: Will Smith
Will Smith is a Program Manager with the Microsoft Solutions Framework team, focusing on technology infrastructure. Will was previously a Senior Consultant, and a Senior Systems Engineer for Microsoft. He has 15 years of experience in the computer field. He also has more than a decade of experience as an engineer and chemist with the automotive industry.
Phone: 425 703-3105
Fax: 425 936-7329
Email: willsmi@microsoft.com
In today’s complex world of information systems, a defined process and team approach for infrastructure deployment projects is imperative. Such an approach helps ensure that infrastructure implementations are consistent with business objectives, and can be effectively utilized once the technology has been deployed. A defined process also serves as a road map so that important aspects of a project will not be overlooked.
Managing Infrastructure Deployment Projects applies the Microsoft® Solutions Framework (MSF) Process and Team Models and other principles of the MSF Solutions Development Discipline (SDD) to information technology infrastructure implementation projects. It also incorporates a set of industry-founded best practices to yield a framework that improves the efficiency and effectiveness of infrastructure deployment projects, and that maximizes the business value realized after the completion of these projects.
Technology infrastructure exists to meet the business needs of the organization. It supports the enterprise architecture, facilitates communications and/or exchange of information, facilitates the attainment of business objectives, and organizes the knowledge capital of the enterprise.
The technology infrastructure is where it all comes together. No single element or part of an Information Technology (IT) organization can be considered the infrastructure. All elements must be considered for a project to be successful.
Composition of the technology infrastructure includes:
The purpose of the infrastructure deployment process model is to provide a framework that will assist organizations to successfully implement technology solutions that meet or exceed the predefined vision and business objectives.
There are four phases in the infrastructure deployment process model: Envisioning, Planning, Developing, and Deploying-and there are four milestones associated with them: Vision/Scope Approved, Project Plan Approved, Scope Complete/First Use, and Release. The activities within each phase are broken into incremental events called interim milestones and content components called deliverables. These are explained later in this section.
The processes within each phase are iterative, actively encouraging feedback and adjusting the output accordingly. The process arrow extends past the Release milestone because the process is designed to accommodate enhancements to, or the growth of, the deployed infrastructure technology.
An effective team uses checkpoints throughout the process to ensure all issues are on track. These points are interim milestones and are associated with phases. They affect the process of getting to a milestone. Reaching a milestone is represented by delivery of a project component. A deliverable usually represents having reached a milestone. Physical deliverables are not only recommended, but are essential to efficiently documenting the project
The MSF Team Model focuses on staffing, competency, management, responsibility, and quality in complex projects. An adaptation of the model for infrastructure projects is critical for successful deployments.
The MSF Team Model is defined as a Team of Peers working in interdependent and cooperating roles. Each team member has a well-defined role on the project and is focused on a specific mission. This approach encourages the feeling of ownership and ultimately results in a better product. The leaders of each team are responsible for management, guidance, and coordination, while the team members focus on carrying out their missions.
The six team roles identified in the MSF Team Model are:
IT organizations may have additional requirements that call for supplementing the team with supporting roles such as systems management, help desk, implementation, and communications.
Vision
A clear vision is a pivotal element relative to the ultimate capability of any product. The means of attaining the vision may not be known at this point in the project. However, without a clear vision for the product, it is unlikely that the product will achieve greatness. The goal at this point in the project is to focus on what is most desirable, from a business and user perspective, without limiting one’s imagination to the technical implementation.
There are seven fundamental concepts and guiding principles that underlie the MSF project vision and scoping approach.
Peak performance begins with a commitment to vision
The most productive teams are the ones in which all team members feel they are important and at the same time are committed to the common mission of the team. Mission starts with determining what the customer really cares about and wants to accomplish, and then committing to it. There will be plenty of time to develop expertise as the project unfolds. Discover your customers’ preferences first.
To produce great results, vision must exist and be communicated
Teams that produce great results have refined their capacity to see clearly what they want to accomplish for their customer and know how to state it in terms that motivate the whole team and the customer. This statement of vision points the way for the team by providing the why that inspires the how, which in turn leads to action.
A great project vision combines verbal and visual information
Developing a vision means seeing a pattern in the things and thoughts that get your customer moving, assessing your resources, and then formulating your ideas into words. It means bringing together two major components: visual and verbal. Productive teams keep the visual element alive in the ways they state their vision, often conveying it to great effect through images and metaphors. The team must have the capacity to see what the customer wants and to state it in terms that motivate the whole team and the customer. Visions that motivate are the call to action, the click that starts things moving.
Vision is bounded by no preconceived limitations
Vision is bounded by no preconceived limitations. It inspires the team to reach for what could be and to rise above their collective fears of uncertainty and preoccupations with the current state of things.
The sustaining source of vision is business value
The bottom line for project teams is delivering business value by creating and combining elements of technology into practical solutions that solve pressing business problems and/or leverage opportunities.
Vision guides shorter-range objectives (scope)
Vision establishes and sets a direction in which the whole team can be impassioned, committed, and empowered for the long haul. And vision guides the shorter-range objectives. Both in turn lead to high-quality action.
Scope
The team must have a vision before it can develop a scope. The scope maps the vision against the reality of what is required to achieve the vision. The scope must quantify several parameters-the problem, the new technology expected to resolve the problem, the constraints (including time), and the risks-and evaluate the value of alternative solutions. The scope is where the features functionality and a high-level schedule are defined. (A detailed schedule cannot be developed until some requisites in the Planning Phase have been satisfied.)
Setting the scope means that the needs of a diverse set of end users must be balanced against each other as well as other priorities set down by management. Several variables may impact the potential success of the project, including costs, resources, schedule functionality, and reliability. The key is finding the right balance between these variables.
It is essential that each project team role be kept informed about the activities of the other so that they can react to any adjustments that are made.
The Envisioning Phase culminates at the Vision/Scope Approved milestone. The Vision/Scope Approved milestone is reached when the members of the project team, the customer, and key project stakeholders have achieved a common understanding and agreement on:
The Envisioning Phase has three interim milestones.
The Envisioning Phase culminates in the Vision/Scope Approved milestone.
The first interim milestone during the Envisioning Phase is Team Formation Complete. Bringing the right team together is essential to developing an effective vision and has serious impact on successful project completion.
Team formation may be by direction when it comes to dealing with organizational issues within the company. The process of team formation brings together the skill sets needed to complete the project successfully. It is not necessary to determine every team member at this time, but a core team with representatives from each of the six team roles should established.
Once the core structure of the team has been established, the vision must be distilled down to a problem statement-the reason for the project. The team must then evaluate the problem and determine how to resolve the issue. The team should take care to make sure that the solution is directly related to the identified problem so that the solution does not become the purpose of the project.
Not only is it important to identify who will sponsor the project (the customer), but it is also critical to make sure that the customer agrees with the vision of the project at this time. Ensure that either the customer or the stakeholders in the project have a span of authority consistent with the scope of the project.
The solution concept outlines an approach that provides the basis for building a specification.
The deliverables for the Envisioning Phase must be available and stable at the Final Vision/Scope interim milestone so that the scope of the project can be defined. The critical success factors provide a checklist for each phase in the process model and the activities within a phase to ensure that none of the essential elements is overlooked. The business improvement metrics provide a convenient means of measuring the actual value derived from the solution, in comparison with the anticipated benefits. All involved parties need to understand the level of commitment that is necessary to move to the Vision/Scope Approved milestone and beyond.
Reaching a milestone is represented by a delivery of a project component called a deliverable. Deliverables can be distinguished from interim milestones because deliverables are physical components while interim milestones are points in time. There are four primary deliverables-Vision/Scope Document, Risk Management Plan, Project Structure Document, and Next Phase Estimate. Some of these deliverables have distinctly identifiable content elements that could be viewed as subdeliverables.
The Vision/Scope Document
The Vision/Scope Document defines a clear direction for the project team, sets expectations, and provides the criteria for the designing and deploying the solution. There are four content elements in the Vision/Scope Document which address the what, where, when, why, who, and how of the project: The problem statement (or statement of objectives), vision statement, user profiles, and solution concept.
The purpose of the problem statement is to establish what motivates initiation of the project. This can be stated as a problem definition and/or a statement of objective. Some good information can be gathered by reviewing contractual or commitment documents, including proposals, cost justification, and executive presentations. Interviews with primary customers, users, business, and IT sponsors are also good sources of information.
The purpose of the Vision Statement is to establish a long-term vision to address the problem statement. This provides the context for making decisions and evaluating options throughout the development cycle. Often the Vision Statement has implications beyond deployment of infrastructure technology. It is important to bring these implications to the surface through reviews and discussion during the analysis and design process.
The purpose of the user profile is to identify the users in order to assess the expectations, risks, goals, and constraints. This information, when combined with the user profiles and usage scenarios in the Planning Phase, will enable the team to quantify how much change will be necessitated by the proposed solution. A typical user profile will include data such as geographical boundaries, information flow between users, user functions, resource availability and utilization, organizational stratification, decision-making policies, and political alliances.
The solution concept outlines an approach that provides the basis for planning and scoping the analysis and investigatory work required to build a specification. It also provides a basis for establishing priorities in the target release baseline. Focus is placed on each of the service categories (user services, data services, and business services) to ensure a consistent model that encourages standardizing the development approach.
The solution concept include the following elements:
Project success factors. How success will be defined and measured.
Operational concept. Sample scenario(s) for where and how the system will be implemented, and how users will employ the new technology, all of which are important to establish an understanding of the workflow.
Deliverables. A complete list of project deliverables that will make the new product or service operational.
Acceptance criteria. A checklist of requirements that must be satisfied before the solution goes into production.
With the exception of the User Profile, all of the other content should be high-level. For example, the solution concept should include a high-level schedule. A detailed schedule cannot be developed until some additional requisites in the Planning Phase have been satisfied.
The audience for the Vision/Scope Document includes executive sponsor, the business unit manager, and all team leaders. The authors of this document must take responsibility for other people’s listening. In other words, they must verify as completely as possible that everyone has a clear and consistent understanding regarding the content of the document.
The Risk Management Plan
Risk
When a condition exists or an issue arises, certain consequences can be associated with the condition or issue. Risk ascertains the impact of the consequence by determining the likelihood of its occurrence and the severity of the outcome relative to established project objectives.
Risk Management Approaches
There are two inherently different approaches to managing risk. The first involves the reactive management of risks; the second, proactive management of risk.
Reactive risk management
Reactive risk management means the project team reacts to the consequences of risks (actual problems) as they occur. Reactive risk management consists of three strategies:
Mitigation of symptoms. Mitigation is alleviating or lessening the consequences of a risk, generally through providing additional resources.
Fix on failure. If the team doesn’t have the resources for mitigation efforts or decides that mitigation is not required, then it must fix the consequences of the risk as they occur.
Crisis management. If the failure cannot be fixed quickly enough, the project slips into crisis management in which uncertainty increases and stability and predictability decrease.
Transitional
Prevention of risk is the transition point between reactive and proactive approaches. Prevention occurs in the planning stages of a project, when actions can be taken to preclude risks from occurring. It is important to recognize that prevention is still essentially a reactive strategy for managing risks; it is not a cure for the cause of risk, only a means to avoid its symptoms.
Proactive risk management
Proactive risk management means the project team has a visible process for managing risks and the process is measurable and repeatable.
Elimination of root causes. If the team has a proactive risk management process, it can discover many of the root causes of risk and take actions to eliminate them effectively and efficiently. By understanding and eliminating the root causes of risk, the team can stabilize the development process, increase predictability of the outcome, and minimize the uncertainty involved.
Anticipation of risks. Being able to anticipate when and where risks will arise allows the team to place itself in a position to take actions to manage them before they actually occur.
Change management. By continuously increasing the focus areas for anticipating risks, the team can put itself in a position to manage change to its own advantage. It can, in effect, engineer risk and opportunity. This allows the team to exploit opportunities before competitors are even able to see them. Microsoft has been particularly effective at managing change.
To reach the higher levels of proactive risk management, the team must be willing to take risks. This means not fearing risk but rather viewing it as a means to create the right type of opportunity. To do so, the team must be able to evaluate unemotionally the risks (and opportunities) and then take actions that will address the causes of these risks, not just their symptoms.
While proactive risk management is the preferred process because of the obvious advantage it offers for avoiding risk conditions entirely, it is also apparent that a reactive plan should be in place to address unforeseen issues as they arise. Risk management is an iterative process that continues throughout the life of the project.
The Project Structure Document
The Project Structure Document defines how the project will be managed and supported, and the administrative structure for the project team going into the Planning Phase. The document also encompasses the change control and configuration management functions. It will be updated at the Project Plan Approved milestone when all the project resources have been assigned.
A Project Structure Document may also include e-mail names, e-mail aliases, telephone lists, mail addresses, server share names, directory structures, and other information critical to team organization. This information is a great candidate for publishing on an internal web page, where it can be updated as the project proceeds.
Team Focus during the Envisioning Phase
Each role on the MSF team has a defined responsibility and brings a specific competency that complements the other roles to ensure successful completion of the project.
Product Management documents user needs, defines business problem, identifies expected benefits, articulates vision, identifies management risks, and manages expectations.
Program Management establishes design goals, establishes success factors and metrics, identifies necessary project infrastructure, and documents the solution.
Development researches existing technology solutions and works with Program Management to document technical solutions.
User Education identifies practical user communications channels and identifies training requirements for project personnel and users.
Testing identifies testing criteria based on design goals, identifies testing process and frequency, logs risks and rate by potential impact, and establishes feedback loop for communication of high-risk situations.
Logistics Management researches and reports on material constraints, identifies shipping and delivery issues, and provides the foundation for long-term management and support.
Coordination with External Teams
Relative to an infrastructure technology deployment project, there are several functions that may be external to the core team, yet still have input which is essential to the success of the project. The six core roles defined in the model serve as conduits to the external functions, managing inputs to and responses from external entities.
There are four roles in the operations and support function that directly impact the quality of a technology solution deployment:
System management maintains accountability of the systems, technology, and continued operation of the technology.
Help desk provides ongoing support to users to allow them to maintain a high level of serviceability and functionality of the technology.
Communications maintains voice, video, and data communications capabilities.
Implementation creates the infrastructure solution. The implementation role can either be completely external to Logistics Management, handled completely within Logistics Management, or can be a combined effort of internal and external teams.
The operations and support functions provide contributions that are critical to successfully completing the infrastructure technology deployment process. In addition, incorporating these functions early in the deployment process further ensures a smooth transition of the technology to long-term support.
At the Vision/Scope Approved milestone, the members of the project team, the customer, and key project stakeholders have achieved a common understanding and agreement regarding scope, risks, assumptions, constraints, and the effort required to complete the Planning Phase. When this point is reached, the team should conduct a milestone review to assess what went right and what went wrong during the Envisioning Phase, and why. Each phase will include its own milestone review. At the end of the project there should be a complete project review, using these phase milestone reviews as the baseline
The Planning Phase, which culminates in the Project Plan Approved milestone, expands on the vision and scope defined in the Envisioning Phase. The project plan provides detailed, low-level specifications derived from the deliverables of the previous phase and establishes the structure for completing the balance of the project.
The Planning Phase contains three interim milestones: Conceptual Design Complete, Design Specification Complete, and Master Project Plan Complete. At the Conceptual Design Complete interim milestone, the vision, audience, and conceptual solution have been established. At the Design Specification Complete interim milestone, technical details are assigned to the structures defined in the Conceptual Design Document and logical and physical dimensions are added to the information matrix. For the purposes of this discussion, the Functional Specification is considered to be the combined content from the Conceptual Design and the Design Specification. At the Master Project Plan Complete interim milestone, the tasks for each individual role have been identified and plans have been established for executing these tasks.
There are deliverables that exactly mirror these interim milestones. A detailed discussion of what is included with these deliverables is provided in the following section.
The Planning Phase has nine main deliverables: Conceptual Design Document, Design Specification, Test Lab Setup, Master Project Schedule, Master Project Plan, Life Cycle Management Plan, Change Control Methodology, Risk Assessment, and Business Manager Approval. Most of these deliverables have distinctly identifiable content elements that could be viewed as subdeliverables. The deliverables should be completed prior to the Project Plan Approved Milestone. However, there is no designated time they need to be started. The general rule is to start when enough information is available.
The Conceptual Design document
The Conceptual Design addresses what needs to be included in the product. While it should be non-technical, it should be detailed regarding the new functionality in the proposed solution, how the existing technology infrastructure will react to the introduction of this functionality, how the solution will interact with the user, and what is included in the performance criteria.
Vision/Scope summary. A summary of the Vision/Scope document is agreed upon and refined. It may be useful to provide a brief restatement of the driving Vision/Scope.
Conceptual and logical design. The design goals and constraints in this design depend on the existing environment and the user operations and place the system in a business context
Design goals, usability goals, constraints, and expectations. This list of key design goals is what Development uses as they make implement decisions. The Testing team will verify these goals as part of the validation process. It includes dependencies on other projects and only the constraints that are external to the application requirements.
Field surveys. Field surveys help to ensure that the project team has an accurate depiction of the current environment of the stakeholders and provide input regarding what they expect from the solution. The more detailed the surveys are, the more useful they will be for developing the user profiles and usage scenarios. The surveys should inquire about as many functions as possible that are associated with the project including usage patterns, level of training, hardware and software configurations, network topology, operating environment, hours of operation, physical location, accessibility issues, and security constraints.
User profiles and usage scenarios. These leverage the processes that were delineated in the user profile contribution to the Vision/Scope document in the Vision/Scope Approved milestone, except the previous profile focused on the as-is configuration. In the Planning Phase, the focus is placed on determining the to-be configuration and quantifying the differences between the as-is and the to-be configurations.
The design specification
The Design Specification describes how to implement the "what" defined in the Conceptual Design Document and includes two major subdeliverables: the technical specification and the security plan. The technical specification includes four content elements: the logical and physical design, standards and guidelines, change control methodology, and the life cycle management plan.
Standards and guidelines
Standards and guidelines serve to ensure that the proposed solution facilitates the communication, integration, and consistency of information between and within elements of the organization-and between the organization and external resources needed for business processes
Standards are a detailed set of specifications, processes, methods, rules, or approaches that define the properties of a discreet component of the infrastructure. The level of detail within a standard facilitates the replication of the component elsewhere by using the standard as a template. The explicit nature of the standard also provides the basis for establishing varying levels of integration between dissimilar components. The standard can be formal (that is, approved by a recognized group and adopted over time) or it can be informal (that is, something that is widely used and accepted), thus becoming a de facto standard over time. Either way, standards can be used to establish uniformity within the infrastructure.
Guidelines are a statement of policy or procedure by a person or group having authority over an activity. Unlike a standard, a guideline deals with rules for conduct or activities within the organization, not discreet component properties. Guidelines can be detailed; for example, security policies or naming conventions may need to be extremely granular. On the other hand, they can also be general in nature. As with standards, guidelines can be used to establish uniformity within the infrastructure.
Standards and guidelines:
The change control methodology
Similar to the reasoning behind the Vision/Scope Document, the project team must determine the who, what, when, where, why, and how of proposed changes. The team must be able to assess the risk and impact of the change and should have a mechanism for tracking the changes that have been implemented. The controls introduced by the methodology help the team to effectively direct its change-related activities, avoiding costly errors while maintaining acceptable quality levels.
The change control methodology provides a framework for:
Change control elements
Change management is essential to the Process Model. Whether it is change control of the deliverables, target systems, or technology to be implemented, change control must:
Be a consistent and well-defined process. The process of submitting, evaluating, recording, and maintaining records of changes must be consistent throughout the project. It may be tailored to the individual needs of the project to allow for peculiarities, but the process must remain consistent throughout the life of the project.
Be a reliable and consistent communications mechanism, easily accessible by all parties. The mechanism used to submit, distribute, and post changes must be common and usable by all parties involved in the project. Remote access to databases or e-mail services must be established for remote team members or customers. The nature and criticality of the project must determine the need for real-time access or reporting. Real-time access is not a substitute for reliability.
Contain simple, well-defined, and easily communicated procedures. Simplicity in procedure allows for consistency and easy communications. If the process or procedure for submitting, recording, implementing, or reporting changes to any aspect of the project is not clearly understood by all parties, errors may occur by omission or in translation of information.
Have common format and context. All elements of the change control process and mechanism must reflect commonality on form and format in order to maintain consistency in interpretation and minimize risk.
Use identifiable change criteria. Poorly defined change criteria presents two major risks:
Changes being made outside of the change management process because they were deemed not to require change management.
Changes that do not need to be tracked, creating a load on the management process so that it created an impact.
The technology life cycle management plan
Technology management is a cycle; it does not begin or end with a successful deployment. With this in mind, the impact from and on technology life cycle management must be considered as part of the project planning process. The Technology Life Cycle Management Plan considers the rapid evolution of individual and aggregate technologies, together with dynamic organizational factors. It provides a management framework that encompasses the entire cycle, from the strategic planning stage through the disposition of technology and back to the planning stage again. In addition, it encourages the concept of planning while building. The SDD process is applied to each node of this life cycle. This enables organizations to maximize the business value they derive from their technology infrastructures.
The security plan
The Security Plan helps to ensure that access to data, resources, and services are constrained to the guidelines defined in the scope. The plan also ensures that the value of the solution is not diminished due to misuse of the new technology. The Security Plan is critical to the overall project success. The impact of a security breach could vary from negligible to catastrophic depending on the circumstances.
The integrity of the solution can be affected in several ways.
Loss. Data is considered lost when it is permanently destroyed or rendered unusable-for example, deleting or writing over data that is not backed up.
Denial of access. Access to data is considered denied when an authorized user cannot obtain the needed resource when it is required-such as loss of network connection during critical processing.
Compromise. Data compromise occurs when access to data, resources, or services is provided to unauthorized persons either intentionally or accidentally-such as confidential salary information being provided to coworkers or non-employees.
The Security Plan provides a medium-level guide to the actions that will be taken to:
The security plan also describes::
While the goal of the Security Plan is to eliminate the chance of loss, denial of access, or compromise of data, resources, or services, it is unreasonable to expect any plan to be foolproof. It is very common to overlook the need for security or to fail to consider security of the data early in project planning. It is equally as common to perform over-kill and levy strict security requirements that risk success of the project.
Using acceptable risk, the Security Plan will be written to the following assumptions:
Three-step approach
A rational approach to meeting security needs while maintaining project efficiency using acceptable risk is to build a Security Plan using a three-step approach. This approach provides needed flexibility while protecting against severe losses. The main elements of this approach are:
Early warning. Providing sufficient monitoring capabilities, redundancy, and in-process checks to give early detection to real or suspected security problems.
Rapid response. Having adequately trained personnel and proper diagnostic equipment within easy access to allow a fast, accurate diagnosis and correction of any anomaly.
Full and complete recovery. Being able to restore service or lost data to its pre-loss condition quickly.
The Master Project Schedule
The Master Project Schedule combines all the schedules from the various teams. After Program Management has drafted the Conceptual Design and Design Specification, the team leads map the individual functional components to specific tasks and assign the tasks to the team members. Each team lead is responsible for providing a schedule that their teams can commit to meeting during the development process. The Master Project Schedule has six content elements: the task list, implementation schedule, test schedule, preliminary training estimates, logistics schedule, and marketing schedule.
MSF advocates bottom-up, task-level estimating. Those who perform the tasks provide the estimate for how long it will take them to complete the tasks. These estimates are rolled into the project plan, and the Master Project Schedule is built based on them.
Scheduling guidelines
The Master Project Plan
The Master Project Plan is a collection of plans from the various roles. The Development lead maps out tasks based on the Conceptual Design and Design Specification and groups the tasks into major interim releases.
The Master Project Plan contains the approach, dependencies, and assumptions included in the following plans:
Implementation plan. This plan includes a list of functional improvements and describes how they will be staged during implementation.
Test plan. This plan includes a testing strategy, a list of the specific areas to be tested, and information on the resources (both hardware and people) required to execute the testing.
User education plan. This plan includes a performance support strategy document that outlines the types of solutions required to satisfy user performance requirements given the introduction of the new system. This document includes relevant needs assessment data, a purpose statement, performance objectives and outcomes, audience description, solution strategy (training and/or non-training), media, and evaluation strategy. It provides the basis for the formal Training Plan, which is completed during the Developing Phase.
Logistics plan. This plan includes a strategy for interfacing with other information systems and line-of-business departments.
Solution marketing plan. This plan includes marketing strategy and proposed promotion activities for the user community.
Budget. This plan contains the budget and costing information in the Master Project Plan.
Test lab setup
The Test Lab Setup deliverable serves to ensure that an appropriate isolated environment has been established to simulate and test the functionality encompassed by the proposed solution. The lab setup has been completed when everything that is required to conduct the isolated testing, as defined in the Conceptual Design Document and the Design Specification, is in place. This is critical because it is a prerequisite for the proof-of-concept and the pilot, which will be conducted later in the project.
Each role on the team has a defined responsibility. Not all the responsibilities are necessary at each interim milestone, but all are needed at some point during the Planning Phase of the project. All roles contribute to final review of the Project Plan, and provide input for risk mitigation.
Product Management contributes user data and analysis ensures user expectations are met in product design, and creates the Product Management plan and schedule. Program Management designs the technical solution, and creates the Program Management plan and schedule. Development evaluates technical options, creates the physical design, and creates the Development plan and schedule. User Education determines user needs, designs user performance strategy, and creates the User Education plan and schedule. Testing evaluates the design, and creates the Testing plan and schedule. Logistics Management plans for material procurement, and coordinates the facilities plan/design.
The individual roles have different concerns relative to the project:
The Customer recognizes the business benefits to be delivered and agrees with the delivery time frame.
Product Management believes that the Functional Specification/Design Specification reflect a system that, once delivered, will meet known requirements. The customer is willing to accept schedules and resource estimates based on the scope specified in the deliverables for the Planning Phase.
Program Management believes it is clear who is responsible for each specified function and that the committed schedules are realistic.
Development has sufficiently investigated implementation risk throughout the specification-building process and believes the risks associated with the project plan are manageable. It is willing to commit to schedules based on the state of the Planning Phase deliverables at this time.
Testing has a defined strategy for the test lab.
User Education has a clear idea of who the users are and how the solution will be implemented, used, and supported. This team commits to developing a training plan to accommodate all of the known requirements.
Logistics Management has a clear idea of all the organizational, application, and system interfaces and can commit to implementing the system within the constraints defined in the deliverables for the Planning Phase.
Even though the different team roles have different areas of interest, the entire team must buy in to the total solution. The use of consensus here does not mean there has to be total agreement on all aspects of the project. It does infer that the overall level of agreement is sufficient to move on to the next phase. From time to time, it may be necessary for team members to agree to disagree on individual issues in order to progress to the next phase.
Plans are converted into actions in the Developing Phase. The new technology is refined through these actions to form a production-ready solution. The Developing Phase culminates in the Scope Complete/First Use milestone. During this phase, the solution is developed and optimized until it is deemed ready for production use. Support and training facilities are also developed and optimized during the phase. The milestone is reached when there is a consensus that the solution, and the support and training mechanisms are all ready to be deployed.
During the Developing Phase, the members of the project team work toward validating and quality assuring the solution as specified in the Conceptual Design Document, Design Specification, and Project Plans. There are three interim milestones: Lab Testing Complete, Proof of Concept Complete, and Pilot Complete.
Definitions
Since these interim milestones share some of the same qualities, the purpose and structure of the activities leading to each of these points are often confused. With this in mind, the MSF infrastructure process offers the following definitions for the test lab, proof-of-concept, and the pilot.
A test lab is an isolated technology infrastructure environment that has been established to test the functionality encompassed by the proposed solution. The lab tests the theoretical soundness of the solution, identifies viable alternatives when problems are uncovered in the proposed solution, and plans the optimization and capacity of the solution. The lab does not have to mimic the production environment to accomplish this. Once the project has evolved to the proof-of-concept stage, the test lab will remain intact to test enhancements that could be integrated into future technology infrastructure solutions.
The proof-of-concept, like the test lab, is also an isolated infrastructure environment that has been established to test the functionality encompassed by the proposed solution. However, unlike the test lab, the proof-of-concept is designed to represent a mockup of the technology infrastructure that will be implemented in production. This environment should be a separate facility from the test lab, assuming the scope of the project is large enough to justify this expense. The purpose of this setup is to test the theoretical findings from the test lab in a safe, simulated production environment. The intent is to reduce as much of the risk as possible and to identify and resolve as many unknowns as possible.
The pilot extends the activities of the proof-of-concept one step further. The pilot is not conducted in a lab environment; instead, it is a limited rollout of the proposed solution in the production environment. The pilot provides the means to run a final reality check on the solution without exposing the entire organization to danger. It offers a final opportunity to validate all aspects of the solution, training, and deployment mechanisms prior to the full-scale implementation. When these production processes have been tested and approved, the full-scale rollout can commence.
Lab testing complete
The lab setup is completed in the Planning Phase, and testing may well have begun prior to reaching the Project Plan Approved milestone. Regardless, testing must be completed as early as possible during this phase to provide input to, and to allow time for, the proof of concept and pilot, which must also be completed before the Scope Complete/First Use milestone.
An isolated lab environment allows a great deal of flexibility regarding the breadth and depth of the tests conducted because it does not risk the production technology infrastructure. It may be difficult however, to gather all the facilities required to conduct exhaustive testing.
Proof of concept complete
Like the test lab, the proof of concept should be isolated from the production environment. Unlike the test lab, it should strive to be as representative of the production environment as possible. The objective here is not to determine what the new technology can do, but instead to determine how it will react when it is integrated into the existing infrastructure. Potential obstacles and risks are identified and evaluated in the proof-of-concept. The optimization done in this environment maps the technical capabilities to the business value the solution is expected to yield. The proof-of-concept is also where the defects are eliminated, parameters are validated, and documentation is generated.
Eliminating defects
As with software development, it should be the goal of the infrastructure team to deploy without defect. Allowing defects to continue during the life cycle leads to an exponential cost impact. These costs include:
Personnel costs, the resource cost to revisit a number of sites to perform the fix.
Travel costs, which can be substantial depending on the support model used by the organization and the geographical diversity.
Lost opportunity costs, associated with not having the optimum environment for the production environment.
Bandwidth costs, associated with distributing hardware and software.
Validate all parameters
All process parameters should be defined and verified, and then mapped back to the standards and guidelines to ensure they are in compliance. The parameters need to be grouped into two categories:
Static, not changing for any site within the enterprise.
Unique, on a site-by-site basis or a location within the site.
Documentation
The following items should be documented during the process leading to the Proof of Concept Complete interim milestone: All steps in the selected process, the best case alternatives, and the results of the Proof-of-Concept testing. The documentation created during this phase will be utilized in the next phase of the project.
Pilot complete
The pilot takes the testing concept one step further. While it is isolated as much as possible, the pilot is still conducted in a controlled subset of the production environment. It reveals scale-related issues that weren’t uncovered by the previous testing processes. The intent is to maximize the effectiveness of the solution while minimizing the risk to the entire organization. The pilot execution should be treated just as the rollout execution. The best way to think of it as a dress rehearsal for the main event.
Issues to be addressed
The following issues need to be addressed to ensure a successful pilot execution:
Minimize changes. The base functionality is frozen-the only changes introduced are fixes. The premise is that pilot execution is a matter of performing tasks, not discovery. The change management process should be very controlled during this milestone. Ideally, if a hot fix is needed, it should only be used if it eliminates an insurmountable problem, not to improve a process or add functionality.
Process review. The planned process for the pilot should be reviewed for accuracy and thoroughness.
Customer satisfaction. It is imperative to ensure that customer satisfaction is very high during the course of pilot execution. If an issue arises, the team should re-evaluate the plan and processes, looking for potential improvement. Additionally, one of the scenario alternatives may be utilized to resolve an issue.
The Developing Phase includes five deliverables: Pilot Plan, Training Plan, Capacity Plan, Business Continuation Plan, and Rollout Plan. Carefully constructing each of these plans is key to project success.
The Pilot Plan
The purpose of the pilot is to test the solution in a real environment. With this in mind, the pilot needs to include representatives from every user community and usage scenario impacted and to validate the implementation, training, and support plans and procedures that will be used in the production rollout.
Issues addressed at pilot
Proper representation. Based on the information collected in the usage scenarios, select at least one user for each usage scenario. In areas where performance or high volume is a concern, you will want a larger representation that may include even a whole department. Although it is easier if the pilot group is in the same facility, it may not give a realistic representation of production rollout due to slower links.
One-time visit strategy. It should be the intention to visit the pilot only once during the iteration of an infrastructure deployment. However, there will probably be a delta in the infrastructure that will require an update for the pilot group. Although the project goal may be a single successful pilot, the project team should plan to revisit the pilot to test updates and fixes.
User preparedness. It is important to make sure that the members of the pilot group are aware of the infrastructure changes that are about to take place. Additionally, the following issues should be reviewed:
Production simulation. The Pilot Plan should detail all the steps and processes necessary to get through pilot execution.
Support plan. To minimize the impact of problems that may arise, a support plan should be established for the pilot group and escalation procedures should be defined.
Important Note: It may become apparent while reviewing the results of the proof-of-concept testing that the original goal was too ambitious. The original goal for the infrastructure may not have produced stable results. The following are reasons why this may be true:
In this situation, it is necessary to determine whether there is a reasonable compromise that provides the majority of the functionality and benefit that was envisioned. The best-case alternative should contain the stability, maintainability, and supportability that are required by the enterprise.
The Training Plan
The probability of success of any infrastructure project is contingent upon the quality and appropriateness of the training provided to the respective users. While training is not an end product of the project, it is a critical component in determining the positive or negative impact of the solution.
The Training Plan ensures that:
With this in mind, the Training Plan should ensure that the explicit needs of all user segments have been correctly identified and addressed. The data obtained in the user profiles, usage scenarios, and field surveys provide the basis for establishing the training requirements.
To successfully implement a Training Plan, many detailed issues must be addressed. However, some generalizations can be made to assist in the process, such as differentiating the kinds of users that require training. Typically, there will be five groups of people with distinctly different training needs: trainers, implementers, administrators, operations and support personnel, and users.
The training process does not simply teach individuals the mechanics of a solution, but shows them how to extract the greatest advantage possible from the system based on their unique business requirements. To maximize the value of the training process, the following user-related considerations should be addressed:
The pilot is not only an opportunity to test the viability of the infrastructure solution in a limited production environment, it is also an opportunity to test and refine the training processes. Using instruments such as feedback forms and incident reports, trainers can ascertain the effectiveness of their courses and modify the content as necessary. The instructors can also use the pilot to more accurately quantify their resource requirements, such as the length of the classes and conflicts between classes. Thus, by the time the production rollout commences, training can be tuned to address the rigors of the production training process.
The Capacity Plan
Capacity planning and the optimization of infrastructure components are two activities that must be approached cautiously and systematically because the conclusions drawn from these activities can dramatically impact the overall effectiveness of critical business processes.
Capacity planning is the process of mapping the capabilities and limitations of the new technology to existing and anticipated usage patterns. Optimization is the process of improving the performance of the solution relative to the demands on, and constraints of, the system. The objective is to develop a useful, cost-effective solution with potential to grow to meet future requirements.
Accuracy is key for successfully completing these endeavors, yet it is often difficult to obtain precise, pertinent information. The data collected in the user profiles and usage scenarios, field surveys, and standards and guidelines sections will provide a good foundation of useful material. However, an equally significant portion of the information will probably come from ancillary sources such as case studies, data sheets, whitepapers, functional specifications, and so forth.
During the latter stages of capacity planning and optimization, the largest proportion of the information will come from lab tests and the proof of concept. Regardless of where the data comes from, the benefits derived from capacity planning and optimization increase when more is known about the entities and the elements associated with them.
Capacity planning is the process of using information pertaining to the technical capabilities and limitations of a system, together with data related to usage patterns and trends, to forecast the characteristics the system should possess (including size and scope) to accommodate current and future requirements.
Optimization is the act of defining what actions need to be taken to improve system performance relative to the demands on the system. It involves examining the utilization of resources and identifying where potential bottlenecks could surface. It also involves looking for the residual effect of bottlenecks: the under consumption of other resources.
To effectively execute capacity planning and optimization procedures, it is first necessary to divide the elements within the infrastructure into discreet units based on the types of functions they perform. The degree to which the components inside a particular unit can cooperate with one another is a fundamental concern since this directly impacts the potential success of any inter-unit activities. For the purposes of this discussion, eight functional units have been identified. Since some of the elements border on more than one unit, they could be grouped differently. However, the following distribution of elements reflects one common method of grouping components into functional units: data transmission links, local area network architecture, wide area network architecture, protocols and transports, network operating systems, computer hardware, computer software, and domain/site models.
The information needed to effectively plan and optimize components within the infrastructure can vary dramatically depending on the component involved and the setting in which it is being used. Do not automatically assume that the design of one component can be used as a boilerplate for designing similar components in the system. Always verify that the constraints are the same in each situation before taking this approach.
The complexity of the capacity planning and optimization activities is also a concern. Since all of the individual elements in the infrastructure are interrelated in some manner, the planning and optimization processes must consider the impact on all components related to the entity in question as well as the impact on the performance of the entity itself. The ultimate goal should be to engineer components such that the organization as a whole can attain the optimum flexibility, growth, and performance characteristics.
The Business Continuation Plan
The purpose of the Business Continuation Plan is to recover only the elements of the technology that are essential for conducting business, to minimize downtime and loss of revenue. Disaster recovery encompasses business continuation and extends to the restoration of systems to their pre-failure state.
Difference between recovery and restoration. The Business Continuation Plan is an act of recovery. The purpose of a Business Continuation Plan (relative to the project) is to recover the operations and/or services associated with the technology being deployed that are required to keep the business operating above a predetermined level of revenue loss. It is not designed to restore all systems and operations to their pre-failure state. Total restoration is a process that continues long after the Business Continuation Plan is completed.
A practical Business Continuation Plan, designed to recover from an adverse event, is based on the following assumptions:
Load shedding. A well-designed Business Continuation Plan includes a load shedding plan that defines which systems and processes can be sacrificed in order to keep more critical systems running. When resources such as electrical power and temperature control systems are artificially limited due to an emergency situation, non-critical systems will be shut down in order to preserve the function of critical systems.
Fall back. One alternative for recovering critical business operations is to institute procedures that enable the team to fall back the deployed technology to the last-known-good configuration or to a manual backup process. This strategy is not mandatory, but it does provide the project with a good safety net.
The Business Continuation Plan works with the Security Plan to maintain an acceptable level of service during adverse conditions over the full course of the project.
Having a project Business Continuation Plan for every project does not preclude the need for a total, comprehensive recovery plan. A good recovery plan addresses all systems, processes, and their interdependencies.
The Rollout Plan
The Rollout Plan is a step-by-step strategy for effectively deploying the solution to the targeted users with minimal disruption to the organization’s day-to-day activities. It should address the technical design and implementation issues associated with the new technology and incorporate the training, security, procurement, and support plans and procedures discussed earlier. (Many organizations that have rolled out new systems or applications in the past sometimes refer to the Rollout Plan as a deployment or implementation plan.)
The rollout plan will include:
The Rollout Plan assumes the following exist and have been approved for deployment:
Rollout strategy
Successful rollouts get users up and running on the new infrastructure quickly and efficiently with minimum disruption to business operations. The rollout strategy answers three key questions:
Although each situation is different, four common factors will influence how these questions are answered in a particular situation: nature of business operations, organization, existing infrastructure, and tolerance for risk.
The key to a smooth transition is developing the rollout strategy and detailed site plans in a way that builds consensus, active involvement, and ownership of the targeted user community and supporting groups. View the establishment of an effective cross-functional and cross-organizational team as equally important to, if not more important than, the technical detail in any plan.
During the Developing Phase, the entire team is focused on refining the proposed technology infrastructure functionality into a high-quality, effective solution.
When team members become too focused on their own tasks, they tend to go dark; in other words, they work in seclusion and attempt to solve issues on their own. A tremendous amount of risk is associated with this phenomenon. Communication among team members is imperative during the Developing Phase.
The Developing Phase culminates in the Scope Complete/First Use Milestone. At this milestone, the team has validated that the solution has the desired functionality and is stable enough to implement in full-scale production and that the known issues are being managed. This is also where the essential implementation, training, and support plans and procedures are defined.
The next and final phase of the project, the Deploying Phase, is when the solution is implemented in the production environment and the organization begins to receive a return on its investment in the new technology. It is therefore extremely important that the solution be as stable as possible before transitioning to this phase. As always, the team should conduct a milestone review to determine what went right, what went wrong, and why.
The Deploying Phase, which culminates in the Release milestone, is where the solution is actualized. The key points for the Release milestone in a technology infrastructure project are that the solution is fully deployed as defined by the scope of the project, all parties agree that the performance of the solution is consistent with the objectives of the project, and the technology is ready to be handed over to steady-state management. An example of the latter point is when the project team officially hands the technology over to help desk and is no longer involved with problem escalation.
There are four interim milestones in the Deploying Phase: Rollout Begins, Training Complete, Rollout Complete, and Stabilization Complete. Obviously, Rollout Begins must occur prior to Rollout Complete, but otherwise there are no hard-and-fast rules regarding the order in which these interim milestones are reached.
While the Training Plan was formally developed in the Planning Phase, training has been provided on an as-needed basis throughout the project. Similarly, stabilization may have begun as early as the Planning Phase in the test lab. The point here is that all of these interim milestones must be realized before the Release milestone can be reached.
The types of problems encountered at Rollout Complete, and the frequency of their occurrence, may make it inappropriate to transition the support processes to steady-state management. Additional stabilization may be required before this transition can take place (Stabilization Complete). Once the deployed solution has been stabilized and the management responsibilities have been transferred, customer signoff is all that is required before the Release milestone is officially reached.
Rollout begins
This interim milestone is where the project transitions from plan to reality. The risks are higher because the number of unknowns increases, while the safety net is simultaneously removed. With the additional risk comes a reward: the business starts to realize some incremental benefits from the solution since it is now being deployed in a production environment.
The pilot group is usually one of the first sets of users to be deployed. The training, procurement, security, and support plans and procedures are put into action at this point. It is important to note that the project team supports the solution until it is stabilized.
Site preparation
Site preparation is a large part of the role Logistics Management plays during this phase of the process. Logistics Management ensures that the site(s) are ready and suitable for setup and installation of the physical components. The Logistics Management role is critical at this point in the project. Failure to properly prepare sites for new technology introduction can have a negative effect on how the user/customer perceives the value of the solution. Pay close attention to these activities.
Rollout
The objective of the rollout is to deploy the technology solution to the users targeted by the scope. Because even the best plans sometimes go awry, Development manages the rollout plan and adjusts it to accommodate any variances that may occur. Logistics Management procures the material and implements the solution. The implementation responsibilities include setup of the operations and help desk mechanisms needed to provide long-term support after the Release milestone has been reached.
Cross-role communications and cooperation are key during the rollout. Identify and eliminate any barriers that might hinder intra-team activities.
Testing
Some technologies will react differently in full production implementation than they did in the test lab, the proof-of-concept, or the pilot due to environmental and utilization factors that are difficult to predict or control. As a result, Testing tends to focus more on issues that are manifested in production, as opposed to the isolated test environment. Their goal is to reduce the number of existing and new problems and to optimize the performance of the solution.
Testing also begins to explore enhancements that may have a bearing on future releases of the solution, but do not directly impact the current project.
Training complete
Training may start as early as the Vision/Scope stage. However, all training related to the project must be concluded before the Release milestone. As mentioned earlier in this module, some training will have been completed prior to the Deploying Phase for most technology infrastructure deployment projects. However, it is imperative that training be completed during this phase.
The quality of training will impact the actual and perceived performance of the solution, the cost and speed of the implementation, and the business value derived from the technology. Training needs to cover each of the five groups of people with distinctly different needs: trainers, implementers, administrators, operations and support personnel, and users.
A certain level of follow-up training is required throughout the life cycle of the solution-however, this requirement is handled by the organization’s steady-state maintenance mechanisms, not the MSF project team.
Rollout complete
At the Rollout Complete interim milestone, the proposed solution has been deployed to all of the targeted users. The technology is functional, but may, or may not be stable. If anomalies still exist at Rollout Complete that preclude transition to steady-state management, the stabilization process should be continued until the solution is in a condition that is manageable by the production mechanisms.
Stabilization complete
The final key to a successful rollout is to include a stabilization period and some formal acceptance criteria for each logical group of users moving to the new infrastructure technology. The stabilization period allows time for monitoring and support to ensure a smooth transition and to provide a means of collecting feedback on the problems that are encountered.
The goal of the stabilization process is to identify and resolve as many issues as possible to minimize the number of recurring problems. Formalized user acceptance criteria help to ensure that the user community and their management formally acknowledge that the new infrastructure services are meeting or exceeding previously agreed-upon service levels. This information can then be used to ascertain the progress of the rollout. The Release milestone is reached when the stability of the solution conforms to standard production maintenance requirements. Maintenance is considered to be the point when the technology is acting in a predictable and expected fashion. When this level of stability has been achieved, solution maintenance can be handed off to the production support mechanisms. At this point, the groups maintaining the technology (operations, help desk, and so on) will be dealing with routine failures and administration.
Although it could be argued that completion of the deployment of the technology solution is a deliverable, that would not be very useful since the entire project has been centered on deployment. However, two deliverable have been identified that important relative to the Release milestone: Post-Rollout Baselining of User Profiles and Usage Scenarios, and Project Review.
Post-rollout baselining of user profiles and usage scenarios
In the Envisioning Phase, the user profile was used to define the as-is technology infrastructure environment. This information was then used in the Planning Phase as a basis to project the to-be, post-solution implementation environment. In the Deploying Phase, the project team needs to determine precisely how the projected “to-be” compares with the final solution. This information will then serve as a solid basis for future technology implementations.
Project review
The project review should cover the events that occurred during the Deploying Phase and should compile the information from the interim milestone reviews as well. The focus should be on the problems encountered (what went wrong and what went right) to determine the relationship between the actions taken by the team and those successes and failures. This information will be used to form best practices for future projects.
During the Deploying Phase, the team members focus on deploying the new technology to all of the targeted users, stabilizing the solution and transitioning the support to a standard production mechanism.
Product management
Program management
Development
User education
Testing
Logistics management
All team roles
In the MSF Process Model, the responsibility for quality rests with every member of the team. Responsibility for quality in the release cannot be delegated to a single team or team member. Release of the technology solution is the result of agreement between the leads or managers of each functional team and management and support organizations that the solution is ready for transfer to the infrastructure management team. Not only does the team decide, but the customer should have a say in this decision as well.
The solution is ready for release when:
Where the customer has been involved throughout the process, especially at major milestones and during the deployment, they should be prepared for signing off on the solution.
Conducting project reviews
At each interim milestone, the results of the interim milestone reviews are recorded. This information is now added to the final project review document. As the release to operations date gets closer, ask each team member to consider the milestone review issues. Solicit feedback by sending out evaluation forms to the customer and users.
The Project Review is best done at an off-site location. The focus should be on what could be improved instead of who did something wrong. A professional facilitator can be used to lead an objective and focused discussion.
In addition to documenting the review, the team should generate a list of action items for the next project. These action items are best recorded in the Project Plans for the next technology implementation. Wherever possible, metrics should be devised to measure the effectiveness of these new strategies.