Scope Creep and Project Change Control

If midcourse changes in the project specifications are not controlled, the following are typical results: a newspaper front-page headline reading “Stadium costs soaring;” an article on an inner page stating that “Change orders . . . are one of the most common sources of waste and fraud during projects, experts say;” and a quote from a County Commissioner, “The project is in trouble, but it’s absolutely recoverable. . . . We can work out responsibility for those payments at a later time. Now is not the time to start pointing fingers.” An auditor appointed to look into the matter “found that there is not sufficient oversight to properly monitor the change orders, check if they werenecessary and determine who is responsible” (see Cincinnati Enquirer, February  15, 2000, pp. A-1 and A-4).

As we noted in Chapter 6, input from over 500 project managers regarding things that “bugged” PMs the most indicated that coping with changes is at the top of their list. The most common source of changes is the natural tendency of the client, as well as the project team members, to try to improve the project’s output as the project progresses—a phenomenon so frequently encountered, a name for it has been coined: “scope creep.” The most common result of scope creep is an upset client who was not (or claims not to have been) told how long the change would delay the project and how much it would raise the project’s cost. The general subject of scope management is described in more detail in Chapter 5 of PMBOK.

New technologies and materials become available, new requirements and needs become apparent, and these lead to changed projects. The later these changes are made in the project, the more difficult and costly they become. The one absolutely certain thing about a project—even though virtually nothing in a project is ever certain—is that there will be concerted attempts to change it. PMs must expect these attempts and be prepared to deal with them. Fighting change is not appropriate. The best approach is for the PM to set up a well-controlled, formal process whereby such changes can be intro­duced and accomplished with as little distress as possible.

This process is known as the change control system. The purpose of this system is to:

  • review all requested changes (either content or procedural changes)
  • identify all impacts the change may have on other project tasks
  • translate these impacts into alterations of project scope, schedule, and cost
  • evaluate the benefits and disadvantages of the requested changes
  • identify and evaluate alternative changes that might accomplish the same ends with greater benefits and/or fewer disadvantages
  • install a process so that individuals with appropriate authority may accept or reject the proposed changes
  • communicate accepted changes to all concerned parties
  • ensure that the changes are implemented properly
  • prepare reports that summarize all changes to date and their impacts

Avoiding scope creep is not possible. Controlling it, and thereby reducing some of the pain, is possible—if the PM follows a few rules.

  1. Every project plan must include a change control system by which requests for changes in the project’s plan, processes, budget, schedule, or deliverables are evaluated.
  2. Every project change must be introduced by a change order that includes a description of the agreed-upon change together with any resulting changes in the plan, processes, budget, schedule, or deliverables.
  3. Changes must be approved in writing by the client’s agent as well as by a representa­tive of senior management of the firm conducting the project.
  4. The project manager must be consulted on all proposed changes prior to the prepara­tion and approval of the change order. (The PM’s approval is not required.)
  5. Once the change order has been approved, the project plan be amended to reflect the change and the change order becomes a part of that plan.

The process of controlling change is not complicated. For large projects, a change control board consisting of all interested parties is recommended for handling change requests. For smaller projects, a smaller group may be designated. The main source of trouble with requested changes is typically that the PM, in an attempt to avoid bureau­cracy, adopts an informal process of handling requests for change. Such a process leads to misunderstanding on the part of the party requesting the change, and before the PM can undo the damage, the organization is committed to extending the scope of the project but without the additional resources and time to do it.

In March 2003, the United Kingdom’s Child Support Agency (CSA) started using their new $860 million software system for receiving and disbursing child sup­port payments (PMI, January 2005). By the end of 2004, however, only about 12 percent of all applications had received payments, and even those took about three times longer to process than expected. CSA is now threatening to scrap the entire system and is withholding $2 million/month in service payments to the software vendor. The problem seems to be due to control both scope management problems and the lack of a risk management strategy. The vendor claims that the project was disrupted constantly by CSA’s 2,500 change requests, while CSA maintains that there were only 50 requests, but the contract did not include a scope management plan to help define what constituted a scope change request. The lack of a risk manage­ment strategy resulted in no contingency or fallback plan in case of trouble, so when project delays surfaced and inadequate training became apparent, there was no way to recover.

Source: Meredith Jack R., Mantel Jr. Samuel J., Shafer Scott M., Sutton Margaret M. (2017), Project Management in Practice, John Wiley & Sons, Inc. 3th Edition.

Leave a Reply

Your email address will not be published. Required fields are marked *