How do you ensure user acceptance of CRM systems?
This was the topic of debate at a senior managers' meeting I attended at a computer firm, and the conversation was quite heated. The vice president of marketing, who was expecting the sales force to enter in volumes of information on their customers and prospects, took a "mandate-change" stance; he thought the reps should simply be required to enter in the requested data. Across the boardroom table, the senior vice president of sales dismissed the notion that anyone was going to force his reps to do anything and would instead have to motivate them to provide the necessary information.
The discussion ended in an impasse with the sales executive using the old analogy, "You can lead a horse to water, but you can't make him drink," to which his marketing counterpart retorted, "Yes, but if I keep his head under water long enough, I'll get his attention."
After years of sitting through similar discussions with dozens of other firms, I have to side with the sales executive on this one. Having surveyed more than 2,000 projects over the past nine years, I have yet to see the mandate-change approach work. There is one key reason for this, which I would like to explore this month, along with some ideas on how to motivate change.
Not All Equal
Several years ago, I had the opportunity to interview Bob Epstein, one of the key visionaries of the software industry. We were discussing user acceptance of computer systems in general, and Bob noted that the key error many IT project teams make in their thinking is that they view all users as being equal. Based on his experience, Bob saw that there were actually three main classes of end users, each with its own set of motivations for using new computer systems.
The first class are what Epstein referred to as "indentured users," people who have to use the systems their company provides them, or they don't have a job. This would include employees like claims adjusters, bank tellers, accountants and the like. These people have no choice but to learn the systems their departments rely on, no matter now confusing and convoluted they are.
Epstein's second category was "power users." These people can have a variety of titles on their business cards. They can be manufacturing managers, engineers, even sales reps, but the thing they have in common is that they are "closet programmers." They see computer systems as an opportunity to learn something new and take on the challenge with gusto. All too often, when we look for user feedback on systems, we turn to one of these power users. But they are the wrong people to ask for advice, because they do not really represent typical users.
Epstein noted that there is a third class of users, which he called "volunteer users." I see these people all the time in the sales, marketing and customer support organizations we survey. These folks are already doing their current jobs without the help of major software applications. They may rely on outdated reports, post-it notes and snail-mail, but they still get things done--they launch products, they close deals and they service customers. Bob pointed out that if you want to get these users to adopt CRM systems, you need them to volunteer to do their jobs a different way.
We need to factor this into our thinking regarding CRM projects and be able to articulate how these systems will make these users' jobs easier. If we cannot find a way to motivate them to change how they work, they will simply go back to doing things the way they have always done them.
So how do you motivate change in "volunteer users"? I have seen a number of techniques successfully applied. The first suggestion I have is to involve representatives from the various user departments as early as you can in the project. At Great West Life, for example, the CRM team formed a user advisory board at the very start of the project. This committee represented the voice of the field and took part in all the major project steps: process analysis, requirements definition, vendor evaluation, functional specification, system testing and final system rollout.
The feedback from the advisory board was invaluable in making sure that the project solved real user problems, and the team members became instrumental in selling the final system to their field counterparts, because they understood the benefits the system provided.
If you cannot commit user resources for the life of the project, then another idea you may want to consider is bringing them in at key times. Allied Signal, for example, let users be part of major decisions. At one point a few years back, when the company was making the final choice on what hardware to use, they set up a vendor fair and let the field reps come in and see the three systems IT was willing to support. The reps got to check out the weight, ask questions on battery life, play with the keyboards and more. This was a little thing, but it went a long way toward getting the users to start to view themselves as part of the project.
Another suggestion is, if you are going to ask users to enter in information about their customers, be prepared to justify why you need the data. I interviewed Michael Lodato when he was working at Sybase on its CRM initiative, and he had a great experience in this area. Initially, when they started discussing the scope of the project, various departments inundated the CRM team with requests that data elements needed to be made required fields for the sales reps to enter.
Michael and the rest of the team went back to each person making the request and asked her specifically what she was going to use the information for. Just by going through this exercise, they dramatically reduced the number of items that were required, and for the ones that were, they had a good justification to share with the sales force on why their help was needed.
Another technique for ensuring user acceptance is restructuring your thinking around the purpose of a pilot. Too many companies view the objective of the pilot as ensuring that the software works. In my mind, that is what QA is for. At Chubb Insurance and Pitney Bowes, their pilot goals were very different. In both cases, the main objective during the pilot was documenting hard business benefits generated from using the system.
In both these cases, they gathered metrics of how they were doing business pre-CRM implementation and then tracked how processes improved because of system usage. By having these measurements in place, during the full system rollout they could show the rest of the user community specific examples of how their jobs would be better if they adopted the new CRM applications. This was key to converting their users.
If you continually keep the "volunteer" user concept in mind, you will find that the issue of mandate versus motivate disappears. If the system can answer the question "What's in it for me?" through the functionality it delivers, users will sell themselves on integrating it into how they do their jobs.