We’ve all experienced it.
We’re cranking along in a project and someone comes in with a ‘brilliant’ idea or a new documentation requirement.
AUGHH! Time is ticking, money is being spent. Why couldn’t this have been brought up at the beginning of the project?!?!
There are basically three responses:
- Ignore the request and move forward promising to fold features into the next version
- Agree to the request and try and get more time/money
- Agree to parts of the request and move the rest into the next version.
All three of these cause angst to the team, to management, and perhaps even the users. They result in more time and money being spent. Creativity likewise drops as people go into crunch mode trying to accomplish more with less.
It’s Scope Creep.
So, why would anyone want to embrace this?
Let’s step back a moment.
We all have a tendency to look at projects as totally linear processes. Everyone agrees up front what needs to be done, money is allotted, a timeline is set and everyone is off to the races. The project moves into execution mode – efficient execution.
But, we also know that projects aren’t linear phenomena. They’re a combination of fits and starts, looping back, problems and solutions.
So what happens?
When we first embark on projects, we keep our fingers crossed and hope that nothing gets in the way of launching the product – that there is no Scope Creep. As the project progresses we continue with the same mentality, constantly moving forward but at the same time looking over our shoulders, trying to anticipate what might occur before it does. We hope nothing will knock us off our tenacious trek towards launch – especially no new product requirements. Nevertheless, these new requirements seem to come and wreak havoc.
But, there is a bright side.
Scope Creep is more than something that should be avoided and/or grudgingly dealt with because where there is Scope Creep, there are opportunities to Read the rest of this entry »