The "Shop Talk" column is concerned with all thingstechnology-vendor related: how to organize and execute a vendorsearch, how to negotiate a good deal, and how to implementthird-party software. In the first few articles of this series, wehave looked at some aspects of the search phase. In this issue, I'dlike to leap forward in time to the point where we need to organizethe implementation–where the search "rubber" meets the deliverables"road."

Previous columns have emphasized the need for a searchmethodology. But what about an implementation methodology? First,let's clear one major stumbling block out of the way. Implementingthird-party software is not the same as building software. So,development methodologies, those commercially availablemethodologies that work well for building, are not generally wellsuited to organizing the implementation of third-party software.Then where do we look to find a viable framework to help organizethe effort? The software vendor usually has an implementationmethodology. But let the buyer beware, as vendor methodologiesoften are little more than window dressing; may not be available toclients; and almost certainly are restricted to the vendor side ofthe implementation, ignoring much of the integration, qualityassurance, and testing, and leaving these critical implementationissues to the carrier.

Aside from the vendor's implementation methodology, anotheroption is to reuse parts of the time-tested, in-house, genericproject methodology for individual parts of the overallimplementation. However, with this alternate approach, it iscritical to understand such an undertaking is not a "project" but aseries of interrelated projects more appropriately thought of as a"program."

Oftentimes, the carrier's methodology needs to be extended totake into account the multiple interrelated projects that must beplanned and executed. Adding to the already formidable challenge,the more comprehensive and rigid the methodology, the moredifficult it is to apply the methodology successfully to thecomplexity of a program. I personally have experienced a majorprogram that took unnecessarily long to launch because it did notfit within the strictures of the methodology. Unfortunately, themethodology included the triggers for funding and resourceapproval.

How often have you heard the phrase legacy replacement projector claims system implementation project? Fairly regularly, Isuspect, given the current high level of software acquisition andimplementation activity. The problem is these phrases are bothincorrect and misleading. First, from the purist project managementperspective, a legacy replacement effort is not a single projectbut rather a group of related projects that should be moreaccurately referred to as a "program." Second, and more important,the use of the term project understates the complexity, risk, andcost of replacing or implementing a core processing system.

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

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

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

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

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

The insurance IT equivalent of open heart surgery, theseprograms are completely different animals from the usual "largetactical" projects found in IT maintenance environments. Given thescope, complexity, and risks, these programs need to be handledwith far greater rigor. For the small to medium IT department, thisoften means strengthening the project and program managementinfrastructure by the:

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

o Adoption of a program methodology that produces a high degreeof formality and standardization and supports the creation of bothproject and program artifacts.

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

o Creation of change management and process redesigncapabilities. New systems create new workflows. Users not only mustbe trained to use the new system but also need to be comfortablewith the new workflows and processes. A stark example is the claimsenvironment that goes paperless. I know of carriers that finallyhad to lock up the claim files to wean adjusters off paper and ontoelectronic images. For more senior claims professionals, this was astressful, 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, mostof which ultimately turned up in desk drawers and briefcases.

Many initiatives of this magnitude fail. There are no readilyavailable hard numbers, but I have heard industry sources suggestmore than 50 percent of these efforts either fail completely or endup as partial implementations. The major causes of failure, in nomeaningful order, are:

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

o Choosing an inappropriate vendor can be fatal. Here is themost basic rule of thumb: If the vendor hasn't done "it"successfully before, the vendor may do "it" successfully for youbut 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 givenstate is a much riskier proposition than a vendor whose softwaresupports production activity in the same state. The relationshipbetween track record and risk profile is directly and inverselyproportional.

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

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

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

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

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

o Carrier business teams now are more actively involved insharing responsibility for vendor decisions and for softwareimplementations, resulting in both qualitative and politicaladvantages.

o More business and IT executives joining the P&C ranks arebeing sourced from outside the industry, bringing freshperspective, more collaborative approaches, and higher expectationsfrom core implementations.

Major software implementations and legacy replacement programsare unavoidably messy and easily can go from difficult toimpossible. Keeping them under control requires constant attention,management rigor, and gut-level commitment. Starting off with thegreater realization of the scope, complexity, and risks of such anundertaking significantly will increase the likelihood ofsuccess.