How often have you heard the phrase legacy replacement project or claims system implementation project? Fairly regularly, I suspect, given the current high level of software acquisition and implementation activity. The problem is these phrases are both incorrect and misleading. First, from the purist project management perspective, a legacy replacement effort is not a single project but rather a group of related projects that should be more accurately referred to as a "program." Second, and more important, the use of the term project understates the complexity, risk, and cost of replacing or implementing a core processing system.

In the real world, replacing a core insurance processing system includes (but is not limited to): installing and certifying the new system; configuring the new system to business requirements; integrating the new system into the legacy environment; testing the system; deploying the system; converting the open claims or in-force policies; retiring the replaced legacy asset.

For those who might think these are mere phases of a single project, consider the following points:

These program projects are not sequential and usually overlap or are executed simultaneously–certainly this is true of configuration, integration, and various testing phases. Often, these projects will constitute a major program phase, say, a multistate implementation, which is followed by another major phase (group of states), creating another sequential cascade of overlapping projects.

A project team usually consists of five to 20 resources, while a core system implementation or replacement program may have anywhere from five to 10 teams, each ranging in size from five to 15 resources.

A core system replacement initiative is a multiyear effort. A claims or billing system replacement reasonably can take from one to three years, depending on the size and complexity of the carrier's business operations. A policy administration system replacement probably will require at least two years to complete and may take upward of five in the largest carrier environments. What can possibly take this long? Well, if the carrier writes many different lines of business in 50 states, the configuration, testing, and rollout effort is massive. Also, some large carriers have more than 100 integration points that must be programmed and tested.

The insurance IT equivalent of open heart surgery, these programs are completely different animals from the usual "large tactical" projects found in IT maintenance environments. Given the scope, complexity, and risks, these programs need to be handled with far greater rigor. For the small to medium IT department, this often means strengthening the project and program management infrastructure by the:

o Creation of a project management office. Many carriers have no standards for vendor management, change control, time tracking, task plan creation and coordination, and formal budget tracking.

o Adoption of a program methodology that produces a high degree of formality and standardization and supports the creation of both project and program artifacts.

o Development of formal quality assurance standards and possibly the introduction of automated test tools. A core insurance application cannot be implemented successfully without extensive, formal testing. Carriers often believe the vendor will provide a configured, tested system that can be installed in production. That illusion typically is short-lived. As the client, the carrier is responsible for ensuring the vendor configured the system to the carrier's requirements and did so without error.

o Creation of change management and process redesign capabilities. New systems create new workflows. Users not only must be trained to use the new system but also need to be comfortable with the new workflows and processes. A stark example is the claims environment that goes paperless. I know of carriers that finally had to lock up the claim files to wean adjusters off paper and onto electronic images. For more senior claims professionals, this was a stressful, if not traumatic, experience. The paper claim file was a "security blanket" without which they felt exposed. In fact, a "file back" exercise showed dozens of files had gone missing, most of which ultimately turned up in desk drawers and briefcases.

Many initiatives of this magnitude fail. There are no readily available hard numbers, but I have heard industry sources suggest more than 50 percent of these efforts either fail completely or end up as partial implementations. The major causes of failure, in no meaningful order, are:

o Lack of support or change of senior management. These projects take years, cost millions, and drain energy and resources from both the business and IT. They cannot succeed without a long-term commitment from the folks at the top.

o Choosing an inappropriate vendor can be fatal. Here is the most basic rule of thumb: If the vendor hasn't done "it" successfully before, the vendor may do "it" successfully for you but probably not within the estimated time and cost estimates. There is a significant difference between "can do" and "has done." A vendor whose system "supports" a line of business in a given state is a much riskier proposition than a vendor whose software supports production activity in the same state. The relationship between track record and risk profile is directly and inversely proportional.

o Scope creep creates bloated, impractical projects and programs that never get finished. As the old saying goes: "The road to Hell is paved with good intentions." Major systems programs are like congressional appropriations–everyone sees the opportunity to get a pet project done under the broad umbrella of the strategic program. For example, a rationale such as "there is no point implementing a new policy system without updating all the ISO products" sounds sensible, but it can kill the program. Another popular program killer that may sound familiar: "Let's use this opportunity to create a proper client view and cleanse all our customer data." It's not that these are inappropriate undertakings; it's just that they are major, separate initiatives and must be treated as such.

o Poor or inadequate requirements gathering. The discovery and addressing of missed requirements cost disproportionately more the longer they remain undiscovered. Some business requirements are more concrete than others. For example, gathering the rates, rules, and forms for a given insurance product in a given state may be no more difficult than reading a product filing or even some state regulations. But asking business people to define the details of a new straight-through process may be significantly harder. Why? The former is already defined, while the latter is not.

More carriers are purchasing and implementing core insurance processing systems than ever before, and in general, these projects are meeting some significant success criteria. The key success factors driving this trend certainly include:

o A new generation of vendors in the core systems market that are more capable than the "legacy" vendors in both the quality of the software and implementation capabilities. In response to this new breed of vendor, the legacy vendors are taking notice and raising their game, making for more and better choices for carriers.

o Many carriers are "once bitten, twice shy" and now approach major software acquisitions more carefully and methodically, leading to greater due diligence and better-informed vendor choices.

o Carrier business teams now are more actively involved in sharing responsibility for vendor decisions and for software implementations, resulting in both qualitative and political advantages.

o More business and IT executives joining the P&C ranks are being sourced from outside the industry, bringing fresh perspective, more collaborative approaches, and higher expectations from core implementations.

Major software implementations and legacy replacement programs are unavoidably messy and easily can go from difficult to impossible. Keeping them under control requires constant attention, management rigor, and gut-level commitment. Starting off with the greater realization of the scope, complexity, and risks of such an undertaking significantly will increase the likelihood of success.