Commentary & Analysis
The Scope Creep Virus
The fantasy goes like this when implementing software or managing a software project: "this project will be completed on time and under budget". The reality of many is that "the project is late, we didn't deliver on what we said we would, and we went over budget".
By Jane Mugford
Published: September 4, 2014
The fantasy goes like this when implementing software or managing a software project: "this project will be completed on time and under budget". The reality of many is that "the project is late, we didn't deliver on what we said we would, and we went over budget". While everyone on the team had the best of intentions, the project fell ill. It was stricken with the dreaded scope creep virus. Scope creep being when the project plan gets eroded and in some cases disfigured by additional requests, demands and changes that derail the original deliverables of the plan. Symptoms of the scope creep virus are: agitation, headaches, confusion, and stomach upset that at its worst results in vomiting. The collateral damage results in lost hours of planned work, dramatically reduced productivity, and complete lack of focus on the original goal. The human fallout is arguments, confrontation and upset. Like many illnesses, they can be kept in check with better management and proactive care. While prevention isn’t always possible, proactive planning for scope creep can be helpful. You will never be completely immune to this illness, but you can work hard to prevent yourself from getting too sick.
I have come to believe that on big projects expecting or demanding no scope creep is not practical. The bigger the project and the longer the timeframe, the more the project plan will need to be adapted and modified as time goes on. The more aware your team becomes of the power of the new technology, the more they will naturally want to make modifications to make the solution more all-encompassing. However, the more hands in the pot, the more risky it becomes when everyone wants to see changes or additions before you have even logged in to start configuration.
Once you have come to terms with the fact that some element of scope creep is bound to find its way in to your project, then it becomes about managing scope creep before it starts. First of all, planning a way to channel requests so that they can be organized and vetted is very critical. You cannot allow walking down the hallway to become the dangerous pit of requested changes. You are doomed if you let that happen. When people stop or interrupt you with a great idea, ask them to communicate the request in writing first and then you can follow up with them once you’ve had a chance to review. Set up a ‘requested changes’ review schedule for yourself and let people know you are doing this. Make this a weekly or biweekly timeline. Go and sit in a coffee shop or somewhere comfortable with no ‘office noise’ and look through the requests. See which ones overlap, which ones are very reasonable and beneficial and which ones are off the wall. Then evaluate which ones you think have merit and need to be pursued and assess if they can fit in to the current timeline and injected in to the project plan with minimal impact to time and budget. If the requested change is well worth the effort but it will impact the timeline dramatically, evaluate if it is worth adjusting the timeline or if it can be treated as an additional phase that is considered after the initial launch.
If you make scope creep ‘management’ part of your project plan, you are less likely to succumb to the negative fallout that can happen. Just like the common cold, you know you are likely to get one soon, but working hard to keep yourself as healthy as possible means the cold will only be a minor nuisance.