The Challenges of User Adoption in Implementing EHS Software

“Thus times do shift, each thing his turn does hold new things succeed, as former things grow old” -Robert Herrick

The Challenges of User Adoption in Enterprise Software

Getting people to try new things is tough. Getting people to stick with new things over the longer term is even tougher. And trying to accomplish this at a scale of many hundreds or thousands of people? That sometimes seems like it takes miracles.

There are many studies indicating user adoption as the number one driver of enterprise software success. One such study shows that 72% of value realization comes from this one factor alone:

“Time and time again, the effectiveness and overall success of an enterprise-class piece of software does not lie within the technology itself but in the processes and procedures around them. Many a software deployment delivers 100% on the business requirements only to fail in the final phase of user adoption.”

When implementing software, organizations often try to make certain that all stakeholders are kept happy. They check off every last feature that anyone asked for, and tailor the software to exactly match their existing processes, warts and all. Then they determine that all requirements have been met and go through with their rollout, with confidence that since users can accomplish every functional bullet point they need, they will all use the system and be happy.

What drives user adoption, however, is often much more difficult to measure. Most strategies advocate high levels of communication, training, and enforced use of the system by management. These are very sound practices, and we at VelocityEHS recommend them wholeheartedly as well. But there are other, subtler drivers that can be just as powerful, potentially more so – Simplicity and the Technology Adoption Lifecycle are what I will discuss today.

Rollout Engagement Issues – Don’t Ignore the Users

Attempting to manage enterprise software rollout issues thoroughly and in advance has become mainstream practice over the last several years. There is more and more time (and money) spent by organizations ensuring that all of the requirements are fulfilled, that the training classes and manuals are perfect, that management has visibility and control, and that everyone knows what the expectations are. Then switches are flipped, doors are thrown open… and there is a deafening silence. Or more insidious, usage immediately spikes, and then tapers off over time or eventually falls off a cliff.

This is the point at which failure is declared and blame starts to be assigned. “IT improperly vetted the system!” “The needs of the business users were not clearly expressed!” “The vendor did not deliver on their promises!” These are all common refrains, and how to avoid them is the topic of many articles. What is often ignored, however, is that users just do not want to use the system, and the reasons behind that.

“People are very open-minded about new things – as long as they’re exactly like the old ones.” – Charles Kettering

The folly may be that we treat every user the same and expect them to behave the same. In practice, users are people, and people come with personalities, psychology, and other messiness. To deal with this, we need to examine the body of research performed by those who know how best to influence humans: Salespeople.

Crossing the Chasm – The Technology Adoption Lifecycle

In 1991 Geoffrey A. Moore published the seminal work Crossing The Chasm: Marketing and Selling Disruptive Products to Mainstream Customers. The book describes the barriers technology companies need to overcome in order to bring products to the mass market. It examines the differences in behavior of consumers, specifically their reaction to disruptive change. The premise is that there are five main groups of people based on behavior, and they fit into a bell curve as shown here:

The groups are defined as follows:

• Innovators – Enthusiasts who love new technology, even when it doesn’t yet have a purpose.
• Early Adopters – Visionaries who see how a technology can be used to solve a problem.
• Early Majority – Pragmatists who want social proof that a technology has value before adopting it.
• Late Majority – Conservatives who prefer old technology until its clear a new technology dominates.
• Laggards – Skeptics who avoid adopting new technologies at all costs.

When you put this in the context of getting users to engage with new software, the parallels become eerily similar. Anyone who has been through an enterprise software rollout will likely have vivid memories of these groups. Moore goes on to put forward ideas for ensuring your strategy incorporates the means to reach across the divides.

First, he says, you need to establish a beachhead. In the context of a software rollout, this means focusing on one area or module of the software that solves a specific pain point for the early majority. This earns the interest and trust of the early majority in the software overall. At this stage, your early adopters can use other aspects of the software, and discover and communicate solutions to other pains. From there, you set up the “bowling alley”, where the early majority realize one benefit after another, until they are using the full software package. This critical mass leads to late majority adoption, and eventually to “total assimilation” where even the laggards capitulate.

Simplicity Shrinks the Chasm

When we dig even deeper into the reasons why the chasm exists at all in software rollouts, we arrive at software complexity. The more difficult the software is to use and understand, the scarier change will be, and the harder user adoption will be. The more customizations added, the more changes to best practices that are already in place, the less the users will find the software intuitive and want to use it. The best way to reduce this friction is to simplify, simplify, simplify.

“It is always the simple that produces the marvelous.” – Amelia Barr

At VelocityEHS, we have seen these approaches work quite well together. While I cannot say that this simple rollout approach will work with everyone, our clients have used terms like “snowball effect” and “pull effect” to describe the result where users engage with the software on their own, building momentum over time. Rather than requiring management to continually push the user community to fully adopt the system, the success and enthusiasm of the initial adopters causes more cautious people to want to use it. That leads to true global adoption.

If your rollout plan seems complicated, it may be time to try a simpler approach. We would be happy to discuss our thoughts on user adoption with you.