No, I’m not talking about the new vine on your deck trellis. I’m talking about scope creep. 
It’s every project manager’s nightmare. The project starts off at a manageable modest size and in the blink of an eye, it’s a beheamouth of unmanageable porportions.
In one of HMS Software’s first ever mandates back when we were just getting started, we had a client who asked us to configure their project management system with multiple baselines. This was unheard of in project management software of the day so we had to do some modifications to accommodate the request.
“Why would you need more than one baseline?” we asked naively.
“Ah, you don’t know the ways of the project management world,” our client informed us. “There is the original-original baseline. That’s the one we make when we first create the project. Then there is the official engineering baseline. That one includes any changes we’ve made to the original-original baseline over the term of the project that the head office has approved. Then there’s the internal engineering baseline. That’s the baseline that engineering is actually working against because they know the official engineering baseline is a fantasy. Then there’s the expected baseline. That’s the baseline that will become the new official baseline when we can propose it to head office and get it accepted. That’s the baseline that the engineers project will actually happen.
Depending on who asks, we need baseline-vs-actual reports for any of those four baselines.”
We were stunned. But we did what the client wanted. While we worked on the deployment of the project system, there was a particular project that came up for head-office review. It was a technology project that had been originally authorized 4 or 5 years previously. The original-original baseline had been $4,000. The actual was close to $4,000,000 (No, that’s not a typo. The original budget was four thousand dollars. The actual spent was close to four million dollars.
The project was cancelled.
Over the years we’ve encountered many companies with similar methods which attempt to control scope creep. Here are a few thoughts on how to keep yourself out of the creepier side of scope.
How did we get into this mess?
People almost always get into these problems with the best of intentions. In my own office, when this occurs it is usually because we are too responsive for our own good. We’re trying to satisfy the client before determining if just answering today’s request with changing something is healthy for either of us. Here are some of the most common ways people get scope changes creeping into their project:
Insufficient Scope
It’s obvious to say but some people just don’t look at everything involved when they scope the project. Did you think about training? Did you think about the links to other systems? Did you think about fixing inevitable problems after delivery? Did you think about risk? Did you think about all the existing systems that are affected? Did you think about the functionality in the system you are replacing that you don’t use but that someone else might need?
Taking your time to make sure you allow for all of the permutations of what you’d like to create is key. Working with your vendor to see what else they can see from their perspective is key also.
Not including all the relevant parties
It’s a classic project management error that can cause significant scope creep. A team starts working on the scope for a project but makes a wide range of assumptions for others who are not present and who are not consulted. Only as the project nears completion do those people get involved and suddenly they have a lot to say.
Not walking the business flow from beginning to end
Short-sightedness in creating scope is also a common issue. The project team identifies a function they desire but they don’t walk through all the implications of that function. As a vendor, we often have to do that type of walk-through and it is common to unconceal a plethora of issues that no one thought about. In some cases we find that the request actually contradicts other functions that were requested. In other cases we find the request doesn’t deliver the result intended because of what happens later in the workflow.
Not associating changing functionality to a business requirement
I’ve written about this before but it is a common challenge. Project team members make a series of requests but don’t pause for each one to determine how that request will affect the business. We’ve taken the position with many mandates that each request in the scope must relate to some business purpose else why would we do it at all?
Thinking more of “how” rather than “if”
This takes some culture change in many companies. I consistently ask our staff to justify a requested change from themselves or the client not just with how to do it but whether we should do it at all. For many years I would be faced with a request and the answer, “Because the client wants it” as the answer to, “Why should we do that?” Now my staff challenge clients themselves to ask what the purpose of the request is, to point out how that request might affect other elements of the project and determine if it should be done at all.
Being determined to do it all immediately
Some organizations have a challenge going through a project approval process and, as a result, they try their best to go to the money well a single time rather than making a phased approach. Our experience shows this often to be a mistake. Once a system is in use, new requests for changes from the client are almost guaranteed.
There are no doubt a hundred other causes of scope creep but you’re probably asking yourself if there is light at the end of the tunnel. Is scope creep inevitable?
It doesn’t have to be.
How do we avoid getting into trouble?
Here are a few ways that organizations can avoid or mitigate scope creep.
Start with a commitment to avoid scope changes
Sound obvious? It’s sadly not. Many organizations avoid talking about scope creep at all given how little it’s liked. As a result, those organizations have few tools and techniques in place to avoid the issue.
If you articulate your determination as an organization there are a few things you can put in place that have an almost immediate effect:
Include those affected
If you make a conscious effort to include those who may be affected by the project, you have a better chance of hearing what they need and managing both their objections and expectations long in advance. This can have a dramatic effect on how many changes get requested later.
Review scope before approval
A formal review of the statement of work by all those parties we just talked about is a good place to start to find any holes you didn’t expect when you wrote it in the first place. The review process must have a method for everyone to comment and for those comments to all be resolved before moving forward.
Make an allowance for what you don’t know
Making a contingency budget will allow you to deal with small scope changes without having to go back to a re-scoping exercise. How much contingency you set aside is highly dependent on the amount of uncertainty or risk that you’re confronting in your project.
Monitor scope changes
If you can’t measure something, you can’t manage it. So, set up baselines or other measurement mechanisms to determine if changes are occurring. Those baseline measures will allow you to determine the size of any proposed changes too. Whenever you do a change in your official scope, don’t erase the original, just make sure you reset a new baseline so you can start measuring against that.
Monitor and set reporting thresholds
Along with monitoring goes making a determination that it’s time to pause and relook at your scope. In our projects, we always know there is a small amount of contingency available and we set our own thresholds to take that contingency into account. It’s important to set the rules for what your thresholds are before the project starts so everyone is aware of how much scope change it’ll take to make the project pause and regroup.
Make sure change requests serve a business purpose
I’ve talked about this before from numerous perspectives. Often requests for changes will arrive in a project for purposes that are not associated to business value. Or, the changes may conflict with other functionality that is associated to business value.
Many requests are often about familiarity and comfort
One of the most common types of change requests usually has something to do with familiarity or comfort. The client looks at what has been delivered and says “That doesn’t look like what I’m used to.” This can be frustrating when the entire point of the project was to do something new. This typically means that whatever the legacy system or building or mechanism was is known to the client and what you are now showing is unfamiliar. You need to be able to categorize change requests and their value or purpose so the client can make an informed decision about what they are asking for.
Think in a more Agile fashion
Finally, it’s popular to talk about Agile in software circles these days but I’m really referring here to the Agile concept rather than its entire methodology. Agile at its core means doing things in phases. Whether you call your phase a “sprint” or a “wave” or a “phase” or our “next bit” is less important than the concept of working in small incremental parts. We have had our best success when we deploy not the most we can create but the least with full knowledge of both ourselves and the client that we won’t be done. The sooner the client is using the software in real-life, the quicker we are to get feedback that’s relevant to how they function. Our past experience indicates that no matter how much time we spend scoping the requirements, once the system goes live, we’ll get new requests for changes.
If change in scope is inevitable, the best way to avoid unexpected scope creep might be to plan for it from the very beginning.
