IT-Analysis.com
IT-Analysis.com Logo
Business Issues Channels Enterprise Services SME Technology
Module Header
Craig WentworthMWD Advisors
Craig Wentworth
16th April - Egnyte the blue touchpaper...
Louella FernandesLouella Fernandes
Louella Fernandes
11th April - Managed Print Services: Are SMBs Ready?
Louella FernandesLouella Fernandes
Louella Fernandes
11th April - The Managed Print Services (MPS) Opportunity for SMBs
Simon HollowayThe Holloway Angle
Simon Holloway
11th April - Intellinote - capture anything!
David NorfolkThe Norfolk Punt
David Norfolk
11th April - On the road to Morocco

Analysis

Requirements hole
Philip Howard By: Philip Howard, Research Director - Data Management, Bloor Research
Published: 25th July 2013
Copyright Bloor Research © 2013
Logo for Bloor Research

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.

Advertisement



Published by: IT Analysis Communications Ltd.
T: +44 (0)190 888 0760 | F: +44 (0)190 888 0761
Email: