At the beginning of a project, we have a pretty good idea what the scope of it would be (most of the time). During the life of a project however, we find that the scope has a life of its own and keeps evolving. And most of the time, this evolution affects not only the timeline for implementation, but also the budget.
What is scope
According to PMI, project scope is the work required to output a project’s deliverable.
So what does that mean? Simply put, it means all the work that needs to be done to get the project done.
It means that we have a set of deliverables that need to be identified and reached by the end of the project, while using up some necessary resources and processes to do so.
What is scope creep
Scope creep comprises of all the work that has not been captured and agreed-upon scope.
How does scope creep appear?
There can be various ways that we can get scope creep.
Sometimes, the client just “remembers” to add something new in the requirements, while other times the team can think something could be common sense and needs to be added.
In some cases there has been things that have escaped the initial requirements, and sometimes it is simply because the team had bandwidth and has begun working before the requirements and designs have been completed.
What to do to control scope creep
Communicate with stakeholders
Have a transparent and regular communication with the stakeholders, starting with before the actual initiation of the project.
Also, invest in a good relationship with that customer – and by good relationship I do not necessarily mean friendship, but actual trust and understanding.
Define the scope well
From the beginning of the interaction with the customer or stakeholders, we have to try to understand what its needs are, and how we together with our teams can help.
Following further discussions with them, we can compile and better define their needs and our goal, define the scope.
Get agreement from the stakeholder on the scope
Defining the scope is not nearly enough to get the project up and running and bring it to a successful fruition. We need to also have the customer or stakeholders agree on the scope.
If we do not get an agreement on it, we either misinterpret it their needs, or we leave the door open to unwelcomed changes during the project. These changes will sum up to scope creep and frustration team, stakeholder and upper management level.
So before beginning actual implementation of the project, we should insist and get a sign-off of the scope from the stakeholders.
Progress and Risks Transparency
As mentioned a few rows above, constant communication with the customer and/or stakeholders is key to having a trusting relationship.
Keeping them in the loop helps us solve some issues faster rather than hiding constantly. Also, having them know the progress avoids them from being in constant fear of what is happening and if things are going to be done in time and if applicable, budget.
Prioritization
When defining the features, there are different things that might occur:
1. Features needed require more time and/or budget allocated than timeline needed
2. Dependencies can block progress on certain features
3. Stakeholders do not agree on the features needed
This can mean one of 2 things: we are either blocked from initiating the project, which will create delay in the release, or we are able to be more agile and initiate with a small scope for a limited amount of time.
In both of these situations, one thing can help: prioritization.
When we have a limited timeline, we need to discuss with the stakeholders about what is most essential for their product, an MVP (minimum viable product) – either for an initial phase or release to the public. For situations in which we are not timeboxed, we need to prioritize in order to give regular demos and UAT for the stakeholders, to make sure we are progressing in their wanted direction.
Challenging change requests and negotiate what to take out in order to reach that timeline and cost, split it in phases should be the norm for us in order to get to a satisfying result.
As a note here, trying to understand the business behind these requests will help us even more when challenging, as well as some end-user psychology and analytics.
Change Management
During the RACI and kick-off, we should also establish who can decide on changes and approve them, as well as the process around them.
It is crucial we include this in our initial communication, to avoid confusion at a later date when we are pushing back on certain things.
Use tracking tools
All good so far if we have the scope defined and agreed upon.
During the work on the project, things can come up regardless, be it some small bits and pieces that the client needs changed, or actual dependencies and fixes that we could hardly anticipate.
We need to keep track of the features we are implementing, and also of these updates.
Also, if new requests come up, we should include these, regardless if we are implementing them or not. This will help us quantify the time we are spending in understanding those, the extent of the changes the customer/stakeholder wants and deviation from initial scope, as well as prepare, when needed, for a future phase in the product.
Aside from the changes that the customer requests, it happens sometimes that the team members find something that they believe should be included, let’s say, due to common sense.
Or they find improvements that would be perfect.
Having everything tracked will help also notice such things (although regular updates from the team members are needed as well for this).
Avoid letting the customer or product appeal directly to the team
Changes can come up, but an important thing we have to keep in mind is to not let the stakeholders directly communicate this to our team.
The team will most likely end up feeling too much pressure and can sometimes end up implementing those requests in the detriment of essential tasks.
I hope you got a general idea of the scope creep and how to handle it, at least based on my experience so far.
Leave me a note:
If you have some more ideas, feel free to reach out at say-hello@projectmanagementlifopedia.com
silvana comanici-stoianov 