Editor’s Note: This article originally appeared in the Analyze Re blog.
Historically (re)insurers have had to invest heavily in developing their own proprietary systems. Much of this was driven by the fact that third-party solutions were simply not available in the marketplace. Over the past 10 years, the insurance technology landscape has been transformed dramatically, and (re)insurers regularly confront the decision of whether it makes more sense to build their own proprietary system to solve a problem or purchase a third-party solution. What makes this a particularly difficult decision is that the “build” approach has many hidden risks and opportunity costs that are not immediately apparent.
According to the Harvard Business Review article “Why Your IT Project May Be Riskier Than You Think,” the average cost overrun of an IT project is 27%. But what is more disturbing is the “fat tail” of projects that went significantly over budget and behind schedule. The authors found that, “One in six projects we studied … [had] a cost overrun of 200% on average, and a schedule overrun of almost 70%.” In talking to our clients, we know there are similar (re)insurance stories out there.
The true costs of an IT project to build an application may be costlier than you think, when you take opportunity costs fully into account. Think about your time spent with technology teams defining requirements and getting project updates. What could you have done with that time if it had been spent instead on analyzing and managing your company’s risks, developing new strategies to grow your premiums, and developing the capabilities of your analytical teams?
And to expand the discussion of opportunity costs further, one needs to consider the speed to market of buying a solution versus building a solution. Implementing a third-party solution also takes time to implement, but I think it’s safe to assume that in the majority of cases building a solution from scratch will take much, much longer. So, the question one needs to ask is what that additional time to market costs your business in terms of underwriting profits.
Left in the Lurch
But let’s say your internal projects have proved successful, fit all the requirements, and come in under budget and on time. Mission accomplished? Yes, but what if your star developers and product managers leave for higher-paying jobs at a competitor or leave to create their own startups? How will you maintain and grow your homegrown software amid continual technological change? How will you maintain the culture to attract the talent needed in an area that is not a (re)insurer’s core competency?
I have focused on the downsides, both hidden and obvious, to the build approach. However, in fairness, I need to acknowledge the major challenge of the buy approach, and that is the need to fit your company’s needs to a third-party’s structure and framework. It is for this reason that we believe a hybrid approach represents the best of both worlds for many (re)insurers, and we’ll be exploring this further in future posts.