The Four MSF Phases and Their Major Milestones

Each of the four phases of the MSF Development Process Model concludes with a major milestone. In this overview, we examine each of the phases briefly with the goal of establishing the basic tasks of each phase and their relation to each other. In later chapters, we'll explore the phases in more depth and suggest interim milestones for each one.

Envisioning Phase

The purpose of the Envisioning Phase is to build a shared vision of the project among all the key stakeholders. This vision should include:

• A mutual understanding of the business needs being addressed Many times, developers build an application for a customer (either internal or external), only to discover upon completion that the application solves the wrong problem. This situation arises for a variety of reasons, including poor communication by the customer or poor understanding by the developers. It's critical that the project team members understand the business needs thoroughly before attempting a solution.
• Clearly identified solutions that meet the customer's expectations Developers often deliver a solution and then learn too late that it is not the solution the customer expected. In today's rapidly evolving computing world, customers are more technologically sophisticated than in times past and may have certain solutions in mind before the project begins. Part of the purpose of the Envisioning Phase is to make certain the customer communicates any specific expectations early in the project. As discussed in Chapter 3, this setting and resetting of the customer's expectations is the primary responsibility of Product Management.
• A solid estimation of the project constraints During the Envisioning Phase, the critical project variables—schedule, resources, and features—begin to take shape. In this phase, team members may have only a general idea about these project variables. For example, they may create schedules in terms of quarters or fiscal years instead of weeks or months.

Defining the variables more exactly and establishing their triangulated balance is an iterative process. As analyzing, prototyping, and planning activities proceed, the team may revise the scope because of:

• A better understanding of user requirements.
• A change in business requirements.
• Discovery of technical issues or risks.
• Tradeoffs among the project variables (schedule, resources, and features).

By creating a broad but intuitive view of the project's goals and constraints, the Envisioning Phase begins to define the scope of the project, and sets the stage for the more formal and detailed planning effort that will come later, in the Planning Phase.

Vision Approved Milestone

The Envisioning Phase culminates in the Vision Approved Milestone. This first milestone represents the point at which the project team and the customer agree on the overall direction for the project, including what features and functionality the product will and will not include.

Reaching this milestone meets one of the most fundamental requirements for project success—unifying the project team. The team must have a clear vision of what it wants to accomplish for the customer, and must be able to state that vision in terms that will motivate both the team members and the customer.

The deliverables of the Vision Approved Milestone are:

• A Vision Document.
• A Master Risk Assessment Document.
• A Project Structure Document.

We also recommend that a prototype system be included with the deliverables for this milestone.

As explained earlier, the completion of major milestones results in a synchronization between the customer and the project team, and provides an opportunity for determining whether or not to proceed. Smaller function teams, as described in Chapter 3, must also synchronize with the main project team at major milestones. The Vision Approved Milestone is the first point in the process where the individuals involved may decide that the project does not make sense and should not continue. It is imperative that everyone agrees to move forward at this point in order to prevent misunderstandings later in the project. The creation of application prototypes during the Envisioning Phase can help the team reach a clear understanding of the product vision.

Vision approval signals that members of the project team, the customer, and key stakeholders agree on:

• A broad understanding of the business needs that will be met by the product.
• The vision of the product.
• The design goals for the product.
• The risks that may be incurred by undertaking the project.
• Program Management's initial concept of the business solution.
• How the project should be run and who should be part of the team.

In summary, the true goal of the Envisioning Phase is to create a clear consensus on the product vision between all team members and project stakeholders. Once the product vision is understood, the team and stakeholders can agree and commit to it. Understanding, agreement, and commitment to the vision will place the team in an excellent position to move into the Planning Phase.

Planning Phase

We've all heard the saying "Plan the work, then work the plan." However, daily pressures and deadlines often preempt adequate planning. Proper planning is ensured by following the MSF Development Process Model.

Why is planning so important? For a very simple reason: It costs less to fix design defects early in the development process. Figure 4.6 illustrates the relative costs of fixing design defects during the four phases of the MSF Development Process Model. As the diagram clearly illustrates, early planning pays off in the end, by reducing the cost in time and resources of fixing defects caused by a lack of good planning.

Figure 4.6 Repair cost of design defects by phase

Although some teams risk failure by planning too little, others risk failure by planning too much. It is important to avoid "analysis paralysis." Good planning is necessary, but it's also important to know when to stop planning and move on. As a general rule, the amount of planning necessary for a given project is a function of both its size (lines of code or function points) and the critical nature of the project.

The application's architecture is defined during the Planning Phase. This application architecture, as noted in Chapter 2, is based on the Conceptual, Logical, and Physical Design Models, which we discuss in detail in Chapter 6. Additionally, the modern approach of multi-layer or N-tier architecture provides a solid and scalable product design that can be implemented as a monolithic, client/server, or N-tier application.

Tradeoff Triangle

As we mentioned in our discussion of the Envisioning Phase, every project presents three variables with which the team must work. These three variables—schedule, resources, and features—are illustrated in the tradeoff triangle shown in Figure 4.7. These variables are more clearly defined during the Planning Phase, and by the end of that phase, the team has determined the schedule it will meet, the resources it will use, and the features it will build.

Figure 4.7 Tradeoff triangle

During the Planning Phase, the initial balance of the three tradeoff variables is set. The challenge while moving forward into the Developing Phase is to maintain this balance. We discuss the tradeoff triangle in greater detail later in this chapter.

Project Plan Approved Milestone

The Planning Phase culminates in the Project Plan Approved Milestone, which is the point at which the project team, the customer, and key project stakeholders agree on the project deliverables. This milestone provides an opportunity to establish priorities and set expectations, and serves essentially as a contract between the project team and the customer. Upon completion of this step, the team can move forward to build a solution.

The deliverables at this milestone are:

• The Functional Specification.
• The Master Project Plan.
• The Master Project Schedule.
• An updated Master Risk Assessment Document.

For most projects, another deliverable of this phase might be a proof-of-concept system that helps the team and stakeholders understand the application's architecture. Additionally, any significant design concerns can be tested with the proof-of-concept system before the Project Plan Approved Milestone is reached.

Reaching this milestone means that the project team, the customer, and key project stakeholders agree on:

• What should be built to meet the business needs.
• Prioritization of features.
• How long it should take to complete the project.
• How the product will be built and who will build it.
• The product architecture.
• The risks of building the product.
• The milestones and deliverables along the way.

Developing Phase

By now, some developers will be eager to "crank out some code." As we'll demonstrate in a moment, that's just what the team has been preparing to do in both of the preceding phases. In the Developing Phase, however, the most important task is to build the application.

Part 3 of this book is devoted to the Developing Phase and the various ways and means of approaching it. For now, let's just say that the work of the Developing Phase should be much more straightforward as a result of the work done in the Envisioning and Planning Phases. It's common wisdom that it's much easier to build an application when a clear set of expectations and a properly defined and tested product architecture exists.

Versions, which have been used during the earlier phases, become even more important during the Developing Phase. The team can expect to do multiple versions of the application during this phase. These application versions, which are typically named alpha, beta, and scope-complete release, will be discussed in detail later.

Additionally, all known bugs should have been addressed by this phase. Addressing known bugs does not necessarily imply that all the bugs have been fixed; merely that they have been investigated. The goal of the Developing Phase is to deliver an application that meets all stated expectations and is ready for external testing.

Scope Complete Milestone

The Developing Phase culminates in the Scope Complete Milestone, when all features are complete and the product is ready for external testing and stabilization. This milestone is the opportunity for the customer, users, operations and support personnel, and key stakeholders to evaluate the product and identify any remaining issues that need to be addressed before it ships.

The deliverables of at this milestone are:

• A revised and completed Functional Specification.
• An updated Master Project Plan and Master Project Schedule.
• An updated Master Risk Assessment Document.
• Source code and executables.
• Initial performance support elements.
• A Test Specification and test cases.

At this point in the project, the team should have completed development and functional testing for all the product's features. Additional optimization of feature code can continue, and new bugs can be discovered and addressed, during the Stabilizing Phase.

Reaching this milestone means that the development team will create no new features and that the project team, the customer, and all key stakeholders agree on:

• The fact that the planned feature set has been developed.
• The baseline materials needed to support user performance.
• The fact that development and functional tests have produced a baseline scope-complete release.
• How the product will be tested and deployed throughout the organization, including beta releases and testing.

Stabilizing Phase

Good development teams have known for years that testing should be a major part of any project. Unfortunately, many developers don't adequately test their solutions. They may believe that their code is so good that it needs no testing, or they know that their work was so rushed or ill-conceived that they are afraid of testing it.

Experienced developers realize that software is never error-free. They also know that only good testing procedures can minimize software errors. Experienced developers not only expect testing, they demand it.

CAUTION

---

It is important to properly set the expectations of the user community at the beginning of this phase. Pilot deployments should be designed to identify performance and environment issues. After these issues are addressed in subsequent bug fix releases, the final product will be deployed.

The functionality of the code is tested during the Developing Phase. However, significant performance and environmental testing occurs during the Stabilizing Phase. During this phase, all known issues are resolved before delivery, and any tasks needed for support and ongoing maintenance of the product are completed. This phase seeks to tie up the loose ends. Documentation, release notes, final "bug stomping," product hand-off, and product deployment are all part of this phase.

The Stabilizing Phase starts when the team shifts its focus from code development to stabilizing and shipping the product and ends when the customer accepts the product as complete. A significant aspect of this phase is that the customer and users begin significant testing of the product. This phase is also the training ground for the organization's operations and support teams. During this time, Logistics Management works to ensure a smooth transfer of product support to the organization's internal support groups, with the product release completing the transfer.

Release Milestone

The Release Milestone is reached when the team has addressed all outstanding issues and ships the product, placing it in service. At the Release Milestone, responsibility for ongoing management and support of the product officially transfers from the project team to the operations and support groups.

The deliverables of this milestone are:

• Golden release.
• Release notes.
• Performance support elements.
• Test results and testing tools.
• Source code and executables.
• Project documents.
• Milestone review.

By now, the product is fully operational and ready to ship. The Release Milestone signifies agreement by the project team, the customer, and all key stakeholders on:

• Product stability and resolution of all known bugs.
• Customer acceptance of the product.
• Transfer of ownership for long-term management and support.
• A change in team focus to the next release.

Importance of All Phases

Immature development organizations often minimize the first and last of the four phases of the MSF Development Process Model. Early analysis of the development task noted that two essential steps are common to the development of computer programs: analysis and coding. These steps correspond almost directly to the second and third phases of the MSF Development Process Model: the Planning and Developing Phases.

For a development organization, or any specific project team, to move from an immature state to a mature one, the organization must pay adequate attention to the Envisioning and Stabilizing Phases. Both of these phases feature increased interaction with the customer and others outside the traditional development team. A development team that does not relate to non-developers will never realize its full potential.

One of the advantages of the MSF Development Team Model discussed in Chapter 3 is that certain team roles are responsible for customer and user interaction. Use of that model ensures that the project team cannot gloss over the Envisioning and Stabilizing Phases. Use of the MSF Development Process Model also ensures that interaction with non-developers is approached in a professional and organized manner. The team should be motivated by the simple fact that the success or failure of the project depends on the attention given to each phase, not just to analysis and coding.