Silence. That was the sound in our support center. Our team interpreted this hush as a sign that our largest customer’s software installation was working perfectly.
We were basking in the glory of a perfect enterprise rollout. The users had gushed over the new software during training and swore that they couldn’t wait to use it. What a grand success!
Turns out we were acting like the proverbial ostrich with our heads buried in the sand. Sure the software was installed OK, but no one really knew if it was working because no one was actually using it.
How could this happen? Where did we miss the boat? Our management team decided to review the implementation project and found three major reasons why the rollout ultimately failed. Whether you are an independent software vendor, consulting firm or customer, you can learn from our project’s shortcomings and help ensure that your users embrace new software.
Certify, Certify, Certify
The first shortcoming in our rollout was directly related to training. We didn’t require a certification to prove the users could effectively make use of the software in their day-to-day job tasks. If users know they will be tested, most likely they will pay closer attention in class. In addition, a certification that is driven by business scenarios will make them think through exactly how they will apply the software to their work environment.
Kathryn Whitmore, a principal with Enterprise Solutions Group in Hunt Valley, Md., found lack of certification to be a significant reason why the rollout at a hospital fell flat on its face.
“Our project team followed implementation best practices, including getting buy-in from the hospital’s president and having nurses develop the training curriculum,” says Whitmore. “However, when the software was implemented the nurses said it was cumbersome and fell back on their manual process. Turns out the mistake we made was asking the nurses to complete a voluntary tutorial on their own time, resulting in required training not being completed. A more diligent of certification process would have solved this problem.”
Pilot and Phase In
The second problem resulted from lack of a true pilot project. This is especially important when rolling out software to multiple locations. If you pick one location to test the software, you can reduce the risk of identifying problems too late in the game.
For example, if the test location finds that the new software requires an extra step in their workflow, you can modify the workflow accordingly. By doing so, you show that you will listen to their feedback and will win them over as champions of the software who will help promote the eventual rollout to other locations. By implementing all at once, this problem would have undermined the confidence of the entire user base.
Whitmore not only believes in pilots, but in a phased rollout approach.
“You don’t want to bite off more than you can chew. A phased implementation allows you to address problems without overwhelming your support team,” says Whitmore. Wouldn’t you rather have a few users identify a problem, instead of hundreds? Whitmore goes on to say, “Garnering support and involvement of folks in the field is critical to any rollout’s success.”