To print: Click here or Select File and then Print from your browser's menu

This story was printed from silicon.com, located at http://www.silicon.com/

Story URL: http://management.silicon.com/itdirector/0,39024673,39161810,00.htm

Quocirca's Straight Talking: Talk to the user
Or your IT project will fail

By Quocirca

Published: Friday 25 August 2006

Why do so many IT projects end up as costly, overdue, resource-sucking failures? Because the people creating the technology fail to speak to the people who will use it, says Quocirca's Elaine Axby.

IT systems and applications mean nothing unless they actually get used to deliver products and services to customers - whether customers are those in the supermarket or citizens trying to pay taxes.

Quocirca research shows end users are still rarely involved in any sort of strategic IT decision making, and many big IT projects in the public sector fail to deliver the benefits sought. The current troubles of the NHS Connecting for Health (CfH) IT project are a prime example - much of the discontent is because key groups of users do not feel they have been sufficiently involved in the process, nurses being the latest to voice their unease.

How to deliver what the customer wants is becoming ever more challenging. Business process lifecycles are shortening - new financial products need to be available in days, not weeks or months, more systems and applications need to be integrated into whatever it is that IT is developing.

It has always been difficult for IT and the business to talk together - I recall a billing project in my telecoms experience, whereby the conversation went something like this:

IT: What do you want to bill for in the next five years?
Marketing: We don't know. This is how we do it now but we really want infinite flexibility in the future.
IT: OK, so just take a look at this list of fields and tell us how to prioritise them.

It was almost impossible to define a set of user requirements and then we had to cope with IT following the traditional 'waterfall' approach - taking those requirements and then delivering the 'solution' sometimes months, if not years, later. The main problem with large projects is that they solve today's problem (sometimes) but deliver that solution a year or more in the future - and the problem is then no longer the same.

Clearly this is not adequate to serve the needs of today's businesses. So what sorts of things should be done to get the users on board?

Firstly, having smaller projects would help - again CfH is a prime example and there are many others in the public sector. It is possible to design major change programmes such as Connecting for Health whereby the business retains a tight hold on the strategic objectives while a number of smaller projects contribute to that objective. Smaller projects can therefore be run and aligned with what the 'people on the ground' are doing and want to do in future. The stated needs of the users are dealt with in shorter timescales - thus actually solving their existing problems and allowing future issues to be dealt with as they come along.

Being able to explain to the business what the application is going to deliver is also crucial. Too often IT uses a different language to the business and presents workflows in terminology that is hard to understand. Much effort has been put into trying to find a common language over the years.

Some recent products seek to improve this - Borland's Caliber DefineIT development tool, for example, seeks to improve the ability of IT and the business to speak a common language. Intersystems, which has had some success in UK and US healthcare applications, has an integration platform Ensemble that offers an easy-to-use way of showing users what the system will deliver. Rapid prototyping is also key - no matter how well something is described in a common language, actually seeing something in action enables users to say, 'ah - not quite what I was looking for'.

Taking a more iterative approach to development and project management enables closer collaboration with those who actually use the system. Microsoft Services, which works with a range of partners to deliver big IT projects to public and private sector clients, has a somewhat different take on the traditional waterfall approach, preferring short, timed project milestones, many of which are just iterations of the last one, with a 'culture of daily build' that enables them to build the application closely with those involved from the business.

A good communications strategy is also vital. The Vehicle and Operator Services Agency has recently rolled out computerised MOT testing to more than 18,000 Vehicle Testing Stations. The project involved consultation with trade and consumer user groups, and although it has not been without its teething problems, it has got a wide range of different garages from big chains to one-man bands onto a new system.

Of course, involving users doesn't mean slavishly doing what they want. Many IT projects involve implementing significant business change, and there will often be much resistance to that change. This is why it's important to have the strategic benefits clearly set out and any change to business processes developed as far before the IT as possible.

IT won't be a success unless it is used but creating applications that everyone can use is possible. This is more than just an issue of nebulous concepts like user friendliness or pretty graphics, it's about how well the application fits the business and working practices of the user. This can never happen if the project is developed in isolation or delivered as a 'big bang'. IT projects and their eventual users have to see they are in the same boat and try to stay in it - less waterfall, more rapids.