Jon Hughes, VP of the Technology Solutions Group for Robbins-Gioia, recommended getting lead users from different parts of the organization to come in and do the acceptance testing. Not only do they provide the viewpoints of different user groups, but they can then act as ambassadors to their fellow employees, easing the final deployment.
“If the test is successful, they will go back to their coworkers and friends and peers and say that when we get the system, life will be so much easier, it will improve productivity, we won’t having to worry about data integrity and walking all these papers around,” said Hughes. “You need that kind of energy going back out into the organization because it is the users who will make or break a deployment, despite executive buy in.”
Out the Door
Finally, the software is ready to roll out to the end users. Even if another part of the organization will be conducting the roll out, that doesn’t absolve the developers of all responsibility. “What we realized is that the end to end experience determines the customer perception,” said Abid. “Your customer will not be happy with a very well-developed system which got bungled up in roll out.”
The deployment can be done either as a “big bang” deployment, or by taking a phased approach, gradually issuing the functions or rolling out the software to one group of users at a time. If you have successfully involved users in the requirements and testing phases, users should be looking forward to getting to use the new system.
“A very good practice is to have a focus group of users working with you closely throughout the project,” said Bykov. “You will not only get great feedback from them, but also get supporters and trainers for other users.”
Letting them see and click around in prototypes is an easy way to gain familiarity, but there is a risk in doing this too soon.
“If you start giving the users early builds containing lots of mistakes, you may get disappointment and lose their trust,” Bykov continued. “So, give builds often, but only with ready functionality; all non-implemented or buggy parts should be disabled.”
Even if users are looking forward to the new system, their enthusiasm can be crushed if they aren’t properly trained before they have to use it for production. The education should be ongoing during the development process, and it should take into account the current skill level of the employees. While most are now used to web-based applications and pull down menus, not all are.
“Avoid a big bang deployment unless it is a very intuitive system and dedicate the necessary time to training,” advised Hughes. “There will be users who are resistive and very negative and you just have to show them they will be better off with the new system.”