When it comes to legacy systems replacement the definition of success varies from company to company. And the criteria for success and how those criteria are measured varies from pretty low to …………………….not very high.
Let’s consider four key criteria that might be appropriate to measure the degree of success of a core legacy system replacement:
· the new system was implemented into production where it meets the functional, technical and quality requirements as defined
· the replaced legacy assets were decommissioned and no longer run
· the project was completed roughly within time and cost parameters
· the estimated business benefits which were used to justify the cost of the project were substantially realized.
Clearly these criteria are cumulative with the first being the most basic measure. Indeed it tends to be this basic measure, and only this basic measure, which most carriers invoke when declaring success, or ……..putting the project on hold. And even by this basic measure it is generally agreed that at least half of all such projects fail, as in they don’t result in an implemented system, or result in only a partially implemented system. This low level of success criteria and its corresponding high level of failure is yet another indication of how hard it is to succeed at transformational change. In fact it is not uncommon for carriers to try two or three or more times to replace a core legacy system before finally succeeding. Consider the following time line which is real but has de-personalised to protect the honest folks who put it together:
· 1998 – Carrier’s “Replacement Project” convenes with its number one recommendation endorsed by CEO – Replace the current Claim System!!
· 1998 – IT commences a huge project to build its own claim system – X is the lead BA; Y is the sole SME
· 1999 – The project fails miserably; the CIO is fired. X and Y get to keep their jobs
· 2000 – After Y2K, an RFP team (led by Y) chooses a Software vendor to replace all systems
· 2001 – The project commences to implement the vendor’s Commercial Lines System
· 2002 – The project commences to build with the vendor a new claim system
· 2003 – Both efforts (led by Y) fail miserably
· 2003 – And yet another RFP commences to find another Claim system (led by X)
· 2004 – The RFP team concludes there’s nothing out there and Carrier should build its own system!!
· 2004 – The project to build a system begins; a screen-scrape of the old system for claims occurs in the meantime
· 2004 – Both projects (led by X) fail miserably
· 2005 – Carrier contracts with a new vendor and begins (in July) the first of three phases to replace the claims system
· 2006 – Phase 1 goes in on schedule
· 2007 – Phase 2 goes in on schedule
· 2008 – Phase 3 goes in on schedule
· 2008 – Ten years after Replacement II, carrier replaces a core operating system!!
The striking thing to me is that this story is not unique, it is common. Many carriers fail multiple times before they succeed at transformational change. The interesting thing in this instance is that having got it right, the carrier got it really right. The phases of the implementation went in on schedule, and by implication pretty much on budget as well. Now the legacy claims system has been “completely replaced”, allowing for legacy retirement. I don’t know the extent to which the stated benefits are being realized in this specific instance but as the song (almost) goes: “three out four ain’t bad”.
So are there any lessons that can be generalized from this particular story? Yes indeed.
They at least include the following:
· most carriers have no rational case for getting involved in trying to build core insurance applications. The apps are too complex and the carrier will almost certainly fail
· if you do not select a vendor partner carefully and thoroughly a “package” implementation is also likely to fail
· if you are involved in a build failure or “package” failure learn from it like the folks in the timeline did
· just because there wasn’t a good third party solution the last time you looked, doesn’t mean there isn’t now
And finally, this is a story with a happy ending. And happy endings are not guaranteed.
As we have said before, transformational change is a risky business.
Recent Comments