Scoping a Solution | Microsoft Solutions Framework Essentials: Building Successful Technology Solutions

Up until this point, the team and stakeholders have brainstormed about what a solution should be. The next step in the life cycle is to start to constrain a solution into something tangible that is able to be delivered within project constraints (i.e., scoping a solution). Scope is the sum of deliverables and services to be provided in a 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 solution releases.

The benefits of defining the scope are the following:

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 term "scope" has two aspects: solution scope and project scope. Although these two correlate, they are not the same. Understanding this distinction helps teams manage the schedule and cost of their projects.

Solution scope describes a solution's features and 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; and the ability to encrypt e-mail messages before sending is a feature of messaging applications. The accompanying user manual, online help files, operations guides, and training are also features of a solution.

Project scope describes the work and services being provided by a project team to deliver each item described in a solution scope. Some organizations define project scope as a statement of work (SOW) to be performed.

Clarifying project scope includes the following benefits:

Focuses a team on identifying what work must be done
Facilitates breaking down large, general tasks into smaller, specific 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 a team
Clarifies those parts of a solution for which the team is responsible (often referred to as in-scope) as well as the ones for which it is not responsible (often referred to as out-of-scope)
Ensures that each aspect of solution delivery clearly has an owner responsible for building or maintaining it, even if the owner is outside of a project team
Identifies assumptions used to define project scope

Managing Project Trade-offs

Lead Advocacy Group: Program Management

Managing scope is critical for project success. Many projects fail, are completed late, or go dramatically overbudget because of poorly managed scope. Managing scope should not be bureaucratic or complex. Rather, it should be as simple as possible while providing the necessary controls to manage changes in scope. Managing scope prevents unapproved features and services from being added to a solution (i.e., scope creep). The best way to avoid scope creep proactively is to make sure a project team thoroughly understands a solution vision and business goals, and make sure they are able to trace critical features they are building back to the requirements.

There are many ways to implement scope management. One easy means to communicate necessary trade-offs when managing scope is to use a trade-off triangle.

Project Trade-off Triangle

Many trade-off paradigms are used to help teams metaphorically visualize balancing solution delivery parameters (e.g., good, fast, or cheap). MSF offers a trade-off paradigm that balances the relationship between project variables of resources (people and money), schedule (time), and features (scope). These variables are expressed in a triangular relationship as shown in Figure 7-10.

Figure 7-10. MSF project trade-off triangle

The triangle represents an elastic relationship such that a change in one parameter (e.g., resources) has an effect on one or both remaining sides of the triangle to maintain balance. For example, if a project feature set is to be expanded, a compensating change is needed to project resources and/or project schedule to rebalance the triangle. The changes needed to rebalance a project equate to impact realized from the change request.

As stated in Chapter 3, "Foundational Principles, Mindsets, and Proven Practices," different aspects of a solution likely have different quality levels (e.g., a financial component of a solution likely requires higher quality than an employee intranet component). To accommodate this, quality should be viewed as another dimension, which transforms the triangle into a tetrahedron (or three-sided pyramid). The obvious risk to making quality a variable instead of a fixed level that is nonnegotiable is that some teams might choose to lower their quality to enable a reduction in required resources and/or schedule.

A key to deploying a solution that matches the customer's needs is to find the right balance between resources, deployment date, and features. Because customers are sometimes reluctant to cut features, the trade-off triangle helps to explain the impact of that decision (it also supports their adoption of a versioned release strategy if they have not already adopted one).

Project Trade-off Matrix

Another powerful tool to manage trade-offs is a project trade-off matrix. It visually represents an agreement between the team and stakeholders, made early in a project, regarding the default project-wide priorities when making trade-off decisions. For instance, Figure 7-11 shows the typical trade-off matrix used by Microsoft product teams. If the default project priorities do not seem applicable to all parts of a solution delivery effort, use a matrix for each major aspect of a solution (e.g., training). However, there still should be an overarching matrix for a project. Please note that each column must contain only one check mark.

Figure 7-11. MSF project trade-off matrix

Literally interpreting the figure, it reads: Given fixed resources we will choose a schedule and adjust features as necessary. In other words, for this example, managing resources is top priority, is essentially unchangeable, and is followed by managing the schedule; taken together, this dictates which features the team is able to deliver.

The main benefit of establishing default priorities is to help make trade-offs less contentious. Note that the real power of using this matrix is the process to reach consensusthe matrix is just a graphical conversation starter.

Lesson Learned

Organizations often begin a project saying that features are top priority, but after assembling rough resource and schedule estimates to deliver those features, they often reprioritize. So make sure the team revisits this matrix a few times with the stakeholders and at each major checkpoint.

Assessing Risk (Deliverable)

Lead Advocacy Group: Program Management

Assessing risk starts from inception of a project. Every decision has direct or implied risk that should be documented. Alternate approaches to implement a solution have inherent risks that should be considered. Making project trade-offs has associated risks, too. Everything has varying degrees of risks. These risks influence all decision making and planning.

All the risks identified during envisioning are documented in an initial risk assessment document. This document forms the basis for ongoing risk management. This is also the time to determine how a team is going to implement the MSF Risk Management Process.