SCOPE CREEP IS ONE of the most common problems faced by project managers, and controlling it is not easy. This article presents a hypothetical case, analyzes some of the various sources of scope creep, and proposes a number of practical suggestions.
A Creepy Case Study. Let's follow a time-warped replay of an all-too-typical project. The type of project or the type of business in which the following scenario is happening is irrelevant, as you will see.
“A” is the proud project manager of Project Thingamajig, a major, important project for his company. The customer is his company's “Capital C” Customer, with lots of projects going on within “A's” organization, longstanding relationships and good connections at the top—so “A” knows he must keep the Customer satisfied.
“A” has the whole project planned out, following all the rules: the teams are fully staffed, the processes to follow are in place, schedules are in place, monitored and met—just about the dream project.
One day the Customer calls and requests some very minor changes to Thingamajig's functionality. They really are minor, and the project is in its very early stages, so “A” decides that keeping the Customer happy is important enough, and the cost of doing so is small enough, and he agrees. Oh, by the way, the Customer would like to also review some of the prototype GUI screens of Thingamajig, just for info, so he can prepare his users—and “A” agrees, thinking an early customer feedback can't be bad.
The Customer arrives, reviews the GUI, and has some minor comments, which “A” thankfully accepts and instructs his team to implement. The scenario repeats itself once or twice more and, while preparing for his project review with his manager, “A” realizes that the changes are causing him to add more functionality than he originally had, and that Thingamajig is over budget and behind schedule. He rationalizes it to his manager as being “the cost of keeping the Customer happy,” and ultimately they both agree that they will have to take a tougher stance the next time any changes come from the Customer.
Adrian Abramovici is a systems engineering program manager for Spar Aerospace on the Canadian Space Station Program's Special Purpose Dexterous Manipulator Robotic Arm Program. He has six years of project and program management experience at increasing levels of responsibility.
In the meantime the GUI design lead decides to add some more minor modifications that will improve the product even more, and which he is sure will please the Customer, as they are clearly along the lines of the various Customer requests that have been accepted before. He communicates the changes to his peers and documents them, but does not request an impact assessment from the other teams involved nor prior approval from “A,” since all he is doing is “minor” modifications just like the previous ones—and no impact assessments were required for those.
As expected, the Customer has some more “suggestions” to make, but “A,” with his manager's backing, is less than eager to accommodate them, and argues that they are out-of-scope changes. A lengthy argument ensues, and while on legal terms “A” is correct, the Customer is not pleased with the sudden change in attitude, and makes sure company executives are apprised of his displeasure.
Project Thingamajig's first milestone review is coming up, and the Customer attends it. And so do some of the company executives, feeling their presence is required to show the troops and the Customer their ongoing commitment. While he is only an observer, the Customer's comments and critique carry a lot of weight. With the executives in the room “A” is reluctant to invoke legalistic hurdles such as “scope change” defenses, and ends up accepting not only legitimate critique on errors and problems with the implementation, but also all the Customer changes he rejected prior to the review, and more.
Thingamajig is by now hopelessly behind schedule and over budget, and nobody is pleased, not “A's” manager, nor the Customer, nor the executives. “A's” weak defense that it can all be traced back to the Customer's required changes is rejected as poor configuration control. “A” is in hot water on all fronts.
Test time finally arrives, and all hell breaks loose. Thingamajig just doesn't work, major changes must be implemented, functionality must be changed, and so forth. In-depth analysis reveals that the cause for all “A's” problems lay in conflicting Customer requirements imposed late in the program without proper impact assessment and system architecture redesign. “A” feels vindicated for a short while … and his successor has a hard time completing the project—late, and over budget!
Sound familiar? Unfortunately, it probably does.
Scope Creep and Its Sources. So, what did “A” do wrong? Just about everything that is in any way related to project scope definition and change control—he allowed uncontrolled scope creep to take over his project. Let's look at the major components of scope creep exemplified in our story: external and internal changes.
The most familiar scope creep to us all is the externally induced one. Customer requirement changes, environment, platform changes—all kinds of sources of change outside the project. The project manager must be able to allow the customer visibility into the program, receive clarifications of his requirements and constructive criticism of the design, using the customer's knowledge as an additional reviewer of the development. At the same time the project manager must ensure that all of this is strictly maintained within the framework of the project's scope, and that the customer's involvement is not allowed to degenerate into a “continuous requirements improvement process.”
Reader Service Number 054
One of the oft-underrated external scope creep sources is poor understanding of the customer's requirements prior to the project scope definition and contract signing. If the customer's specification is vague, if there is potential misunderstanding between the customer and contractor on the work scope, the processes that will be applied, the deliverables and milestones of the project, then clarification of these issues once the project is under way, even if achieved “peacefully” and without antagonizing the customer, will often result in scope creep.
Internal scope creep is more insidious, and harder to control. Engineers will by their nature tend to improve their product, to make the best product they can. They have always tried to excel, to be the best, and will disdain as an underachiever anyone who tries to “just meet minimum requirements.”
But meeting minimum requirements is what internal scope control is all about. Unless “the best” has been negotiated into your original scope, anything you do beyond meeting the minimum requirements comes off your bottom line, and might threaten your schedule and increase your risk. Improvements and “the better way” should be used in the sustaining engineering (or whatever you call the post-delivery support) part of the project, thus generating new revenue.
Some Practical Advice. Controlling scope creep is one of the project manager's major tasks, and he or she has to start working on it even before the project statement of work is written.
On any project, preferably before the negotiations are complete, the following steps are suggested.
For externally induced change:
■ Ensure the specification and SOW are reviewed requirement by requirement with the customer prior to signature. Review yours and the customer's interpretation of the requirements in both documents, and ensure no gray areas are left in them. If any are found, make appropriate modifications to ensure absolute clarity of the agreements.
Reader Service Number 057
■ At negotiation time, it sometimes seems mutually beneficial to leave “vague” statements in specifications and SOWs. Don't! There is no benefit in it for you. Customers hold the money; they are “The Customer,” and, therefore, afterwards it is your burden to convince them that their interpretation is wrong and yours is right—and that is seldom successful.
■ Establish the ground rules for customer involvement with the program: What can the customer influence during the program? What are the two sides’ roles and responsibilities during the program and at milestone reviews? How is the customer expecting you to react to requests for support, such as change request evaluations (how fast, how to handle impacts on daily work, and so on)?
■ Once you have clearly established the scope of work, specify how work that is out of scope will be evaluated, accepted and performed—and obtain customer agreement to your definition of scope and your process. Establish who can initiate change-of-scope proposals (the contractor, the customer, or both), and how the proposals are to be handled. Make sure the costs of analyzing the change impacts and preparing the proposal are to be borne by the customer.
■ Review with the customer all other customer expectations, as disagreements in these areas can cost you and create potential problems with fees and milestone payments. If necessary, capture all this in the SOW, or a customer expectations agreement. Remember: Customer representatives will change, especially on long projects or programs, so verbal agreements are not good enough.
All these ground rules, if established, understood and accepted up front by both sides, will make the program and the relationship with the customer much smoother and will eliminate friction and bad feelings during the program. Apply the agreed-upon ground rules consistently. Allow no “freebies,” or they will be “expected.” After the initial agreement, establish a “no freebies” discipline. If that is not in place, the customer will expect you to accommodate “minor” changes and requests for data or work. There are no small impacts—every time an engineer is set onto an unplanned task much more is lost than the direct time applied to that task. And it's a truism that any minor change carries risk.
To control internal scope creep, at the outset of the program, review with the team the program ground rules:
■ State clearly that the scope of the project is to do whatever is required to meet minimum requirements, and explain clearly the link between the so-called improvements and budget and schedule overruns, and risk.
■ Define how additions and improvements will be dealt with. Suggest that team members spend no time on them beyond raising the suggestions to you, who will then put them into the “sustaining engineering bin.” Make sure that you do implement such a suggestion box; it is good practice and will give you a head start during the Sustaining Phase.
■ Deletions, simplification—as long as the requirements are met and functionality or quality are not compromised—are welcome, but their impact must be thoroughly analyzed to ensure there are no hidden impacts that would make the apparent simplification into a problem down the road.
Obtain agreement on these working principles from the team. Post them on the team intranet, if you have one. Make sure that all new additions to the team are shown the ground rules and buy into them.
Managing Scope Creep. Scope creep, no matter how much one tries to control it, sometimes is inevitable. When it happens, the project manager must switch to protecting the boundaries of the baseline project and clearly defining the scope of the change.
Protect your baseline. Always ensure that no request for work is accepted without a clear agreement on it being in or out of scope.
If you must start or proceed with work in a “change environment,” always collect all costs associated with what you believe is out-of-scope work, including indirectly impacted work in other areas, in a separate cost account, and document in writing what the charges are for and why. If your change-of-scope proposal is rejected, the worse that can happen is that you will have to move some hours back into the established cost accounts.
In most cases, upon receiving a request for change it is in your best interest to minimize the magnitude of the resulting change. Therefore it is recommended that you help your customers analyze the options, help them analyze how and to what extent their proposed changes mitigate perceived problems. If needed, help them perform a cost/benefit/risk analysis showing what their money will buy them in system functionality improvement. Maintain the cost of any such activities in a separate cost account to be covered by the resulting change-of-scope proposal.
Changes of scope must be thorough, looking at all possible impacts on all aspects of the program, including impact on risk—every new feature, no matter how benign, adds risk. A project-specific change-of-scope proposal checklist is a good idea for projects that expect or experience significant change traffic. The checklist should be based on the project schedule, at a level that includes all the tasks on the project, and should be used to establish the impact of the proposed change on all areas of the project. Use this checklist consistently to ensure estimate accuracy, and show it to your customer (if your relationship allows it) to obtain customer acceptance of the checklist as a tool and communication device.
Do not take any risk to minimize the impact of a change-of-scope proposal. Do not assume a “success oriented” approach, do not ignore risk, do not “parallel up” activities to shorten the schedule impacts. Submit a change-of-scope proposal that reflects the true impacts of the change, and negotiate from there.
NO MATTER HOW WELL ORGANIZED a project is, how good a team working on it, how well it is supported from within the organization, uncontrolled scope creep can break it. It is the project manager's responsibility to avoid scope creep, or, if needed, manage the incorporation of the new scope into the project in the best possible manner. ■
Reader Service Number 030
