o Acquiring appropriate software from a suitable business partner.

o Managing risk when negotiating terms for software and services.

o Managing risk in the acquisition and implementation process.

o Structuring a successful implementation project.

This month's column provides a general overview of a suitable software-acquisition process with the objective of staking out some of the domain we will consider in subsequent, more in-depth articles.

With your indulgence–and with advance apologies for any minor political incorrectness and perhaps taking the scenic route to making a point–I'd like to start our series with a cautionary and illustrative tale: “The Death of a Software Salesman.”

A software salesman, let's call him Larry, dies and (miraculously, you may think) ascends to the gates of Heaven where he meets St. Peter. As St. Peter processes his new arrival, Larry peeks around and checks things out. He sees angels gliding on the soft breeze and cherubs sitting by babbling brooks strumming lyres. “Not exactly Vegas,” muses Larry. His thoughts are interrupted by St. Peter, who demands in suitably official tones, “Do you wish to enter the Kingdom of Heaven?” Always looking for an option, Larry inquires whether he has any alternatives. St. Peter replies yes, indeed, there is one choice, nodding his head vigorously downward. “Do you mean where I think you mean?” asks Larry, gesturing with a down-turned thumb. St. Peter winces in the affirmative. “Well, it's got to be less boring than this place,” thinks Larry, and employing his professional skills, he negotiates a brief visit to check the place out before making a final decision.

In a flash, Larry is in Hell. Hell is a night club: Strobe lights. Rock music. Long, cold drinks. Larry orders a beer, hops up on a bar stool next to a beautiful blonde, and . . . suddenly he is back before St. Peter, who again intones, “Do you wish to enter the Kingdom of Heaven?” Without hesitation Larry replies, “No, send me to Hell.”

Instantly, Larry finds himself chin deep in a pit of boiling oil, wrists manacled to a wall. He cries out in agony, “What happened to the night club . . . the music . . . the long, cold drinks?” A familiar figure, striding by complete with horns, red cape, and cloven hoof, turns and, in a deeply sinister voice, says, “Welcome. I'm so glad you enjoyed the demo.”

Here are some of the big lessons I have learned over the past 25 years concerning software evaluation and selection: First, many carriers have experienced at least one major failure in acquiring and implementing core insurance processing software. These failures cost millions of dollars, may negatively impact the company's ability to perform basic business operations, and can ruin careers. Despite these failures, some carriers don't seem much wiser the second or even the third time around.

Next, the acquisition process is systematically skewed in favor of the vendors, if for no other reasons than these:

o Given most core legacy systems are 20 to 30 years old, the carrier staff members participate in major acquisition projects only once or possibly twice in their career as opposed to vendor personnel who do this every day for a living. Considering this simple fact, which side do you think will be more effective at leading and supporting its respective interest in the software acquisition process?

o Vendors know intimately well what their software does and doesn't do, while the carrier staff has to find out for itself or trust a “partner” who may have an incentive to at least shade the truth upon occasion.

o It is difficult for carriers to distinguish between objective vendor research and marketing infomercials.

The process of acquiring a core insurance system, such as a claims management, policy administration, or billing system, should follow a proven methodology that stresses consistency, open communications, and vendor performance. One such methodology that has proven successful consists of the following steps:

1. Define your evaluation criteria. Any software selection project should start with the definition and agreement of a scoring matrix, a set of selection criteria, and associated metrics that state what features of a vendor's software and services are of interest to the carrier and how those features will be measured relative to each other.

2. Select target vendors. Using the agreed selection criteria as a guideline, choose a small number of target vendors, given there are only a limited number of viable solutions for a specific carrier profile. Many vendors are stronger in commercial than personal lines; some target smaller or larger carriers; and some have functionally rich legacy software, while others have more technically current “rules and tools.” You can verify the initial target vendor group by requesting the response to a brief, high-level request for information that contains any agreed “knock-out” criteria.

3. Execute a request for proposal (RFP). Prepare, issue, and evaluate responses to an RFP. The RFP is the fleshing out of the criteria summarized in the scoring matrix. The key objectives of the RFP are to state the carrier's functional, technical, and contractual requirements and to solicit the vendor's standard terms and conditions. One word of caution: If you ask vague, general questions, you will get vague, general answers. Where possible, avoid “Can you” or “Does your system” type questions; the answers almost always will be yes. Try questions that start with, “In what states is your system in production?”

4. Execute a scripted demo. Prepare, issue, and evaluate vendors' performance on a scripted demonstration. A scripted demo essentially is a very small proof of concept (POC). It should represent a real (but probably simplified) carrier business problem, using real carrier data, providing vendors the opportunity to demonstrate the capabilities of their software within a strictly defined context and time frame. The scripted demonstration also allows the carrier to evaluate the performance of vendor systems on a familiar problem set, using familiar data.

5. Visit the vendor. A successful vendor visit includes demonstration and exercise of the scripted demo; in-depth discussion of functional issues based on RFP responses; and review of the vendor's technical, development, implementation project, and production support capabilities. If time and resources allow, this also is an appropriate point to engage in the due diligence process–reviewing the legal, financial, and general corporate well-being of the vendor.

6. Visit client references. The key objective in visiting a client reference is to talk directly and freely with another carrier about its experience implementing the vendor's software. There are two important issues you should insist on:

o Don't leave the selection of the reference client up to the vendor. Ask for a complete client list, and decide which one you would like to visit.

o Insist on meeting the client team without the vendor being present. Once you are on site, the major questions should include: Does the software work substantially as advertised? What did the vendor's staff members do, and how did they perform during the implementation? Is the vendor a good and trusted partner?

A final recommendation for the client visit is to assess the extent to which the client's experience with the vendor is a good predictor of what might be in store for you. If the client's business model is substantially different than yours, make sure you take that into account. Just because the vendor has solved the client's business problem, it doesn't mean the vendor knows how to solve yours.

7. Execute a proof of concept. Even having diligently executed the prior steps, it is not yet time to commit completely to the “chosen” vendor. Several issues still need to be addressed, including: Will the vendor software load and run well in your environment? How will it be to work alongside the vendor's staff? Will the vendor's software scale appropriately and perform adequately in your environment?

The only way to answer these questions is to execute a proof of concept. The POC requires the vendor install its software at your site and complete the build of an agreed functionality “slice” in an agreed time frame. This step requires the vendor to install successfully and certify its software in your environment; configure and deploy its software to solve the agreed business problem under close scrutiny; and meet any reasonable performance test using realistic transactions.

Prior to the start of the POC, software installation requires some form of temporary contract to protect the vendor's software rights. This requires that you focus on and begin negotiation of terms and conditions with the vendor, giving you a good sense of what the vendor is like to do business with. If the POC, the scalability tests, and the negotiations end satisfactorily, you are in the position to complete negotiations and begin the “real” project with your new business partner.

Insurance Systems Heaven is now “only” an implementation project away. But that is a conversation for another time.