Project Plan Approved Milestone and Its Deliverables

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:

  • A Functional Specification, which outlines the product being developed and the needs it will meet.
  • A Master Project Plan, which shows how the team plans to execute the project and includes any subsequent milestones and deliverables the team intends to meet.
  • A Master Project Schedule, which outlines the time required for each subsequent milestone and deliverable.
  • A revised Master Risk Assessment Document, which identifies possible risks to the project and outlines how the team plans to deal with each one.

We also recommend including proof-of-concept systems to demonstrate and validate the team's design choices.

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.

Interim Milestones

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.

Functional Specification

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:

  • Failing to provide enough detail.
  • Providing too much detail.
  • Creating an unrealistic design.
  • Freezing the Functional Specification too early.
  • Spending too much time updating the Functional Specification.
  • Failing to communicate changes in the Functional Specification to the customer, project team members, or other key project stakeholders.
  • Failing to involve the whole team in design.

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.

Functional Specification Contents

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.

Functional Specification Review and Consensus

An important step in developing the Functional Specification is its review by the project team. The Functional Specification review:

  • Allows everyone with a stake in the Functional Specification to take part in creating it.
  • Involves a variety of people in making sure that requirements are met.
  • Serves as a method of communicating what is going to be built.
  • Provides a forum for negotiating and for achieving buy-in.

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.

Master Project Plan

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:

  • Consolidate feature team and role work plans.
  • Describe how feature teams and roles will execute their tasks.
  • Synchronize the plans across the team.

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.

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.

Master Project Schedule

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:

  • Development schedule.
  • Product ship dates, both internal and external.
  • Test schedule.
  • Training schedule.
  • User support schedule.
  • Communications schedule.
  • Deployment schedule.

Principles of Scheduling

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:

  • The greatest risks tend to be those with the highest level of unknowns, and addressing them first gives the team more time to work on mitigation where mitigation is feasible.
  • If the team attacks a show-stopping risk early in the project and realizes there is no mitigation, the project can be canceled much earlier, minimizing wasted resources.
  • Working through the process of understanding what's important to the customer and explaining what is most risky to the project helps to manage customer expectations.
  • Mitigating show-stopping risks (those severe enough to end the project) often means developing proof-of-concept systems during the planning process to prove or disprove the probability or impact of those risks.

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.

click to view at full size

Figure 6.13 Methods of scheduling for an uncertain future

  • Add buffer time Program Management adds buffer time to the end of the schedule to accommodate project slippage. Although buffer time is often controversial and disliked by management, it is an essential part of an effective schedule. A project without buffer time is a project set up for failure. The amount of buffer time that Program Management adds to a schedule directly depends on how much confidence Program Management has in team estimates. Bottom-up scheduling determines the internal ship date. Adding buffer time to that date determines the externally communicated ship date. However, buffer time should be owned and managed at the Program Management level, not at the individual resource level, because resources must stay focused on their estimated dates.
  • Use interim development milestones These development milestones are alpha and beta releases within a single project. Breaking projects into smaller pieces provides more indicators that tell the team earlier and more often how the project is progressing. The product will also be more stable, and the schedule will be more predictable. Using practice releases with their own Stabilizing Phases allows the team to practice shipping and also indicates the health of the project.
  • Use discrete tasks The team can keep the project on track by using visible deliverables over short intervals. It is much easier to define and manage short tasks. Also, the shorter the duration of the task, the smaller the margin of error. For example, it would be difficult for a one-week task to slip by six weeks. The team should break down the product functions into associated tasks that are clearly defined, with a beginning and ending point, a single output, and a single owner. Task size should be limited to efforts that require, at most, one to two weeks. Then, each task should be tracked as the project progresses, and schedules should be adjusted accordingly.

Revised Master Risk Assessment Document

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.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182 © 2008-2017.
If you may any questions please contact us: