How to communicate requirements to IT

In this issue of Industry Insider, Craig Errey, our guest columnist from PTG Global, discusses the art of mis-communication and managing expectations between technology departments, enterprises and end users. How many times have you heard the executive -- or even end users, say: "That's not what I asked for!

Craig Errey, PTG Global
In this issue of Industry Insider, Craig Errey, our guest columnist from PTG Global, discusses the art of mis-communication and managing expectations between technology departments, enterprises and end users.

How many times have you heard the executive -- or even end users, say: "That's not what I asked for!".

The IT department then responds: "But that's what you said you wanted".

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:

  • The user interface should no longer be considered a non-functional requirement. The user interface requirements should be given the same standing as functional requirements and conducted in parallel.

  • Iteration is not a good thing&nbsp. There is no need to release 10 versions before you get it right.

  • The technology platform should not be chosen before the user interface requirements are captured and the user interface designed.

  • Subject matter, user interface/usability and change management experts must be engaged at the beginning of the project to fully understand business, people and work. Industrial psychologists can add significant value to the design of technology for people. After all, it's not about technology, it's about people.

    So what are the steps in getting the requirements right? Here is what I consider to be the critical set of activities for any enterprise-level application -- activities that should occur in parallel with business analysis and be conducted by usability and design experts:

  • Observe people at work to understand the specific activities they engage in, how they add value to customers and the business. The intention is to understand the 80/20 rule: the 20 percent of functions used 80 percent of the time.

  • Hold workshops with the business and end users to agree on the user requirements necessary for people to perform at a consistent and high level.

  • Design the user interfaces to deliver on the business and user requirements, followed by usability testing to confirm the design decisions,

  • Finalise the user and business requirements and release to the market to seek vendors and a suitable technology platform

    With such a precise document (a blueprint) there is no need for vendors to add a 50-100 percent contingency for all the iterations they know they're going to go through because the business can't make its mind up. Think of the potential cost savings and the market advantage of getting it right the first time.

    biography
    Psychologist Craig Errey is managing director of PTG Global, which builds and tests online interfaces for intuitiveness and usability.

  • Newsletters

    You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
    See All
    See All