What is Scope Creep?
Scope creep is the bane of a project manager’s existence. It happens all the time. You have a project that you’ve painstakingly planned out, you know exactly how it’s going to progress, and for a while, everything is going smoothly. Then, as you’re about a quarter of the way into the coding process, your client contacts you and says, “Could we change feature X so that it does behavior Z instead of behavior Y?” Then the avalanche starts.
“Can we add feature A?”
“How about feature B?”
“You know, feature C is just something we can’t live without. We need to add it.”
“We need feature D added asap.”
“Why isn’t feature E in there? What do you mean we didn’t scope that? We can’t live without feature E!”
And so on…
The scope of the project continues to creep slowly into new territory, and the project becomes larger as the changes and additions pile up and begin to affect other aspects of the project already completed, and now they have to be redone.
Scope creep usually begins with small requests; tiny adjustments to the defined requirements, that gradually become bigger. Over time, those requests can spell disaster for a project.
The Risk of Scope Creep in an Agile Project
Scope creep can be catastrophic in waterfall-style projects, but it can be a significant problem for agile projects as well. Agile documents, by their very nature, are somewhat fluid and intended to be easily changed. They are living documents. The temptation with such documents is to readily agree to changes without giving proper consideration to the implications.
Another problem area arises because of the natural client involvement in an agile project. When the client receives regular and frequent deliverables, elements that require change are spotted and dealt with quickly. However, this also creates an opportunity for additional requests that are beyond the initial scope.
I once worked on a large custom software project that ultimately failed due to these issues. The problems began with inadequate planning and a long list of must-have features as opposed to an effective client brief. No project brief was ever written. It was supposed to be an agile-type project, but no sprints were ever planned. Instead of concrete deliverables for individual sprints, the client was given access to the development version of the project online to test daily as it was being coded. This led to frequent complaints about broken features; which were in development - not broken. The client became increasingly dissatisfied as they used the development version of the software as if it were a completed production version. No stakeholder management plan was ever developed, so there was no plan for dealing with the situation other than complete capitulation. Once the project manager established this pattern with the client, it spread throughout the agency. The client stopped sending change and additional feature requests through project management channels and sent them directly to the development staff, expecting them to be addressed immediately. The scope ballooned as the project manager lost control of the project and the client. The entire project ultimately became an unmitigated and expensive disaster.
Using propositional logic to summarize this chapter so far, we can identify the following true propositions:
Proper planning is essential to the development of effective documentation.
The development of effective documentation is essential to successful project planning.
Proper project planning is essential to the success of any project.
Therefore, proper documentation planning is essential to the success of any project.
Mitigating the Risk
So how do you mitigate the risk of scope creep? We’ve already identified the answer: planning. You need a plan to deal with scope creep when it happens. Two of the most useful tools are an effective client brief and a stakeholder management plan. The client brief is the first document you and your client formally agreed upon, and it forms the foundation for your relationship as well as for the project. Ensure that your client brief clearly defines the business requirements, the expected deliverable(s), and the success criteria for those deliverables.
Document a plan for handling change and additional feature requests. Before agreeing to any change in the original scope, thoroughly research and document the change and its implications for the rest of the project, and present your findings to the client.
The SMP will provide additional insight into managing the relationship with your client, and when coupled with the client brief, can provide additional protection against scope creep.
Let’s Recap!
Scope creep begins with small requests, but can ultimately spell disaster for a project.
Regarding planning:
Proper planning is essential to the development of effective documentation.
The development of effective documentation is essential to successful project planning.
Proper project planning is essential to the success of any project.
Therefore, proper documentation planning is essential to the success of any project.
The best tools to mitigate the risk of scope creep are an effective client brief and a well-prepared stakeholder management plan.
In the next chapter, you’ll learn how templates can simplify your documentation efforts.
