Is a requirements freeze in a software project a bad idea?
Learn why imposing a requirements freeze in an application project is usually a misguided idea.
An application project has been delayed due to the addition of significant unanticipated additional requirements. How can I best explain to the business end users that they need to stop adding requirements so that we can hit our deadline for implementing the system?
Development team members, including project managers, analysts, programmers and QA/testing, regularly find their ability to hit project deadlines thwarted by scope creep -- changes, mainly additions, to requirements which supposedly already were settled.
Their understandable reaction is to want to "freeze the requirements," prohibiting further changes to the requirements until after they have implemented what they'd already been assigned to deliver. Unfortunately, requirements freezes are generally a misguided solution.
Frankly, freezes frequently thaw, as the needs of the business almost always prevail over the development team's concerns and convenience about how they'll do their work. Moreover, requirements freezes usually don't work because they don't address the real causes of creep, which are: (1) project budgets and schedules routinely are cast in concrete without meaningful input regarding the work that needs to be done and the time and effort needed to accomplish it; (2) people misunderstand what scope really is and thus define it in ways that cannot help but creep, or even gallop; and (3) 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.
Business prevails
What exactly is the value of persisting with completion of work that isn't what's needed most? That's what freezes often do. If the requirements were wrong, which includes having overlooked important requirements, there's no better time than right away to get back on track addressing the right requirements, even if newly recognized.
There are two problems here. First, the development organization tends to act as if it's in a silo, failing to recognize the needs of the business, let alone appreciating that development is there only to meet the business needs. Second, senior management seems oblivious to the mixed signals it often sends. It's okay to want development to respond flexibly to important changes, but management can't expect development also to finish the outmoded assignments with the same total time, effort and resources.
Wrong estimates
The main reason projects overrun budgets and schedules is that those budgets and schedules were set impossibly low, usually without meaningful understanding of the work to be accomplished. The triple constraints of the project manager's triangle say that we accomplish changes in one of the three project variables (product functionality and quality, cost for resources and effort, and time schedule) by modifying one or both of the other two variables. If management needs something by an early date, it's unlikely they can meet their need by also cutting costs or delivering an inadequate product/system.
Misunderstanding scope
A major reason estimates are wrong is related to common misunderstanding of what scope is. Most project scope statements are not scope at all but rather merely objectives or even wishes. Objectives can be met (or not met) in any of myriad ways, and scope stated as objectives gives no clue as to what is really involved. Consequently everybody has a different idea and practically everything turns into apparent changes.
Some organizations define scope in terms of the tasks or activities they will perform. Most vendors have learned to use this technique because it enables them to meet contractual commitments regardless of whether their customer receives expected value. "I promised to do A, B and C, and I did A, B and C. You owe me for that. If you're still not getting what you need, I could also do D, E and F, and here's what it will cost."
The appropriate way to define scope so it doesn't creep so much is in terms of high-level business deliverable whats that provide value when delivered/satisfied/met -- REAL business requirements. Most organizations tend not to know about this type of requirement and consequently don't know how to discover them effectively.
Changed awareness
Scope defined in terms of high-level REAL business requirements creeps much less because the value is what one must end up with. That doesn't change very much, certainly much less than possible ways how to achieve the value.
Most organizations define scope in terms of objectives and define "requirements" in terms of a product or system they presume will meet those objectives. Often implicit in such presumptions is that the defined product/system is the only or at least obviously the best way to meet those objectives. Although seldom recognized, going this way from objectives to product/system involves numerous judgment leap presumptions which have a way of being wrong.
When (or preferably as) the defined product/system is created, its failure to provide intended value becomes evident, frequently through a series of iterations. The common response is to make additional presumptions about what a somewhat different product/system would be that actually would provide the intended value. Such changes to the presumed product/system are usually considered to be changes to the already settled on requirements and are called "creep." Users are often blamed for "not knowing what they want."
In actuality, much of such creep occurs because the product/system and its requirements (which really are high-level design hows) fail to meet the REAL business requirements (whats) that have existed all along but haven't been defined adequately, mainly because people think product/system requirement hows are the requirements.
Thus, instead of falling prey to the illusory approach of freezing requirements, learn to define scope appropriately so it doesn't creep so much -- in terms of high-level REAL business requirements or deliverable whats that provide value when delivered. In turn, estimates can be made much more reliably by basing them on how to accomplish the REAL business requirements deliverable whats that provide value when delivered.
