By Laura Martin
Originally Published Wired Magazine, Innovation Insights, 2014
McKinsey and Co. came out with a terrific article, “Building the Social Enterprise,” listing the following as necessary principles for successful implementations of social collaboration tools:
1) Add Value, Not Complexity
2) Provide Essential Organizational Support
3) Experiment and Learn
4) Track Impact and Evolve Metrics
I certainly agree with these principles; (advertisement alert: the M4 adoption program offered by Techlaborate employs each one) and, the rising debate on the effectiveness of collaboration tools implies a need for this type of guidance.
While reading the article, I wondered: Why is this list not implemented for all enterprise-wide technology deployments? Limited company resources jumps to mind; however, why would a company invest in an enterprise technology solution if they did not have the resources for successful implementation? No one purposely buys software just to decorate their shelf, right? So why do teams struggle with tools like enterprise social software? Who is responsible for effective enterprise software implementations?
Historically, responsibility fell on our IT departments. They know technology, they install it and maintain it; so, they should know what to do. The logical fallacy is transposing proficiency in technology with a proficiency in training and change management techniques. Additionally, the incredible work by Harvard professor, John T. Gourville suggests IT knowledge could actually be part of the problem.
Information Technology’s Curse of Knowledge
Behavioral scientists call it the “curse of knowledge”: people find it impossible to ignore what they already know. For example, in a study by Stanford University graduate student Elizabeth Newton, she assigned people to two roles: “tapper” or “listener.” According to Chip and Dan Heath,
“Each tapper was asked to pick a well-known song, such as “Happy Birthday,” and tap out the rhythm on a table. The listener’s job was to guess the song.
Over the course of Newton’s experiment, 120 songs were tapped out. Listeners guessed only three of the songs correctly: a success ratio of 2.5%. But before they guessed, Newton asked the tappers to predict the probability that listeners would guess correctly. They predicted 50%. The tappers got their message across one time in 40, but they thought they would get it across one time in two.
Why?
When a tapper taps, it is impossible for her to avoid hearing the tune playing along to her taps. Meanwhile, all the listener can hear is a kind of bizarre Morse code. Yet the tappers were flabbergasted by how hard the listeners had to work to pick up the tune.
The problem is that once we know something—say, the melody of a song—we find it hard to imagine not knowing it. Our knowledge has “cursed” us. We have difficulty sharing it with others, because we can’t readily re-create their state of mind.”
Our IT teams are no exception to this error. Technologists learn new software relatively quickly and can appreciate its value much faster than the average end-user. The necessary amount of training and transition is skewed in their mind due to their own proficiency with such tools. For example, IT teams frequently believe they can roll out a software solution with less time and money than recommended. The fail-rate of formal change management programs, budget constraints and management expectations surely has impact on their decision; however, IT being charged with a roll out reminds me of a recent Visa commercial with San Francisco coach Jim Harbaugh. In the commercial, he is passionately addressing his team with high end football strategy – the team is comprised of little league kids who have no idea what he’s talking about. The technology teams have the best intentions; but, it is exceedingly difficult for IT to put themselves in the end-user’s shoes.
Finally, my favorite: understanding technology does not translate into understanding the needs of other lines of business. I would not want Mrs. Marketing manager to make decisions on the security needs for data in motion versus data at rest. However, IT frequently believes their knowledge of software tools allows them to extrapolate the needs of the marketing department, for example.
“If We Build It They Will Come” (Field of Dreams, 1989)
The same mental error occurs with the manufacturers and consultants who create, market and sell software solutions. Manufacturers often take years to develop software, meanwhile falling victim to what behavioral economist Richard Thaler labeled the Endowment Effect. They begin to overvalue their technologies’ innovative benefits creating a bias that discounts and unconsciously rationalizes any shortcomings. This perception shift blinds them to what it would really take for consumers to adopt their product. Most people operate under the old economic rules that people will rationally adopt new tools if the tools have relative advantages. We are not inclined to appreciate the necessary mindset required for a new toolset.
Let’s apply these perceptions to a typical transaction of enterprise software for a Fortune 1000 company.
Everyone in this part of the transaction has backgrounds and knowledge in technology. They all speak the same language when deciding on a Knowledge Management solution, for example; so, the benefits are often obvious to all parties. Their perceptions are then reinforced when others of the same knowledge base agree. No one is able to put aside their existing technical knowledge to estimate if and how a lay-end-user would implement the tools. The result: “provide and pray” with finger pointing as to why a project failed.
As it turns out, end-users suffer a similar behavioral error, called The Status Quo Effect.
Studies show we have a strong bias towards valuing items we possess above items we do not.1 I already own this, I am used to this, I am comfortable with this; therefore, I understand and value this more than an alternative. For example, the benefit list of enterprise social software may be very logical; however, to an end-user, they understand and are comfortable with email. They value email more than an alternative. But wait, there’s more! Nobel Prize psychologist Daniel Kahneman in research with his partner Atmos Tversky, found that a loss has a greater impact on people than gains of similar weight. In the mind of the end-user, giving up some of the benefits in email outweighs possible benefits from enterprise social software. The loss irrationally has a greater psychological impact.
Gourville summarizes:
“…consumers overvalue the existing benefits of an entrenched product by a factor of three, while developers overvalue the new benefits of their innovation by a factor of three. The result is a mismatch of nine to one, or 9x, between 
what innovators think consumers desire and what consumers really want.”
Gourville goes on to show that in study after study, when people are shown evidence of their irrational bias, “they were shocked, skeptical and more than a bit defensive. These behavioral tendencies are universal, but awareness of them is not.”
“Go to the Light Carol Anne!” (Poltergeist, 1982)
Now that we are aware of our unconscious mental biases, what do we do? We still need to solve the question, “Who is responsible for effective enterprise software implementations?”
As we discussed above, technology implementation historically falls to the customer’s technology team. The manufacturer or reseller receives their check and the onus falls on the customer to make their purchase function effectively. Implementation services (as in install and turn on) and possibly, but rarely, technical skills training for end-users may be negotiated. If the customer fails to create effective adoption in the company…too sad, too bad: Shame on you Mr. Customer.
Unlike the psychological biases, this is not an unknown phenomenon to the involved parties. However, according to Wood, Hewlin and Lah in “Consumption Economics: The New Rules of Tech, “The old play from the product playbook has run its course. The ability to successfully drive consumption is about to become the critical enabler of profitable growth.” They attribute this shift to:
1) Scrutiny on technology ownership costs and ROI,
2) The disruptive promise of cloud-computing, and
3) The consumerization of IT.
In an increasingly competitive market, riddled with shelfware, two things need to change to achieve adoption success. First, manufacturers and their resellers need to take responsibility for effective enterprise software adoption. They can no longer rely on the customers’ IT departments and expect repeat business. Gourville asserts that to overcome the resistance to behavioral changes with new software, your product must have 10X the improvements of the incumbent (compensating for the 9x factor previously mentioned), and; you should attempt to minimize resistance. To do so, innovator’s value-add must shift from technical to business expertise. This change in perspective will allow them to create effective adoption strategies. Strategies that include the principles in McKinsey’s list:
1) Add Value, Not Complexity
2) Provide Essential Organizational Support
3) Experiment and Learn
4) Track Impact and Evolve Metrics
Please note – “Value” is defined as something that solves business problems or aids in reaching business goals. It requires the ability to map tools to customer’s business process. A special call out to the last construct – Metrics: FYI, they matter. The tools and adoption programs should have specific, measurable results. (The adjective “specific” is meant to rule out results like “increased employee engagement” and “improved cultural competencies”.) According to Wood, Hewlin and Lah:
“’Get me the result’ is the new RFP. And that is a services-led discussion.”
Second, IT departments need to learn the business needs and goals of their line of business brothers and sisters. Their focus must also shift from ports to people by speaking the language of business. Again, real metrics matter, not fuzzy ROI; so, IT also needs to know what to measure. CIOs should budget for and mandate programs that focus on business goals with measurable results. If the software provider does not offer adoption solutions with their tools, it is imperative to find (and budget for) a consultant who can.
On a final note, I will be sending an Enterprise 2.0 Thank You Card if anyone else wants to sign it. This is not the first great software solution to hit adoption road bumps (my favorite: Lotus Notes); but, it has certainly received the most hype. My goal here was to ride the hype-train as a vehicle to shed light on necessary changes in the software and services market. So, thank you Enterprise 2.0 for bringing attention to these issues.
1. Jack Knetsch, 1989.