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.

10 Golden Rules of Project Risk Management

Three red dice reading: Manage your risk

The benefits of risk management in projects are huge. You can gain a lot of money if you deal with uncertain project events in a proactive manner.

Project Planning in a Nutshell

Gantt chart

This article provides an overview of why it is important to prepare a project plan. It also shows what elements a good project plan will include.

Building Teamwork

Business colleagues arranging multicoloured labels on a meeting table

Teamwork isn't something that just happens. The project leader needs to put in the time and effort to build the team and help everyone get along. Here's how.

Agile Through the Waterfall

Agile and waterfall tag cloud

Many organisations have adopted Agile practices into their development methodologies and they have proved to be successful for the organisation as a whole.

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

Samara Grantham commented on…
12 Tips for Being a Good Manager
- Thu 1 December 2:46pm

Adolfina commented on…
Introduction to Project Management
- Mon 21 November 9:52am

Edward Brown commented on…
Project Status Reports Everyone Can Understand
- Wed 16 November 3:38pm

Latest tweets

Business Book Reviews • Re: Project Management Booklist #projectsmart #pmot about 12 hours ago

General Project Management • Prioritising Change Requests #projectsmart #pmot about 12 hours ago

Managing IT Projects Offshore: The Project Manager's Perspective #projectsmart #pmot about 17 hours ago