The User Acceptance Problem



The User Acceptance Problem

Norman Carnovale

pEoplE AREn’T AlWAyS HAppy about new systems or major upgrades. This can pose a threat to the successful completion of a project.
It’s not uncommon for people to disagree with the decision to implement a new system—especially at the beginning. This should be expected, and the reasons noted. However, initial reactions to a new system are less of a concern than a sustained negative reaction.
Your goal as an architect is to be aware of and measure the threat of acceptance problems and work toward mitigating those threats. To do this you have to be cognizant of them and consider the reasons for them. Some of the more com- mon reasons are:
• People may have concerns about the need for a new system (and subse- quent retirement of an old system). This can also include fear of losing functionality or losing influence or power when roles change.
• People fear new (unproven) technology.
• People have cost/budget concerns.
• People simply do not like change.

Each of these reasons requires different possible solutions, some of which you can address and others you can’t. You have to recognize the difference and deal quickly with those that you can. Start early having discussions with your end users about the new system and its real and perceived benefits and disad- vantages. The most effective long-term solution is to use the design of the sys- tem itself to address the concerns. Other effective solutions include training, scheduled system demonstrations (early in the project lifecycle), and sharing knowledge of what users will get with a new system.
A “project champion” can help avoid user acceptance problems. Ideally this should be a person that represents the user group or stakeholders. This person sometimes has to be convinced himself. If there is none, then push for one from the very beginning. Once you’ve recruited a project champion, give him your assistance in every way you can.