How to communicate requirements to IT

And so begins the countless iterations as the business attempts to refine its requirements and the IT unit attempts to interpret them. Once they're done, the product goes to the end user, who often says the same thing: -That's not the way we work". And the whole process starts over, until the application approaches something workable ... at about version 4.
Why does this occur? The answer lies in the absence of a clear and unambiguous -blueprint".
In the building industry a blueprint allows all parties to communicate in a way that is unambiguous and requires no interpretation. The architect fully captures all of the client's requirements and presents them to the builder. I have rarely, if ever, heard of a building owner or architect saying -That's not what I wanted". Clearly, there is something very different in the means of communicating requirements from the architect to the builders, compared with business to IT.

For the most part, the end users know what they want -- generally something that is -easy to use" and that -just works" -- but like the executive, lack the means to precisely communicate to IT their needs. The requirements end up being incomplete and vague -- -include a superannuation calculator", for example. However, there are a hundred different ways of building such a calculator -- from a simple form, to a graph, to a dynamic Flash-based application.

The imprecision means developers are left to fill in the blanks based on what they know (and often don't know). But what if the developer has never managed his or her own superannuation before? Or has never read a medical instrument to make a diagnostic decision? Or has never been an accountant? How can they really understand these professions if they've never done it before? It's often the small things -- the nuances -- that make an application align with how people go about their activities and make it -user friendly".

The situation is similar to an elite athlete who can't clearly describe how they do what they do -- it's so ingrained and so automatic, that it can't be easily explained.

Getting it right
The inability to accurately communicate requirements is probably the biggest cause of IT failure -- either the project is rejected by users, or it goes through endless iterations before it's right. Or, it's canned altogether because the technology can't deliver what's required.

As far as the end user is concerned, the user interface is the application. The technology department and business need to make a fundamental shift in how they view the role of the user interface in software development. It's not good enough to say -we'll train them", or -they'll get used to it". These are the mind-shifts necessary: