Certification Objective 2.03: Analyzing and Refining the Scope of the Solution Project

Defining the scope of a solution involves an understanding of the various constraints that will be imposed on a project. Whereas the project vision is drafted without consideration for time and expense, the project scope must take the dreams and downsize them to fit within reality.

In the MSF envisioning phase, the project scope defines the functionality that will be developed and released in a single version of the project. Whereas an application might eventually encompass 15 or 20 separate business functions, the scope of the project consists of the initial 4 or 5 functions to be deployed after the first cycle during the iterative development process. Each iteration in the development process requires its own scope, even though the solution concept might change very little during that time.

The project scope is important because it provides a good start for the design phase of the project. Based on what features are included in the scope, a project leader will be able to define a rough schedule and begin thinking about the types of resources required to design and develop the solution. When the client wants one or more new features added to the project after the design phase has ended, this is known as scope creep. Scope creep is not necessarily a bad thing, but your project has to have a change management process in place to handle such occurrences.

Of course, there is a limit to the number of new features that can be added to an application before it starts to affect the delivery schedule or the project budget. That is when you have to put a stop to scope creep and say, “It will have to wait until the next release.” Of course, if the client insists that the new features be in this release, the project schedule, the budget, or both, will have to be redone, which might mean having to revise the design specifications. These disturbances to the development process should be avoided if at all possible.

As you are creating the solution concept and setting the scope for the project, document your decisions in a “vision/scope document”. This document is one of the three deliverables that are produced during the envisioning phase. The other two documents deal with risk assessment and project structure, and have been discussed elsewhere in this chapter.

Exam Watch

In the MSF process model, the project vision is an unbounded view of the solution to the business problem at hand. The project scope identifies the part of the vision that can be realistically accomplished in this release.

Case Study: Defining the Scope for the RPM System

Jack decides it is important to follow the MSF process model and develop the RPM system in small, manageable parts. He decides that the system should be developed in three phases:

• Phase one Create a data entry application for existing coupons that links nightly to the accounting system.

• Phase two Add reporting functions to the application to better track and manage the coupon programs, and add the ability to create monthly limits to the number of coupons a retailer can send in.

• Phase three Add a few more promotion types and modify the data entry and reporting functions to support them.

The scope for the first phase is to develop a simple data entry application using Microsoft VB .NET that links to a SQL Server 2000 database. Using the application, data entry clerks will be able to add, update, search, and delete coupons that are associated to retailers. All transactional activity will then be passed on to the accounting system so that credits can be applied to a retailer’s monthly invoice. The RPM application must have basic security and auditing features.

Now that the project scope has been defined, Jack can move on to the final step of the envisioning phase: identifying project risks.