In December, The Wall Street Journal reported that Avon Products, Inc. had spent 4 years and $125 million with SAP on a major software project that was being terminated. Apparently, Avon discovered that “users — the company’s sales force — found the new system so burdensome and disruptive to their daily routine that many left Avon.” Avon paid dearly in money and time, as well as employees, for a poor user experience. In this case, that cost has been quantified.
For most people, the terrible software they’re forced to use as part of their job never gets this much attention. It’s not clear what went wrong for Avon, but they’re certainly not alone in facing a disconnect between what they bought and what their users wanted.
How does this happen? There are several potential points of failure:
Buyers aren't Users
The people who evaluate enterprise software and make the purchasing decision are rarely the people who will be using the system. Even if they know the users and want them to be successful, buyers don’t adequately represent users’ needs during the purchasing process, and are likely to prioritize cost or technical constraints over factors that will guarantee users a positive and productive experience.
Remedy: The purchasing process should include discussions about who will be using the software and what those users need to accomplish. Purchasers should disqualify vendors who are unable to engage with real users and explain how their software can be customized (if necessary) so that users can accomplish their goals, and how assessments can be conducted during the customization process to ensure the effort is successful. The purchasing team needs to consider not simply the resources required for that customization effort, but which tool is likely to reward that investment with the best user experience.
Implementers aren't Users Either
Once the software is purchased, an implementation team typically takes over to determine the schedule and details for deploying it. This implementation team doesn’t usually include users. And though there may be business analysts charged with understanding user requirements, the team prioritizes ease of implementation and maintenance over users’ needs. Consequently, sticking with an out-of-the-box implementation gets prioritized, because that will make upgrading later more straightforward.
Remedy: People identified as key users of the new system should be included on the implementation team to highlight the tasks that make them successful, and ensure those get prioritized. These key users should also validate that the design is appropriate for their needs as the work progresses to reduce the chance of surprises after rollout.
The inclusion of key users as team members should happen even if — specially if — the rest of the implementation team is external to the company. An Agile development process can be helpful at this stage with its emphasis on cross-functional teams, prioritizing a backlog of tasks worded from real users’ perspectives, and completing user-visible chunks of implementation in short, time boxed iterations that can be touched and validated by actual users.
User Expectations are Higher in a World of Devices and Apps
Enterprise software used to represent the most sophisticated, feature-rich software a person could expect to interact with. Now, compared with the apps that many people use daily to manage their personal lives and interact with their friends and family, most enterprise software looks third rate. It is often too complicated, too slow and too cumbersome to compete with the market’s evolving expectations.
When users are accustomed to using dozens of apps that are immediately understandable, useful, visually engaging and accessible across a range of devices, they become increasingly intolerant of tools that demand they learn new vocabulary, use specific versions of software, stay tied to a desktop workstation, and figure out how to avoid causing catastrophic results.
Remedy: Understanding employees and the tasks they need to perform to be successful at their job requires research into how they do work, with whom, where and when. Also useful is knowing which devices they currently use — whether for work or not — which apps they’ve become accustomed to, and what kinds of languages and gestures they use in interacting with those apps. The technology landscape changes quickly, and ongoing research like ethnographic studies, usability studies and discussions are required to understand a target user population and what will help them be effective and satisfied.
Change Management is Overlooked
Rolling out a new software system typically involves training users. Management may mistakenly believe this rollout plus training combination alone is what users need to get accustomed to the new way of working. Work gets done, however, via an interaction amongst people, processes and technology. Changing any one of these variables is going to affect the others and requires consideration, planning and preparing the people involved. New software that will change the approach to work (even if it has many of the same features as a previous system) is a revolutionary change for users, and requires more support over a longer period of time than a few days of training.
- Are You Too Old to Work in Tech? IT's Midlife Crisis
- EMC Should Sell Documentum, HP Should Buy It
- Customer Success is a Failure
- If Hadoop Disappears, Will the Label on Your Distro Matter?
- 7 Deadly Signs of Career Burnout [Infographic]
- Inside Acquia's Gartner Ascension, Web CMS' Next Road Trip
- Connecting Workers to Information in the Digital Workplace