What is Scope Creep?
Scope creep is an unapproved variation to the scope. This could impact the Product Scope (the deliverable) and/or the Project Scope (the work).
Product Scope Creep
This would be a variation to the agreed scope which affects the deliverable or project outcomes. This could be the addition of new features, new unplanned aspects, or changing the product’s grade.
An example: An agreement to deliver a Basic Website slowly turns into the development of a complex Website with an online store, payment gateways and a multitude of additional functionality.
Project Scope Creep
This is a variation to work, outside what was approved. Commonly this is seen as the engagement of any tasks outside the Work Breakdown Structure. Project Scope creep is normally a result of product scope creep; additional work done to yield unapproved changes. As per the earlier example as the sophistication of the website grows, so does the work required to make it happen.
However, project scope creep isn’t always an effect of a change within the product scope. Project management itself is a victim to project scope creep. This can include aspects such as a change in reporting, communication, documentation and even the degree of management. In reference to the website example above; project scope creep could occur simply through increasing the frequency of status reports from weekly to daily. If a report takes an hour to generate the time allocated to reporting has increased by a factor of 5. You can see the work has increased, but the product scope has remained unchanged.
Scope can creep both ways
Every text defines scope creep as a slow growth to the project’s scope. However, in some projects scope creep is actually a reduction of work from the agreed scope. A classic example is reporting; for instance, the project was initially set up to have monthly status meetings with the client. As work got busy, appointments were not made and they slowly fell off the project’s scope. Similarly, functionality that was initially requested and scoped for but slowly becomes obsolete or “too hard” to achieve, well that criteria starts to disappear until someone notices.
Where does Scope Creep come from?
A number of factors can be associated with originating scope creep, commonly creep comes from:
Casual requests for slight adjustments in features, or additional reporting requirements are classic points of origin for scope creep. Generally, the smaller the change and the more casual the setting in which the request is made, the less chance of it going through a formal change process.
For example: you are having a coffee with a client who drops into the conversation that his manager is now asking him to report weekly as opposed to monthly and says “I don’t suppose you could send me the status reports on a weekly basis could you”? Sure, why not…..after all it’s just a simple request. It’s the sum of these simple request that cause the issue; an extra hour here, quickly adds up and erodes the available time you have to manage the project.
The Project Manager
In the pursuit for perfection, or something along the lines many Project Managers sneak in additional aspects. The perspective is often that it either should have been included and was an oversight by the client or would undoubtable add value. Other common situations arise from the “opportunity of the moment”. For example; you are managing a project and since a task has completed early, the machinery you have hired is still available for a few more hours, why not do a little extra?
The Project Team
“Gold platting” is a term used within project management to account for the embellishment of the project scope by the project team. This changes are not approved, nor reported and take the shape of an increase in grade, quantity etc. The direct impact is seen on time and materials, but since the actions are not approved they can be hard to charge to the client.
Most situations of Gold Platting occur from the desire to do a “better job” than asked. It is often accompanied by being allocated too much time and or resources to complete a task. For example, you are part of a project team of 3 and your team has been allocated an entire day to complete a task that was initially scheduled for 1 person. So what do you do? Why not increase the scope since you’re there anyway?
When contractors are provided a vague scope and paid on a time and materials basis, it’s in their best interest to increase the time and or materials. A classic example of this is taking your car for a regular service, just to receive the pleasant news that your brakes have also been changed as well as a range of other urgent repairs. You feel thankful until the invoice arrives.
What causes Scope Creep
I would say this is where most of the issues stem from. That is the failure to sufficiently identify the inclusions and exclusions prior to commencement of the project. The scope is basically a delineation between what will be done/included and what won’t be. Simple in theory, but the scope creep devils in the detail.
Using the example of building a website.
A client sends you the following email:
Hi, I would like a price for building a website for my small business.
- As the Project Manager: you assume it will be similar to your past works, the client surely has seen your portfolio so they should be expecting something nice and basic.
- As the client you are expecting something highly sophisticated
It’s obvious that without drilling down further there are going to be some issues in this project.
Consider this circle, everything inside is within the scope, everything outside is an exclusion.
As a project manager this is the scope definition, you will use this as a basis for calculating the cost, time and resource requirements. You will then add a modest profit margin and send the quote to the client.
Now consider the circle in red. That is what the client is expecting.
You can see they are expecting a lot more than you had budgeted for and quoted. This realisation may not occur until halfway through the project and what follows next is a nightmare. The client will push for the project to include their expectations, whilst you will try to stop the scope creeping past what you had budgeted for.
At some point both parties will realise that the scope wasn’t as clear as they thought and there are some big holes in the scope. Each gap in the scope is an aspect where a decision has not been formally made on whether it will be included or excluded. Both parties become hopeful that it will pay favour to them. The uncertainty of what is included or excluded creates a perfect environment for scope creep.
An incredibly detailed scope can still give rise to creep and in some cases an overly complex WBS or schedule simply isn’t read or followed. All that time and attention to detail fall through the cracks as the reality of “just getting the work done” takes over.
Lack of monitoring and control leads to scope creep and the longer the absence of monitoring, the larger the potential for creep.
Lack of communication
Clearly communicating the parameters of each task with specific focus on what has been excluded is a good measure in the minimisation of creep. If the scope hasn’t been effectively passed on to the project team then it is very likely creep will occur. This translates to both the product and the project scope. In relation to project scope creep this includes both the work which should/should not be done as well as clarifying any specific work methods which should be followed.
No central point of communication
The lack of a central point for communication often results in additional work creeping in. This often results if the project team or contractors are approached directly by the client and request small additions to the scope. If the flow of communication hasn’t been directed to pass through the project manager, the potential for scope creep is huge.
No formal change process
Well this should be obvious but many projects don’t have a formal process for changes. In many cases changes simply occur after a verbal encounter. I hope you can see the issues there. The key difference between a change and creep is that of approvals. If a change is identified, planned for and approved it is not scope creep.
Having too much time or budget can actually be a doubled edge sword. In many cases simple tasks turn into complicated exercises simply as there is too much time, cost or resources assigned. Parkinson’s Law is a good consideration here; work will expand or shrink to fit the time (and cost) available.
How to reduce creep
Define the scope
Tools such as the scope matrix are extremely useful in this exercise. The greater the number of factors which are identified as either inclusions or exclusions the less the chance of scope creep. Visually, that reduces the number of gaps in the circle enabling us to move from this
Managing scope is also about managing expectations. This may require translating the features into benefits that the client can relate to, for example; rather than stating a feature, such as; “the site have a SSL Certificate”, it is clearer to translate that into a benefit; “your client’s transactions will be secure when paying through the website”. This helps in better framing the scope to the client and having a shared understanding without needing the technical knowledge.
Communicate the scope
From the client to the Project Manager, the stakeholders to the team each should be clear of the scope they are responsible and working towards. Setting the culture that assumptions should be clarified prior to taking action is also a good strategy.
Set up your quality plan to review the work at suitable frequencies, regular status reports and meetings with the client. Where possible have the client personally inspect the deliverable at key stages to validate you are on the same page.
Feel free to add your comments on what causes scope creep in your environment and how you deal with it.