When Telent implemented a scheduling system last summer, the telecoms company was confident the technology would mean it could offer more competitive Service Level Agreements to customers. However, the response from its 1,500 workers was less than enthusiastic.
The application automated the process of assigning jobs to field service engineers, using GPS receivers in engineers' vehicles. Rather than telephoning engineers and locating the closest vehicle to a fault, back-office staff were monitoring the scheduling system to ensure the automatic scheduling was working properly.
"There was a lot of concern we were de-skilling the back-office staff and spying on the engineers," says Paul Waterhouse, Telent's head of system and process development. "We had to do a lot of work to secure user buy-in."
Billions of pounds are wasted every year because companies do not win the buy-in of end-users when deploying new desktop applications, says Chris Gledhill, managing director of software engineering firm PDMS. "When you look at the number of licences sold versus the number of people using a product, you see the scale of the problem. Simply buying Microsoft Sharepoint does not make people collaborate or share information," Gledhill says.
Having spent months building a business case for a new technology project, managers cannot afford to neglect the issue of buy-in. Telent began by involving users in the specification of the product at a very early stage, says Waterhouse. Six employees were invited to attend software awareness workshops with IT staff where their requirements were captured and, where possible, fed into the project. "I think getting people involved early, and incorporating their suggestions gives them a sense that the software is going to help them, and make their jobs easier," says Waterhouse.
Users should also be involved early in the design of bespoke software, or during the customisation of a packaged application, advises Gledhill. "We will often work with users at a storyboard stage, where the software is just a series of sketches showing screen layouts. If you do not do this kind of work you do not get the engagement, and the risk is that people who have nothing to do with using the system end up designing it themselves," he says.
Some experts advise consulting with users before settling on a specific product or supplier. "As an IT manager, you might prefer a web interface because it is £50 a seat, but the users might prefer the richer native Windows interface at £100 a seat," says Richard Edwards, information management practice director with Butler Group. "However, you need to be aware that the world's greatest reporting tool is an expensive waste of money if 90% of your users do not like it and keep storing their information in Access or Notes."
If you do not consult with users before deploying software, do not be surprised if they tell you to get lost when you present them with a new system, says Clive Longbottom, a research director with Quocirca. "If you have not sat down with users and asked them what problems they have, the chances are this software is not going to do much to make their jobs easier," he says. "Consultation is about identifying their problems and doing what you can to address them. If you can do that, you will automatically start to generate buy-in."
Of course, consultation can be time-consuming and there is a risk that you will spend long hours listening to trivial user complaints, Longbottom admits. The key is in creating a forum for feedback that is manageable - for example, using anonymous online forums where there is a large workforce to consider, or recruiting a small team of user "champions" if the software is likely to be deployed across a number of different departments.
Workforce champions can help in communicating the benefits of a new desktop application to users themselves. "Whatever you say, a good champion can say with more credibility," says Longbottom. However, this only applies if you recruit champions who are liked and respected within their department. "Do not forget ultimately this is a human problem about change management and not a technology problem. You are not recruiting people for their technical savvy, but for their ability to take on board new ideas and communicate them effectively," Longbottom says.
It is important to not just use one channel for consultation. Longbottom advises using whatever combination of wikis, blogs, websites, workshops, mentoring and surveys is suitable for your project. "If you just have workshops, the gobby workers will dominate proceedings and they may not have the best ideas, but if you just post something on the intranet there is a very real chance that nobody has looked at the corporate intranet since 1948," he says. "Think about what you want to achieve and what information you want from users, then decide what is the best way to get those ideas."
At Telent, the company's management used a combination of techniques to secure user buy-in for the new scheduling system. This included a series of internal websites alongside monthly meetings between the company, senior managers, six worker representatives and the unions.
"We did everything we could to keep people up to date and incorporate their wishes into the system - or at least explain why we could not if it was not practical to do so," says Waterhouse. "In the end, I think we probably won over 90% of the staff before the new system was rolled out."
Once software goes live, perhaps the biggest mistake you can make is to provide staff with a manual and leave them to get on with it. As a web design agency, Slightly Different is often involved in rolling out new web-based applications. The company often does not produce any manuals for staff following a roll-out, says Nic Drew, the company's technical director. "You can have a really glossy manual that documents everything but users do not want to read a manual when they get stuck - they want to know how to cancel an order, or how to amend something they have entered."
Instead, Drew recommends that companies invest in a "super support" team of staff who can provide onsite or telephone support in the weeks following deployment. "What people really want is to be able to ring someone or e-mail someone friendly and ask how to do that one specific thing," he says. "That makes all the difference to how they feel about the software. If they are having to look through and read pages and pages of documentation, they will almost certainly have a negative view of the experience."
Ultimately, you may never secure 100% buy-in for a new software product, particularly if the increased efficiency means some roles have been de-skilled or dispensed with. Sometimes the best approach is absolute honesty, says Slightly Different's Nic Drew. "We do a lot of web applications that replace traditional processes, and people can be sensitive about that," he says. "The best approach is to explain clearly to people how this fits in with the wider business strategy, and ensure that if people are doing less of one thing, you have come up with and communicated a new way for them to use that freed up time more productively - or they will just worry their jobs are at risk."
There will also probably come a point where you will simply remove any alternative products from the desktop, says Gledhill. "You can use carrots but they will not work and sooner or later you need to not be too scared to use the stick," he says.
Case study: Herman Miller
With annual sales of more than £1bn Herman Miller is one of the world's largest suppliers of office furniture.
In 2007 the company deployed a customer records application from Info to help staff gain better visibility of customer accounts. "We wanted to be able to see everything to do with a customer when they called," explains Kevin Hill, international business systems manager with the firm. "We did not want customers to wait because someone was not in the office and the relevant information was in an Excel spreadsheet."
To ensure user buy-in, Herman Miller set up a series of small user awareness workshops with managers. "We knew if we got buy-in from managers, and they understood how this fitted in with the wider business picture, the information would cascade from there," says Hill.
Next, the IT team set up end-user workshops with staff representatives to demonstrate the software, focusing on how the application would add value to the business without adding anything to the user's workload.
Although there was a demonstration of the software, it was early enough in the process that feedback and suggestions could still be incorporated into the new software. "We wanted to be able to respond to suggestions and incorporate some of their wishes so that users would feel a greater sense of owners hip of the product. It feels like 'our' software even though it is a packaged product," says Hill.
Once the product configuration was finalised all staff were invited to training workshops where the managers and staff were invited to run through scenarios on the software, screen by screen. "We showed how they could handle a customer enquiry, and importantly what it looked like when something had gone wrong," Hill says.
Finally, following the deployment, the IT department used monitoring to find whether the software was being used, and how it was being used. In addition, the IT staff performed regular "walk by" visits to the customer service floor to check the software was being used and provide support to users. "Fortunately we are located very close to that department so it was easy to do," says Hill.
Get web design agency quotes.