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.

However, there are certain standards that are not necessarily required but can be important in surviving.
Posted by: hollywood bistro | November 16, 2011 at 04:45 AM
Yes,There is absolutely no worse trait in a leader than the lack of ability to make a decision.
Posted by: ugg outlet | October 26, 2011 at 02:44 AM
Thanks you. Very good post.Unless they can offer a really compelling reason for users to come back, it will be the next Bebo, MySpace
Posted by: cheap uggs on sale | September 29, 2011 at 08:51 PM
it really looks comfortable and beautiful and gorgeous.
Posted by: UGG Roslynn | September 26, 2011 at 07:32 PM
These kind of post are always inspiring and I prefer to read quality content so I happy to find many good point here in the post
Posted by: UGG Classic Short | September 26, 2011 at 02:42 AM
Your post is an excellent example,I keep on reading this attractive blog.
Posted by: raiders Jerseys | September 25, 2011 at 06:39 PM
Thanks for your share,thanks a lot.Good luck!
Posted by: Cheap UGGs Boots | September 07, 2011 at 02:32 AM
Nice article,You did a good job .
Posted by: penny auctions | July 25, 2011 at 01:25 AM
I have to say that Im really unimpressed with this. I mean, sure, youve got some very interesting points. But this blog is just really lacking in something. Maybe its content, maybe its just the design. I dont know. But its almost like you wrote this because everybodys doing it. No passion at all.
Posted by: Official NFL Jerseys | July 15, 2011 at 01:23 AM
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”.
Posted by: nfl wholesale | June 30, 2011 at 12:22 AM