Project Scope Creep
Although my organization specializes in the rescuing and salvaging of troubled or failing projects, we spend a lot of time reviewing performance and results to understand where the project when wrong in the first instance. Saving a project before it needs to be saved is a much more positive experience than arriving in to try to rescue a project that has already clearly failed. Project scope creep is a major contributor to the failure of projects. Worst case scenario is that the project cannot be rescued.
One of the main causes of failure is scope creep. This is the slow but steady of expansion of the original scope of work without proper management of that scope. Management of the scope and management of the requests to increase scope are crucial if you are to be successful as a project manger.
As a Project manager have you ever been in apposition where you find scope creep has slowly started to have an impact on your project and the ability of your team to deliver on time and on budget?
How Scope Creep Starts
Verbal requests and meetings or water cooler conversations can often find you subconsciously accepting extra scope into your project.
This is particularly prevalent in software projects.
“Can I have another screen that……….?”
“Is it possible to have another field or value in that report that……?”
“Could you visualize that trend here……?”
“My team needs to have access to ……”
These will all add to your burden as a project manager.
This may be an important client that you do not wish to upset AND if it is an early engagement in the client /supplier relationship you do not want to come across as completely rigid.
If your default response is “No”, you may come across as negative and non co-operative.
This type of dilemma faces software and system project managers on a regular basis across all industries.
Project Scope Creep First Response
You need to fire the burden of work back onto the requester. (Often when you give the “easy rider” people work to do, nothing will happen!!! These are the people that make generic statement during meetings that have no basis other than to derail your work)
It is too easy for someone to state that they need something else included in the scope of work that they had not anticipated at the beginning when developing requirements. The easier you make their life, the more likely they are to keep making your life difficult.
Through trial, error and experience we have developed the following approach for responding to and managing such requests.
Project Scope Creep Questions
This is a simple response followed by a set of 4 direct questions.
Let us consider this request against the original scope of work and we will run it through the process of Project Change Management to see how we respond and manage this new information. However, before I do that we need to understand the following information:
1. What are you trying to achieve?
Please provide a written detailed description with graphics of exactly what is required. One of our Business Analysts can assist you in putting this together once you are clear what is needed.
2. What is the business requirement?
Business projects are typically executed to serve the needs of the business and therefore for every requirement there should be an underlying business issue being resolved or a need of the business being addressed.
3. What proof is required that will indicate that this requirement has been satisfied?
Software systems projects typically incorporate a User Acceptance Test whereby the vendor and the user can verify that the system serves the needs of the business and operates as expected. Both happy path and challenge tests should be considered here.
4. What are the steps, effort (and therefore cost) required to achieve this deliverable once the need is understood?
From the user perspective, they will need support from the project team to understand this impact. Involving the requester in assessing this impact is a very effective means of providing insight to the design and development process without being secretive. You will come across as being transparent.
These 4 questions if answered honestly will provide you with enough information to allow you make a clear assessment of the impact of what is being asked. You will also come across as structured, disciplined and professional.
Be careful not to fall into the trap of getting into arguments that you cannot win. i.e. this is too expensive, this was in the original scope etc. Keep to the facts and it is difficult for anyone to argue.
Project Scope Creep – Protect You and Your Team
On many occasions, I have had a finance director telling me that my estimate for the project was far too expensive only to find that they had no basis for the statement when challenged. I normally answer that statement with “We are expensive compared to what?” or “What is your expectation and what is the point of reference for this amount?” Always make a concerted effort to come across as non-confrontational. In many organizations confrontation is non-productive and only delays the inevitable. The inevitable in all instances of disagreement is that people come to a compromise and work together in order to move on.
Project Scope Creep Conclusion
Project management is a contact sport and it is not for the faint hearted. This doesn’t mean however that you need to get badly injured every time you “lock horns” with an adversary (someone trying to make your project more difficult). Rugby can be a brutal contact sport but some of the most skillful athletes emerge from most games unscathed.
If you apply the approach described above I can guarantee that it will yield results.
If you are interested in further information you can download our Guide to project rescue here.
If you are struggling to come to terms with repetitive project issues and you need some advice or support, contact us by email: firstname.lastname@example.org with some background on your particular issue and we’ll be in touch.
Download our Project Team Motivation Guide Here