Conventional wisdom is that stakeholders must be involved when selecting enterprise software. But who are the stakeholders and why must they be involved? How can you maximize that involvement? Note that this is not a technical issue, but a people issue that directly affects the outcome of a software acquisition project.
Who are the stakeholders?
Internal users: Employees who make regular use of the system. In most projects, the internal users are the most relevant stakeholders. If they have truly bought into the new system, the probability of success is far greater. This article focuses on driving end-user buy-in.
Executive sponsors: They will be using their budgets to invest in the new software. They want a sizable ROI, otherwise why bother with the project?
Indirect users: Anybody served by primary users of the software. Think of an employee using the software to help a customer. That customer is an indirect user.
External systems users: Users of any systems that interface with the new software. For example, think of an employee using an expense claim system that connects to the corporate accounting system. In this capacity, the employee is an indirect user of the accounting system.
External users: Non-employees who use the system. They could be vendors, job applicants, “free users” and so on. Consider job applicants and the everyday frustrations they face with recruiting software:
- The software wants a resume and then demands the applicant duplicate that information by describing each job in detail on a form.
- The system wants the applicant’s zip code, and then demands city and state as well, information that should be derived from the zip code.
- The home phone number is a required field. Why, when for most people the primary contact number is their mobile number?
If external users find the software frustrating, the best candidates won’t bother using it. Only those desperate for a job will make the effort – hardly the best way to recruit. Although external users can be difficult to work with, achieving success with a software projects may require considering them.
Why is buy-in so important?
New enterprise software requires considerable effort from users, such as in learning the new system, or using new and old software in parallel for a few months. When users are disinterested in the new software, resent the extra work, or are actively working against it, that can doom the rollout to production.
The best way to launch new enterprise software is to have the user base seeded with champions for the new system. When enough of those champions fully buy into the vision, their enthusiasm becomes contagious and helps the entire user community through the implementation efforts.
How do you get stakeholder buy-in?
End users must feel involved in the process of selecting the new software, and know they’ve been heard with regards to their needs. They must know their lives will be easier after the transition. Try to discourage excitement over particular products because employees will be disappointed if their favorite is not selected. Have a transparent, data-driven and repeatable decision-making process that does not favor political interests over real needs. Users are far more accepting of transparent decisions.
These three steps will help create end user buy-in:
1) Initial requirements interviews: These interviews signal to the organization that the project has started, and present an opportunity to build rapport with users. Unfortunately, most users know only their pain points, and not many other requirements, so don’t expect too much from them. (See other methods for gathering requirements.)
2) Rating requirements for importance: Here the different user teams are interviewed, such as finance, IT, production and so on. For each requirement, you capture how important it is, why it is important and to whom it is important. When users see their input being captured on each requirement, they feel the organization is listening to them, and this is what builds the most buy-in.
Capturing data to rate the importance of user requirements
3) Software demos: A gap analysis ranks products by how well they meet the organization’s needs. Taking budgets into account, typically one to three products are selected for a demo. Users are reminded that the products are selected based on the gap analysis and that the demo serves only to confirm that decision, not to make it. The demo is where the excitement for the new system builds in the user community.
It goes without saying that there needs to be constant communication with the stakeholders all the way through the project. However, using the three steps above will maximize user buy-in. In turn, this will help drive the new software acquisition project to a successful conclusion.
This article was written by Chris Doig from CIO and was legally licensed through the NewsCred publisher network.