Close Inspection

An insurer can follow peer and expert advice to the letter, but there still is no guarantee its next software deal will unfold without pain and suffering. While carriers keep searching for that elusive perfect purchase, software implementation is an imperfect science. "There's always a risk factor in whatever you do," says Piyush Singh, CIO, Great American Insurance.

Companies have learned over the years all parties involved must work together if there is to be any measure of success in a software deal. Vendors are aiming to make money, and carriers are trying to find a system that won't take years to install and set back the IT budget for the rest of the decade.

Insurers have to be aware of today's solution landscape because there is an increased trend toward vendor-provided solutions and components to solve business problems, according to Matt Josefowicz, manager of Celent's insurance group. "Improving the ability to evaluate and select [vendors and products] is an important skill set," he says.

Josefowicz doesn't believe buying software is a riskier proposition today than it was a few years ago, but its consequences are becoming more evident. "Insurers need to realize they really are marrying their vendor and need to look more at the organization than at the RFP [request for proposals] checklist," he says.

Many insurers have a broken process when it comes to evaluating core system vendors, notes Josefowicz. Carriers normally start the process with an exhaustive documentation of their current state and practices and then look for a vendor that will support what they have been doing. "Not only does this prolong the selection process unnecessarily, but it also means insurers are missing the opportunity to use a technology change to refresh their processes and take advantage of new, unimagined capabilities," he observes. "Insurers that have been living with stone-age tools often cannot comprehend the sharpness of iron."

Carriers have serious issues to address, such as: How are we going to use this solution in concert with everything else? "Some vendors want to make a quick sale, talk the talk, and then walk away hoping for a successful product life," says Singh. "The customer would like to ensure the product is going to be utilized effectively in the larger context, is part of the business transformation solution, and has a sustainable future. There can be a happy medium there."

Failure with a project can be humbling but lead to greater success in the future, contends Trae Jones, vice president of Appix Consulting. "Companies start to look at the vendor selection process with a more critical eye [after a failed project]," he says. "They are willing to invest the time and effort to make sure they come up with a stable, experienced vendor with the right functionality at a reasonable price."

Below are 10 tips to help mitigate the risk when buying software. The suggestions offer some insight into one of the most important tasks a CIO undertakes.

An insurer should start by looking thoroughly at its requirements, which can be encapsulated into a formal RFP. Issuing an RFP allows companies to cast a wide net to ensure a number of different vendors are brought into the fold, Jones explains. "You take a high-level look at the vendors, their functionality, pricing, experience, stability, and implementation approach as well as their technical approach," he advises.

Carriers need to define their requirements upfront, Jones suggests, then issue a formal RFP and let the RFP process bring the larger group down to a smaller, more manageable group–vendors that seem to have the right high-level functionality, pricing, implementation approach, experience, and stability.

Insurers should issue a formal demo script for three to five vendors. "Come up with exactly what you want to see from the demo, otherwise vendors will be apt to show you what their system does best and will skip over some other areas where they are weaker," Jones says.

Ernie Pearson, director of systems development for SECURA Insurance Companies, has two simple pieces of advice for shoppers: Don't buy anything based solely on a PowerPoint presentation, and make sure you can see the system in use in a company whose environment is similar to your own. For example, a regional mutual carrier writing multiple lines in multiple states ought to see the product work in that environment. Being shown how the product works for a direct writer or a managing general agent doesn't really indicate anything unless the carrier doing the shopping is a direct writer or an MGA, points out Pearson. "Is there anyone out there who looks like you and is using the system?" he asks. "Do a proof of concept. Make a limited commitment in dollars and time to run the product through its paces to see whether [the vendor] can deliver certain key elements and whether the product works as advertised."

A good rule of thumb is to check the maturation point of the software being considered, recommends George Grieve, CEO of CastleBay Consulting. If the vendor is doing frequent deliveries of code, it probably means the software is not stable or mature. "Any upgrades occurring more frequently than every six months implies [the vendor] is in a significant development cycle," he says. "If [the vendors] are [upgrading] the software any more frequently than that, they are fixing bugs."

Carriers need to make sure vendors have written the software in such a way that taking an upgrade isn't some teeth-grinding experience for the carrier, cautions Grieve. "That's why we have so many legacy environments today that are so difficult to get out of," he says. "You bought a version of a piece of software, you modified it internally, and you never can take another upgrade." Fortunately, most of the newer vendors are doing a significantly better job of isolating base code from client configuration, he adds.

Insurers have to look at their own skill sets, too. "If you are buying a system that's written in Java and using Oracle and you are a SQL server .NET shop, you are going to need to do some training or hiring to get those skill sets in-house," says Pearson.

Buyers must take a cold, hard look at a vendor's financial condition. Jones has seen carriers become enthralled by new technology from an upstart vendor, but going with their emotions can be dangerous, even if the software proves to be a good fit. "I can't understate the importance of looking at the financial stability of vendors," he says. "You can sign software escrow agreements that ensure you will have access to the source code if the vendor goes belly up, but generally speaking, you don't want to have to inherit that source code."

A vendor that is here today and gone tomorrow or gets purchased by a larger vendor presents significant risk for a carrier if the product licensed from the vendor is no longer supported. "Some of the best solutions might be provided by companies without the capital resources or financial backing you'd feel comfortable with," says Pearson. For example, there may be a relatively new company with a leading-edge product but no track record. "You don't really know what's going to happen," he warns.

When it comes to the financials, all carriers can do is try to understand the ownership of the vendor, its financial condition, and its capitalization. If the vendor is precarious from a financial perspective but the product is attractive, Pearson maintains carriers have to do more work to determine how to mitigate that risk. "If [the vendor] folds its tent and vanishes in the middle of the night, what are you going to do?" he asks. "Do you have the source code? Do you have the skill set to pick up where the vendor left off and finish the project? Do you have the documentation and training?"

Checking the financial information of the vendor is an important step, agrees Singh. In the insurance market, many vendors are smaller, privately held companies, so carriers must have confidence the vendor is going to be there for the long haul. "You need to reaffirm that by talking to other companies," he says. "What is [the vendor's] track record prior to you buying something from it? Who are the backers, and what are their business interests?"

Not surprisingly, a vendor that is unprofitable and doesn't have a successful install base is a red flag, Jones explains. "The reason a large install base is important is vendors make a good deal of their money from the recurring revenue stream associated with maintenance contracts," he says. "If a vendor has 50 live installations and is receiving recurring maintenance revenue, that's nice from a financial stability standpoint. Even if that company doesn't sell a single license over the next 18 months, you know it is going to have 50 customers paying maintenance fees."

On the other hand, a vendor with, say, three to five installations in its history and a large employee base should make carriers wonder what will happen to it if it doesn't sell any software for a long period, remarks Jones.

First, carriers must define the functionality they are seeking. Next, the project "is going to be done at a certain cost and within a certain time," Pearson says. "If those are moving targets, it doesn't matter whether the project is a vendor-developed system or an in-house system." The result will be cost overruns and exceeding the budget. To avoid this all-too-common trap, he recommends carriers have a change management process in place–a process by which significant changes are approved before the scope of the project is expanded to include proposed changes.

Carriers need to understand a vendor's capacity to serve its customers, Pearson believes. If a carrier has $100 million in direct written premium (DWP) in personal lines in a single state and the vendor's other customers include national carriers writing $2 billion or more DWP across the country, the smaller carrier should know whether it will get the same level of service as a bigger company.

The situation works both ways. "If you are a big company and most of [a vendor's] clients are small companies, [it] may not have the horsepower to take care of you," notes Pearson.

The most abused word in a vendor sale is partnership, Singh believes. "Every [vendor] says it is going to be your partner, but in reality, I don't think most vendor companies realize what being a partner means," he says. "What vendor is going to tell me it isn't going to be a good partner?" When a vendor promises it will be there to help the carrier succeed, Singh asks the vendor to provide examples of how it has accomplished that task with another company. "Every implementation is going to go through some rough spots, but a true partner is someone who is willing to stay with you through the rough spots," he says.

Most vendors are quick to provide references to potential customers, but Singh warns there are things to listen for when the references seem to be too glowing. He becomes worried, he explains, if none of the references talk about rough edges in the implementation and whether the vendor was there to help work through them. "Those things are important," he says. "That's a true attribute of how good a team is going to be."

Problems also arise if the buyer is unwilling to make the necessary contributions to the project's success, Singh comments. "It has to be a give-and-take relationship as you proceed through the whole process," he says. "We need to be willing to educate. [Vendors] need to be willing to learn and apply, not just listen."

Singh respects vendors that are willing to take the time to learn the carrier's environment so they put their solution in perspective, he says, as opposed to giving a death-by-PowerPoint presentation on how good their product is. Customers want to know how the solution applies to their business, he points out, asking, "How will it work in my environment, and what are the things I need to be aware of?"

Grieve advises carriers to look for mature software. Getting involved in a development project with a vendor "is not for the faint of heart," he says. One reason to stay away is the issue of scale. "If you are a small- to medium-size carrier, you have no business getting involved in that kind of an arrangement," he says. "Bigger companies can do it and know if the project doesn't work out, it doesn't cost them a lot of money."

Singh recommends CIOs talk with their peer network or trusted friends and advisers from within the industry to determine how the vendor's product has performed in the past. He describes some vendors as having a "watertight boundary" around their sales staff, the implementation people, and the support team. "If you buy a solution, you want to make sure [all three groups] are there for you for the long haul, and it's not a situation where someone sells the product and hands things over to another division," he says. "You want a close relationship and a true partnership among the various [vendor] units."

When the field is narrowed to one or two finalists, Jones suggests a carrier visit some of the vendor's clients to see the product in use. "A product demonstration is fine and dandy, but there's no comparison to the benefit you will get from actually seeing the product in use on the client side," he says.

Vendors are going to supply a list of reference checks, but Jones also likes to ask them for an entire list of customers. "As you might imagine, if you ask for references, the ones they are going to give you are some of their happiest customers," he says. "Most vendors will have a couple of customers that aren't happy. You might know someone on that list. Networking sometimes is the best way to look under the covers."

Oftentimes when a company finally makes a decision to purchase a system, there is an urgency to select the provider and implement the product immediately, according to Jones. Carriers ought to resist the temptation to fast track the decision process, he advises, even though there may be pressure to get on with it. "This particular decision arguably is the most important technology decision a carrier will make in years," he says. "If you rush certain pieces of the process, you can cut out valuable steps that certainly could impact the overall decision."

To make sure the vendor delivers the system it has advertised, Pearson believes it is imperative to reference all the documentation the vendor provided throughout the process. "As you go through the process with [the vendor], you are building a set of requirements and expectations around what the system can do and holding the vendor accountable for meeting those functionalities," he says.

In addition, examine a vendor's track record on delivery of products, recommends Grieve. Has the vendor dealt with your volume of business or the same type of business in the jurisdictions in which your company writes business? If it has done those things before, Grieve asserts it is likely the vendor can do it again.

Carriers also should break down projects into smaller deliverables so they cantrack the progress. "If you say to a vendor you are going to pay for delivery, you are giving that vendor an incentive to deliver something to you," Grieve says, but he cautions the insurer is not giving the vendor an incentive to deliver quality. "What you need to do is not only say you will pay for delivery but define what you want delivered," he adds. "You agree to a minimal set of criteria–a piece of code, for instance–and it has to meet those criteria. If it meets the test, the vendor gets paid. If it doesn't pass the test, the vendor has not delivered."

One of the final steps in the selection process, Grieve indicates, involves the vendor demonstrating a significant level of performance. "Before you actually ink the real deal and get yourself deeply locked in, it's an obvious and good risk mitigator," he says. CastleBay tries to set up the proof of concept in such a way the vendor has to perform in the customer's environment working with the customer so there is nothing hidden. "You get to see whether the software does the things [the provider] says it can do and whether [the company] can deliver the things it says it can deliver," he notes.

Grieve tells a story about a vendor that had written policy administration software for one customer, and the vendor thought the system would work for any size carrier. The initial customer had a particular shape and size, though, and the software was written to fit that particular customer. It turned out the product had shortcomings for other customers.

The first customer, acting as a reference, told everyone the solution worked, and other customers agreed to buy the product, continues Grieve. "The vendor sold about five or six of these systems in about a year, even though it never had done multiple projects at the same time," he says. "This wasn't the case of a vendor misleading the customers. It just didn't know." Grieve proposed to his client it do a proof of concept, but the advice was rejected. "Two years and millions of dollars later, [the carrier] staggered out of the wreckage."

Grieve's advice? "Get to know the vendor, what it has, and how it works on an interim basis before you commit to some major project or major purchase," he says.

Given the level of recent merger and acquisition activity occurring in the insurance software space, insurers should be sure they understand the "change of control" provisions in any vendor contract, according to Josefowicz. "Insurers should expect any vendor they deal with that has less than $50 million in revenue is more likely than not to be acquired," he says. "The good news, though, is these acquisitions generally are made in order for the buyer to benefit from the target company's intellectual property rather than just to buy a customer group and migrate it to the buyer's own platform."

The contractual arrangements should be based on pay for performance, according to Grieve. Traditionally, vendors want the price of the software upfront, which he believes stacks the deck for the vendor because the carrier already is in for millions of dollars before it really sees whether the vendor can deliver anything. If the project goes in the wrong direction, the first reaction of the customer often is to keep going because of the money it already has spent. "In other words, I've thrown $5 million down a rat hole, so now I have to throw some more millions down there on the off chance these [vendors] are not really what they look like–which is the wrong choice," says Grieve.

These are difficult decisions for any carrier. "People's careers get damaged by these things," observes Grieve. "They lose sleep; they get stressed. If you never commit the $5 million in the first place, you are more capable of seeing reality as it enfolds in front of you. If these guys look like the wrong choice, you can get out."

Grieve claims he always advises customers to write a contract where they have a way out and always write contracts to pay for delivery. "If the vendor doesn't deliver, you don't pay," he says. "You still are stuck with a vendor that hasn't delivered, but you have mitigated the financial impact of that result."

Once a carrier has determined the finalists, it can engage in some final pricing and contractual language negotiations, instructs Jones. "You've got to write a tight contract," he says. The biggest risk a carrier takes is the actual implementation of the solution, he warns, so to be sure to include the specific requirements that are important to the carrier and work the requirements document into the contract as an appendix. "It will help to ensure you come out of the process with a product you are happy with," he says.

Although selecting the right vendor is obviously critical, Pearson says he has seen it done poorly as often as he has seen it done well. "We think we're pretty smart here at SECURA, but even in our current project, we are finding there probably are a few more questions we could have asked," he concludes. "I don't know whether you ever can ask them all, but you certainly can't ask too many questions."