IT projects require end-user buy-in

Almost everyone in IT can name a technology project they have been personally involved with that never lived up to its original promise. But no

   
 

User acceptance: How to do it

As change management projects go, the Crown Prosecution Service (CPS)’s was pretty dramatic: to take 7,500 users in 240 locations with very few PCs between them and have them become fluent not just with the basics of desktop computing, modern productivity suites, email and the web, but also a brand new system that automates one of the most vital aspects of their work.

"We constructed a PFI [Public Finance Initiative] deal with Logica in January 2002," says Clair Hamon, director of business information systems at CPS. "One of the core goals was to provide a case management system for the whole CPS." Each year, CPS has to deal with 1.5 million cases, all of which were processed using a paper-based system. Unfortunately, says Hamon, that led to lost and misplaced files. Neither could the system warn lawyers when custody times of suspects were due to expire. The new case management system was designed both to mirror the paper system and augment it with additional capabilities.

With Logica developing the system, Hamon and her team interviewed 400 users across the community of lawyers, case workers and administration staff to see what their typical response to change, working culture and IT was. They then developed a programme of work around change management education.

Three months before demonstrations of the new system became available, Hamon’s team went out and talked staff through what was likely to be coming and how it would affect their working practices. They also worked with local management to look at general levels of IT literacy among their staff. In conjunction with a third-party supplier, they developed an ‘IT driving licence’ which showed the least literate how to use desktop PCs, email and so on, so that when training was ready for the case management system, all the staff would be working from the same baseline.

"The system design team was drawn from the lawyer community and they worked with Logica to design the core business processes," explains Hamon.

Rollout of the system was completed at the tail end of 2003, with several system updates implemented since then.

"There was a variety of responses to the system," says Hamon. "The admin staff and the case workers found it much easier to transfer, as did people new to the organisation. The area where there was some reluctance was around the lawyers who argued they were lawyers not typists."

But, says Hamon, the benefits of the system to both the lawyers’ working lives and to victims of crimes, who can now see how their cases are progressing online, have convinced the majority of its usefulness.  

   

matter how carefully scoped and crafted the project, it has often been the way the organisation has rolled out the system – resulting in a lack of end-user enthusiasm or a downright refusal to use it – that has been the problem, rather than the technology itself.

With three-quarters of big IT projects classed as failing to meet their original goals, according to analysts at the Standish Group, and many billions of pounds wasted, organisations need to look at the way they apply IT and how it impacts users if they are to reverse the trend and establish a clearer pattern of success. In other words, they must achieve user ‘buy-in’.

Any project means change in processes, and change is never universally welcomed. "People tend to be afraid at the beginning [of an implementation]," says Keith New, vice president of the mobile business unit at workforce management company Aspective. "They’re uncomfortable and distrustful of the motives of management: is it Big Brother in disguise or do they plan to get rid of 20% of us?" In common with many organisations implementing systems, he finds most end users are initially resistant to new technology.

"I’ve seen businesses where they deal with email by having the secretary print out each email, have the exec scribble out a response on each, which the secretary will then respond with," recalls Khalid Aziz, chairman of communications specialist the Aziz Corp. "It’s hugely resource wasteful and not a very edifying use of a trained secretary’s time."

But, says Aziz, most end users are not actually technophobic or resistant to technology. "This is very much an area where people feel very insecure. When we brought in electronic diaries six years ago, we found that people did not believe them, trust them or rely on them, not because they weren’t working, but because they hadn’t had experience of using them." The company decided that to cushion the impact of the implementation, it would initially run a parallel, paper-based system, until employees were comfortable using the new system.

"If you only look at the cash cost and say, ‘My God, we’ve spent all this money on computerisation, we ought now be able to ditch this antiquated stuff’, then you will throw the baby out with the bathwater because you will actually disaffect the people you need to work the system. What you have to do is let individuals feel their way and gently nudge them."

For big projects, the best way to get employees to use a new system is to get them involved in its design from the outset.

"What we’ve found is that if you get people involved in the nuts and bolts of the project early and involve them all the way through, you get buy-in," maintains Mark Williamson, client services director at change management consultancy Partners for Change. Design workshops and interviews with users to identify who is critical to an implementation’s success are both good ways to introduce end users to the reasons why the organisation wants to implement the system, while giving end users the chance to voice their opinions and shape the project so they benefit. This can even invigorate systems that have already failed and are lying unused, although many organisations are rightfully wary of throwing good money after bad.

"In any rollout, there has to be something in it for the users, otherwise you will never carry them along with you," says Kevin Jones from TEC International, a mentoring organisation for chief executives and managing directors. "You can tell a salesman to put orders into a customer relationship management (CRM) system, but I think you’ll get far more willingness if, as a consequence, they can also get information on prospects and customers. It’s much better to give them a benefit than argue that it’s their job and they should just key it in." Involving users at an early stage, consulting them regularly on progress and problems

   

User acceptance: How not to do it

Simon Ball, commercial director of IT services and consulting company Salmon, is an evangelist for end-user involvement. Partly, he says, it was because of his own experiences as an end-user. A former salesman at a US-run multinational corporation, Ball was one of many caught up in a customer relationship management (CRM) and salesforce automation system rollout that, while technologically successful, ended up unused by the majority of the company’s employees.

"It didn’t take into account cultural, even language differences in the rest of the world," recalls Ball. "Americans are used to one currency and one language: American. Head office was eight hours away in California and this was a massive rollout, yet there was no communication from the top end about why the company was doing it, the business imperatives and the benefits at all levels."

To Ball, it was clear that the project was doomed from the beginning, since few basic questions had been asked. "There didn’t seem to be any consideration in the implementation of how our daily working lives were actually run and how the system would impact and change those. I ended up being the militant shop steward and saying, ‘We can’t do our daily job and achieve things you want us to achieve because what you’re doing with this is reversing our efficiency, rather than increasing it.’"

Ball was not alone in his dislike of the new system, with colleagues becoming "angry, resentful, emotionally checked out and fearful". But few passed on their dislike of the new system to managers. When he consulted his US colleagues and asked if they were using the system, "they said, ‘No, because it didn’t work’. They went on the training courses, nodded like ‘Stepford wives’ and then just went on doing things the way they’d always been done."

When management became aware of the sales team’s dislike of the system, they asked Ball to get involved in helping with the implementation. "It raised the question of who was going to do my day-job? Who would be looking after my clients? Who was actually going to take into account that a percentage of my income was based on commission, which is based on me doing a selling job, not on the implementation of an IT system?" Eventually, says Ball, the system "got placed in the ‘too hard’ tray". Parts of it were implemented, such as shared customer contact databases, but the full suite with shared prospect information and sales prospecting was never fully used. "It was declared a success, in as much as bits were being used and the vendor took the licence money, but full value for money and return on investment? I don’t think they ever went there."  

 
   

(but without overloading them with technical information) and even engineering into the system new features that will give users rather than the organisation added benefits, will likely lead to greater end-user take-up of the system.

While it is impossible, of course, to involve all users at this stage, opinion-formers among the target users can be brought on board. They in turn can help explain to their colleagues the benefits of the systems – something that carries greater weight than the coercion of management if these champions are well respected.

Effective education

Aspective’s New says that in his experience, most users actually want to adapt to technology change. Initial fears – most common among employees who grew up before PCs were commonplace – are often overcome through training. For example, says New, in the case of a rollout to field service workers at a major utilities company, end users quickly appreciated the fact that new PDAs gave them more information about the jobs they were working on than the existing telephone-based dispatch centre, plotted more sensible routes between jobs and, most importantly, eliminated hours of filling in timesheets and other administration. It is only when companies begin to implement features that ride roughshod over previous practices (and rights) or impede an individual’s ability to get the job done that employees complain and find their systems a burden rather than an improvement. For example, a large telecoms company recently withdrew a proposal to add global positioning system technology to its field engineers’ PDAs, that would have enabled the company to pinpoint their location at any point during the day, after misgivings from employees about the sense of being spied on.

There will, however, always be recalcitrant users, unwilling to accept change and unwilling to use a new system. A combination of carrot and stick is useful for many, with both the advantages of a system (eg it will help the end user do his/her job better) and the disadvantages of not using the system (eg he will not be paid any commission unless he enters his/her orders into the system) being used to sell it. In some extreme cases, it may even be necessary to make special arrangements. Partners for Change’s Williamson suggests that if a salesman is so vital that it would be impossible for the organisation to fire him even if he refuses to use a CRM system, it might be possible to work round the problem. "With a CRM system, it might be just the issue of inputting information. An interim or long-term solution might be for a PA to be entering information via a fax or phone call. You need to balance the benefits of the project against the risks of key people leaving the organisation."

One big problem for most IT departments, however, is the issue of communication: most are not very good at it. "We thought we were the intellectual visionaries who knew how to run the company," TEC’s Jones recalls of his days in an IT department. "We had more intellect in our little fingers than all the senior management. That was never the recipe for success, was it?"

The Aziz Corp’s Khalid Aziz agrees. "The kind of person that makes a good IT person is often not particularly good at thinking about the needs of the user," he suggests. "Most people who went into IT didn’t go into it on the basis that they liked talking to people: many actually prefer sitting in front of a computer screen and interacting with that."

Aziz says that it is vital to demonstrate to IT staff the importance of communication and how to look at things from the end user’s perspective. "You need to teach them understanding and tolerance. It’s immensely frustrating when you know how something works to see someone who just doesn’t understand it."

Meta Group analyst Ashim Pal agrees that communication is vital and an IT department’s attitude to communication can determine whether or not a project is successful. By promoting what the IT department does and "selling" the systems it deploys, the department is more likely to have successful rollouts.

To get end users to use a system requires a combination of managing expectations, persuasion, coercion, education and training. But successful implementations often require a two-way process, with management and end users negotiating on features. Give employees the ability to do their job better, in a way they believe is better, and a system is far more likely to get used than one that is simply imposed from above.

Related Topics