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.