Controlling Scope Creep

It is quite normal that the business requirements for a project will change after the project has started – requirements become clearer once tasks start to be completed, market conditions change, budgets, priorities and resources are altered. So changes to the scope of a project shouldn’t be unexpected and should be embraced as a means of delivering just what the client wants. A project on which change is resisted will usually end up delivering something out-of-date or irrelevant; or something that doesn’t quite meet the business goals.

However, poorly managed changes where there is no clear justification for the change, or where it doesn’t directly contribute to meeting the business objectives, can lead to costs and timescales that become out of control.

Scope creep is the name given to these situations where constant changes are being made to the project without a business justification. Some clients and stakeholders use change requests as a way to sneak in features or functions that would not have been agreed in the more rigorous requirement phase of a project. These “nice-to-have” features are a serious risk to the successful delivery of a project.

You will need a strict change management process in place that assesses every single change request and aligns each one that has been agreed with a specific business case or objective. But change management doesn’t have to be a battle between project manager and stakeholders – communicate clearly to those involved that if unnecessary changes are made it will simply jeopardise the whole project. If the risks are made clear to everyone there is much less likelihood that unnecessary change requests will be submitted.

Start at the Beginning

This type of clear communication should be in place right from the start of the project and re-iterated whenever necessary; controlling scope creep should start well before any changes are requested. Controlling scope starts by first clearly defining the scope and ensuring there is agreement on the scope definition from all concerned; without that you will be fighting a losing battle. If you are working in an agile environment then there should be a short scope definition for each iteration.

A sensible project manager will also factor in some contingency resources for those changes that are necessary.

Prioritisation of Changes

But what happens when the requested changes are not just “nice-to-have” but essential for the project success but the contingency has been used up? In situations like this, one of the commonest reasons for failure is poor prioritisation. Prioritising changes should be done on a rolling basis; when a new change request is received it has to be reviewed in the light of all existing changes and priorities re-assigned if necessary. Less critical issues may need to be deferred to a later date to accommodate new, more critical issues. Such decisions will need to consider any additional costs or risks or any other implications and should be made in consultation with all stakeholders.

Stay Focused

It can be difficult to stay focused when there is a constant stream of change requests but if they are not controlled and prioritised effectively the whole process can affect the quality of the end-product and lead to delays in delivery. Changes to project scope always need to balance the expected benefits with the extra resources required. The project manager’s aim should be to deliver maximum benefit for the agreed cost but where an extra cost is unavoidable to meet the client’s aims the PM should be able to accurately describe where costs have already been incurred and what benefits can be delivered for the additional cost.