CHAPTER 9

Project Scope Management in Practice

RUTH H. ELSWICK, PMP, PM COLLEGE

For many project managers, as well as other stakeholders, managing scope is truly a mystery. We could even give it a name: “The Case of the Creeping Scope.” Project managers must get into the “crime prevention” mode rather than the solution mode to effectively define and manage scope!

The first step in the scope creep prevention process is to understand exactly what is meant by scope. The Project Management Institute (PMI) breaks scope down into product scope and project scope. Product scope is defined as the “features and functions that characterize a product, service, or result.” Project scope, on the other hand, includes all the work that needs to be done to deliver the product, service, or result as defined in the product scope. Figure 9-1 shows how most projects are structured. At the top we have the project level. On the left are the project management activities that focus on the processes needed to carry out the project. On the right is the product or technical side, which contains the deliverables to produce the product, service, or result for which the project was undertaken. Product scope is only the right side of the equation, while project scope is the top level and includes both sides of the equation.

Most project managers focus on the product side and, during estimating, often forget the time and money that it takes to produce and monitor the project management activities. Resources, as well, focus on the product side and forget that they need to participate in the project management activities such as developing the team charter, work breakdown structure (WBS), schedule, and so on. The bottom line is that there is a real need to understand the two types of scope.

Also key to effectively managing scope is to know exactly what is required. PMI describes this process as follows:

• Plan the approach you will take.

• Collect all the requirements.

• Define what you want the scope to be.

• Create the WBS.

• Verify that all the deliverables have been accepted.

• Monitor and control the scope.¹

FIGURE 9-1. PRODUCT SCOPE VS. PROJECT SCOPE

PLANNING THE APPROACH

Planning the approach to the scope is a new concept for many project managers. The plan that is put into place gives all stakeholders an idea of how the scope, both product and project, will be managed throughout the project. Notice that it is managed throughout the project—not just in planning. Often the approach to scope planning, if it is done at all, is to put a WBS together, wipe the sweat off the forehead, and say, “Wow, I’m glad that’s done!” Scope planning, and replanning, admittedly has heavy emphasis during the planning process, but it is also essential during the monitoring and controlling process, where a comparison can be made between what was thought to be a good approach and how the plan actually measures up. The project manager should tap into the experiences and knowledge of the team members as well as other stakeholders to gather lessons learned and suggestions on how to best approach the scope. This input from the various sources not only results in a better, more manageable plan, but also (1) generates commitment from the stakeholders to the plan, (2) gives more credibility and reality to the plan, and (3) ensures that everything has been covered.

COLLECTING ALL THE REQUIREMENTS

Once the scope management and requirements plan is in place, the real fun begins, as it is time to collect all of the requirements—“all,” not just some. The key to successfully gathering requirements is to use different methods of information gathering. Focus groups and facilitated workshops work well in an environment where everyone can attend the meetings. In a virtual environment, the Delphi technique or questionnaires and surveys may better fit the bill. Interviews can be used in either environment. The environment should dictate your techniques. The challenge is that there may be conflicts in what the requirements should be as well as what the priorities are. The good news is that the project manager realizes early on that there is a difference in priority perceptions. Once those differences are recognized, they can be addressed early in the project rather than trying to address them further into the project where more is at stake. Group decision making techniques such as the pairwise comparison can be very helpful in determining priorities.

The output of collecting requirements should be a traceability matrix, which traditionally has been used in software development, but now has found its way into the project management environment to ensure that each requirement relates to the business and project objectives. Table 9-1 is a suggested template, but there is no set standard for the traceability matrix and it should be adapted to the individual projects.

DEFINE THE SCOPE

Scope definition is primarily accomplished through the use of a project scope statement; Table 9-2 is a suggested template.

This statement can be considered a “handshake document.” After the sponsor or other executive, often with the assistance of the project manager, has issued the charter, the team then develops the project scope statement, which is a high-level document ensuring that all stakeholders have a common understanding of the project’s deliverables and the work that will be required to create those deliverables. The statement takes the project deliverable that is described in the project charter and details it for one level in the WBS. Figure 9-2 is a graphic depiction of the relationship between the charter and the project scope statement for an project involving the development of a training course.

Although there may be some variance in the content, typically the project scope statement includes the following:

• Product scope description of the product, service, or result.

• Acceptance criteria: what will determine if the deliverables have been met.

• Deliverables: the tangible product, result, or capability that the project delivers.

• Project exclusions: what will not be included in the project. Often the comment is made that if it isn’t included in the deliverables, it is excluded. The problem with this theory is that people have different perceptions of what the deliverable entails. For example, included in the construction of a new house may be a three-car garage. Some people picture a three-car garage as having wiring, sheetrock, and a finished floor. Other perceptions may be that is just the building with just sheetrock or just wiring. It is far better to preclude any differences in perception and simply specify the exclusions.

Project Title

Date Prepared:

Purpose: The project scope statement is used to define, develop, and constrain the project and product scope. The scope statement should directly include, or include by reference, the items described below.

Product Scope Description:

Deliverables:

Acceptance Criteria:

Project Exclusions:

Project Constraints:

Project Assumptions:

Approvals:

FIGURE 9-2. THE RELATIONSHIP BETWEEN THE PROJECT CHARTER AND SCOPE STATEMENT

• Constraints: the items that limit the team’s options. A number, whether it is budgetary amount, a date, or number of resources, is typically a constraint. “The project will start on July 20,” or “The project must complete by December 10,” or “The project budget cannot exceed $100,000,” or even “The project will not exceed three resources”—these are all constraints that contain numbers. It is important to note, however, that a constraint could be something other than a number, such as “The project will only use internal resources.”

• Assumptions: anything that is considered to be true, real, or certain and often allows you to move forward. The key learning point here is that assumptions must be validated as you move through the project.

CREATE THE WORK BREAKDOWN STRUCTURE

Once there is stakeholder agreement on the project scope statement, the team then creates the WBS. Just as the scope statement is based on the project charter, the WBS is based on the scope statement. The WBS helps the project manager and the team members organize the work so that all project deliverables are identified, estimated, and scheduled. The WBS defines the what, who, how much, and how long. This is accomplished by deconstructing each of the major deliverables, identified in the scope statement, down to its lowest level, termed a work package. It is at the work package level (the “what”) that resources are assigned (the “who”), the time or effort to complete it is estimated (the “how long”), and what it will cost to produce that work package (the “how much”) is determined. It is important that the team actively contributes to the development of the WBS. The project manager may choose to further define the elements of the WBS, including the work package elements, in a document that provides such things as detailed deliverables, a list of associated activities, milestones, start and end dates, resources required, cost estimates, technical references, and quality requirements. This document is referred to as a WBS dictionary.

Since developing a WBS from scratch can be difficult and contentious, it is strongly recommended that a WBS from a previous, similar project be used as a template for the WBS development, or the project manager can develop a “straw man” to get the team moving in the right direction. Another way that a project manager can efficiently facilitate the WBS construction is to assign core team members to each of the major deliverables identified in the scope statement. These core team members will manage getting input from resources who will be working on those deliverables, and then all the core team members, along with the project manager, will meet to blend the deliverable areas.

The WBS becomes a key tool in tracking project progress. The prudent project manager will consider how tracking and reporting WBS deliverables will be accomplished to better track progress on the project.

It is important to note that the scope statement, in combination with the WBS and the WBS dictionary, makes up the scope baseline for the project.

The WBS facilitates the following:

• Understanding the work involved

• Planning the work

• Identifying end products and deliverables

• Defining the work in successively greater detail

• Relating end items to objectives

• Assigning responsibility for all the work

• Estimating costs and schedules

• Planning and allocating resources

• Integrating scope, schedule, and cost

• Monitoring cost, schedule, and technical performance

• Summarizing information for management and reporting

• Providing traceability to lower levels of detail

• Controlling changes

The WBS provides a common, ordered framework for summarizing information and for quantitative and narrative reporting to customers and management.²

VALIDATE THAT ALL DELIVERABLES HAVE BEEN ACCEPTED

Scope validation is accomplished when all the stakeholders formally agree on what the project deliverables are; each deliverable is objectively validated.

The basic idea of scope validation is to take the deliverables, which have been objectively validated using the quality control process to ensure that they meet the customer’s expectations, and then present them to the customer for formal acceptance. These could be classified as interim deliverables, with the final deliverables formally accepted as part of the closing process. Although scope validation is certainly closely aligned with the quality control process, they have a major difference in objectives. Scope validation is concerned with the acceptance of the deliverables while quality control is concerned with how correct the deliverables are. The tools used to accomplish scope validation vary from organization to organization and project to project. Usually the tools consist of work performance information that indicates the status of the deliverables, change requests to track changes to the deliverables, and updated documents such as WBS.

MONITORING AND CONTROLLING SCOPE

Information from the following documents contributes to controlling scope:

• The scope baseline compares actual results to determine if any changes or preventive action is necessary.

• The scope management plan describes how the project scope will be monitored and controlled.

• The change management plan defines how change management will be managed on the project.

• The configuration management plan addresses change to the technical side of the project.

• The requirements management is a part of the change management plan but addresses only changes to requirements on the project.³

Monitoring these items aids the project manager in determining the causes and degree of difference between the scope baseline and actual performance. Getting to the root cause of variance is key in determining whether or not corrective, or even preventive, action is necessary.

The output of controlling scope is a true picture of work performance information, what changes are required, and what documentation needs to be updated.

REFERENCES

¹ Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK^® Guide), 5th edition (Newtown Square, PA: PMI, 2013).

² David Pells, “Comprehensive Planning for Complex Projects,” in Paul C. Dinsmore and J. Cabanis-Brewin (editors), The AMA Handbook of Project Management, 3rd edition (New York: AMACOM, 2010), p. 51.

³ PMI, 2013, p. 138.