The goal of the Planning Phase is to reach the Project Plan Approved Milestone, which is the culmination of the team's work during this phase and signifies agreement between the customer and the team on critical project issues.
Four deliverables are required to meet the Project Plan Approved Milestone. They are:
We also recommend including proof-of-concept systems to demonstrate and validate the team's design choices.
NOTE
The goal of any deliverable is to serve as an efficient communication tool. In this context, a deliverable does not necessarily result in a paper artifact. A deliverable can take whatever form is appropriate (a document, a diagram, an application, a screen shot, e-mail, and so on) so long as it facilitates communication.
Every major milestone in the MSF Development Process Model signifies an agreement between the customer, the project team, and any other key project stakeholders. Reaching the Project Plan Approved Milestone indicates agreement on the points listed in Table 6.7.
Table 6.7 Agreement achieved by the Project Plan Approved Milestone
Point of agreement | Documented in |
---|---|
What to build to meet the business needs | Functional Specification |
What features have priority | Functional Specification |
How long it will take to complete the project | Master Project Schedule |
How to build the product and who will build it | Master Project Plan |
Risks of building the product | Revised Master Risk Assessment Document |
Milestones and deliverables | Master Project Plan |
The Project Plan Approved Milestone also provides an opportunity for the customer and the project team to decide whether to proceed with the project. After reviewing the deliverables from the Planning Phase, the customer or the project team may decide that the product does not provide enough benefits to justify its costs. This decision represents a critical point in the project and is one of the reasons why the Planning Phase is so significant. A well-executed Planning Phase enables the team and the customer to proceed with confidence, knowing that the necessary up-front work has been done to maximize the chances for success.
To break the Planning Phase into manageable chunks, interim milestones can be set throughout the phase. Because the plans and schedules are developed by the various team roles based on the Functional Specification, it makes sense to create a draft version of the specification first. Team members can then create draft versions of their own plans and schedules, which can be "rolled up" into an overall master version. The team will probably revise and expand these draft documents as it moves through both the design process and the Planning Phase.
The Functional Specification is the primary deliverable of the Planning Phase. It is a detailed set of specifications for the product, and serves as a contract between the customer and the project team. It is not an exaggeration to say that all the work of the project team to this point has been leading up to the Functional Specification, and all subsequent work of the team will flow from and be based on it. Out of the Functional Specification flow the remaining deliverables for the Planning Phase: the Master Project Plan, the Master Project Schedule, and the revised Master Risk Assessment Document.
Program Management is the owner of the Functional Specification and is responsible for its ultimate completion. This is not to say that Program Management must write the entire document. Indeed, the Functional Specification should reflect the entire team's understanding of the product, and should be based on information contributed by various team members.
As the team creates the Functional Specification, certain pitfalls should be avoided, including:
Although most of these pitfalls seem obvious, many teams find them easy to overlook. The team might want to post them in a prominent place while it develops the project's Functional Specification.
The Functional Specification should contain all the items or sections listed in Table 6.8. The project team may decide to include additional items in the document to suit the demands of a particular application development project.
Table 6.8 Key components of the Functional Specification
Item | Description |
---|---|
Vision summary | What the team wants the product to be, justification for it, and key high-level constraints. Based on the vision document from the Envisioning Phase. |
Design goals | What the team wants to achieve with the product. Development will use these goals to make decisions on such issues as performance, reliability, timeliness, and possibly usability and accessi- bility. These goals were originally developed during the Envisioning Phase. |
Requirements | What the customer, users, and stakeholders think the product must do. The requirements should be prioritized. Conflicting requirements should either be resolved or balanced in some way. |
Usage summary | When the product will be used and who will use it. This is a high-level aggregation of the usage scenarios that were defined during the design process. |
Features | What exactly the product does. A prioritized list of each of the product features, including such things as potential user interface, application navigation, and detailed functionality. |
Dependencies | What the product depends on. A description of external entities upon which the product might depend, including both high-level issues (such as interfacing to corporate systems) and low-level issues (such as a shared component). |
Schedule summary | What the schedule is. A summary of the Master Project Schedule, identifying key interim milestones, deliverables, and the product ship date. |
Risks | What the risks are. A list of risks that require external visibility or escalation. |
Appendixes | What remains. A collection of the design process output that the team used to develop the Functional Specification. |
An important step in developing the Functional Specification is its review by the project team. The Functional Specification review:
The primary purpose of reviews of the Functional Specification is to get the input of all the team roles. If all team roles participate in these reviews, the specification will describe a much better product that will meet the needs of each of the roles. Holding reviews is one way to ensure that team members actually read the document.
Note the use of "reviews" (plural) in the preceding paragraph. Because one of the interim deliverables noted earlier is the draft Functional Specification, the Planning Phase should include at least two reviews of the Functional Specification. Ideally, the Functional Specification will be reviewed and updated regularly throughout the Planning Phase.
The goal at the end of the Functional Specification process is consensus. Everyone directly involved with the project—the project team, the customer, and any other key stakeholders—should concur that the Functional Specification accurately and adequately documents their expectations of the product. Specifically, the customer and each team role should agree with the items shown in Table 6.9.
Table 6.9 Agreements required for the Functional Specification
Role | Agrees that |
---|---|
Customer | Solution meets business needs. The customer is willing to accept development schedules and resource estimates based on the scope specified in the Functional Specification. |
Product Management | Solution meets known requirements. Product Management believes the Functional Specification reflects a product that will meet known requirements when delivered. |
Program Management | Team responsibilities and schedules are realistic. Program Management believes that it is clear who is responsible for each specified function and that the committed schedules are realistic. |
Development | Solution is implementable. Development has sufficiently investigated development risks throughout the Planning Phase and believes the risk in meeting delivery dates is manageable. Development is willing to commit to schedules based on the state of the Functional Specification at this time. |
Testing | Solution is testable and can be stabilized. Testing has a defined strategy for test platforms, scripts, and data and commits to testing all aspects of the Functional Specification. |
User Education | Solution is usable, and user support needs are defined. User Education has a clear idea of who the users are and how the product will be used and supported. It commits to developing the user support systems outlined in the Functional Specification. |
Logistics Management | Solution is supportable and deployable. Logistics Management has a clear idea of all the organizational, application, and system interfaces and can commit to deploying the system. |
All roles | Everyone agrees to the ship date. |
The Master Project Plan tells how the product will be built by gathering detailed plans from members of the project team. The team then uses this collection of more detailed deliverables to synchronize its work throughout the remainder of the project.
The purpose of a Master Project Plan is to:
The overall owner of the Master Project Plan is Program Management, because this role is the primary coordinator of planning and process for the project. However, each role on the team is responsible for developing and maintaining its own realistic project plan within the overall plan.
The Master Project Plan should include the items listed in Table 6.10.
Table 6.10 Components of the Master Project Plan
Plan | Description |
---|---|
Development | Tells how Development will build what s described in the Functional Specification. It describes such things as tools, methodologies, best practices, sequences of events, and test methods. |
Test | Includes a testing strategy, the specific areas to be tested, and the resources (hardware and people) Testing will require to do its job. |
Training | Includes a strategy and a plan for developing any necessary training materials. |
User support | Includes a strategy and details for developing anything that users will need for performance, such as wizards and user manuals. |
Communications | Includes a marketing strategy and promotional activities for users. |
Deployment | Includes a strategy and a detailed plan for preparing end users and operations personnel before and during deployment. |
NOTE
The Master Project Plan is not typically used for direct project management, because it is too cumbersome and at too high a level. Instead, each team role should manage its responsibilities according to its own project plans and merely synchronize any necessary changes with the Master Project Plan.
We are discussing the Master Project Schedule as the third deliverable because it's important for both the customer and the project team to understand that the schedule comes after the Functional Specification and the Master Project Plan. The team can't prepare the schedule until it knows what the feature set is and how the team plans to deliver those features.
This is not to say that these three deliverables fall like dominoes. This process can be, and often should be, iterative. The team prepares the feature set, then the project plan, and finally the schedule, and then realizes that the current feature set will push the ship date too far into the future. So the team revises the Functional Specification, revises the Master Project Plan, and revises the Master Project Schedule, iterating through these steps until all three are acceptable.
The point to remember is that while it is legitimate for the team to include the ship date in its planning, it's not good management practice to prepare the schedule first and then try to fit the Master Project Plan and Functional Specification into it. The schedule must flow out of the other two deliverables. The original ship date identified in the Envisioning Phase acts as a design guideline.
The owner of the Master Project Schedule is Program Management, but Program Management does not prepare the schedule as much as consolidate the more detailed schedules prepared by each of the other team roles. Program Management uses this aggregated version of those lower-level schedules as an overall project schedule.
Of all the schedules in the Master Project Schedule, the development schedule is the most crucial. All the other schedules will be based on it.
The Master Project Schedule includes:
Although covered throughout the book, we have summarized these MSF-based principles for project scheduling here for easy reference. As the team develops plans and schedules, it should keep certain principles of scheduling in mind. These four principles from the MSF Risk Management Model will help build schedules that are realistic and attainable.
Bottom-Up Scheduling
The people who will do the work should also plan the work. Their task-level estimates should be rolled up into the Master Project Schedule. This principle not only increases the accuracy of the estimate, but also fosters team acceptance of the schedule.
Fixed Ship-Date Mindset
Fixing the ship date eliminates easy excuses and limits tradeoff decisions to resources and features. It's a way of heightening the importance of shipping on time. It also drives the engineering decisions about what will be built and to what extent. Note that a fixed ship-date mindset means realistically setting a ship date, not arbitrarily setting one. Achieving a fixed ship date requires using the other three scheduling principles.
Risk-Driven Scheduling
Risk-driven scheduling essentially means doing the most difficult and most risk-laden tasks first. There are several significant advantages to this approach:
Obviously, for the team to practice risk-driven scheduling, it must be prioritizing risks through some sort of risk management.
Scheduling for an Uncertain Future
Scheduling something uncertain seems like a contradiction in terms. The point of this principle is that, because the future is uncertain, the team must create schedules that are designed to adjust to the unexpected. The three methods illustrated in Figure 6.13 can help create such schedules.
Figure 6.13 Methods of scheduling for an uncertain future
By the end of the Planning Phase, the team should have a much clearer picture of the risks associated with the project, and also of their relative impact and priority. This revision of the Master Risk Assessment Document should reflect increased insight into these risks.
Again, Program Management is the owner of this document and is responsible for ensuring that the revision is complete and accurate. The revised Master Risk Assessment Document represents a collection of more detailed risk assessments from the various team members. The team can use this aggregated version of those lower-level assessments to get an overall view of risks.
This document helps synchronize risk assessments across the team. It also drives the team's decisions about risks and aids in prioritization of risk-management effort. Risk management is still handled by the individual team roles responsible for the given risk, because it is difficult to manage risks from the level of the Master Risk Assessment Document.