Chances are you have been involved in an insurance technology implementation at some point in your career. Whether you have ripped and replaced a core system, installed a new rating engine, or even just upgraded existing systems, there is a good chance you have had to deal with situations like the one in Doorway episode 6.
The real dilemma here is that the solution provider is on the hook to deliver their system, and customer priorities and needs can change throughout the implementation. It is not necessarily a bad thing, but does expose some fundamental issues with insurance technology implementations – that is if the technology being implemented is the wrong tech.
1 The technology being implemented is not as flexible as you thought
While many insurance solution providers claim their software is flexible and configurable, the reality is that most are not. Configurability tends to be masked with custom coding that ends up being unique for each implementation. The result is that the software is so intertwined that any change on something previously delivered has a domino effect on everything else. Even the smallest change can have the largest impact and disrupt the entire implementation – extending the project lifecycle and increasing cost.
In order for technology to be flexible, it needs to be hyper-configurable – meaning the user has complete control over the implementation where they can make changes as needed without the risk of crashing the entire system.
2 Agile is not always flexible
Technology flexibility is undoubtedly the greatest impact to any implementation; however, the process or methodology being used is also a major factor. While Agile approaches are widely adopted throughout the insurance industry, the reality is that it is not a perfect process. It promotes flexibility, fast deliveries, and instant feedback, but just because you are doing an Agile project does not mean it will be successful.
The problem is that Agile is not always flexible.
Agile still has dependencies and every sprint builds upon previous deliveries. Any requested changes are pushed to future sprints in order to keep the flow of the project, and if subsequent sprints rely on previous deliveries, the whole model could collapse. Combine this reality with technology inflexibility and you have a perfect recipe for a failing project.
3 The customer doesn’t always recognize what is possible
It’s a known fact that customer requirements and priorities will change throughout the project. What the customer initially thought they needed or wanted can change as more functionality is delivered. This is does not mean that the client doesn’t know what they want, but realize new opportunities as features become available. For many organizations, this could result in a complete overhaul of business processes, or underwriting procedures, and so on. Many pre-implementation decisions are based on initial product demos which tend to only scratch the surface of most insurance software. It is not feasible to understand every feature before starting an implementation, but the customer (and vendor) need to be flexible to adapt when necessary.
The ClarionDoor Experience
The major difference with ClarionDoor is our technology. We designed our software as a no/code solution with the utmost flexibility and configurability which means that you can make changes throughout an implementation without disrupting prior and future deliverables. Our software was designed with you in mind, ensuring that every customer can control and manage their insurance products with ease and without the need for exhausting implementations.
With implementation times that far exceed the industry norms, we have employed a process that actually gets clients live in weeks, liberating you to focus on innovation rather than implementation. So, if you need to change something, you won’t have to worry about crashing the implementation.
Learn more at clariondoor.com and follow us on Twitter and LinkedIn for the latest ClarionDoor updates.