Swamped in Detail

In the world of requirements – How much is enough?  While this might seem like a bizarre question to attract vehemence to anyone outside the profession, it’s certainly a question that will incite the opinionated and the pundits to stand on a soapbox and rant.  To me, the whole debate is a red herring that can be argued from any angle since everyone’s business context will be different.  If one team is looking at selecting and implementing a large commercial application, the business context for requirements are very different than if another team is doing smaller maintenance activities:  my suggestion is the structure and purpose of requirements is far more important.

Let me prove it to you…

Imagine yourself at a buffet – the largest in the world if you will.  Every dish imaginable, made with impeccable care and attention to detail. Now imagine it’s all in one gigantic bowl…  Now all of a sudden all that attention to detail is a lot like eating out of a dumpster – not really appealing.  However, this happens all the time, people focus on the wrong type of detail at the wrong time but generate huge volumes of information.  If the structure is wrong, if you can’t connect the critical functionality back to the basic business processes, you might as well through it away.  You can spend millions trying to generate requirements, but without careful consideration to what kind of information needs to be generated, those millions can be wasted; you end up with a whole lot of not particularly useful information.

Let’s talk about the purpose of requirements…

Should you generate the same structured set of requirements when doing, for example, the purchase of an application as when you do an offshore build of an application?  Most BAs and project managers reading this will say ‘absolutely’…  most businesses actually doing the activity radically change the structure and approach to doing the requirements when they change the type of project.  My view:  this is why so many millions are lost on failed projects.

Here’s a thought:  the basic structure and approach to requirements should never change for any application that transacts a process…  ever.  What changes is the purpose of the requirements and how you situationally align detail and documentation to that purpose.  For example, if you’re doing an RFP for selection of an application:  do the requirements exactly the same as always, and add to it, the evaluative and vendor management detail.  If you are doing a design/build/offshore:  do the requirements exactly the same way, and add to it, the incremental detail of architecture, system interface, GUI, and greater elaboration of functional/non-functional process.  How much detail is enough?  Well, it depends on the situation and purpose of the requirements -e.g., what do the interdependent and downstream stakeholders need to do with the requirements, and in what format can they best use the requirements, and how adept are they with requirements, and how can I best format this same basic set of information to meet their needs?

Companies sometimes get too smart for their own good – people over think the requirements process just because they have a project that is substantially larger or more complex and they make a radical change, sometimes leaping into something that is relatively unproven in approach.  Candidly, the requirements process should be boring – always the same way, all the time.  Another word for this would be ‘consistent’.

So how do I know I have the right level of detail?

Well, if you follow my advice:  the right level of detail is found ONLY when:

1. you’ve followed a consistent framework for doing the requirements that is considered best practice for your organization; and,

2. you’ve assessed the needs of the recipients of the requirements and both framed the requirements information into a format that is easily used by these recipients, and added to the information sets necessary for that those recipients to perform their tasks.

Don’t get caught up in the trap of debating detail as a standard – it’s a trap.  Keep the framework consistent, and let the level of detail be driven by the purpose and form of the requirements – i.e., Let detail be driven by what is useful, not for the sake of doing it.  This means that Effort is now better tied to Utility … so long as a consistent framework of action is followed.

My suggestion…  don’t get swamped in detail for the sake of detail.  Have all the information that is necessary and sufficient to the purpose, and a form that is optimal to the usage…  You may actually find yourself eliminating detail that distracts from the purpose and usage of a document – and gain something that communicates business need far more effectively as a result.