Document Best If Implemented By The Date On The Cover

There is a great scene in the movie ‘Clerks’ where a woman is going through every single gallon jug of milk in the store, checking to see if which one has the expiration date that is the furthest out into the future. The clerks behind the counter muse that its as if she’s looking for a magical gallon of milk that will never expire.

I often wonder if requirements documents should come with a similar expiration date. I have lost count of the number of times when I created a requirements document and had achieved sign-off, only to have the project delayed for months or years. When the project started back up the following year (or years), we were right back at square one, revising, updating and sometimes scrapping and rewriting the entire document.

Stakeholders remember signing off on that document years ago and occasionally ask why we can’t just use what we already did. Why do we have to 'reinvent the wheel’ when there is a perfectly good document which has all their needs outlined in it, just sitting on a shelf collecting dust???

It can be a painful conversation to explain that the impacted systems and business processes have not stayed the same during the interm time since the document was signed. The business environment, even in a relatively static market, has likely changed in some way that invalidated some requirements and caused other requirements to be brought forward. Priorities for requirements may have changed as what used to be the customer’s primary goal is no longer even a consideration when looking to purchase a product or service.

It is with these types of conversations in mind that I begin to think that an expiration date on a requirements document would be a very good thing. The date listed would be the timeframe in which the requirements document could be implemented without the need for major review of the information contained within the document. So how would we go about setting such a date?

I think there are several factors that would all go into making such a date. First, what is the duration of the project implementation if we started development on the day the document received sign-off. This could be the minimum date into the future in which the document is still valid. But what about change requests to the requirements that happen during the project implementation phase? Do those not implicitly invalidate the document already? Possibly, but they could also represent additional requirements or additional detail to existing requirements that do not necessarily invalidate what has already been elicited.

Another problem with using the implementation duration is that, especially in the case of large waterfall projects, the timeline can be excessively long. The first project I ever worked on had elicited requirements 18 months before I joined the team and didn’t end up fully implementing those requirements until 6 years later. An 8 year timeline between initial elicitation and eventual implementation meant that much had changed in the industry, resulting in a raft of changes to the original document. Thankfully the original document did expire in this scenario, because if we had implemented what was originally elicited, we would not have been nearly as successful.

So, we’ve got a potential minimum date, but that doesn’t necessarily mean the requirements would not still be valid for some timeframe after that date. There are two more factors which I suggest could help push the date out further.

The first is the rule of the 3 C’s: correctness, completeness and complexity. If you’re confident that the document is correct and complete plus the requirements are not complex, then the timeframe over which you can probably implement the document without needing to do more than a cursory review of the existing requirements.

The second reason that could allow you to push the date out further into the future is the stability of the business environment. This is probably the most difficult variable as markets that have been relatively stable for years or decades can be turned upside down in moments. It is often difficult, when in the midst of such upheaval, to really know you’re caught in the middle of radical change. Businesses often react to change like this instead of anticipating. This negative response can be compounded by the person who remembers that old requirements document which will 'fix’ the business when implemented, who dusts it off and touts it as a savior, only to find out after implementation that they just solved a problem that no longer exists.

Its hard, when caught in the middle of such business strife, to not look for a savior in something you’ve been wanting to do for a long time. You’ve had it in your mind that this project would solve all your problems, even if it would only solve those problems you had 5 years ago and not the ones you have today. A turbulent market is not the time to go without proper analysis and to simply implement something that is meant to solve a different problem.

Could your requirements documents use a 'best if implemented by’ date? What are some other factors that could influence how you set such a date?