If I had a buck for every time I've had this conversation I could take my wife to Starbucks and really splurge. I meet with the executive of a prospective client to discuss their soon-to-start legacy replacement project and we talk all around the main issues—resources, split of work between vendor and in-house staff, possible use of third party help, how to measure business outcomes, how not to saddle the project with so many other “related” initiatives that it will be in danger of sinking from its own weight.

Finally a “C” level somebody asks, “So, how long will this take?” Silence descends like a guillotine. The room becomes still. “C” levels and minions alike gaze at me like I'm a laboratory specimen. But this is why I am here. This is my job. In journalism they call it “speaking truth to power.” In my line of work it's called “getting real.”

Because inevitably the questioner already has an answer, and it is either something they arbitrarily invented, heard and took out of context, made up consciously in order to “focus the team on success,” or more venally fits with their bonus objectives. Regardless of its genesis, the answer which this “C” leveler already “knows” bears little if any relation to reality.

This is where I launch into my time worn “unencumbered by information about your particular project as I am, let me tell you what I think” speech. The gist of which is (for a policy or suite implementation) nine months to a year to go live with initial line(s) and state(s); depending on complexity another year for other lines and states; and a year for conversion. A total of three years (give or take).

Of course the time worn speech seldom gets completed because it's not what the “C” level wants to hear. He (women are usually much more rational) wants confirmation not reality. The interruption usually follows one of two or three well-worn paths, which include “The vendor told me nine months”; less relevantly, “It only took Amazon six months to change their website”; or completely irrelevantly, “We already told the board it will take a year.”

My reactions in turn are (at least as they play out in my internal dialogue): “The vendor told you how long it will take to get initially live, not get done”; “What does that have to do with anything?” and; “Really, based on what, and why would you box yourself in like that in the first place?”

Many executives are shocked at the length of time it takes to replace core systems. Few people outside the IT department have any realistic idea of the scope, complexity, and intense effort involved in such an undertaking. My reaction is to be shocked that they are shocked. After all core system legacy replacement involves picking apart and replacing irrational, badly-written systems that have grown like an untended garden for 20-plus years; integrating new and hopefully superior components into the overall “eco-system”; defining thousands of business rules and inventing new ways of doing business; all while keeping the business running with minimal impact. One of my favorite analogies is changing the engines on an airplane whilst it is still in flight.

And yet, unencumbered by information as they are, some carrier executives sit, like King Canute before the ocean, and command that something that is not possible, be done. But like the ocean tides, replacement projects run on their own internal clock, driven by forces which can be understood, harnessed, and somewhat affected, but not dictated to.

This reality leaves IT types in the unenviable position of trying to explain, educate and influence in the direction of what we are pretty sure is going to happen regardless of how convenient or otherwise the outcome may be. One of the oldest truths in project management is that success relies heavily on expectation management.

Tell management that a project will take 15 months and complete it in one year and you are a hero; tell them the same project will take nine months and complete it in one year and you are a goat. The only difference is the expectations that we set (or worse, allowed to form).

So, now that I got that off my chest what are reasonable expectations as to what will happen when, during a core legacy replacement (PAS or suite)? They are as stated above, but let's review them in some detail. All projects get done in phases.

The first phase of a PAS replacement usually entails the configuration of the new system to accurately rate, issue, maintain and report on new policies for one (or a small number of) line(s) of business in one (or a small number of)state(s). Phase one delivers the majority of all the technical aspects of the project—installation, integration, project infrastructure such as test harnesses, environments, and code libraries.

Most of the interfaces are common across all lines of business, so implementing a smaller business footprint requires a significantly larger technical footprint. As a general rule of thumb this phase will take nine months to one year to complete. The business value at this point will vary depending on such variables as the extent to which the carrier writes stand-alone policies for the line of business.

The second phase adds little by way of technical capabilities but adds most of the remaining lines of business and state combinations which fill out the carrier's portfolio. If the carrier chooses this as the second phase then we are still only capable of adding new business policies to the new system while all in-force policies (bills and claims) are handled by the legacy system. For most carriers this will take about a year, but can take longer for companies with complex and varied books of business written across many states.

The third phase, which usually overlaps the second phase, is focused on moving the in-force book of business from the legacy environment to the new environment. This is the point at which “legacy replacement” actually begins; to this point all that has happened is that we have added an additional set of systems to the application architecture.

This phase requires two new capabilities to become functional: the renewal logic in the new system and an extract, transform, and load (ETL) function, which may be achieved by program code, manual effort or a combination of the two. The details of how the ETL is done will depend on the approach (in-force or at renewal), the complexity of the transformation and the volume of policies involved.

We have discussed the ins and outs of in-force versus renewal conversions in prior articles. The complexity issues vary greatly from project to project; with some the mapping is relatively straight forward, with others (e.g. where a product change is foolishly added to the project scope) it is too complex to code or requires new choices to be made by either the underwriter, agent or insured.

Policy population is an unavoidable fact. Thousands, even tens of thousands of policies can be manually converted; hundreds of thousands cannot. If a carrier chooses to convert at renewal it will take a minimum of one year to run all the policies off the old system on to the new one (assuming the carrier writes 12-month policies). Should the carrier choose to undertake an in-force conversion, which is a higher stakes risk/reward proposition, it will still take at least six months to code and test the ETL software, which in theory will run once in production over a weekend, but in reality will probably run two or three time over a month or two before completion.

So, having read what I just wrote, the “C” level would pounce on the unstated fact that if we overlap phase two with phase three by six months my initial three-year timeline becomes two! Arithmetically correct as he may be, it doesn't usually work out that way. Suffice it to say most PAS/suite replacements will take three years. Trust me, I have seen this movie many times and King Canute always gets wet.

(Footnote: The legend of King Canute (Cnut the Great) a 10^th century Norseman, is that he had his throne placed on the shoreline and commanded the incoming tide to stop. The story is popularly misinterpreted (as it is here) to imply that this was done in an act of ill-fated hubris and that the king indeed believed he could turn back the tide. In fairness to the long dead monarch it should be pointed out that his actual intent was to demonstrate the insignificance and impotence of man when faced with the overwhelming power of nature and God's will. So much for historical accuracy.)

Special Reports /

ShopTalk: Three Cheers for King Canute!

Related Stories

Recommended For You