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 Steady

In 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 in

In this scenario the Spec doesn't describe what is desired, but the team goes ahead and builds it anyway.  An undesirable result. 

Scenario 3: Creep

The 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 response

In 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 development

In 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.  

Conclusion

Ideally 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:

• The customer gets the documented product but not what they want (scenario 2).
• The customer gets the desired product through uncontrolled scope creep that kills the supplier (scenario 3). 
• The short fall of the spec is realised, but there is insufficient capacity to build the desired product (scenario 4) 

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:

• Controlled (i.e. capacity is static even if the scope is changing; in other words avoid scenario 3)
• Timely (if capacity has been used up then it is too late; in other words avoid scenario 4)

With controlled and timely scope management, you get a satisfied customer and stay in business (scenario 5).