Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Consequently, it's common for the project team to want to "freeze" the requirements at some point so that subsequent creep-causing changes are not allowed. While seemingly a good idea, freezing requirements seldom actually works. Furthermore, freezing frequently provides only temporary illusory benefits and ultimately can end up producing more problems than the freeze was intended to avoid.
Consider that most requested changes are reactions to a product/system/software that doesn't do what the business needs done. It should be easy to see from this perspective that there's not much rationale for persisting to build a frozen product which doesn't do what's needed. That's throwing good money after bad.
Sooner or later, the product is going to have to be changed so that it meets the business needs. No matter how disruptive such changes seem now, they'll only get more disruptive, difficult, and expensive the longer one waits to make the changes. Because the business often understands this better than the project team apparently does, many freezes fail almost immediately--as soon as management (i.e., the business) determines that some requested late change indeed is necessary and overrules the freeze.
I'm not advocating automatically jumping to make every requested change, which is as mindlessly mechanical a response as freezing and inevitably also leads to big problems. The decision of which changes to make, and when to make them, should be reasoned thoughtfully on a change-by-change basis.
Conventional wisdom relies mainly on iterative development to reduce the impact of late changes. By producing only relatively small iterations of code at a time, less code may need to be thrown out and redone when changes occur. However, a caution, because such seemingly change-friendly approaches in fact can become self-fulfilling prophecies creating creep.
While iterative development is valuable, creep can be curtailed far more by coupling it with additional methods that prevent much of the seldom-recognized real main cause of creep. That is, traditionally creep is blamed on seemingly inevitable numerous new requirements due to constant changes to the business and to the need to change requirements whose definitions were not sufficiently clear or testable.
In fact, most creep is not due to new or unclear requirements. Rather much of creep really results from late changes in awareness of requirements that have been there all along; but these are not the requirements that most projects focus on.
Projects generally focus on requirements of the product, system, or software that they think should be created; and these are the requirements that change so much. What doesn't change nearly so much are the real, business requirements that the product, system, or software must satisfy in order to provide value. By learning to better discover the real, business requirements creep can be cut dramatically.
This was first published in August 2010