In the MSF process model, a baseline is a measurement or known state by which something is measured or compared. Establishing baselines is a recurring theme in MSF. Source code, server configurations, schedules, specifications, user manuals, and budgets are just some examples of deliverables that are baselined in MSF. Without baselines, it is impossible to manage change.
Scope is the sum of deliverables and services to be provided in the project. The scope defines what must be done to support the shared vision. It integrates the shared vision, mapped against reality, and reflects what the customer deems essential for success of the release. As a part of defining the scope, less urgent functionality is moved to future projects.
The benefits of defining the scope are:
| • | Dividing a long-term vision into achievable chunks. |
| • | Defining the features that will be in each release. |
| • | Allowing flexibility for change. |
| • | Providing a baseline for trade-offs. |
The scope of a solution's features must be defined and managed as well as the scope of work and services being provided by the project team.
The term "scope" has two aspects: the solution scope and the project scope. While there is a correlation between these two, they are not the same. Understanding this distinction helps teams manage the schedule and cost of their projects.
The solution scope describes the solution's features and the deliverables, including non-code deliverables. A feature is a desirable or notable aspect of an application or piece of hardware. For example, the ability to preview before printing is a feature of a word processing application; the ability to encrypt e-mail messages before sending is a feature of a messaging application. The accompanying user manual, online Help files, operations guides, and training are also features of the overall solution.
The project scope describes the work to be performed by the team in order to deliver each item described in the solution scope. Some organizations define project scope as a statement of work (SOW) to be performed.
Clarifying the project scope includes the following benefits:
| • | Focuses the team on identifying what work must be done. |
| • | Facilitates breaking down large, vague tasks into smaller, understandable ones. |
| • | Identifies specific project work that is not clearly associated with any specific feature, such as preparing status reports. |
| • | Facilitates subdividing the work among subcontractors or partners on the team. |
| • | Clarifies those parts of the solution that the team is responsible for as well as the ones for which it is not responsible. |
| • | Ensures that all parts of the solution have a clear owner responsible for building or maintaining it. For large solutions especially, features are part of the solution, but not part of the project team's deliverables. For example, a team may be building a corporate procurement solution that interacts with a company's enterprise resource management (ERP) system. The integration is part of the overall solution scope, but not necessarily part of the project scope for that team. |
Managing scope is critical for project success. Many IT projects fail, are completed late or go dramatically over-budget due to poorly managed scope. Managing scope includes clarifying the scope early and good project tracking and change control.
Due to the inherent uncertainty and risk involved with IT projects, making effective trade-offs is key to success.
In projects, there is a well-known relationship between the project variables of resources (people and money), schedule (time), and features (scope). These variables exist in a triangular relationship as shown in Figure 5.
After you have established the triangle, any change to one of its sides requires a correction on one or both of the other sides to maintain project balance. This includes, potentially, the same side on which the change first occurred.
The key to deploying a solution that matches the customer's needs when they need it is to find the right balance between resources, deployment date, and features.
Customers are sometimes reluctant to cut favorite features. The tradeoff triangle helps to explain the constraints and present tradeoff options.
Figure 5: Tradeoff Triangle
Features have a fixed level of quality that is presumed to be non-negotiable. You can view quality as a fourth dimension which would transform the triangle into a tetrahedron (or three-sided pyramid). Although lowering the quality bar results in simultaneously reducing resources, shortening schedule, and increasing features, it is obviously a recipe for failure.
Another powerful tool to manage tradeoffs is the project tradeoff matrix, shown in Figure 6. This is an agreement between the team and customer, made early in the project, regarding the default priorities when making tradeoff decisions. There can be exceptions to the default priorities, if necessary. But the main benefit of establishing default priorities is to help make the tradeoffs less contentious.
Figure 6 shows the typical tradeoff matrix used by Microsoft product teams. This matrix helps identify project constraints that are essentially unchangeable (represented by the Fixed column), constraints that are desired priorities (represented by the Chosen column), and constraints (represented by the Adjustable column) that can be adjusted to accommodate those constraints that are Fixed and Chosen.
Features are not cut casually. Both the team and the customer must review all project constraints carefully and be prepared to make difficult choices.
To understand how the tradeoff matrix works, resource, schedule, and feature variables can be inserted in the blanks of the following sentence:
Given fixed ____________, we will choose a ___________ and adjust ___________ as necessary.
Logical sentence possibilities are:
| • | Given fixed resources, we will choose a schedule and adjust the feature set as necessary. |
| • | Given fixed resources, we will choose a feature set and adjust the schedule as necessary. |
| • | Given a fixed feature set, we will choose a level of resources and adjust schedule as necessary. |
| • | Given a fixed feature set, we will choose a schedule and adjust resources as necessary. |
| • | Given a fixed schedule, we will choose a level of resources and adjust the features set as necessary. |
| • | Given a fixed schedule, we will choose a feature set and adjust resources as necessary. |
It is essential that the team and the customer are completely clear on the tradeoff matrix for the project.