You often hear complaints from developers and project managers about scope creep in a project. This is often pointed to as the #1 cause of project failure or delay…how could those dastardly sponsors add more…why didn’t they know this a year ago when we started this project….well the truth of the matter is – SCOPE CREEP IS USUALLY JUSTIFIED and the root cause of it is poor planning. WHAT? How could I say that…let’s look at some reasons for scope creep:
- Missing work – the actual #1 cause of project failure according to Capers Jones. Either through incomplete business requirements or project definition something that needed to get done was missed. Adding the MIA element back in is not scope creep, but scope discovery….better planning and requirement reviews would uncover these issues.
- Delayed project delivery – sometimes delayed project delivery is caused by priority changes or productivity issues (to aggressive in the planning phase), regardless, a delay in delivery means more time for external or internal business changes, resulting from a change to the project…scope creep? Yes, but for a valid business benefit reason.
- The world changes – even if the project is tracking good things happen in the world that require the business to shift its focus…offering 100 photo uploads? Well you competitor just went to unlimited uploads…can’t say no or you’re delivery may seriously impact revenue (aka you paycheck)….
I wouldn't go that far. If we have incomplete or just inconsistent requirements we deal with poor planning, not necessarily scope creep. Responsibility for poor planning goes to both sides: a client and a vendor. Since requirements gathering is usually a difficult process agile techniques emerged. They focus on delivering better product instead of product which suits best to specs.
ReplyDeleteNow, if the client understands that they should rather look for a vendor which exploits these techniques. This would make discussion about scope creep irrelevant, since then adding new requirements or adding more details to old ones are a win-win scenario.
On the other hand most of the time it's easier for customers to stick with old heavy-weight methods. Then they agree to pay some money for some project. As far as software they get sticks to the picture from the requirements they shouldn't complain much. If they do and they expect to get additional features that's a scope creep which I wouldn't call a justified thing.
Another situation is when requirements are complete but vague. Then we come to all kind of project assumptions and that's more a responsibility of the vandor (PM) than a task for the client. With this sceanrio it's not fair to talk about scope creep or at least it's justified (not a client's error).