Chapter 3 - Planning Phase

Article
12/05/2007

Goals for the Planning Phase
Developing the Solution Design and Architecture
Validating the Technology
Creating the Functional Specification for the Solution
Developing the Project Plans
Creating the Project Schedules
Setting Up the Development and Test Environments
Closing the Planning Phase
Key Milestone: Project Plans Approved

Goals for the Planning Phase

Figure 3.1: The Planning Phase of the MSF Process Model

In the Planning Phase, the team defines the solution in detail what to build, how to build it, who will build it, and when it will be built. During this phase the team works through the design process to create the solution architecture and design, writes the functional specification, and prepares work plans, cost estimates, and schedules for the various deliverables.

The Planning Phase culminates in the Project Plans Approved Milestone, indicating that the project team, customer, and key project stakeholders agree on the details of the plans. Plans prepared by team members for areas such as communications, test, and security, are rolled up into a master plan that the program manager coordinates. The team's goal during this phase is to document the solution to a degree that the team can produce and deploy the solution in a timely and cost-effective manner. These documents are considered living documents, meaning they will be updated continuously throughout the Planning Phase.

Diligent work in the Planning Phase, which often involves several iterations of plans and schedules, should mitigate risks and increase chances for success. The team continues to identify all risks throughout the phase, and it addresses new risks as they emerge.

The tasks summarized in Table 3.1 need to be completed during the Planning Phase. This project guide describes the processes and roles required to accomplish them. Detailed information specific to each migration project about each task, especially technical information, is provided in the migration guide for that project.

Table 3.1 Major Planning Phase Tasks and Owners

Major Tasks	Owners
Developing the solution design and architecture The team begins the design process with the solution design and architecture and culminates it with a design document that becomes part of the functional specification.	Development
Validating the technology	Development
Creating the functional specification The team creates a functional specification that describes the solution requirements, the architecture, and the detailed design for all the features.	Program Management
Developing the project plans The team develops a collection of plans that address how the six MSF team roles will perform their tasks. These plans are consolidated into the master project plan. The master project plan is considered a roll-up of all of the plans and, thus, also includes strategic items such as the approach, dependencies, and assumptions for the solution.	Program Management
Creating the project schedules The team creates the master project schedule, which consists of milestone-driven schedules developed by each of the individual team roles when planning their respective activities.	Program Management
Setting up the development and test environments The team creates development and testing environments that are independent of the production environment to develop and test the solution.	Development and Test
Closing the Planning Phase The team completes the approval process for the Project Plans Approved Milestone and documents the results of completing the tasks performed in this phase.	Project team

Team Focus during the Planning Phase

Table 3.2 addresses the tasks described previously, but considers them from the perspective of the team roles. It describes the focus and responsibility areas of each team role during planning.

The primary team role driving the Planning Phase is the Program Management Role.

Table 3.2 Role Cluster Focuses and Responsibilities in Planning Phase

Role Cluster	Focus and Responsibility
Product Management	Conceptual design; business requirements analysis; communications plan
Program Management	Conceptual and logical design; functional specification; master project plan and master project schedule; budget
Development	Technology evaluation; logical and physical design; development plan/schedule; development estimates
User Experience	Usage scenarios/use cases, user requirements, and localization/accessibility requirements; user documentation/training; plan/schedule for usability testing
Test	Design evaluation; testing requirements; test plan/schedule
Release Management	Design evaluation; operations requirements; pilot and deployment plan/schedule

Developing the Solution Design and Architecture

Developing the solution design and architecture begins with a design process, the results of which become the functional specification. The design process prepares the team members for their responsibilities during the Developing Phase by building upon the vision the team developed and business requirements gathered during the Envisioning Phase. The design process gives the team a systematic way to work from abstract concepts down to specific technical detail by developing a conceptual, logical, and physical design for the solution. These are not three separate design processes, but are more properly thought of as three overlapping stages of a design continuum.

Note: As the team moves from gathering requirements to designing the solution to creating detailed functional specifications, it is important to maintain traceability between requirements and solution features. Traceability does not have to be on a one to one basis; in fact, it often is not. There may be features that satisfy more than one requirement, and it may take many features to satisfy a single requirement. But every requirement must be traceable to its solution counterpart. Maintaining traceability serves as one way to check the correctness of design, and to ensure that the design meets the goals and requirements of the solution.

Conceptual Design

The conceptual design depicts the functionality present for each major feature of the solution. For migration projects, the conceptual design is generally identical to that developed for the current version of the application or infrastructure component. It is nonetheless important to articulate that design in the functional specification for the migration project; the actual concept for the current component may have drifted from its initial conception. Even if that conceptual design has remained constant, it serves as a touchstone for subsequent design phases.

For example, conceptual designs illustrate each of the user interface elements that must be included in the solution. The conceptual design captures how the solution will work both for users and administrators. The team considers the needs of all the user profile groups when designing. To do this, they must first develop a strong understanding of the requirements.

This is done by reviewing a series of documents that were developed during the Envisioning Phase:

Business requirements
User requirements
Usage scenarios
Operational requirements
System requirements

The designers incorporate these requirements in terms of descriptions that eventually become part of the functional specification.

Logical Design

Logical design takes each piece of conceptual design and assigns it to a specific logical role within an architecture. For infrastructure projects, the architecture might be a series of block diagrams showing networks, service components, and network connection elements. Application architecture is typically broken down into at least three levels: presentation, business, and data level.

Because this is a migration project, the team should document the existing logical design as well as the logical design of the migrated application or infrastructure component, emphasizing the areas of change. It may be necessary to show how other components outside the scope of the project interact with the subject of the migration.

Physical Design

The physical design of the solution specifies which logical pieces fit into specific physical pieces of architecture. The physical design should include anticipated metrics to assess the performance goals, uptime goals, and milestones of the solution code to be written. For example, the physical design might include metrics for transaction speed performance requirements prior to deployment. Production metrics for the particular deployment scenarios must also be established.

Migration deployment scenarios must do more than describe how the fully migrated technology will exist after the migration is complete. They must also cover how the existing application or infrastructure implementation will be supplanted by the new implementation without violating ongoing service level agreements (SLAs). In other words, the deployment scenarios must show both the desired end-state and the path for getting there from a start point of the current organizational state, in terms of specific deployment activities.

Validating the Technology

Often in parallel to the design process, the team validates the technologies being used in the solution. During technology validation, the team evaluates the products or technologies to ensure that they work according to specifications provided by their vendor and that they will meet the business needs for the specific solution scenario.

Technical Proof of Concept

After validating the technologies, the team then makes an initial pass at creating a model of the technology to be implemented. This is the initial iteration of an effort that later produces a proof of concept, and ultimately the development of the solution itself. This initial proof of concept model often produces both answers and additional questions for the team. This information helps in the risk management process and identifies changes needed to the overall designs that must be incorporated into the specifications.

Baselining the Environment

During this time the team must also conduct an audit, sometimes known as discovery, of the as is production environment in which the solution will operate. Information is collected on server configurations, network, desktop software and all relevant hardware. This baseline allows for the team to account for any changes required or design issues that may cause the solution to be at risk.

This baselining step is critical to the success of a migration project. You must thoroughly understand where your organization is today before you can effectively plan how to move forward.

Interim Milestone: Technology Validation Complete

At this point, the team has confirmed the high-level features and functionality of the technologies planned for use and has sufficiently documented the current environment. The team is comfortable that all issues have been addressed or tracked sufficiently in order to move forward with creating the functional specification.

Creating the Functional Specification for the Solution

The functional specification is the technical description of the solution and represents the contract between the customer and the project team. It is the basis for building project plans and schedules. The Program Management Role takes the lead in creating it, with input from the role leads regarding their areas of responsibility. During the Planning Phase, the functional specification is baselined and placed under change control.

Because it includes all requirements documents and design specifications, the functional specification contains the information required to design the solution. It serves as formal documentation of the design process, and it incorporates the conceptual, logical, and physical designs. Accordingly, high-level design decisions such as server placement and network configuration should be included in the functional specification.

A basic functional specification should include the following:

A summary of the vision/scope document as agreed upon and refined, including background information to place the solution in a business context.
Any additional user and customer requirements beyond those already identified in the vision/scope document.
The solution design.
Specifications of the components that will be part of the solution.

The functional specification must describe, without ambiguity, the complete functionality of the solution under development. Quantitative measurements should be included in the functional specification whenever possible. Quantifying performance or business metrics in a functional specification is significant because the information can be used to drive justifications (in development and operations, for example) for a project. These metrics are as much a part of the specification as any other functional details.

The following items are examples of information that should be included in a functional specification:

Features. The functional specification should document the complete set of planned features for the solution. The features of the solution should be expressed using both words and diagrams, if possible. Quantitative specifications for the solution, such as database capacity, concurrent user capacity, performance metrics, and so on should be clearly stated.
Security requirements. A functional specification should specify the strength of security to be used for things such as transactions, including a description of any encryption standards to be used. A description of the type and location of security systems also should be included.
Legal requirements. Legal requirements must be clearly understood and stated in a functional specification, including what needs to be done to adhere to these requirements (for example, custom code to meet a custom user scenario, governmental requirement, or business policy).
Risk analysis documents. Risk analysis documents should include descriptions of potential impact to the project and mitigation strategies. For example, the risk analysis documents should state what the risk of failing to obtain necessary hardware would be, and provide a mitigation strategy for dealing with this risk.

The following are examples of information that should not be included in a functional specification:

Details of software architecture. Too much detail in a functional specification can overburden a project team with extraneous facts.
Detailed database schema. A high-level description of database details is sufficient to include in a functional specification.
Details about programming languages.

Interim Milestone: Functional Specification Baselined

At this interim milestone, the functional specification is complete enough for customer and stakeholder review. At this point, the team baselines the specification and begins formally tracking changes.

The functional specification is maintained as a detailed description of the various solution components and how the solution will look and operate. The functional specification can be changed only with customer approval.

The functional specification is the basis for building the master project plan and schedule.

Developing the Project Plans

The MSF approach to project planning recommends creating a master project plan, which is a collection of plans that address tasks performed by each of the six team roles. The master project plan is prepared by Program Management, but the individual plans are prepared by various team roles. Common plans are illustrated in the following graphic. The master project plan consolidates the feature team and role plans and guides the project to completion, as defined by the functional specification. It is a key Planning Phase deliverable. MSF templates for the master project plan and the individual plans that comprise it are available at https://www.microsoft.com/technet/itsolutions/msf/default.mspx in the MSF Resource Library.

Figure 3.2: Sample project plans that comprise the master project plan

Note: The master project plan does not include schedules. Schedules are determined and recorded in the master project schedule, which consolidates feature team and role schedules.

Table 3.3 lists the team role that has primary responsibility for creating the various plans a project team might create when planning for development of its solution:

Table 3.3 Project Plans and Driving Team Roles

Project Plan	Driving Team Role
Development plan	Development
Test plan	Test
Budget plan	Program Management
Purchasing and facilities plan	Release Management, Program Management
Usability plan	User Experience
Security plan	Development, Release Management
Deployment plan	Release Management
Communications plan	Product Management
Operations plan	Release Management

A project team should review the various plans and determine which apply to their situation and benefit the projects master project plan. Project sizes vary and not all master project plans would require each sub plan.

The benefit of having a plan that breaks into smaller plans is that it:

Facilitates concurrent planning by various team roles.
Keeps accountability clear because specific roles are responsible for various plans.

The benefit of presenting these plans as one is that it:

Facilitates synchronization into a single schedule.
Facilitates reviews and approvals.
Helps identify gaps and inconsistencies.

Interim Milestone: Master Project Plan Baselined

At this point, the team has rolled-up all initial drafts of the plans required to create estimates for the time required to fulfill these project plans. Adjustments to these documents may be necessary as the project moves forward. It is important, however, to ensure there is enough of a base to provide clarity for schedule estimation prior to the transition into the Developing Phase.

Creating the Project Schedules

Similar to the master project plan, the master project schedule combines and integrates all the schedules from each team lead and includes the release date. The team determines the release date after negotiating the functional specification draft and reviewing the master project plan draft. Often, the team modifies portions of the functional specification and/or master project plan to meet a required release date. Although features, resources, and release date may vary, a fixed release date causes the team to prioritize features, assess risks, and plan adequately.

Any team role may choose to divide its schedule by functional area. For example, if different development sub teams will be working on differing feature sets, each sub team might create its own schedule. Each team lead performs a functional breakdown and prioritization of the roles responsibilities, while team members perform task-level estimating. The length of an individual task should be between a half-day and a week. If the task duration is too short, the overhead in managing the task may be too high. If the task duration is too long, it is difficult to manage the scope of the work.

MSF advocates "bottom-up estimating" to create accurate schedules. Bottom-up estimating means that the person who will do the work predicts how long it will take. Estimates made by those who will do the work are more accurate because the person making the estimates usually has experience executing similar work. Furthermore, people who develop their own work estimates feel more accountable for their work schedules.

MSF also recommends using "risk-driven scheduling" to create project schedules. Risk-driven scheduling means performing the difficult and highest risk tasks first. The greatest risks tend to be those with the highest level of unknowns. Risk-driven scheduling is important because it minimizes wasted effort and allows the greatest amount of reaction time for risk mitigation.

Interim Milestone: Master Project Schedule Baselined

The goal for the release date should now be set. Baselining the project schedule by way of bottom-up task level estimation and early scheduling of riskier items helps each individual contributor have a sense of ownership of the project and heightened awareness of the project's priorities.

Setting Up the Development and Test Environments

The development, testing, and staging environments must be properly set up before moving into the Developing Phase in order to maximize development team productivity and to mitigate risks. In order to avoid delay, the development and testing environments should be set up even as plans are being finalized and reviewed. The MSF Release Management Role is typically responsible for performing these tasks for the project team.

Establishing a development environment entails setting up hardware and other infrastructure resources, as well as any project structure or policy elements that will guide solution development activities. A source code repository must be established and populated with the baseline version of the source code to be modified. The team should install according to the configurations established in the development plans. Policies include those that ensure all members of the development team are using compatible versions of software, integrating their code using a standard method, checking in code changes to the project source code repository, enforcing rules for creating daily builds, and tracking all bugs.

The process of creating the testing environment is centered on setting up the architecture (hardware) according to the configurations established in the test plan, choosing the build process to use, and obtaining approval from the development team in this decision process. Similar to the development environment, the testing environment should be designed to emulate the production environment as closely as possible, but the team must balance the level of representation with the associated costs. Other necessary choices to make for the testing environment include deciding on a common bug-tracking utility and other tools. This is the point in the project where all solution software is installed.

The staging environment is where the team tests content and code being changed or deployed to ensure that they function as expected. The content and code are moved from the development environment to the staging environment before they are published to the production environment. Solution components successfully tested in the development environment may not necessarily work after all elements are in place and have been integrated. The staging environment provides a place to test code with all solution elements to make sure it works before it is put into production.

Hardware and software installed in the staging environment should mimic the production environment as closely as possible. Depending upon the availability of hardware resources, an individual server can perform several different server roles in the staging environment. However, it should be recognized that all deviations from the production environment detract from the representative value of testing, and should therefore be clearly known, understood, and agreed upon and tracked. Ideally, the staging servers are built according to the documented server build procedures that are developed. This ensures that testing accurately portrays what will be seen in production.

Development, testing, and staging environments are functionally separate, but their physical location varies according to the size of the deployment scenario and hardware used for the solution. Separating these environments provides a number of advantages for the team:

Developers can continue to write solution components while testing is under way.
Individuals responsible for operations can participate in creating the development and testing environments and gain valuable experience in deployment while development is still in progress.

Ideally, the staging environment is identical to, but physically separate from, the targeted deployment environment. Typically, duplication of the target environment is prohibited due to expense or unique resource requirements; in these cases, the staging environment attempts to simulate the target environment. The simulation may be assisted through the use of synthetic load generation or other custom or commercial tools. When the staging environment is different from the target environment to a significant degree (typically, in terms of size or capacity), or when project constraints do not support the construction of a staging environment, some testing must occur in the deployment environment. Such testing must be closely coordinated with the operations staff for that environment.

Once the solution has been successfully deployed, it is important to continuously monitor actual performance against projections. A risk mitigation plan should be in place (developed during the Deploying Phase) to resolve potential system failures.

Interim Milestone: Development and Test Environment Set Up

At this point, the team has the necessary settings in place to enable the work of building and stabilizing the solution. With the environment setup completed, the teams can now begin shifting their focus entirely to development work involved in migrating.

Closing the Planning Phase

Closing the Planning Phase requires completing a milestone-approval process, culminating in the Project Plans Approved Milestone. The team must document the results of all of the tasks it has performed during this phase before submitting the project to key stakeholders and customers for approval.

Key Deliverables from the Planning Phase

A deliverables checklist for the Planning Phase includes:

Functional Specification
Master Project Plan
Master Project Schedule
Updated Risk Management documents
Milestone Review Report
- Team Member Project Progress Report
- Team Lead Project Progress Report

Key Milestone: Project Plans Approved

At the Project Plans Approved Milestone, the project team and key project stakeholders agree that interim milestones have been met, due dates are realistic, project roles and responsibilities are defined, and mechanisms are in place for addressing areas of project risk. The team approves the functional specifications, the master project plan, and master project schedule, which then become the project baseline and provide the basis for making future trade-off decisions.

The baseline takes into account the various decisions that are reached by consensus by applying the three project planning variables: resources, schedule, and features. After the baseline is completed and approved, it is placed under change control. This does not mean that all decisions reached in the Planning Phase are final. But it does mean that as work progresses in the Developing Phase, the team should formally review and approve any suggested changes to the baseline by using a change control process.

Project teams usually mark the completion of a milestone with a formal sign-off. Key stakeholders, typically including representatives of each team role and any important customer representatives who are not on the project team, signal their approval of the milestone by signing or initialing a document stating that the milestone is complete. The sign-off document becomes a project deliverable and is archived for future reference.