Stop Scope Creep Running Away With Your Project
By Duncan Haughey | minute read
Scope creep is one of the most common reasons projects run over budget and deliver late. Often done with the best intentions, changes to scope during a project is an event best avoided.
Most project managers have experienced a case where the customer asks for something outside the scope agreed and expects it included in the project at no extra cost. In fact, they're probably acting as if it was always in scope.
Defining the boundaries of a project is difficult and without a precise definition, you're heading for problems.
What is Project Scope?
The scope is what a project manager commits to deliver early in the life of a project. Definition of the scope takes place during the requirements analysis phase. The project manager, working closely with the customer and the users, identifies what is needed to bring about the project objectives. The scope gets recorded in the project documentation and agreed with all interested parties.
What Causes Scope Creep?
The primary causes of scope creep are:
- Poor Requirements Analysis
- Not Involving Users Early Enough
- Underestimating the Complexity of the Project
- Lack of Change Control
- Gold Plating
Let's take a look at each in more detail.
Poor Requirements Analysis
Customers don't always know what they want and often have only a vague idea. The
I'll know it when I see it syndrome. Failure to spend enough time gathering business requirements (or assuming you know what is needed) can lead to a need for extra resources, increased cost and longer durations when new requirements emerge. In short, scope creep.
Ensure you understand the project vision. Spend some time documenting and agreeing on the project objectives with the customer. Produce a project initiation document that describes the deliverables and the result. It's a good idea to document what is out of scope, as well as what is in scope, for absolute clarity. Agree on this document with the customer, spending the time to walk them through it, and ask them to sign it off. Don't continue without a firm agreement.
Not Involving Users Early Enough
Thinking you know what the users want or need is a grave mistake. It is important to involve them in both the requirements analysis and design phases. The more involvement they have in the early stages of the project, the more likely it is you'll avoid scope creep.
Involve the users from the beginning of the project, encouraging them to take part in the requirements and design phases. Incorporate their suggestions and ideas into the product. In software development projects, document how the users will interact with the software and develop test cases for use later. Agree on the requirements and design with all the projects stakeholders before the execution phase starts.
Underestimating the Complexity of the Project
You can often predict the success or failure of a project by looking at whether similar projects have been successful in the past.
Many projects run into problems because they are new in an industry and never before done. Nobody knows what to expect. There are no lessons learned and no people to ask. Under these circumstances scope creep can hardly be avoided, causing budget overruns and late delivery.
These types of a project need to have a degree of contingency built into them. Include some slack in your project plan to allow for unforeseen issues and events. Increase the budget to account for extra resources that may be needed. However, don't overdo it, being significantly under budget and delivering too early is often viewed negatively.
Lack of Change Control
You can expect there to be a degree of scope creep in most projects. It is important to design a process to manage these changes. A simple process of; document, consider, approve and resource can be carried out.
Introduce a change control form and change log from the start of the project. Communicate their use to the customer and project team. A formally written change request will allow you to assess the business benefit of any change, and gain approval before including it as additions to the scope. Attach a cost and time to each change so the customer is clear about its impact. Asking the customer to go through a formal process helps ensure there's a clear business value for any changes.
Gold plating is the term given to the practice of exceeding the scope of a project in the belief it is adding value. In software development projects, it is not unusual for developers to add new features and functions believing they will increase customer satisfaction. These changes consume time and budget and are not guaranteed to increase satisfaction.
Make sure all team members are aware of the project scope and concentrate on delivering it and nothing more. Ensure specifications are detailed enough to avoid any ambiguity that may lead to unnecessary work.
Reward team members for delivering to specification, on time and budget. Make it clear that they are not to add undocumented features, but instead, put them through the change control process.
Let the customer decide what to do with any time or money left at the end of the project.
Ensure you set expectations correctly at the beginning of a project, working closely with the users to define what is in and out of scope. Record it in the project initiation document. However, don't assume the customer will read and digest this material. Spend time with the customer to walk them through it and ensure they understand and agree on the scope. Don't continue without a firm agreement.
Often, it's not possible to avoid increasing scope during a project, especially if there is a sound business reason to do so. However, it must be managed properly. Design a change control process to ensure all changes are clearly documented, considered, approved and resourced.
Alternatively, you may wish to prevent changes being added piecemeal during the project and may decide to record them for a later phase of the project. This approach allows delivery of the agreed phase on time and budget, and management of the changes separately.
If you consider that only 32%¹ of all projects fully succeed; then you're better off spending your time delivering the requirements agreed at the beginning of the project and avoiding gold plating.
Scope creep causes many project failures. By taking a few simple measures; you can make sure it doesn't affect your projects.
¹ The Standish Group International, Inc. CHAOS Summary 2009. Boston, MA 02109: The Standish Group International, Inc., 2009.
Note: Where budget and time get increased with scope, the change is not usually considered scope creep.