Someone asked me the other day – “how do you handle scope creep in your development projects?” I thought I’d share the answer with the wider world!
First of all, what is scope creep?
New software is usually developed as a result of a customer (an internal or an external organisation) identifying a need. The next step is to specify how the software will meet that need; specifically, what functionality will be developed. This is the ’scope’ of the project. The project plans are drawn up, based on the estimates for developing and delivering the specified functionality, and an end date is agreed.
Development starts and the project seems to be progressing well. But then the customer realises that there are additional requirements they forgot to mention, or extra elements of functionality that they need. Often, adding these extras will cause the project duration to be extended, resulting in missed deadlines and increased costs, leading to erosion of margin on the project and potentially customer dissatisfaction and loss of credibility due to late delivery.
So what can we do about it? Our solution is a functional specification, written in terms that the customer can understand: we often write a ‘walk-through’ of the process that the software will support, illustrated with mocked-up screen shots. This helps clarify how the new system will work from the user’s point of view.
The functional specification is agreed and signed by the customer, and it includes a Scope Statement. This states that only the functionality which is explicitly described in the specification is included in the project scope, and that anything not described is outside scope.
If the customer subsequently identifies additional elements, reference is made to the specification: is the required functionality described or alluded to? If not, then the new development is outside scope.
We work out the impact of developing the new functionality: what extra effort will be required? What effect will this have on the overall project duration? What additional costs will be incurred and how will this affect the project margin?
If the impact is trivial, we’ll often agree to include the new functionality in the existing project, but we still issue a revised specification. There’s a danger that the customer believes a precedent has been set and that further revisions will be made in a similar way, so we make clear the reasons for allowing the revision in this instance.
However, usually the additional development will cause delay (as it affects the critical path) and/or extra cost. The implications of the revision in terms of its impact on timescales and costs are discussed with the customer, and a separate specification of the additions and changes is written (with its own Scope Statement). It’s then up to the customer to decide whether they are willing to pay more, and if they can accept the revised end date for the project. If they agree, the new specification is signed off as before.
Now you may think that writing a sufficiently detailed specification to be able to make the Scope Statement involves more time (and cost) than is warranted by the value of the project as a whole. If this is the case, we assess the likelihood of the risk – based on our knowledge of the customer and how confident we are that all the requirements have been identified – and the possible impact. Then we build in sufficient contingency in our estimates of time and cost to cover all but the most major revisions to the specification.
Linda Russell 