Requirements Discipline: Avoiding “Death by a Thousand Paper Cuts"
Let’s agree that it is irrational to assume that we can completely define the requirements of a complex system upfront. Few sane practitioners would suggest that was ever an option. I’ve heard some agile advocates use this as justification for omitting requirements altogether, but that delays, and in some cases amplifies the requirements problem rather than eliminating it.
The majority of development projects in my world are awarded on a fixed price, fixed schedule basis. These projects need a solid scope definition to protect parties to the agreement. We do the best we can to define the requirements up front so that a common baseline is documented and agreed upon, knowing that there will be discovery and refinement as the system is built.
Some sources have suggested that requirements change at a rate of two percent per month. I can’t speak to the validity of the studies or data behind those assertions, but they seem consistent with my experience over the last 40 years. Do changes represent flaws in our requirements gathering process? Not necessarily. Complex systems often exchange data with other complex systems. If one of your business partners changes an interface after your requirements effort is “complete” are you expected to ignore this new information and build what was in the initial requirements set? That would be foolish. What about new laws or regulations that are promulgated after development has begun? Again, ignoring the reality of the evolving world while waving around your “approved” requirements would be a sign of insanity.
Why bother trying to capture requirements if we know they will change? Because an agreed-upon baseline helps manage change.
This essay was prompted by a recent project meeting. The project started with a body of “high level” requirements. The agile development team is doing a pretty good job of implementing those requirements and flushing out clarifications, corrections, and changes. As sprints are completed, the team is providing detailed documentation of the solution and business rules implemented to the customer for final review and approval.
The problem is that the project has a fixed timeframe and fixed budget. The customer is reviewing the resultant “detailed requirements” and discovering omissions and what they see as “errors”. This is resulting in a back and forth conversation trying to clarify and enhance the requirements. Meanwhile, the clock is still ticking. The budget remains fixed.
I don’t think there are any bad actors here, everyone wants the project to be successful. However, the fact remains that rather than spinning and agonizing over the requirements set BEFORE the schedule and cost were fixed, the project is now in the fourth quarter of the game and still debating the rules. Are the developers at fault? Are they doing bad work? Is the customer at fault? Are they not being clear about their desires?
Even if a project starts with an agreed-upon requirements baseline it remains likely that the problem and solution context will continue to evolve as the project progresses. The value of the baseline is that it helps distinguish requirements evolution from poor performance on the parts of the client or provider. Treating change as change provides a basis for negotiating new cost and schedule agreements rather than having the end game descend into finger-pointing.
As the project is unfolding now, the schedule is tight, the budget is tight, the customer is becoming concerned that the vendor isn’t being thorough, and the development vendor is beginning to suspect that the customer is moving the goalposts. The lack of up-front discipline is eroding credibility on both sides with each minor issue discovered. One person’s “new requirement” is another’s “clarification of existing requirement.” I worry the project is dying the death of a thousand paper cuts… few of the issues being raised are “show stoppers”, but in aggregate they may represent significant scope creep that affects both schedule and cost. Absent an effective baseline it is difficult to distinguish clarifications and error correction from enhancements and changes to the original ask.
Requirements discipline is hard. The alternative, lack of discipline is worse. Choose wisely.
Sounds familiar. If the customer seems to be picking on details of the requirements (which I am afraid most of the times will be the case - Agile or not), it's always better to flush out the details upfront even before the fixed cost and schedule are decided, don't you think? Fair enough, it may not be possible all the time, but the development team could mark 'unknown' and 'open to discussions subject to change in scope of project' items, so that the contract has a way to save the vendor for unreasonable claims from the customer? Thanks for the perspective!