11

Scope Control

Major topics in this chapter are scope control tools:

• Change Coordination Matrix
• Project Change Request
• Project Change Log

The purpose of these tools is to zero in on controlling the scope of a project in the course of project plan execution (see Figure 11.1). Closely coordinated with the schedule and cost control tools, the scope control tools help the project team get their arms around the sound scope changes and updated scope baseline. This information about the updates is used to report project progress and close down the project at the end of the implementation. Helping in this effort are team development, quality, risk, and other controls.

Figure 11.1 This is when and how scope control tools are used in the standardized project management process.

This chapter focuses on preparing practicing and prospective project managers to acquire the following skills:

• Become familiar with various scope control tools in the proactive cycle of project control.
• Select scope control tools that match specifics of their situation.
• Customize the tools of their choice.

The acquisition of these skills is critically important in successfully implementing the project and building the SPM process.

Change Coordination Matrix

What Is the Change Control Matrix?

Think of the Change Coordination Matrix (CCM) as a convenient roadmap to a destination called “project changes properly controlled.” To serve this purpose, a CCM helps spell out steps in the change control process, identify actions to be taken, assign responsibilities for the actions, and coordinate those responsible [4]. By weaving other tools such as the Project Change Request (PCR) and Project Change Log (PCL) into the process, a CCM fully translates change control policy and rules of an organization into a practical change control procedure of a how-to-do nature (see Figure 11.2).

Figure 11.2 An example of the Change Coordination Matrix.

Developing a Change Coordination Matrix

Constructing a CCM that harmonizes steps, actions, owners, and their interactions in the change control business calls for a carefully crafted process that would minimize uncontrolled changes (see the box, “The Fear of Uncontrolled Changes: If You Have to Do It, Do it Early”). Following we describe the process pictured in Figure 11.2.

Prepare Information Inputs. Three inputs play a major role in furnishing information necessary for building a CCM:

• The change control plan (described in the “Scope Statement” section of Chapter 5) provides details of the project change rules that have to be incorporated in CCM steps.
• An appropriate coordinator must be appointed to conduct project change business (see the box, “Who Is Older: The Coordinator Or the Change Control Plan?”).
• Scope baseline with Work Breakdown Structure, to which requested changes may be made. It is also presented in the “Scope Statement” section of Chapter 5.

Submit a Project Change Request. Naturally, anyone involved in a project, inside or outside the team, is welcome to submit a PCR, assuming the project scope is not frozen. Details about PCR are provided later in this chapter.

Record in the Project Change Log. After receiving a PCR, the coordinator records it in PCL and distributes copies (see Figure 11.2). Typically, copies go to the change authority (for example, to the members of the change review board) and the originator. Distributing copies to other people who can help evaluate the change is an even more efficient method. In that case, managers and specialists who may be impacted by the requested change may notice implications that the authority have missed.

Review Project Change Requests. The coordinator submits the change requests to the change authority. This is usually done in batches or in any other way that ensures the prompt review of the requests.

Decide on a Project Change Request. The change authority's responsibility is to make an approval or rejection decision, which is recorded in the PCL (Figure 11.2). When A PCR is rejected, a copy is stored in a master file. A copy is returned to the originator, explaining the decision and the grounds for rejection. If the PCR is approved, the coordinator makes the PCR official and sends it to those impacted by the change to carry it out. Also, the coordinator informs the originator. Finally, it is not unusual that the change authority finds a PCR incomplete, prompting the coordinator to request more information from the originator.

Monitor the Change Implementation. The life of a change is not over with its approval, although challenges of its implementation may take time and diminish its visibility. This is why a coordinator needs to exercise disciplined monitoring of the change implementation status. A practical tool for this is a PCL.

Update Project Cost and Schedule. Approved changes may change basic project parameters of the total cost and completion date, necessitating their update. Again, a good tool for the update is a PCL, because it provides the necessary visibility. This, of course, does not preclude updating project cost, schedule, and scope documents. Since updates of this type are typically a reactive type of behavior, you might consider a proactive tone to CCM (see the box that follows, “Consider a Proactive Use of CCM”).

Utilizing Change Coordination Matrix

When to Use. CCM should be developed in each project that is subject to change, possibly in the early planning stage before the scope is defined [5]. In that case CMM offers the change roadmap when the first Project Change Request emerges, setting the tone of change control throughout the project. This is especially vital in larger projects, in which the rule is often one of: the larger and more complex the project, the stronger need for CCM. Because of their lesser scope and complexity, smaller projects will face a very simplified change control process – the project manager often may be the only person available to handle the change. In circumstances like this, an informal, not documented but well-understood CMM would be more logical than having a formal one.

Time to Develop. Assuming that an organization has the change control policy and rules in place, preparing a CCM is a relatively straightforward activity. It won't take more than an hour, because drafting a CMM will pretty much be reduced to a quick adaptation of the policy, followed by the recruitment of the change authority and the coordinator. This time requirement may significantly grow when an organization lacks the policy and the project team needs to build a CCM from scratch. Even in smaller projects where the project manager may be one-person band, 15 to 20 minutes may be necessary to clarify an informal CCM process with his or her manager.

Benefits. CCM's value is in bringing order to the project change process. Through a methodical prescription of the sequence and arrangement of tasks and people in the process, this order significantly diminishes the possibility of problems, including scope creep, budget overruns, and project slippage [6]. Making the change process how-to-do's known in advance also helps direct behaviors of project participants, eliminating notorious perplexity of people involved in project changes.

Advantages and Disadvantages. CCM's advantages are in its

• Visual impact. Pictorial appearance of CCM makes it user-friendly and easy to follow, building on a natural ability of humans to better process graphical than the narrative information.
• Step-by-step nature. The visual impact is further strengthened by presenting the CCM as a sequence of steps, a format that adds more transparency and user-friendliness to the process.

On the other hand, to those busy project managers struggling to get through their tight schedules, asking for a CCM may look like one more thing competing for their time. This feeling may grow even stronger in organizations without the change control policy, where building one from scratch may easily be a real time drain.

Customize the Change Coordination Matrix. The description of the CCM that we have offered here clearly reveals its true potential for customization. It can be developed in various ways, allowing us to find one that best fits our needs. The following ideas may help you customize the CCM.

Summary

The focus of this section was the Change Coordination Matrix (CCM), a tool that maps steps in the change control process, identifies actions to be taken, assigns responsibilities for the actions, and coordinates those responsible. CCM should be developed in each project that is subject to change, possibly in the early planning stage before the scope is defined. Its value is in bringing order to the project change process. Through a methodical prescription of the sequence and arrangement of tasks and people in the process, CCM considerably lessens problems such as scope creep, budget overruns, and project slippage. Following we sum up the key highlights in constructing a CCM.

Customization Action	Examples of Customization Actions
Define limits of use.	Use formal CCM in all larger projects that are subject to change.
	Understand and apply an informal CCM in smaller projects that are subject to change.
Modify a feature.	Require the existence of the change review board (in large projects).
	Identify the project manager as the change coordinator (usual in smaller projects).
	Show CCM process from left to right, not top-down as we did.

Project Change Request

Performing an All-Angle Evaluation of a Possible Change

The impact of project changes on its scope, schedule, cost, quality, and other matters may easily surpass the awareness or expertise of their originator [7]. As a consequence, the project may severely suffer and in certain cases even collapse (see the boxes that follow, “Scope Creep by Design” and “Scope Creep by Lack of Design: A Quick Interview with a Project Manager”). For this reason, it is very important to ensure that each change is evaluated in a disciplined and professional manner before receiving a go-ahead. It is the task of the Project Change Request to help perform an all-angle evaluation of proposed changes (see Figure 11.3).

Developing a Project Change Request

While the request appears as a simple form (be sure to keep it to a one-page format, with as much supporting detail as necessary), it does require doing homework, which begins with preparing solid information inputs.

Prepare Information Inputs. For larger projects, major inputs to the application of the Project Change Request are the scope baseline with WBS and the change control plan (see the “Scope Statement” section in Chapter 5). For smaller projects, inputs usually involve verbal directions on issues involved in the plan.

Figure 11.3 An example of the Project Change Request.

When Do You Start Applying PCR? As the conventional wisdom goes, a change should be proposed as soon as it is needed. We would like to add a little bit more precision here. The early conceptual stage of scoping the project is the time when there is no use for PCR as a change control arm. With the scope being only roughed out, it is impractical to attempt to control changes. At a later stage in the progress of scope definition, however, it is practical to start using the PCR tool. For example, a new product development project that has not done any piece of design work or has not issued any drawing would not need to apply PCR. Rather, it would start using PCR for changes that would [7] either

• Constitute a departure from the agreed design specification.
• Affect specifications issued by the engineering department for purchasing or production planning.

Considering these as examples, an organization still needs to create its own policies.

When Do You Stop Applying PCR? Although the question may seem less than meaningful, there will come such time when any change may impede the progress pace, potentially leading to costly waste and rework. An effective action in such situations would be to impose a scope freeze, a mandate that no changes will be considered unless an overriding reason exists. An example may be a customer-funded requirement to add a new safety feature to a product. A good understanding of how these issues of the change control plan and timing will be handled is necessary before we start dealing with specific change requests.

Describe Requested Changes and Their Impact on Scope/Quality. This self-explanatory action assumes that the description of the requested change will be sufficiently precise to provide an easy understanding about which part, deliverable, or work package should be changed and in what manner. We don't rule out a need for longer descriptions when complex matters are involved. Generally, the language used for this purpose should be as laconic as possible.

Explain the Reason for Change. Why do we want to make this requested change? Motivation may vary. To make sure it comprehends this motivation and prevents motivations that harm it, an organization requires the originator of change to state whether the requested change is of a must or want type. In their corporate lingo, a must change is one without which the project might perish. Consequently, it draws the appropriate attention and approval. A want change, on the other hand, would typically provide more elegance but not substance to the project product. At the same time, the want change may easily lead to the replanning effort, thus making itself a primary target for disapproval. This well-aged must/want change concept may be a good messenger to those who ignore or underestimate risks of scope creep. We may or may not like this concept, but to be on the safe side, ensure that every proposed change has its rationale.

Identify Emergency Changes. One of the major problems with regular, formalities-oriented treatment of PCRs is that they are unnecessarily slow. To overcome this problem, you need a feature in the system that ensures fast responses to urgent PCRs, which is marked in the PCR as “emergency action required.” Its task is to inform the change authority that the requested change needs an urgent consideration and approval. This may mean that the authority will have to act promptly. Depending on the policy rules, they may choose to interact in a face-to-face meeting, on the phone, or via an intranet-based program (see the box the follows, “An Intranet Helps Treat Customer-Funded Changes as a Royalty”). It is of utmost importance that emergency changes should not be an excuse to circumvent evaluation of matters related to quality, performance, reliability, safety, or any other aspect. Building safeguards that enforce appropriate consideration of the change may be a useful aid.

Explain Impact on Project Schedule. It is very difficult to evaluate the impact of changes on schedules without a good network diagram. Simply that is where dependencies between activities are shown, helping us analyze how a change to one deliverable and its activities will affect dependent activities down the road. Still, more often than not, that is what occurs—a schedule impact assessment is made on the basis of a gut feeling. To safeguard against risks related to such assessments, rely on network schedules to produce reliable estimates, even if you are dealing with a small project and have no time to document in detail. An informal but good network analysis will benefit the small project.

Evaluate Impact on Project Cost. Requiring a cost or resource estimate for the proposed change is a well-meaning strategy to prevent cost surprises. That humans have a tendency to underestimate the cost is well documented in many books and papers. Several decades ago as well as today, missing an estimate by 20+ percent has not been unusual. What is unusual is the failure on management's part to take this tendency into account when evaluating a change request. Asking for a databased, bottom-up estimate when the change request is proposed is a sound management safeguard against the tendency. If the change is major, it is possible to go further and request an estimate from an independent source to compare with the estimate of the change originator, a practice frequently used by Intel project managers under the name of “shadow estimating.”

Identify the Type of Change. Some organizations have a habit of approving major changes to the scope without ever referring back to the original (often called baseline) scope. This phony practice results in an ever-changing scope, making it a moving target. The risk is that moving scope, schedule, cost, and quality may inflate to the point of representing an all-new project that needs planning and implementation different from the current one. To prevent this, screen all proposed changes by identifying how they will impact the scope and quality. Should the change have minor, if any, impact, it may be treated as a minor corrective action, not impacting baseline scope, quality, cost, and schedule.

In contrast, we may identify a major change to scope of work, funding, or schedule requirements. That may warrant a replanning (or rebaselining) effort, including changes to the scope statement, WBS, schedules, budget, and resource allocation. To make all involved fully aware of such consequences, identify whether the requested change is a major or minor one. This is, of course, possible only after we assessed the impact of the change on scope, quality, cost, and schedule in the upper part of PCR.

Still another type of change may be identified and reviewed under this section of PCR. For time pressures in our busy schedules, some organizations require prioritization of change requests, imposing shorter turnaround times to more important changes. One organization has installed a change system with four layers of priority, where the change authority has to respond to a first priority change in 24 hours and to the fourth one within 30 days. This is a fine example to provide responsiveness where needed and discourage change when unwanted.

Miscellaneous Issues. Part of PCR are also such requirements as the change board decision on the request or the need for supporting detailed information. Since they are rather self-explanatory, their more detailed treatment here may be a redundancy.

Follow Up and Close Down. Approving a change request is no more than a prelude to the change action. And as with any other project action, this one will demand planning, very meticulous for major changes and less so for minor ones. Organizing for the change action and closely monitoring its implementation are prerequisites to its successful closure. To get there, however, make sure that all conflicts are resolved—and those may occur in the course of the change action—and finish all changes resulting from the change action before proclaiming it is finished.

Utilizing the Project Change Request

When to Use. Each project should use a PCR to screen and rationally evaluate the proposed changes [8]. In larger projects the PCR use needs to be as documented as possible to leave a trail of recorded changes. Because of their small budgets pressure, smaller projects typically cannot afford the documented PCR, warranting a unique, informal approach to PCR. First, all issues present in documented PCR will be on the table of small project changes as well. However, these issues will be discussed, established, shared, and applied verbally in any considered change. The sheer presence of such discipline surely cannot make up for the rigor of the documented process but can easily accommodate the lack of resources and hectic pace typical of a small project environment. In short, let small projects live with what is possible.

Time to Use. A few minutes—that is all you need to complete a PCR. But that is only the technicality part, which must be preceded by a substantial analysis that is a function of the size and complexity of the proposed change. In a small-scale change, like in the example from Figure 11.3, figuring out its scope, cost, and schedule consequences may take 15 to 30 minutes. At the other end of the spectrum are major changes to major projects, where a group of experts may spend a week or two to fully assess the requested change's impact on the project's business purpose and goals—the triple constraint of scope, time, and quality.

Benefits. Because of its process, structure, and content, PCR brings to management the value of making conscious decisions instead of letting everything happen by default. Naturally, then, as a result of management and project team members working together on a PCR, the decisions tend to be of a higher quality. When the decisions are based on or coordinated with other tools necessary to assess the PCR impact, project scope, cost, and schedule are kept in check and agreement with each other. Also, the apparent outcomes are documentation of changes, reduced project participants' confusion, better-controlled scope change, lower total cost, and fewer delays.

Advantages and Disadvantages. Major advantages of PCR are its:

• Clarity. PCR projects an image of clarity: “this is the change we propose to make and here is how it impacts the project's fundamentals.” To be able to fathom the essence of a change this clarity is of huge value.
• Brevity. PCR intentionally excludes any detail beyond the fundamentals. If there is a need for more details to support the case of change, they will be relegated to an attachment. In that manner, the very essence of the change, its crux, will not be compromised by excessive detail.

Customization Action	Examples of Customization Actions
Define limits of use.	Use PCR in every major project for every proposed change.
	Apply a “verbal” PCR in small projects.
Add a new feature.	Include prioritization of PCR with the turnaround time (works for time-to-market or customer-oriented companies).
	Add information about major risks and risk responses (favored by high-tech projects).
Leave out a feature.	Leave out “emergency action required” feature if prioritization of PCR is required.
Modify a feature.	If in a time-to-market project, perform a very tentative estimate of cost impact of the requested change (so-called order of magnitude estimate).

The very best advantages will be even more appreciated when disadvantages of PCR's time-consuming nature are revealed. In large contractual projects, the number of changes may run in the thousands (the author's first-hand experience). Even with a well-designed and applied PCR system, this number of changes exacts a sizable chunk of PM time, translating into major expense. Although this expense gives a solid return on investment when it comes to controlling scope, cost, and schedule, many will enjoy a sigh of relief knowing that small projects are usually spared from too many time-consuming changes.

Customize the Project Change Request. Different types of projects may need different approaches to PCR. To opt for a generic PCR such as the one described here is to ask for trouble, which can be avoided by customizing PCR for specific project needs. The preceding hints may give you some ideas on how to customize it.

Summary

In this section we covered the Project Change Request—a tool that helps perform an all-angle evaluation of a possible change. Each project should use a PCR to screen and rationally evaluate the proposed changes. In that case, the process, structure, and content of the PCR help businesses make decisions of a higher quality, keeping project scope, cost, and schedule in check and agreement with each other. Also, the apparent outcomes are documentation of changes, reduced project participants' confusion, better-controlled scope change, lower total cost, and fewer delays. Finally, the following box highlights key points in developing the request.

Project Change Log

What Is a Project Change Log?

Project changes may not come in small numbers; rather, they may proliferate. This creates a need for recording, numbering, and coordinating the flow of project changes (see Figure 11.4). Monitoring the change process in this manner is enabled by the Project Change Log. Administered by a coordinator, a PCL records each change request and assigns it a number, making sure the decision about it—whether it has been approved or rejected by the change authority—is recorded as well. When a request is approved and the change implemented, that information becomes part of a PCL.

Figure 11.4 An example of the Project Change Log.

Keeping a Project Change Log

Forms such as PCLs have a major advantage in that they look simple to complete. Their appearance of a simple spreadsheet (see the box that follows, “It Only Takes a Spreadsheet, Even If It Is Big”), however, fails to inform us that it takes some information and energy spent in an orderly sequence of steps to produce a meaningful entry to the PCL. Following is a description of these steps.

Prepare Information Inputs. There are four major inputs to a disciplined and sound process of running a PCL:

• The change control plan (see the “Scope Statement” section in Chapter 5) provides a full understanding of the project change rules, which are necessary to direct the log.
• An appropriate coordinator must be appointed to administer the PCL.
• The Change Coordination Matrix supplies a procedure of steps that a change goes though, something no PCL can function without.
• The Project Change Request is a subject of administration in a PCL.

Record the Submission of the PCR. When the coordinator receives a PCR from the originator, his or her job is to issue a serial number for PCR and record the name of the originator, with a brief description of the pro-posed change.

Enter the Submission Date. Recording the date when the PCR was registered in the PCL helps maintain the schedule of change coordination. Reckoning from the date, we know how many days are expected for subsequent steps in processing the request (see the “Change Coordination Matrix” section earlier in this chapter).

Record If the PCR Is Approved and When Issued for Execution. The decision about the request may go both ways. If it is not approved, write “No” in the “Approved” column of the PCL and cross out the entry, making sure it is still readable. In the opposite case, when PCR is approved, write “Yes” in the column and fill in the column “Issue Date,” recognizing that the change order is now officially issued for execution.

Track the Change Implementation. Once they get to be executed, changes may fall through the cracks and disappear from the project radar screen. To avoid this, the coordinator will deem any change incomplete (therefore, “Not Yet” in the “Complete” column in Figure 11.4). Once complete, “Yes” will be entered in the column. Although it sounds paradoxical, sloppy change coordination may easily fail to catch a change that was never requested but implemented (see the box above, “What Do You Do with a Change That Was Implemented but Never Requested?). Should this happen and if it doesn't hurt the project completion, put that change in the change coordination loop as soon as possible.

Keep a Running Total. Certain changes will impact the project cost and completion date. To know the true project budget and completion date, we need to add cost and completion date details for all approved changes to keep a running total.

Utilizing the Project Change Log

When to Use. PCL should be used in each project that is subject to change. The size and complexity of a project, again, will have a say in how PCL is administered. Unlike the emphasis on a disciplined recording of all requested changes in larger projects, smaller projects are likely to build an informal PCL approach (see, for example, the box that follows, “Small Projects: Running a Change Log on a Palm Pilot”). When changes come in small numbers, a PCL may not be of much help.

Time to Use. Keeping a tally of requested and implemented changes may not be a favorite task in projects, perhaps because PCL's appearance of a spreadsheet may not be able to stir excitement. Balancing the act may be a consolation that it takes a few minutes to make an entry in the PCL. Adding up the minutes for many entries in larger projects will not be a significant time burden when spread over the course of the project.

Benefits. In projects fraught with changes, PCL's role of a repository of changes provides a good oversight of all requested, rejected, approved, ongoing, and complete changes. The value of this information is in its potential to prevent both cost losses and project delays, by indicating to the decision makers the impact of major changes on the project budget and schedule. Such clarity is bound to trim down the confusion often seen in situations when PCL is absent.

Advantages and Disadvantages. Advantages of a PCL is its

• Clarity. PCL looks like a model of transparency, offering the fundamental but brief information on all changes in the project in one place. For such clear oversight of changes to be maintained, any unnecessary detail is left out.
• Simplicity. A glance at a PCL is perhaps enough to be able to interpret it, and even possibly keep it. To busy project people, simplicity is a productivity booster.

The red-tape impression that PCL's appearance creates in some project participants is probably its major disadvantage. As a result a resentment toward maintaining a PCL is not unusual and may be a major threat to good and cost-effective oversight of project changes.

Customization Action	Examples of Customization Actions
Define limits of use.	Use PCL in all projects subject to change.
Add a new feature.	Add a column indicating the incremental cost of a requested change (useful for cost-conscious organizations).
	Add a column for keeping a running total of the project price (used in contractual projects).
Modify a feature.	Highlight major changes impacting the total project cost and completion date.

Customize the Project Change Log. Although a PCL's simplicity may not induce a flurry of creativity when it comes to its customization, we still should consider some changes to the standard format described. These changes should help better reflect your own needs for overseeing project changes by means of a PCL. The ideas below are designed to help you customize the scope and direction of a PCL.

Summary

Presented in this section was the Project Change Log, a tool with the purpose of recording, numbering, and coordinating the flow of project changes. A PCL should be used in each project that is subject to change. Unlike the emphasis on a disciplined recording of all requested changes in larger projects, smaller projects are likely to build an informal PCL approach. In both cases, a PCL provides a good oversight of all requested, rejected, approved, ongoing, and complete changes. Such clarity is bound to decrease the confusion often present when PCL does not exist. Tailoring PCL to specific project needs adds more value to its users. To sum up, we highlight key points in establishing the log.

Concluding Remarks

The three tools reviewed in this chapter—Change Coordination Matrix, Project Change Request, and Project Change Log—are building blocks of the scope control (see the summary comparison that follows). Each is designed to meet a different, unique need in preventing the scope creep. Building a roadmap that defines the scope control methodology with a proactive focus is the essence of the Change Coordination Matrix. A Project Change Request, a key component of the methodology, secures control of each requested change. Finally, a Project Change Log leaves a trail of the requests. As complementary as they are, each one can be used without the other two, formally in larger projects or informally in small projects.

A Summary Comparison of Scope Control Tools

References

1. Harrison, F. L. 1983. Advanced Project Management. Hunts, U.K.: Gower Publishing Company.

2. Cleland, D. I. and D. F. Kocaoglu. 1983. Engineering Management. New York: McGraw-Hill.

3. Meredith, J. R. and S. J. Mantel. 1989. Project Management. 2d ed. New York: John Wiley & Sons.

4. Ra, J.W. and J. R. Hemsath. 2001. “Web-Based, Real Time Protocol for Management of Change in a North Slope Oil Exploration and Production Operation” at Portland International Conference on Management of Engineering and Technology. Portland, Oregon.

5. Kerzner, H. 2000. Applied Project Management. New York: John Wiley & Sons.

6. Hed, S.R. 1973. Project Control Manual. Geneva: Sven R. Hed.

7. Lock, D. 1990. Project Planner. Hunts, U.K.: Gower Publishing Company.

8. Klien, R. L. and A. H. Institute. 1986. The Secrets of Successful Project Management. New York: John Wiley & Sons.