Requirements hole

One of the interesting things about being an analyst is about discovering holes. By that, I don’t mean anything to do with golf, but technology holes: places where there are gaps in the market. With hindsight, for example, it is easy to see that there was a glaring hole in the data warehousing market before Netezza and its appliance-based imitators stepped into the breach. There was a similar hole in the spreadsheet management market before the likes of Cluster Seven and Prodiance (now part of Microsoft) came to market. Well, I think I’ve discovered another such hole though, in this case, it has yet to be filled.

We all know that the biggest cause of failed IT projects is what used to be known as “specification mismatch” – the gap between what the user wanted and what IT delivered. And, of course, it’s primarily caused by the fact that the relevant people don’t speak the same language and, generally, think in different ways (for example, business entities versus tables). There are lots of products that have business glossaries and other such capabilities, but these are really only skirting around the edge of the problem. The real issue lies with the requirements themselves: how do you capture these in such a way that they can be easily understood by both the business users who are commissioning the project and the IT department that has to implement it? And then, how do you ensure that your requirements are actually what gets implemented?

Well, there are answers to those questions. Sort of. You can implement requirements management. According to Wikipedia this is “the process of documenting, analysing, tracking, prioritising and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.” The problem with these products is that they are large, complex and expensive. Not that they don’t do what it says on the tin but they represent pretty heavyweight solutions that will be most suitable for very large and/or complex projects.

The alternative approach is typically to use Visio, Word and PowerPoint. This is a bit better than drawing by hand on a whiteboard but it’s hardly high-tech: it’s very much a low-end solution. On the other hand, it’s about all that’s available if you aren’t prepared to go in for the significant investment involved in requirements management.

So, here’s where the hole is: it must be possible to create a product that can capture requirements and detail how they should be fulfilled, which can be understood by both technical and business users, and represents a genuine automation of this process rather than an automation of white-boarding without going to the extremes of a full-blown requirements management system. Such an application probably needs to be based on some sort of flow charting, but just supporting flow charting (you can do that in Visio) won’t be enough.

I think such a product can and should be created and I’ll be returning to what such an offering might look like in a further article.