When companies deploy a new software solution, they do so because they believe it will solve a growing problem, create a new capability, or drive efficiency.
Part of your organization’s success may hinge on an effective deployment. If it goes well, that’s great. But if it doesn’t – well, you’re probably worse off than if you’d done nothing.
You need to get it right.
Consider this typical scenario:
You start with a part of your organization that’s struggling, perhaps badly, in one way or another. That’s why you want the tool to begin with. If you’re considering a new incident-management tool, for instance, it’s probably because you’re experiencing too many incidents and dealing with a long backlog, you aren’t monitoring your applications properly, and every day is a new fire drill. To that dysfunctional environment you add a new tool. The tool is supposed to drive transformational change – and for that to happen, your people need to adapt and change, too. If all that fails, you’ve taken a troubled situation and added a raft of new problems.
To get the new tool approved, you carefully built a business case, enlisted allies among your peers, and made your pitch, perhaps to a cross-departmental committee charged with approving such purchases. It’s one thing to be rejected. But if your proposal is approved, and the deployment fails, either during or after the implementation, you’ve jeopardized everyone’s credibility, especially your own, and generated ill will among your peers.
You may not get a second chance to fix the problem that you implemented the new tool to solve. You’ve already spent significant company resources trying, and failing, to solve this problem. Sure, the problem still exists – and is likely worse than ever. But will the company be ready to write another big check to fund another new software tool after being burned the first time?
Is it any wonder, then, that when a deployment fails (as so many do), that the software itself so often takes the rap? Just as a craftsman blames his tools when a project fails, IT people blame software. I’ve heard it a hundred times: We were misled by the vendor. That tool didn’t do everything it was supposed to. The software didn’t integrate with our legacy systems the way we expected it to. Simple upgrades cost a fortune.
It’s Not the Software’s Fault
But here’s the dirty little secret: Nine times out of 10, there’s not a thing wrong with the software. What usually happens on an unsuccessful deployment is that the people managing it inside the organization failed to fully understand the tool; they made fundamentally poor design choices upon implementation; they built complex customizations on top of the tool when they could have just configured it to do what they wanted; they failed to address internal staffing; or they made any of dozens of other common mistakes.
For example, I’ve worked with several companies that have deployed new software tools, only to seek upgrades shortly after launch that cost far more than they anticipated. The reason? They customize their new tools upon implementation to make them work more like the software they’re replacing, increasing by 10-fold the cost of eventual upgrades.
How to Avoid Failure with Software deployment
How can you reduce the likelihood of these kinds of mistakes at your organization?
First, consider your people. How familiar are they with this tool? Are they capable of managing it after the implementation? Will they know how to expand its value in a smart way over time? Or will you need to bring on new staff, either temporarily or permanently?
Many organizations assume that a given employee will be able to continue performing a crucial function on the new software, just as he or she did on the legacy system. And they don’t discover that’s not true until it’s too late. It’s imperative that you have a plan for how you’re going to manage the tool over time – and for who in your organization is going to do the work. If there’s no one you feel confident can handle it, you may want to consider an alternative.
Next, think about your processes. Are the business goals of the implementation clear to all? Does everyone know what to expect once the new software is deployed? Are the right people being trained, at the right time? And what happens the day after the deployment?
Moreover, are your existing business and technical processes conducive to this new tool, or will you have to make changes to how your IT department (or other departments) actually work in order to use the new tool successfully?
The challenge you take on when you deploy a new software solution only increases after the installation, when you’ll be left on your own to drive user adoption, manage your new tool, configure it, and increase its value over the long term.
Do you have a plan for all that? If so, great. If not, maybe we should talk.
