Requirements freeze against scope creep?
Recently an interesting question was asked:
The person asking the question was running a project that got delayed because the users kept adding requirements.
Robin F Goldsmith answered that in his opinion a requiements freeze is the wrong solution to the problem of scope creep.
Mr Goldsmith must have been really happy the question came along, because he wrote a book (http://www.gopromanagement.com/book.html) on the subject.
Requirements freezes usually don't work because they don't address the real causes of creep:
- Project budgets and schedules are commonly fixed without proper understanding of the work that must be done and the time and effort needed
- Scope is often not defined in terms of requirements that provides value when delivered. As a result everybody has a different idea about what must be delivered, making everything look like a change.
- Most creep is actually not new or changed requirements but rather new or changed awareness of requirements that have been there all along but haven't been identified adequately
In essence, Mr Goldsmith suggests a two-step process:
– define the scope in terms of REAL business requirements (or deliverable "whats") that provide value when delivered.
– base your estimates for budgets and schedules on "how" to accomplish these REAL business requirements to make them more reliably.
This advice matches nicely to our guidelines on the use of Use Cases. We state that Use Cases should deliver REAL value to the stakeholders!
– High Level (shortly described) Use Cases define the scope. This scope is in terms of the value to be delivered and is froozen.
This scope becomes the basis for estimating budgets and schedules.
– When we are unsure about the estimates or the solution, some more elaboration on the Use Cases is needed before we can give accurate estimates.
This is common to all projects, typically we would elaborate when we are unsure about the (logical or technical) solution or the process to get to that solution