Some of you know that we (Summit Business Media, Tech Decisions, and CastleBay Consulting) recently completed a series of webinars as part of our 2013 Shop Talk Community initiative.  These webinars followed the Shop Talk book structure and focused in turn on the vendor software market, software selection, and core system implementation projects.  This was an opportunity to update our thinking on these relatively dynamic areas.  Here is the main narrative which emerged from this exercise.

Not Your Father’s Software Market

The core systems software market has changed radically and for the better in recent years.  Indeed there has never been a better time for a carrier to acquire third party software.  There are several reasons for this assertion. 

First, vendors are writing better and more complete software.  The functional footprint of a policy administration system has always included product definition, rating, policy maintenance, and print functions.  Modern PAS often include significant functional additions such as portals, for agents and consumers, BI capabilities, and other major enhancements. 

While the base functional footprint has grown there also is recognition that a “package system” will not meet the specific needs of any potential customer and that bridging the delta between the base functionality and the carrier’s requirements is critical to the success of the implementation. 

This fairly obvious fact led to a profound shift in how vendors thought about and delivered software and hence to the development of configuration toolkits which can be used to close that defined delta more quickly and at lower cost than ever before.   Further, most core systems now support both personal and commercial lines solutions; as recently as seven or eight years ago this was not the case. The hoped for result is a highly customized system at “packaged software” prices. 

Second, the carrier now has more acquisition and implementation options.  Vendors commonly offer in-house licenses, ASP models, and are increasingly moving toward the provision of SaaS and cloud solutions.  Also, the days when “rip and replace” was the only implementation option are gone as vendors provide “best of both”  offerings that blur the lines between best-of-breed and suite solutions and allow carriers greater freedom in deciding how and when to take software. 

Third, vendors generally have moved to a more agile style of implementation methodology which increases the likelihood of better implementation outcomes by encouraging early viewing and feedback cycles as the software evolves.

Success Needle Hasn’t Moved

Given the above, you would expect that the industry’s implementation track record would have improved significantly.  It hasn’t; or if it has it’s not as obvious as it should be.   A recent study by consulting firm PwC concluded that: “Despite heavy investment in policy administration system modernization projects, less than one-third succeed, half are ‘challenged,’ and one fifth of them fail.” 

PwC defined the folllowing:

  • Succeeded: The project was completed on time, within budget, and met all original benefit requirements.
  • Challenged: The project made it to the deadline, but experienced cost/schedule overruns and was unable to fulfill all the original benefit requirements.
  • Failed: The project was abandoned or cancelled due to project being unable to meet cost, schedule, or customer expectations.

One can take issue with the definitions provided here and there is an argument that  some of the projects that end up in the “challenged” category should be moved to “succeeded,” but there probably are projects in the same category that are closer to “failed.”

The key point is that these types of studies, which despite their intermittent appearance and inconsistencies across publishing entities, reflect broadly similar results which have not changed much over the past 15 years. 

So, the significant improvement in development and delivery on the part of the vendor community has failed to move the needle in terms of overall industry success in core modernization projects.  Why?

How Do You Get to Carnegie Hall?

The single biggest problem faced by a carrier in undertaking a core systems legacy modernization project is the fact that they undertake this kind of complex, enterprise-wide initiative once every 15 to 30 years.   

An old joke comes to mind: “Question:  How do you get to Carnegie Hall?  Answer:  Practice.”  Suddenly, the carrier is supposed to be capable of pulling off a Carnegie Hall performance having spent years playing “Chop Sticks.”  So while the vendors, who practice for Carnegie Hall on a constant basis, are much more capable, their clients by and large are not.  Fifteen years of maintenance, bug fixes, regulatory changes and rate increases does not prepare a carrier for the rigors of core legacy replacement. This fact is reflected in some important ways. 

  • Wrong- headed thinking.  Some carriers still feel that having contracted with a vendor, that vendor will run the project and somehow make the project a success.  Carriers must recognize that the vendor is responsible for only a subset of the project, which does not include such crucial activities as defining requirements, testing and validating the software, planning and executing data conversions, training staff on the new system, planning the rollout of the software, and planning and organizing the overall project, including coordinating with the vendor.  In a recent publication Blueprint for Success: Core System Decisions SMA Partner Karen Furtado states: “An examination of the total effort involved in a core system implementation shows that approximately 30 percent of the time expended involves the actual core system software. The remaining 70 percent of the effort is spent developing requirements, dealing with systems integration, managing the data, and testing and deploying the system.”  This 70 percent is almost exclusively the responsibility of the carrier.
  • Carriers lack expertise. Most insurers lack discipline and the infrastructure necessary to successfully execute a core system project.    Furtado again: “Insurers need to assess their implementation readiness …  A project management discipline is mandatory—one that gives transparency to the project … Experienced project managers …. that have experience with a number of software implementations is critical. Another crucial area …. business analyst resources that have expertise in quality assurance and testing methodologies…”  And of course these key resources are the very people that every project wants, and they are also the people who keep the business operations running.   Many carriers mistake project administrators for project leaders and fail to grasp the important fact that if the project leader does not viscerally understand the goals of the project they may drive it to the wrong destination.  Similarly those key business analyst resources may know the business but they may not know how to develop and execute a formal test plan.
  • Still lacking. Furtado again: “Experienced project managers are key resources. The knowledge of those that have experience with a number of software implementations is critical. Another crucial area for most insurers is the staffing of implementation projects. Key business analyst resources that have expertise in quality assurance and testing methodologies are needed”.  And of course these “key resources” are the very people that every project wants, and they are also the people who keep the business operations running. 
  • Think differently. Carriers need to start to think about these transformational projects in a different way.   The real objective of most core system replacements is to create a new, flexible platform which can support and even facilitate the growth of the carrier for years to come, and yet our usual criteria for success is a list of business function requirements.  Another aspect of this mindset issue came out in our webinar on implementations when a colleague of mine, Ralph Vagnoni, stated that carriers need to realize: “Budgets and timelines are based on estimates and assumptions, not facts.”  The implication being, for example, if the assumptions change so will the timeline and the budget.  Rational as this statement is, it raised eyebrows and voices.  Carriers, it seems, still want these huge undertakings to be defined as delivering a list of identified functions on an unchanging timeline for a fixed budget.  Hardly a recipe for success.  I am not suggesting we throw discipline out the window but even the best-run projects grow and change for good reason and it seems that rigid thinking is sometimes mistaken for disciplined thinking. 

Carriers face real challenges born of the Carnegie Hall principle, in executing core system projects, but the ongoing dismal results of surveys like the PwC report cited above may be simply how we look at and think about these projects.  Partly it seems the way we define these projects makes it impossible for many of them to succeed.