4 Ways to Guarantee your Software Implementation WILL Fail!

Implementing a new substantial software system at ANY organization is a challenge at best or a pure nightmare at worst. Challenges, if properly managed, can be overcome without a lot of drama. Nightmares on the other hand, can largely be avoided, but once your company is in that realm, can make you want to update your resume and get out of Dodge! There is a lot of commonality between building new custom software for your organization and implementing existing best of breed software. Both projects have a natural course of “the toilet” unless actively managed from the start. Here are 4 common ways we’ve seen implementations that should have been relatively easy, turn into “resume updaters”.

1) Don’t provide top-down support

This sounds so logical and intuitive, doesn’t it? But the reality is upper management many times decrees something, like “get new software”, then is hands off after that. For us, top down support means top management sanctions the project, explains WHY it is important for the company to do it, then holds everyone accountable for the successful execution. Basically, it must be conveyed that this is our new “bus” and everyone is welcome on the “bus”, but if you are not 100% committed to the successful conclusion of this “bus ride”, then you are encouraged to get on another “bus”. Oh, please keep in mind we can transfer you to another “bus” at any point during the ride if you are disruptful to the other passengers (see item 4).

2) Don’t involve employees in the process

So upper management may make the final decision, but they MUST include all relevant employees in the decision making process. The average employee must understand the reasons why this change is going to help the company, help them and make their job easier. Change is hard, and it’s harder for some employees than others. Keeping employees in the dark during the process of finding, testing and deciding upon a new software system only helps to place barriers between the employees and management. Barriers contribute to item 4.

3) Don’t give employees tools to understand and manage change

As mentioned in item 2, and everyone can testify, most people find change difficult. It has been said that the only constant in life is change. The better someone can adapt to new situations, I believe, they more joy they will find at work and life in general. One aspect of a dramatic business change that is nearly always missing, is providing some “tools” that help employees identify their individual “change anxieties”, and ways to manage and ultimately overcome those anxieties. Sometimes it’s fear of being perceived as “not smart”, or not being the system expert anymore, or thinking the software will replace them and they will be out of a job. Not allowing Items 1 and 2 go a long way to calming many of these anxieties, but providing managers tools to help employees past their individual issues will help to make the implementation a success.

4) Allow employees to undermine the change

Someone who has been working at your company for a long time, or the current software system is the only software they ever used at that company, may have a harder time with change than newer or younger employees. We all get into comfortable “ruts” in life; work is no exception. Properly addressing items 1-3 should be laying the groundwork for a successful implementation, but sometimes an employee just will not cooperate. Instead they sow discord in the company, and find any possible reason why the new software will never work. There is usually one such person in every company, and management must be compassionate but firm. This person should be taken aside and nurtured, but if they persist in trying to undermine the project, they must be let go. Sometimes it’s an employee that has been there “from the start” and sometimes it’s a relative newbie. In either case, allowing that employee to remain is like leaving a malignant tumor in your body because you don’t want a scar. That person, if allowed, can sink the entire implementation. I’ve seen it happen more than once, and it is pretty predictable if items 1-3 are allowed to exist.

Conclusion

While this is not an exhaustive list of ways to torpedo a software implementation or any major change at an organization, it does represent a good indication of the probability of a successful or nightmare project. Before we start an implementation, we go through these and other items during a pre-mortem so we can give the people responsible for the implementation at their company a heads up of what to avoid.