Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

Dealing with "Scope Creep" in Software Development Projects

~ By Linda Russell

Dataflow chart, shallow focus in middle of chart

Scope creep is a significant risk in software development projects. We discuss why this is so, and how to avoid or at least mitigate the risk.

What is Scope Creep?

New software is usually developed as a result of a customer (which may be 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.

How to Deal With Scope Creep

It is important that a functional specification is produced at the outset, written in terms that the customer can understand. For example, a walk-through of the process that the software will support, perhaps illustrated with mocked-up screen shots, will help to clarify how the new system will work from the user's point of view.

The functional specification must be agreed and signed by the customer, and should include 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."

When the customer subsequently identifies additional elements, reference is made to the specification: is the required functionality described or alluded to? If it is not, then the new development is outside scope.

The next step is to 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, it may be agreed to include the new functionality in the existing project, but ideally this should be stated in writing by issuing a revised specification. The danger here is that the customer believes that a precedent has been set and that further revisions will be made in a similar way: it is important to communicate the reasons for allowing the revision in this instance.

It is more likely that the additional development will cause delay and/or extra cost. The customer needs to be made aware of the implications of the revision in terms of its impact on timescales and costs, and a specification of the additions and changes should be written (with its own Scope Statement). It is 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 should be signed as before.

Do we Really Need a Scope Statement?

You may think that writing a sufficiently detailed specification to be able to make the Scope Statement would involve more time (and cost) than is warranted by the value of the project as a whole. For instance, if the whole project is expected to only take a few weeks and it would take 5 days to write a detailed specification, a cost/benefit analysis would show that it is not worth doing.

If this is the case, assess the likelihood of the risk (based on your knowledge of the customer and how confident you are that all the requirements have been identified) and the possible impact, and build in sufficient contingency in your estimates of time and cost to cover all but the most major revisions to the specification.

Linda Russell has an M.A. (with Distinction) in Technical Authorship, and over 25 years' experience in software implementation and consultancy.


Be the first to comment on this article.

Add a comment

(never displayed)

What is the sum of 1 + 2 + 3?
Notify me of new comments via email.
Remember my form inputs on this computer.

My Story: Working Smarter; Not Harder

Woman thinking with a light bulb drawn on a blackboard

When you realise that you have the power to change your beliefs and remove a limiting factor that has been constraining you, you have an AHA! moment.

Project Plans: 10 Essential Elements

Four colourful tags spelling the word plan

A project plan is more than just a Gantt chart, but do you know what you must have in your plan? This article takes you through the ten essential elements.

Helping Project Teams Succeed

Business team brainstorming using coloured labels on a table in an office

Project teams will be successful when the right environmental conditions exist; sadly this is not always the case.

How Agile Practices Reduce Requirements Risks

Road warning sign - Risks Ahead

Every software project carries some risk, but many of these risks can be mitigated. That's true of problems related to product requirements.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.

Latest Comments

Joseph Marandus commented on…
How to Apply PRINCE2: Engaging Senior Management in Your Projects
- Tue 21 March 1:59pm

Janine Greene commented on…
The Role of the Project Manager
- Fri 17 March 1:30pm

Ben commented on…
The Role of the Project Manager
- Sun 12 March 12:30pm

Latest tweets

General Project Management • No Sponsor #projectsmart #pmot about 8 days ago

General Project Management • Re: Software Product Delivery Plan for an Agile project #projectsmart #pmot about 9 days ago

General Project Management • Re: How do you track who from your human resources have related… #projectsmart #pmot about 10 days ago