Scope creep occurs when requirements are added to the project scope in an uncontrolled manner. Customers often cause scope creep by adding requirements such as new functionalities during the course of the project that were not agreed upon. But the development team itself can also be responsible for the uncontrolled addition of requirements. Sometimes they develop more than was requested. Due to scope creep, effort and costs grow uncontrolled in the project and agreed timelines and costs cannot be met. Therefore, this risk has to be controlled. It is THE problem in agile project management methods that emphasize flexible addition of changing requirements.
Often, the blame for scope creep cannot be placed on the stakeholders alone. For example, it may be the case that the project scope and requirements were unclear and insufficiently specified, or that customers were not sufficiently involved in the project work. Therefore, the stakeholders do not understand why the requests are not part of the agreed project scope. Scope creep can also result from unrealistic promises made by management, or because changes to the scope were insufficiently controlled. When the project scope cannot be defined, it is called a scope grope. When the project scope is completely changed, it is called a scope leap. Scope creep is also called requirement creep, function creep or feature creep and is characterized by the uncontrolled addition of new requirements.
Gold plating can also be a reason for scope creep. In this case, new functions are intentionally added to the project scope and more is delivered than required. In this case the developer team itself is the cause of scope creep, because it wants to deliver more than originally agreed on.
To prevent scope creep, or rather to control it, there are several measures. First, requirements must be formalized and written down. Create a place where every requirement ends up so you can keep track of it and ensure traceability. This keeps the impact of changes to the project scope more transparent.
Customers should also be involved from start to finish. Often, customers are only asked at the beginning what they want and then there is not enough communication until the product is ready. This can lead to dissatisfied stakeholders because they may have imagined something different. But even if customers have always been involved, misunderstandings can still occur. To reduce this risk, it is recommended to use use-case diagrams or system context diagrams.
All project participants should clearly understand the requirements. It is therefore worthwhile to subject them to a review. In this way, ambiguities, discrepancies and errors can be eliminated right from the start. This approved status can then be used throughout the project to make it clear to the stakeholders that a further request will involve effort, costs and delays.
A clear process should be in place for change management. Each change request must then actually go through this process. Requests should not be accepted through emails or verbally, or the amount of work will be underestimated. It should be made clear what exactly the change involves, what impact it will have and what risks are involved. This will allow you to control additional effort and associated costs.
