In the immortal words of Keanu Reeves in Speed, "Pop quiz, hotshot!" Answer the following questions:

  • On average, how long does it take for customers to implement your technology? (Include people using the technology in the definition of "implement.")
  • In all phases of a project (building the justification, drafting the requirements, selecting vendors, implementing the technology, reviewing its success), is there anyone in the customer organization who champions the project from start to finish? If not, when and how does the hand-off happen?
  • Is there anyone responsible for successful execution in each phase? Again, if not, what does the hand-off look like?
  • How does the project team convince people in their organization to use your technology?

Don't worry if you couldn't answer some, or even all, of the previous questions. You're not alone. Most technology vendors don't have anything but the most superficial understanding of how customers adopt their technology. Naming a few stakeholders isn't the same as understanding the adoption process, unless you think there's no reason to read Gone With The Wind if you can identify Scarlett O'Hara and Rhett Butler as the main characters.

Tech vendors have all kinds of reasons to understand adoption better than they do. When projects fail, and adoption doesn't happen, those customers are far less likely to stay customers. That's also a potential success story that you must cross off the list. And that's just the beginning of the problems.

Our technology is just too good for you peasants
If pressed about the reasons behind project failures, people in the technology industry can get downright condescending about their customers. Rather than looking at the high rate of project failure as a challenge to themselves, vendors often blame it on defects in the customer organization, such as the lack of an innovative corporate culture. Here's a laundry list of reasons why ERP projects fail that only briefly considers the users, just long enough to describe them as though they're easily startled children: "Combine the normal anxiety associated with change along with an unfamiliarity for the new system and a nervousness from only completing a minimal training program and user fears can escalate if not proactively grounded." Just be sure to distribute juice boxes in advance, and always speak in a low, even voice.

Unfortunately, this blame-it-on-the-user philosophy falls apart when you look more closely at project failures. Information technology adoption often fails for the same reasons that other innovations fail: users may have a completely rational reason to reject it.

Great technical acumen, lousy people skills
In the social sciences, where people study technology adoption for a living, this perspective is hardly new. The initial assumption of "diffusion" research mirrored the assumptions of the tech industry today: technology equals value, so there must be a problem with anyone rejecting that value. This "better living through technology" philosophy ran afoul of too many real-world counter-examples to ignore.

In one famous study, the researcher was faced with the conundrum of why Egyptians continued consuming polluted canal water when cleaner drinking water became available. Familiar ways of encouraging technology adoption, such as awareness campaigns that marketed the benefits of the new water resources, were not working. The problem wasn't the marketing messages, but the idea that marketing alone was going to do the trick. Many other obstacles existed to adoption of the clean water alternative. Some were basic technical problems, such as defects in the pumping equipment. Other barriers required people savvy, not an engineering degree, to overcome. Because of their religious obligations as Muslims, many villagers were using their allotment of clean water to wash themselves before their daily prayers. And that's only a small sample of the obstacles to what seemed like an obvious decision to use clean water instead of polluted water.

I had a similar moment of insight as a product manager when I visited a customer, Salve Regina University, and attended one of their internal training sessions about our product. The trainer described only a handful of capabilities, sticking closely to use cases that were familiar to them. When he discussed optional ways to address the same tasks, using additional features in the product, the audience got bored and impatient. Someday, these users might be interested in the newer features, but for now, they were just mental detritus.

When invited to tell the group about the new version of our product, I kept my comments extremely brief. Options equal complexity, so jabbering about all the great new things in the next release would have undermined the value of the product. The more complexity I described, the less likely they would have been to use the product at any level, which would have been a completely rational decision. If I hadn't seen the training session, I would have launched into the usual spiel about the amazing capabilities of the new product, on the assumption that the more features I described, the more valuable the product would seem.

Man bites dog, then throws away iPhone
We see similar examples of user rejection all the time. We sometimes take it seriously, but we also overlook it, or treat the incident as another item from the "News of the Weird" feed, alongside the image of the Virgin Mary reportedly appearing on a microwave pizza. Here are some examples of seemingly bizarre technology rejection that you might have missed:

In some cases, the puzzle is easy to solve. For instance, many British engineering firms block access to social networking sites. Other cases are harder to unravel, such as the continued dominance of discussion forums, the Ur-social media that gets almost no attention these days. In all cases, assume the rationality of the users first, instead of treating them as an object on which much smarter people like yourself need to work their will.