As an SI partner, there can be pressureto agree to fixed-fee contracts; this requires explicit scope. Forthe carrier, there's a fear of a pure Agile time-and-materialsapproach because "whatever" can be equally problematic. (Credit:metamorworks/Shutterstock)

Core system transformation — such as replacing policy, claims orbilling systems — is a bit of a misnomer because teams end upbuilding projects backward and as a result, take too long and costtoo much. Most importantly, insurers lose some of the benefits ofmoving to the new system(s) because the team has spent too muchtime in the past instead of looking toward the future.

Current 'Agile' approach

Core system replacement is often undertaken with a systemsintegration (SI) partner with experience in the selected softwarepackage. As such, there are important commercial constructs. Oneway to structure this is to define the scope of work duringcontract negotiations. The frame of reference is the carrier'sperceptions of need paired with the SI partner's perception abouthow the software meets those needs (or not). Sometimes, the software vendor is part of thediscussion, especially in those cases when they are the SIpartner.

From there, high-level Agile sprint plans are created, whichfill the gap between what the carrier believes they need and whatthe SI partner believes the selected software package can deliver.This process is sometimes referred to as "as-is" comparedto "to-be." Also included in this plan are data migration andintegration plans; these workstreams are critically important, andyou must sequence them correctly, but functional requirements canoften overshadow them.

In the Agile approach, you execute sprints — usually, two tofour weeks in length — that involve "configuration" of the system,unit testing, integration testing (if possible), incremental useracceptance test (UAT) builds and migration work (usually managedsemi-independently from the main development workstreams).Individual sprints are hard to put into the context of theend-to-end (E2E) process. Regardless, the team marches on untilsome endpoint when E2E UAT can begin.

Throughout the sprints, critical change management and DevOpsdeployment work are also taking place. The former to help theorganization prepare for the upcoming change, and the latter toensure a defined, tested and repeatable deployment occurs not onlyat "go live," but also thereafter.

Related: 6 reasons digital transformation is the future ofinsurance

This approach is problematic

There are good reasons why these projects are done this way —primarily because of commercial constructs. As an SI partner, therecan be pressure to agree to fixed-fee contracts; this requiresexplicit scope. For the carrier, there's a fear of a pure Agiletime-and-materials approach because "whatever" can be equallyproblematic. Unfortunately, they tend to meet in the middle andperform the "as-is"/"to-be" gap analysis from which you create arelatively defined scope.

This approach is problematic for four critical reasons:

• The more often the team discusses "as-is," the more entrenchedthey unconsciously become. It causes the carrier to stick to whatthey know and how they've always done things. This bias usuallydoesn't manifest itself until E2E UAT when the team assembles allthe parts and the reality of the new system becomes clear.
• The SI partner should be hired to bring in new perspectives anda natural bias towards the new system, which is often true becausethe "as-is" pulls them towards the past and away from the future.This pull is incredibly subtle, showing up as change controls orsignificant functional requirements that are unintentionally aimedat making the new system behave more like the old one.
• The entire system is virtually unknown until far too late inthe development cycle — E2E UAT. It's one of the reasons why peopleoften refer to the Agile method used in these projects as "AgileWaterfall." By the time the team gets to UAT and discovers all thebig misses, significant pressures — namely time andmoney — are working against them. It's uncommon for teamsto be on track as they get to UAT; this means there's littletolerance for significant changes, and even if there's tolerance,big changes are difficult to incorporate into UAT scripts that havebeen building for months.
• Migration and integration workstreams are heavilydependent on the incremental development of the system. In thecase of migration, initially, the data is not entirely understood;it takes time and effort. In the case of integration, anintegration point implies that whatever part of the process beingfulfilled by the system exists (which may not be the case). It'soften the case that these workstreams are flying blind because theymake large assumptions they have virtually no way of validatinguntil E2E UAT.

Flip the script

The central question currently asked is: What are the gapsbetween your "as-is" and "to-be" systems? This question is almostthe equivalent of the blind leading the blind because the SIpartner doesn't know the "as-is" and the carrier doesn't know the"to-be." What if the central question was: What's broken with thenew system? This question also gives rise to more questions,including: How does the new system work?

To answer this new central question, and todefine "flip the script", start the entire journey withE2E UAT. This approach saves significant time and moneyand lowers risk by putting everyone's focus on what will be (thenew system), bypassing substantial time and energy on what used tobe (the legacy system). One caveat: your line of business mustexist in the vendor's system for this to work — which may be partof your selection criteria — because otherwise, there will benothing "out of the box" to work with.

Agile still matters with this approach. You must placesignificantly more focus on migration and integrations because youhave the time to do so. This work is built incrementally usingAgile, but all the dependent pieces are in place — the true "out ofthe box" system — on day one. There will also most certainly bechanges, but those should be resisted by default versus accepted bydefault. Again, the working assumption is that the new system is"right" — it's up to the team to disprove this hypothesis.Changes are fed into Agile sprints, just as they are during"traditional" UAT — but far sooner.

Related: Planning to switch technology systems? Use thisguide…

Why this works

Starting with the end is superior for many reasons:

• It focuses everyone on the new system; for the carrier, theyare learning it and focus on it instead of what they alreadyhave;
• You spend no time on "as-is" — this is a big-time moneysaver;
• You dramatically reduce the need to configure the system — agreat deal of time and money is spent configuring systems in waysthat only serve to turn the new into the old;
• The SI partner remains focused on the future without beingbrought into the carrier's past; and
• The entire E2E process is considered at the onset, eliminatingthe "flying blind" scenario with incremental builds.

What it takes

Taking this approach is no trivial matter organizationally.Carriers are accustomed to being asked, "What do you want?" versus"What's wrong with this?" It will feel heavy-handed at firstbecause the SI partner is prescribing the approach. Butfundamentally, if there are so many things wrong with the newsystem that you must rebuild it for your needs, why use it? Thelikely truth is that the system you've chosen is a good one, and itis cognitive dissonance that gets in everyone's way.

Support must start from the top. Without that deep support —because there will be many moments when staff want to revert to oldpractices without realizing that it's not even necessary with thenew system — the team will be back to as-is and to-be.

Also, you need an open mindset. There will still be surprises;there will always be "uh oh" moments. They will just come sooner.An open mindset creates an environment of trust where it's okay forthings to go wrong because the team can fix them. It's okay tothink differently because the team supports different — and it'sokay to break all the rules sometimes if that's what the teamneeds.

Related: How insurers are prioritizing digitaltransformation initiatives

Frank Neugebauer ([email protected]) is a partnerat Capco, a global management and technologyconsultancy dedicated to the financial services industry, and ishead of the firm's insurance practice. These opinions are hisown.