Scope creep. Requirements are creeping into the project scope.
What is a scope creep? How do they happen and what can you do to prevent them?
1
2
3
4
What is a scope creep? Some examples.
The scope refers to the what is implemented in the project. This includes, for example, the products, services or results that the project aims for. This is based on the requirements – so customers’ requests for the product under development. Often, lots of requirements slip into the project scope because the customers put forth some new requests “whilst you’re at it – could you also add another new feature?” for example. Or your development team is working too quickly and implements another feature that wasn’t agreed upon. A scope creep arises. The workload unwittingly increases and more features are developed without previous consultation. A scope creep is a danger for every project that should be stopped or kept under control.
Definition of “scope creep” from the (PMBOK® Guide):
A scope creep is “adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval”.
Link to: objectiF RPM
Try out objectiF RPM.
Do a test: control the scope.
Try out objectiF RPM.
Enterprise software for increased business agility.
Causes of a scope creep
It’s easy to blame scope creeps on stakeholders and their endless requests, but there are many causes of it. In the case of stakeholders, the cause might be that the project scope and therefore also the requirements were not clear enough, so they don’t understand why the requirements don’t count toward the project scope. Or stakeholders have not been included enough in the project work and therefore they do not have the chance to be clear. In the most simple cases, they just want more than paid for.
A scope creep can also arise from unrealistic promises from management or because changes to the project scope were not sufficiently controlled. Even the development team can cause it – if they are overachievers and want to do more than was agreed upon (see gold plating).
Terms related to scope creep
Scope grope: The project scope cannot be defined.
Scope leap: The project scope has been completely changed.
Scope creep (or requirement creep, function creep, feature creep): new requirements have been added to the project scope with no controls.
Other useful terms:
Gold plating: New features are deliberately added to the project scope to deliver more than agreed upon.
Stop and control scope creep
Normally scope creep can’t be stopped entirely, so it’s more important to be able to control it.
Document requirements correctly
All requirements must be recorded formally to prevent a scope creep – this means written down, and better still, in a tool. This makes sure that there is a defined place where each requirement ends up and makes it easier to keep an overview. It also creates a good basis for requirements management, because traceability is ensured. Requirements can be traced to the stakeholders and their goals and identify system components and test cases. This means that the effects of changes to the project scope are more transparent.
Clearly explain the project scope to the stakeholders
A lot of project managers make the mistake of only including the customers in the beginning and end of their project. Something like: tell us what you want. After this, radio silence and then: here’s the product. In a lot of cases, this leads to unhappy stakeholders who had something completely different in mind. Even when the stakeholder is included throughout the project and communicated with regularly, misunderstandings and the related requirements that they add are a part of project work. To clarify the project scope to the stakeholders and make their expectations more clear, working with diagrams like use case diagrams or system context diagrams is recommended.
Verify and accept requirements and secure them with baselines
So that all project participants understand the requirements properly, a review should be carried out together. This makes sure that uncertainties, errors and discrepancies can be cleared out of the way. When all the requirements have passed the reviews and have been accepted by stakeholders, it is recommended to establish a baseline. This creates a reference point for development which you can refer to throughout the project. A stakeholder is making more demands? You can now refer to the point when she agreed to all thing and make it clear that this additional request will cause more costs, work and delays.
Implement a process for change management
To be able to control a scope creep, you need a process for change management. You have to make sure that each change request actually goes through this process. A lot of requirements can sneak into the scope because one member of the team just includes them orally or via e-mails and underestimate how much work they will take.
For change management, the following questions must be answered:
What does the change include, exactly? What are its effects, for example on requirements, system components, etc? What are the risks associated with it? How does the change influence the costs and workload?
Prevent and control scope creep with objectiF RPM
objectiF RPM is an application life cycle management software with which you can keep the scope creep under control. For a better understanding of the system, you can use diagrams like system context diagrams or record the stakeholders’ goals with goal diagrams. Even requirements and use cases can be recorded in diagrams and in text form and connected with stakeholders, goals, test cases, etc. This way, traceability is always ensured and effects of changes to requirements are controllable. Additionally, you can carry out reviews with the stakeholders and share project content easily. Of course, it’s also possible to establish baselines.
