I had pondered writing a post called "Requirements Decay" about how requirements don't last forever. In my research I found that such a post, complete with "my" words "requirements decay" and "requirements half-life", had already been done comprehensively here. In a compact argument underpinned by half-life mathematics, the anonymous author proposes that a requirement isn't likely to stand forever and explores the implications.
For me, requirements decay is an idea that helps us think realistically about project planning and improves our chances of meeting business needs.
I've observed requirements decay in many settings, so I was surprised to find so few references that take this perspective. There are many, on the other hand, that talk about requirements volatility. Some, like this one, follow the traditional failed pattern of demanding business sign-off, "disallowing" changes after a certain point in the project, and applying a robust (and often dreaded) change control process for incorporating requirements changes.
Others are more nuanced. This article provides a list of likely causes, including inexperience with the technology, system complexity, project team instability, and so on, and then details a catalog of management methods and guidelines for their use.
As useful as they are -- and they are useful -- to me posts like the latter still miss the point. The "volatility" analogy isn't helpful. If volatility is the problem, then we can manage it so that it won't affect us, like bottling up a volatile chemical. On the other hand, Carbon-14 will decay if you wait 5730 years whether or not you bottle it up.
Our anonymous author offers a "Rule of Thirds": Regardless of how you try to limit and manage requirements volatility, "in the final system one third of it is in the original plan, one third is in there but very different to how it was envisaged and the final third was not in the original plan at all. It is made up of new requirements that were not considered at the start". In addition, early scope estimates are typically off by 30% (here) adding a fourth third to our Rule of Thirds (in real life it always seems to be plus 30% not minus).
So our expanded concept of requirements decay leads to reality-grounding assumptions that should underpin all application project planning:
- About 30% of requirements will be obsolete at go-live
- About 30% of requirements will need to change over the course of the project
- The scope, and therefore schedule and budget, of the project will increase by about 30%
So rather than assuming everything will work out fine, plan as if your project will go like all the rest. Here are a few suggestions based on my experience:
- Define granular business objectives: If planning operates on the assumption that a lot won't work out, then the obvious question is what must work for it to be worthwhile? Huge objectives like "automate the sales process" or "integrate production data" increase likely requirements decay, but "track order status from sale to delivery" and "display weekly production by plant" give the team more to go on. A prioritized list of specific objectives provides raw material for project planners to structure the project to deliver to business priorities.
- Focus on business requirements first: Quite apart from any app dev project, does the business involved have clear strategic goals, tactical objectives, defined business processes, and performance measures? Overloading application requirements with business requirements definition substantially shortens requirements half-life.
- Separate frameworks from business processing: Effective system designs separate more stable framework "plumbing" from less stable business-facing functions. For example, a business object that returns a list of employee's children should not have to return the results in a particular order. User facing elements can handle that.
There's nothing particularly new in these suggestions, but I think they take on new vitality when you realize that you'll manage unstable, decaying requirements rather than optimistically prepare to put a lid on volatility.