I first heard about scope creep just a few weeks ago. When I started to dig into its meaning, I realized that it is part of our everyday.
What is Scope Creep in project management?
First, it has nothing to do with Radiohead’s song.
2018th PMI’s Pulse of the Profession defines it as the uncontrolled expansion of product or project scope without adjustments to time, cost and resources. Any similarities with our projects are, therefore, only coincidental.
I used to analyze deviations of millions of USD in Technology projects. Now, I’m sure that a significant part of them was due to scope creep, and that great part of it was avoidable.
But let’s see, if we are aware of this, how does this still happens in many companies of different type of industries worldwide?
It’s not only that the scope increases, but it also happens slowly, in a way that we don’t notice the full impact at a glance. That’s why it’s tricky.
It’s the sum of lots of small changes of scope that individually represent nor many days of effort, neither a significant change of the original scope. That’s why when we consider the sum of them at the end of the project we notice that we have a major deviation in costs, time and/or resources, but it’s too late to react.
Which could be some of the reasons for Scope Creep?
One in which I see ourselves reflected is having poorly defined or unclear scope definition. That can make us lose lots of time and money.
If we don’t include in the scope all the assumptions to take into account to define and estimate it, our customers will be able to request for anything that it’s ambiguous or not clear, by the dates agreed initially and not having to pay even one more penny. Legally, they have the right to request for that, as it hasn’t been limited, so we need to be extremely precautious.
Another one could be the lack of change management process. It can lead to agreements reached between our customer and the developers or implementation consultants about tasks that seem simple, but take time and might have a positive impact and add value to our clients. We could have charged for them and negotiated an extension of the delivery date.
It’s a problem if this is not informed to the project manager. It’s even worse if the project manager is aware and allows this to happen.
As we highlighted, analyzing requirements is vital. Not specifying them on time can lead to rework or an extension of delivery time.
Imagine for example that we forgot to request a server, and it needs to be imported from the US to Argentina. We might have a 3 to 6 months delay in the implementation phase. It can make our clients not only being delayed in the deployment but also having penalties for this in certain circumstances.
Last but not least. Having projects freezed for a long time (or blocked) also drifts into rework.
Not executing projects in the planned time difficult our portfolio planning. It can also make us have a bad relationship with our clients due to the need to take up again a project and leave another behind. One of the most common causes of this is not having prerequisites ready.