Why Enterprise Software Rollouts Fail

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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

Lose the Legacy

The third problem revolved around our customer keeping the legacy software in place. Forgetting their password to the new software was all the excuse a user needed to fall back on their legacy application.

To avoid this problem, Whitmore firmly believes that the deployment plan must include sun-setting of the old system.

“You must physically unplug it and turn it off or else it will be an easy crutch for users who have the slightest difficulty with the new system,” says Whitmore.

But Whitmore cautions not to pull the plug without risk management.

“Keep the old system in place until certain metrics are met. For example, you can base metrics on the number of support calls. But it is key to make users aware that the end is inevitable,” she says. “I recommend initiating a visible countdown based on the predefined metrics.”

Now that we have identified these three problems, let’s dig one level deeper. All of these problems can be attributed to an overriding issue at the customer’s corporate management level. There was a lack of leadership from the corporate sponsor.

Even if you gain significant user support, ultimately it is not possible to ensure a successful rollout without a strong corporate guiding hand. If corporate is making a major technology investment, then someone has to lay down the law!

Corporate Buy-in a Must

The corporate sponsor must not only be an enforcer, but an enabler. With regards to training, you could not have a certification without enforcement and encouragement from corporate. If someone fails the certification, the consequences must have teeth and there can be no rubber stamping. They must retest until they pass, tying results to their performance reviews. For those users who have a difficult time adjusting to the change, consider providing additional training or hand-holding.

As for the pilot test site, those users must know they have the full backing of the corporate sponsor to push for changes deemed critical to their productivity. They should be rewarded for taking on pilot responsibilities in addition to their daily job tasks. Make sure they recognize the significant exposure to the corporate management team that could lead to career advancement.

Finally, only the corporate powers that be will have the standing to shut down the legacy system. Predefine metrics as suggested by Whitmore and over-communicate to users so they feel confident in the transition.

By closing down the legacy application, vetting out problems during the pilot and ensuring user capabilities through certification, there will be less resistance to moving off of the old application. Taking these steps will show the user community that the corporate project team has taken the necessary measures to make the rollout a success.

If you avoid these shortcomings on your software rollout, the silence you hear in the support center will be golden.