Stop Scope Creep Running Away With Your Project
By Duncan Haughey
Scope creep is one of the most common reasons projects run over budget and deliver late. Although changes to scope during a project are often done with the best of intentions, scope creep is considered a negative occurrence to be avoided.
Most project managers have experienced a situation where the customer asks for something outside the scope agreed and expects it to be included at no extra cost. In fact they're probably acting as if it's always been included.
Defining the boundaries of a project is difficult, but without a clear definition you're heading for problems.
What is Project Scope?
Scope is what a project manager commits to deliver early in the life of a project. Scope is defined following a period of requirements analysis, working closely with the customer and the users to identify what is required to bring about the project objectives. Scope must be written down in the project documentation and agreed with all parties affected by the project.
What Causes Scope Creep?
The main causes of scope creep are:
- Poor Requirements Analysis
- Not Involving the 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
The Problem:
Customers don't always know exactly what they want and often have only a vague idea. The "I'll know it when I see it" syndrome. A failure to spend enough time gathering business requirements or assuming you know what is required can lead to a need for extra resources, increased cost and longer duration when new requirements emerge; in short scope creep.
The Solution:
Ensure you understand the project vision and spend time documenting and agreeing the project objectives with the customer. Produce a project initiation document that describes the deliverables and the final outcome. It's a good idea to document what is out of scope, as well as what is in scope, for absolute clarity. Agree this document with the customer, spending time to walk them through it, and ask them to sign it off. Don't proceed without a firm agreement.
Not Involving the Users Early Enough
The Problem:
Thinking you know what the users want or need is a serious 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 that you'll avoid scope creep.
The Solution:
Involve the users from the beginning of the project allowing them to participate in the requirements and design phases; incorporate their suggestions and ideas. In software development projects document how the users will interact with the software and develop test cases for use later. Agree the requirements and design with all of the projects stakeholders before the execution phase starts.
Underestimating the Complexity of the Project
The Problem:
The success or failure of a project can often be predicted by looking at whether similar projects have been successfully undertaken in the past.
Many projects run into problems because they are new in an industry and have never been done before. Nobody knows what to expect, there are no lessons learned and no one to ask. Under these circumstances scope creep can hardly be avoided, causing budget overruns and late delivery.
The Solution:
These types of project need to have a degree of contingency built in. Include some slack in your project plan to allow for unforeseen issues and events and increase the budget to account for extra resources that may be required. However, don't over do it, being massively under budget and ahead of schedule can also be viewed negatively.
Lack of Change Control
The Problem:
You can expect there to be a degree of scope creep in most projects, therefore it is important to design a process to manage these changes. A simple process of document, consider, approve and resource can be implemented.
The Solution:
Implement a change control form and change log from the start of the project and communicate the process for using them to the customer and project team. A formally written change request will allow you to assess the business benefit of any changes and gain approval before including them 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 the change being requested.
Gold Plating
The Problem:
Gold plating is the term given to the practice of exceeding the scope of a project in the belief that value is being added. In software development projects it is not unusual for a developer to add new features believing they will increase customer satisfaction. These changes inevitably consume time and budget and are not guaranteed to increase customer satisfaction.
The Solution:
Ensure that all team members are fully aware of the project scope and concentrate solely on delivering it. Ensure specifications are sufficiently detailed to avoid any ambiguity that may lead to unnecessary work.
Reward team members for delivering to specification on time and budget, making it clear that undocumented features should not be added, but put through the change control process for review at a later date.
If there is time and money left at the end of the project, let the customer decide what to do with it.
Summary
So to summarise, ensure you set expectations correctly at the outset of a project, working closely with the users to clearly define what is in and out of scope. Record it in the project initiation document. However, don't assume the customer will read and understand this document. Spend time with the customer to walk them through it and ensure they understand and agree the scope. Don't proceed 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 should be managed properly. Implement a change control process to ensure all changes are properly documented, considered, approved and resourced. Where budget and time are increased with scope, the change is generally not considered scope creep.
Alternatively you may wish to prevent changes being added piecemeal during the project and may decide to document them for a later phase. This allows the agreed phase to be delivered on time and budget and the changes managed and resourced separately.
If you consider that only 26% of all projects succeed, then you're better off spending your time delivering the requirements agreed at the outset, 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.
It was published on 24th November 2007
but when did you publish the article in which date???