Some years ago, a seasoned colleague of mine would introduce our Agile process to the implementation team of a new client with a stark reminder: “Software implementation is a painful, messy process. Be prepared for anger and frustration, because no matter how good the base software, no matter how experienced the team leaders, no matter how effective the process, you will at some point feel like the process is failing.”
Add to that the fact that in many cases the project is failing, and you wonder why any sane leader would undertake a major transition like implementing a new insurance administration system. The number of failed implementations is exceedingly large. There is truth in the perception. “Our old system still cranks out the policies and does everything required, a few things we uniquely need (which we paid for, by the way), and even some bells and whistles. It doesn’t do everything, and we have a ton of workarounds, but It works. And, they still upgrade the software; well, they fix bugs but they don’t really improve it.”
This seems like a reasonable decision. But it is not. There are myriad reasons, but let me offer just two.
First, even if the software is supported, and even if the vendor adds functionality or alters the front end to appear more contemporary, the foundation is still old. Rarely do software companies invest in dramatically improving the core, especially in a way that takes advantage of all the tools and features that accelerate development, protect and secure the data, and enhance the user experience. New software can be bolted on to the old core, making the software look and feel fresh. But often the ‘bolting on’ process makes maintaining the system that much harder in the future, particularly as the original designers and developers move on. Lots of moving parts trying to talk to each other, some of which may not be perfectly compatible.
The second reason may be the more critical, especially for the company: the longer the decision is delayed, the more painful the process will be. Not because the software will not be capable, but because the project will take on a more ominous tone – as the pressure to successfully install the software builds, so does the fear of the undertaking. The decision to pursue new software likely reached a point where it could no longer be delayed, which likely means the staff is at 110% capacity just trying to keep everything together and on time. And now they are expected to devote hours in a day to adapt and test the new system? The pressure leads them to try to recreate their current work experience with the new software, because it’s easier for them, which, of course, reduces the power of the new software. Who could possibly enjoy that experience? Who is going to tell the users ‘no’ to processes or features that are no longer necessary because the solution is integrated into the new software? Somebody wants a button somewhere, and they’ll likely get it. There’s no time to argue, and training the new person will be someone else’s problem, and the cost to train will be someone else’s budget.
Hence the title ‘Fear of Flying.’ Change is hard enough without adding the pressure of time. If the software can help a company ‘soar,’ then the executive team must be closely involved in the implementation process. They’ll understand the risks better, they’ll be able to work through some of the change management issues more easily, and the sense of top to bottom unity will reduce the fear of failure.
There will always be implementation risks; abject failure need not be one of them. There are few companies that are truly happy with their software, and steps can be taken to be one of them. That seems like a reasonable goal to begin with.
~ Bill Montei, CEO, founded Megalodon Insurance Systems with a simple yet BIG idea: provide small and mid-sized insurance companies powerful policy & claims management software solutions at a price that is within reach. To talk to Bill directly, please call: (608) 709-2154.