This blog post is the second in a series of implementation best practices and it focuses on user adoption and user buy-in. I frequently tell my implementation team that they need to be very concerned with user adoption and buy-in on the project or else the project will surely fail. My experience tells me that even if you implement a system that meets exactly the functional goals outlined in the contract but fails to obtain user adoption then the whole system is likely to be scrapped. So, this post will discuss my thoughts on how to obtain user buy-in and adoption. My thoughts:
- Have a kick-off meeting with a broad range of users across the spectrum prior to the formal project kick-off to educate everyone on what the project is, why the company is doing it and most specifically how it will benefit them. This meeting ideally would be held in person to generate excitement or alternatively through an interactive webinar as it is difficult to get all users in the same room at the same time. If everyone is global, multiple meetings may have to be held. I would suggest live meetings over recorded ones so people can ask live questions and get an immediate response.
- The users that are chosen to be “super users” or key users in the project should be people who not only have the requisite functional knowledge to represent their area but also have the respect of the other users they represent. Sometimes people are assigned to the project because of their deep skill knowledge, but lack respect from others on the team so the other users automatically distance themselves. The right person should have both functional skills and respect from their peers/colleagues.
- The key project team members should also be empowered and held accountable. They should be able to represent their area and make decisions for the entire group. Or if they need to ask others for input, that they do so in a streamlined process that does not drag the project around in circles. Too many times I have seen people say “here are the requirements” but when additional users test the system, those users identify gaps in the requirements. The signed off requirements should be the marching orders for the project team.
- A broad spectrum of people need to be involved in the design of the solution being implemented. Let’s assume we have a global project and we’ve assigned excellent super users from North American on the project however, this project will also impact users in Europe and Latin America. Ideally someone from Europe and Latin America need to be assigned to represent those regions so the users from those regions feel their voices are heard and buy-into the system being developed. Do not assume great super users from one region can represent another.
- Super users/key users representing a broader group of users should be communicating regularly to the broader group decisions being made and generally keeping them informed on status of project.
- Users need to be involved in testing. Of course the day to day project team members will unit test the system to ensure requirements are met. A broader group of users should be brought in for acceptance testing, although they should be carefully prepped so they aren’t trying to broaden scope or add new requirements. By bringing them into the acceptance testing activity they will not only have a better understanding of the system but they will also feel more involved.
- Effective training is the key and an area not to be skimped on. Generally it is not a problem for the day-to-day project team members to get training on product, but some companies don’t spend a lot of time focusing on end user training. Effective (or non-effective as the case may be) end user training can make or break user adoption.
- Communication – again, regular communication on status of the project, timelines, scope, how it will impact them will aid in user adoption.
- Some projects I have been associated with will also perform a parallel run, this can be useful if you are worried about user adoption at go-live and of course mitigate the risk at go-live.
- And lastly leadership, the company leadership needs to be vocal about the benefits of the system and enforce use of the system by their teams. If the users don’t see leaders involved and stressing the benefits, they may not get on board.
Those are my thoughts, please share your thoughts and experiences as well. See first post of series here on executive sponsorship.
Leave a Reply