Some IT leaders believe purchasing vendor solutions is the mostimportant and exciting aspect of their jobs. Making the rightdecisions involves planning and preparation. Here are some tips onhow best to spend those dollars.

Robert Regis Hyle

Selecting the right technology vendor is one of the mostimportant activities for any insurance carrier, affirms BillGarvey, IT director for Main Street America Group. "Using the rightvendors is critical because they will build applications for us andwe have to rely on them for running the operation of our business,"he says. Vendor selection is not an issue that sits on an ITdirector's table every week or even every month, but when it doesland there, nothing else takes priority. "Everything else takes abackseat," says Ernie Pearson, IT director, applicationsdevelopment, SECURA Insurance Companies. "Trying to get [productselection] right is very difficult and requires the focus of asignificant team of people who bring both a technical perspectiveas well as a business perspective to the table."

STATE OF THE MARKET

One area of concern for insurance carriers is the state of theinsurance software market. There have been numerous vendors mergingin recent years–almost too many for carriers to keep up with–andthere have been a lot of new products introduced.

Kimberly Harris-Ferrante, research vice president for Gartner,asserts it is becoming difficult for a CIO to keep track of themarket because of all the movement. "The good news is the vendormarket is maturing," she says. "The older vendors have modernizedtheir solutions, and new vendors have proven their ability tosupport the functions an insurance company would require. The badnews is there are more viable options out there, so the ability toevaluate the vendors is trickier than it was two years ago."

Bob Ingram came to his position as CIO for Argonaut Group from abackground in which almost all core applications were customdeveloped. When he joined Argonaut, he realized even though heconsiders himself a developer at heart, he had to initiate astrategy to integrate commercial applications. "We just selected apolicy admin vendor, and we're currently in pilot mode," he says."When I got here, I confirmed a decision that was in process on adocument management vendor. I'm also looking at claims vendors andforms management."

Ingram chose to look around for help in making those decisions."I'm using external data sources," he says. "I have a lot ofconfidence in what Celent does. We've also checked with Gartner andForrester, and I believe they have good sources. There is a lot ofanalytics about what's going on in the marketplace."

To prepare for the policy administration system, Ingram turnedto CastleBay Consulting for assistance. "I'm reaching out to peoplewho have done analysis," he says. "There is a rich set of availableinformation. As my career has progressed, [the analysis] has becomemore sophisticated. We're still going through the processes, butthey've been greatly accelerated by the information that'savailable."

MANAGING RISK

Carriers don't want to be left in the technology dust, but theycan't always afford to be on the leading edge. "You balance it outby having good risk mitigation practices," says Harris-Ferrante.One such practice is to have vendors put the source code in escrowin case something happens to the vendor. Carriers also have toworry about IT skill sets to maintain and update the system. "Arethere third-party professional services teams that are trained andknowledgeable on these vendor solutions?" she asks. The RFPs thatGartner helps its clients with look beyond functionality andtechnology to areas such as training of employees, knowledgetransfer, third-party providers, and ecosystem partners of thatvendor, according to Harris-Ferrante. "With mergers andacquisitions you could be left with a system that is not going tobe maintained," she says. "You sometimes have to look beyond thesoftware aspects to outsourcing or go to a more hosted environmentwith Software as a Service (SaaS)."

Another area that has changed in recent years is the trend awayfrom core systems that did everything to components. "You aremoving into more modular chunks of technology, which means part ofthe evaluation criteria has to be interoperability, open standards,and the ability to integrate data with all the other systems," saysHarris-Ferrante. "The new twist is not just buying an isolatedsystem; you have to understand how it works with everythingelse."

PAST PERFORMANCE REVIEW

Early in the process, Main Street America studies how similarprojects have been handled previously. The carrier keeps a libraryof lessons learned that is used in initiating the RFP process.Integration is one lesson the carrier has learned from conductingdue diligence. "I can contact all the insurance companies a vendorgives me, and they will tell me all the wonderful things about theproduct, but there's nothing like seeing it work firsthand," saysGarvey. "We've been told a product does integrate and then we'd get[the product], and for some reason, it doesn't work in ourenvironment. That lesson learned is to make sure it works in ourenvironment before we sign a license."

Pearson believes strongly in reference checks but points outthey don't always provide the answers a carrier is searching for."Talking to other people and trying to get actual experiences canbe difficult," he says. Looking at his own experience searching fora policy administration system, Pearson recalls there were not alot of good references for the current version of some of theproducts. "There were more companies that were in implementationthan could say they have worked through the implementation and itwas a good experience or a bad experience," he says.

Pearson discovered the maturity of the products was such thatthere were not a lot of experienced users. Some of the referencescould talk about their experience with an earlier version of aproduct. Pearson felt that was helpful because it spoke to theworking relationship between the carrier and the vendor, but itdidn't necessarily provide enough useful information about theimplementation of the most current version. "To some extent, theinformation you may be getting from references may be more areflection on the vendor than the particular version of the systemyou are looking to license," he says.

To make sure the proposed product will work with its existingsystems, Main Street America often requires a mini-pilot projectthat entails integrating the new product so the IT staff can gain acomfort level with the product and ensure it interfaces well withthe other systems. "If that litmus test isn't met, we're feelingkind of queasy [about the product] at that point," says Garvey.

Another simple test performed by Main Street America might seemunnecessary to some, according to Garvey, but has proven its value."We demand a vendor boot up its application in our environment," hesays. The carrier is not looking at integration or configurationissues in such a test. "I just want them to bring their CDs to ourshop, and I want to see it booted up," says Garvey. "I get allkinds of weird looks from vendors, but I've been down this road toomany times, and the first thing that goes wrong [with a newproduct] is the software doesn't work. It's just one easy step thatgives us a comfort level we're buying a good product."

THE RFP REQUIREMENT

In determining the initial direction of vendor selection, Garveypoints out everything starts with the business need. IT has tounderstand the business problem and what the business hopes toaccomplish. Only then can the carrier put together a request forproposal (RFP). Garvey indicates the RFP process involves theimpacted business unit as well as IT and sometimes requiresbringing in outside help.

When a carrier asks the consultants at Appix to evaluatevendors, vice president Trae Jones finds a structured process hashelped ensure the optimal solution ultimately gets selected."There's no Holy Grail out there to vendor selection, but thebottom line is following a structured approach is going to enablethe carrier to come out ahead of the game," he says.

Jones believes a comprehensive RFP document is the best way tostart the process and ensure the carrier is reaching a wide groupof vendors. To develop the RFP, Appix uses a template that containsabout 1,500 functional requirements that span the various moduleswithin the carrier's systems. "We like to interview the users andunderstand what the must-have requirements are, identify somenice-to-have requirements, and cross off our list some of therequirements this carrier might not be interested in," saysJones.

Typically, the functional requirement list is broken down tobetween 1,000 and 1,400 items, explains Jones. "It's a lot, but thereality is if you really want to pick apart functionality at adetailed level, you have to ask the detailed questions," he says."You're not going to be able to get into that level of detailthrough demos." Appix encourages the vendors to demand answers toall of the 1,000-plus requirements, which then can be attached tothe final contract as an appendix to refer back to in case thereare any squabbles during the implementation.

The vendor's financial stability, experience with the relevantlines of business, implementation approach, technology platform,and cost are other parts of the RFP, adds Jones.

Appix generates a list of vendors to receive the RFP, and Jonesadvises the carrier to interview some of the vendors either byphone or preferably by e-mail to see which vendor is a fit. "As youknow, there are numerous players in this market right now," hesays. "You don't want to score 50 RFPs, so you want to ask somehigh-level questions before you release the RFP." Such questionson, for example, the vendor's length of time in business, number ofemployees, number of implementations, and the number ofinstallations for the lines of business the carrier is looking forshould be easy enough for a carrier to get answers to within days.That information will allow the carrier to create a reasonable listof between 12 and 18 vendors to which to send the RFP.

The responses enable the carrier to come up with a short list ofsemifinalists. "The purpose of the RFP is to allow you to make acomparison between the vendors that will enable you to come up witha semifinalist list for much more detailed analysis," says Jones."You don't want to bring in eight to 10 vendors for demonstrationsbecause you simply won't be able to remember the difference betweenvendor three and vendor six."

Jones recommends the carrier issue a formal demo script to thesemifinalists in which the vendors are given specific instructionson what the carrier wants to see. He adds the vendors should all bebrought in for the demonstrations within a short time frame. "Neverlet it run over the course of three-plus weeks because you justcan't remember what you saw three weeks ago," he says.

Pearson agrees the carrier needs to control the demonstration."We find it particularly useful for us to create a script for themto follow rather than for them to come in and demo the system in away that presents [the product] in the most positive light," hesays. "We wanted to take control of what that demo ultimatelyshowed."

After the demonstrations, Jones contends the carrier needs toselect two finalists. This allows for a reasonable process of doingthe final analysis, which might include a visit to the vendors'headquarters. At that point, the carrier also needs to push thevendors for their specific implementation plans and their approachto any modifications they are going to need to make to the system."When you have a smaller list and the vendors realize they have alegitimate shot at your business, they are more willing to investmore time in providing that detail around their project plan andtheir approach to dealing with necessary modifications," he says."If you push them for too much detail too early in the process whenthey are one of 10 or 15 vendors, you are not going to get thelevel of detail. Most strong vendors are hesitant to invest muchtime at the beginning of the promise compared with when they have a50/50 shot at your business."

COMMON PITFALLS

The time-consuming nature of software demos can cause users tosuffer from what Jones calls demo-fatigue, which can result inusers losing interest in other potentially strong applications. "Weadvise carriers not to bring vendors in for demos too early in theprocess," he says.

Jones also believes in asking for pricing information upfrontthrough a formal RFP. "If a carrier creates a short list of vendorstoo early and before it asks for pricing, it loses significantleverage in pricing negotiations," he says. "If vendors come infrom the get-go and know it's their business to lose, they are notgoing to be as aggressive in their pricing strategy, particularlyif your users begin to generate a lot of enthusiasm for thatparticular application before they know what it costs."

Negotiations over price shouldn't begin too early, though."We've found if a vendor feels it has a legitimate shot at thebusiness, it is willing to sharpen its pencils and work with you onprice as well as contractual negotiations," Jones says.

Harris-Ferrante would like companies in evaluations to focusless on a system's functionality and more on how the vendor canconfigure the system to make it fit the carrier's requirements–thetechnology piece related to integration. "We spend so much time onthe evaluation of functionality that people don't have enough timeto spend as they should on other areas," she says.

Another concern Pearson suggests carriers discuss is thevendor's capacity to take on additional customers. Most vendorsclaim they won't oversell their ability to deliver, but Pearsonadds, "Nobody ever walked away from a sale."

Carriers need to determine the vendor's ability to supportmultiple, concurrent implementations. "They can tell you they cando that, and for some of them, it's not difficult to outsource partof the development or to contract with project managers or businessanalysts," says Pearson. "The questions are: What is the quality ofthese [additional] individuals? What do they know about theparticular system? What do they know about the delivery methods ofthe vendor? Vendors can ramp up in sheer numbers, but it can bemore of an illusion than real additional capacity."

BUILDING A BOND

Perhaps as important as the quality of the software is thequality of the people you'll be dealing with, Garvey has learned.It's important to determine whether the vendor's corporation isprocess heavy, whether work gets done without six people weighingin on the discussion, and whether the vendor is being entirelyhonest.

Garvey recommends having a lot of discussions with the people onthe vendor side with whom staff and business users are going towork once the contract is signed, not just the sales rep. Therealso need to be discussions between the senior management of thetwo corporations. "There has to be a bond between ourorganizations," he says.

What makes Ingram comfortable in making a final decision on avendor is the people he is dealing with and the principles thevendor operates with. "When you spend time and you're involved inhands-on ways, those things come out in the discussions," he says."The software doesn't run straight out of the box, so the companybehind it is important. We're trying to make five-year-plusdecisions, so the durability, future strategy, and the paths thesecompanies are going to take are always in the back of my mind.Often when we get the short list, the intangibles of the people andour view of the future direction of the company led us to onedecision over another."

Garvey acknowledges it can be difficult to differentiate betweentwo vendors, and it may come down to a gut feeling. He compares thesituation to hiring a new employee. "Doesn't [hiring] frequentlycome down to your gut feeling?" he asks. "If an applicant passesall the interview questions and you still feel he or she may not bea good fit for your organization, do you think you'd hire him orher? The same approach applies to software selection. You shouldhave to have a good feeling about the vendor and the people you aregoing to work with. You can get a vendor's track record from othercustomers, but you also get it from your own discussions with thevendor prior to making a decision that may be the most importantand exciting business decision you'll make."

In Pearson's case, he considers himself more of a fact-basedkind of decision-maker. "I'm not a real shoot-from-the-hip type ofperson," he says. Still, during precontract discussions with avendor, the quality of the vendor's technical staff, developers,design people, architects, and business analysts was a huge factorin creating a comfort level and determining those people wereproblem solvers. "They understood our business, and we determinedit was an organization we could work with," he says.

But while this can help initially, Pearson points outorganizations change and people come and go, including managementteams. "So, if the comfort level is part of your decision processat one point in time, it also could be a weakness in yourdecision-making process if management teams change or the companygets acquired," he says.

EXCITING TIMES

Selecting a vendor product is an exciting part of the job of aCIO, and some even consider it fun, according to Ingram. "It's whatpeople in leadership positions get paid for," he says. Therecertainly is pressure, too, because the decisions that are madeoften affect the performance of the company for years to come"That's part of what you're going to get judged on," says Ingram."I'm excited about that. You train a lifetime to make those kindsof decisions."