Majesco TL
Follow Us



Has Insurance IT Changed that Much?

George Grieve | November 02, 2015

Core systems modernization remains the hardest technology initiative that an insurance carrier will undertake. Many of the functions core systems perform are not visible and therefore not valued by the higher levels of the company who approve major technology spending. 

They cost an arm and a leg. They detract from the company’s ability to do other things. They take years to complete. They are complicated and hard to do well. They suffer from unrealistic expectations. They are hard to cost justify. None of these facts have changed, nor will they change.

On the good news side, as we have discussed in the past, the vendors are getting better at software development and delivery and the third-party services available are growing and varied.  As I’ve said before, there is no better time than now to undertake these major projects, but I remain unconvinced that the success rate of core system modernization projects is as high as it should be and I think the main cause for this is to be found in the carriers themselves.

Historically, responsibility for project failures were pretty evenly spread across the participants—vendors that were less than honest, SIs that were focused on billings, and carriers that didn’t know what was going on. I believe the first two groups have substantially improved and cleaned up their act, but there is still too much evidence that the carriers don’t know what is going on. 

Depressingly, there is evidence some carriers that made the legacy migration journey in the past 10 years are unhappy enough with the results that they are making it again with a new vendor.  One would hope these carriers come to the second go-round with some hard-earned knowledge that will minimize the likelihood of a third go-round at some future date.

I have been banging on (and off) for years about what makes these mission critical projects succeed. It would seem to be worth stating again, even though I thought we were beyond the “what makes projects succeed” conversation.

Core systems modernizations, as I have said many times before, are irreducible, complex, and difficult to pull off and I in no way want to make it sound as if there is an easy prescription for success, but the more I think about the topic the simpler the problem gets. If a carrier does the following three things well there is a high likelihood of a good outcome.

Choose the Right Solution

I have argued recently that the definition of the “right” solution is changing away from being heavily functionality-based to being more execution-based. Vendor systems are now are more functionally broad, better written, and more easily modified and extended. Therefore, the possibility that one vendor will differentiate themselves on functionality alone is smaller as time goes on. Where vendors win or lose is more on execution—their implementation track record, software configuration capabilities, support, pricing, and contract terms. 

As important as choosing the “right” vendor, the carrier must have a complete understanding of the vendor they choose. Often, problems that arise with implementation projects can be directly traced back to a lack of homework during the selection process. The landscape is littered with problems large and small that originated with a lack of insight as to what the vendor’s capabilities were is a given scenario. A project may go swimmingly well for a period of time and then hit the rocks. 

Analysis often shows the early going was a repeat of efforts the vendor had previously done and the rocks appeared when the vendor was being asked to do something they hadn’t done before. One of the truisms of projects is it’s never good to be first.        

Resource the Project Adequately

In almost 40 years of being involved with technology projects, I have never seen one that allocated too much time, too much money, or too many qualified people. Pretty much every project is under resourced in one or more of these key areas. 

Why do we do this to ourselves? If we can fail for $3 million or do a half-cocked job for $5 million, why not do a good job for $6 million?  Why is it the people who know almost nothing about the project get to arbitrarily set down deadlines that the project must meet? Why is it that people who should know better undertake an expensive, mission-critical, enterprise-wide project without securing key resources that have done this before? What makes a carrier’s management think that the people that have spent 20 years doing maintenance can suddenly pull off a core system replacement? Or that the vendor will do it for them? 

Here is a second truism: The best risk mitigator is to have key resources on the project who have expertise doing core system modernizations. It is unrealistic to expect people to figure out how to control such a demanding project without the benefit of prior knowledge. Third truism: Not knowing is dangerous, not knowing what you don’t know is very dangerous. 

Experienced resources don’t know everything, but crucially they know what they don’t know, and they know how to figure that out. In discussing the keys to project success we often talk about methodologies, realistic plans, and suitable approaches. These frameworks and artifacts are, of course, important, but they are secondary. If the project is (human) resourced appropriately then these assets will follow, brought along by the experts who have done it before.

Why do we place arbitrary and unrealistic timelines on projects? There is some justification in time-boxing a project to meet a compelling date; regulatory changes, contract expirations, and important business triggers come to mind. But if the project is made to labor under such restrictions then senior management should reasonably be expected to loosen the purse strings and resource the project adequately. 

In my experience most projects are under resourced and time constrained because of systemic lack of understanding of the sheer scope and complexity of work involved. But if nobody actually knows what the project will take, then at least build flexibility and reserves into the time and cost estimates.

Truism number four: Ultimately the project is going to take what it is going to take. Any senior management notions that somehow the project will expand to fill the time available fails to recognize the commitment and extreme efforts of those who participate in these projects.  There is enough stress to go around without management’s help.

Control Expectations  

If you get the right vendor, and you get the right people, you still have to control expectations. The reality is that core system modernizations happen infrequently and therefore take place in an atmosphere of long-suffered frustration and disappointment on the part of business users who have been waiting for all kinds of fixes and enhancements for years. This pent up demand, coupled with the sales pitches about speed, flexibility, and functional completeness—both internal and external—required to procure approval and funding can easily overwhelm the project scope in a way that can threaten success. 

As every IT professional knows, the best course is to slim the initial scope delivery in order to get into production and create momentum. This, of course, is diametrically opposed to the business-users view that if I don’t get “it” now I never will.

I have argued previously that the best way of viewing a core system modernization project is that rather than satisfying a (lengthy) laundry list of functional requirements, it is about establishing a modern and flexible platform on which the company can continue to evolve and enhance its core processing capabilities for years to come. The project is not a once and done event. Truism number five:  The implementation is not the end of the project, it is the beginning. 


Not every project we at CastleBay see suffers from these three major problems, but those that don’t are the exception, not the rule. Given the infrequency and the criticality of these projects it seems rationale to expect senior management’s only question should be, “What do you need and what can I do to help?” If they don’t have enough trust in those charged to execute the project that they feel they can take this approach then they should get a stronger execution team or cancel the project.   

Featured articles

MT 160x600

Majesco RH


The Email Chat is a regular feature of the ITA Pro magazine and website. We send a series of questions to an insurance IT leader in search of thought-provoking responses on important issues facing the insurance industry.


The tide is up! It's time to register for ITA LIVE 2019, our annual educational and networking conference! Our theme is "The InsurTech Revolution: Cutting Through the Hype." and we'll be bringing in a torrent of industry thought leaders, amazing insight and wonderful perspectives on the world of insurtech and its impact on the insurance landscape.

ITA LIVE 2019 will present real-life examples of true startup technologies that are helping insurers gain real advantage -- and a competitive edge -- in the marketplace. We’ll highlight the more successful InsurTech partnerships, while offering case studies that demonstrate exciting innovation and cutting-edge techniques impacting all aspects of the insurance ecosystem.

Ride the wave to LIVE 2019. Sign up today! We look forward to seeing you in May, 2019!


only online

Only Online Archive

ITA Pro Buyers' Guide

Vendor Views

Partner News