|
|
Controlled Scope Management: How much deviation is OK?I was mulling over why scope creep is desirable/undesirable and came up with a few scenarios that seem to illustration "How much deviation is OK". Scenario 1: Rock SteadyIn this scenario, the spec exactly describes what is desired, and the team go ahead and build it. This is a desirable result but nigh on impossible.
Scenario 2: Locked inIn this scenario the Spec doesn't describe what is desired, but the team goes ahead and builds it anyway. An undesirable result.
Scenario 3: CreepThe classic scope creep. In this scenario the Spec doesn't describe what is desired, the team builds to the Spec, but through uncontrolled scope changes the desired functionality is also built. An undesirable result - at least for the who ever is paying for the work.
Scenario 4: Delayed responseIn this scenario the Spec doesn't describe the desired product, and the team sets off to build to the spec. Part way through they realise the spec is wrong, and try to adjust course, but it is too late and the end result is neither the contracted product nor the desired products. An undesirable result.
Scenario 5: Responsive application developmentIn this scenario the Spec doesn't describe the desired product, but this is realised and through managed change control the scope is changed and the team builds to the revised Spec. A desirable result.
ConclusionIdeally the initial spec defines what is desired and the team build it (scenario 1). Ideal, but I haven't seen it yet. That means a fixed price contract based on a documented spec can easily lead to unhappiness. At the extreme either:
It is most useful to think of a fixed price as a price for development capacity and the spec merely points the initial direction. Deviation from the spec is OK as long as it is:
With controlled and timely scope management, you get a satisfied customer and stay in business (scenario 5). |
Copyright © 2001 - 2008 Steven Thomas | Contact Me |