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
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.