Flipping the script on core transformation

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

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

Current 'Agile' approach

Core system replacement is often undertaken with a systems integration (SI) partner with experience in the selected software package. As such, there are important commercial constructs. One way to structure this is to define the scope of work during contract negotiations. The frame of reference is the carrier's perceptions of need paired with the SI partner's perception about how the software meets those needs (or not). Sometimes, the software vendor is part of the discussion, especially in those cases when they are the SI partner.

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

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

Throughout the sprints, critical change management and DevOps deployment work are also taking place. The former to help the organization prepare for the upcoming change, and the latter to ensure a defined, tested and repeatable deployment occurs not only at "go live," but also thereafter.

This approach is problematic

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

This approach is problematic for four critical reasons:

The more often the team discusses "as-is," the more entrenched they unconsciously become. It causes the carrier to stick to what they know and how they've always done things. This bias usually doesn't manifest itself until E2E UAT when the team assembles all the parts and the reality of the new system becomes clear.
The SI partner should be hired to bring in new perspectives and a natural bias towards the new system, which is often true because the "as-is" pulls them towards the past and away from the future. This pull is incredibly subtle, showing up as change controls or significant functional requirements that are unintentionally aimed at making the new system behave more like the old one.
The entire system is virtually unknown until far too late in the development cycle — E2E UAT. It's one of the reasons why people often refer to the Agile method used in these projects as "Agile Waterfall." By the time the team gets to UAT and discovers all the big misses, significant pressures — namely time and money — are working against them. It's uncommon for teams to be on track as they get to UAT; this means there's little tolerance for significant changes, and even if there's tolerance, big changes are difficult to incorporate into UAT scripts that have been building for months.
Migration and integration workstreams are heavily dependent on the incremental development of the system. In the case of migration, initially, the data is not entirely understood; it takes time and effort. In the case of integration, an integration point implies that whatever part of the process being fulfilled by the system exists (which may not be the case). It's often the case that these workstreams are flying blind because they make large assumptions they have virtually no way of validating until E2E UAT.

Flip the script

The central question currently asked is: What are the gaps between your "as-is" and "to-be" systems? This question is almost the equivalent of the blind leading the blind because the SI partner 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 the new system? This question also gives rise to more questions, including: How does the new system work?

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

Agile still matters with this approach. You must place significantly more focus on migration and integrations because you have the time to do so. This work is built incrementally using Agile, but all the dependent pieces are in place — the true "out of the box" system — on day one. There will also most certainly be changes, but those should be resisted by default versus accepted by default. 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.

Why this works

Starting with the end is superior for many reasons:

It focuses everyone on the new system; for the carrier, they are learning it and focus on it instead of what they already have;
You spend no time on "as-is" — this is a big-time money saver;
You dramatically reduce the need to configure the system — a great deal of time and money is spent configuring systems in ways that only serve to turn the new into the old;
The SI partner remains focused on the future without being brought into the carrier's past; and
The entire E2E process is considered at the onset, eliminating the "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 first because the SI partner is prescribing the approach. But fundamentally, if there are so many things wrong with the new system that you must rebuild it for your needs, why use it? The likely truth is that the system you've chosen is a good one, and it is 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 old practices without realizing that it's not even necessary with the new 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 for things to go wrong because the team can fix them. It's okay to think differently because the team supports different — and it's okay to break all the rules sometimes if that's what the team needs.

Frank Neugebauer ([email protected]) is a partner at Capco, a global management and technology consultancy dedicated to the financial services industry, and is head of the firm's insurance practice. These opinions are his own.

Want to continue reading?
Become a Free PropertyCasualty360 Digital Reader

Your access to unlimited PropertyCasualty360 content isn’t changing.
Once you are an ALM digital member, you’ll receive:

Breaking insurance news and analysis, on-site and via our newsletters and custom alerts
Weekly Insurance Speak podcast featuring exclusive interviews with industry leaders
Educational webcasts, white papers, and ebooks from industry thought leaders
Critical converage of the employee benefits and financial advisory markets on our other ALM sites, BenefitsPRO and ThinkAdvisor