In this series, we have discussed many of the things carriers should do when undertaking the vendor selection and software acquisition of core insurance processing systems such as policy, claims, and billing administration. In this article, I am going to focus on things carriers should not do. The search for and acquisition of core insurance processing systems takes months, if not years, and the result can have a major impact on the competitive capabilities of the acquiring carrier. Also, the consequences of such a decision, good or bad, will be around for years to come. So, here then are some "watch outs" based on real-life events I have encountered over the years of working with carrier companies:

Don't do this in your spare time, and don't choose the B Team. Core system vendor and software evaluations should be executed by a team of qualified professionals who can dedicate a significant amount of their time over an extended period. This is not something that can be entrusted either to people who cannot commit the time or who are not some of the best qualified resources in the company to undertake such an important project. The carrier needs to form a team that represents the diverse interests of the various business areas and IT that would be involved in an implementation and would be stakeholders in its outcome. The team also needs to have a blend of resources that know not only the way the carrier works today but also can represent the way the carrier should work in the future.

Don't look at the vendors before you figure out what you are looking for. I regularly talk with carrier folks who have not organized a formal search and have not created any agreed criteria for what they are looking for but have gone out into the market and have contacted vendors and arranged visits and demonstrations anyway. When I ask carriers why they do this, I usually am told they feel they can learn about what is available in the market and get smarter by having vendors visit with them.

My honest reaction to this is, first, it is bad process to shop (even if it's only window shopping) without knowing what you want or why; and second, I think it's a way of avoiding the hard task of defining requirements and criteria and metrics. While it is possible carriers can learn from these types of encounters, it is more likely they will spend an inordinate amount of time focusing on one vendor and then another, finding the process to be confusing, contradictory, and repetitious. Often the carrier will end up revisiting the same vendor more than once without necessarily being any further forward.

While the carrier is busy getting confused, the vendors become jaded and cynical and write the carrier off as a "tire kicker." One fact for carriers to bear in mind is vendors make choices about which carriers to focus on based on their perception of the seriousness and preparedness of that carrier to do the work necessary to reach and execute a major software decision. In today's active software market, where vendors are busy responding to multiple prospects, a carrier that does not appear to be organized and serious may find itself last on the vendor's priority list and ignored at the point when it decides to get serious.

Don't buy price, buy value. Figuring out the cost of a major software acquisition is complicated. Figuring out the benefits is even harder. Faced with these types of complexities, it is understandable many carriers will err on the side of what they think is caution and select the vendor that offers the least expensive solution. Unfortunately, this is thinking that is appropriate when buying a commodity, not a complex piece of software. Any perceived savings, even those as substantial as six or seven figures, can evaporate quickly if the software turns out to be incomplete, poorly built, inadequately supported, or architecturally inappropriate.

Interestingly, market trends have shown in recent years that the vendors that are succeeding are not necessarily the low bidders and that carriers are increasingly wise to the issue of value rather than price. Measuring value is hard. Indeed, one smart guy in our industry recently compared estimating the ROI of a major software investment to measuring the ROI on funding a child's college education. We are not sure exactly what a college education is worth because so many variables can affect its value, but we can intuit we value it highly because we pay for it. Difficulties aside, value-based thinking is the only way to assess complex software assets.

Here are some simple facts to bear in mind when thinking about what is an appropriate price to pay for software:

o Software is expensive to build.

o Paying a fair price for the product allows the vendor to grow, remain viable, and support the software over time.

o Good software and a strong vendor are in the carrier's best, long-term interest.

o Buying a new core insurance processing system is a long-term investment.

In other words, the best deal is one that both parties can live with and should be based on the vendor's value proposition.

Don't take vendor responses at face value. It should go without saying when vendors are in a competitive sales situation, they will present their solution in the best possible light. This means it is incumbent on carriers to dig hard to find out what they need to know in order to avoid nasty surprises after the deal is done.

By way of illustration, let me repeat an example I have used before. If in an RFP the carrier asks: "Does the software support all of our lines of business in all the states in which we write?" the answer from all respondents likely will be a resounding yes. This answer is misleading for two reasons: first, because the vendor is omitting various important facts and is choosing to interpret the question in the most favorable way by replacing the word does with the word can; second, the question is ambiguously written and not focused enough.

What the carrier really wants to know is something such as: "For each line of business we write and for each state in which we write that line, does your software support production policies, and if so, for what transactions in the policy life cycle?" The key difference between these two questions and their corresponding answers is the difference between assuming the vendor previously has implemented all lines of business in all states and finding out it actually has implemented few or even none, but its software is built to "support all lines in all states." The second qualifier is, if the vendor actually supports "production policies," what does that actually consist of? Does production mean quick quote or full life-cycle policy processing including renewals? The differences are large in terms of risk, cost, and implementation effort, so make sure you know what you actually are getting.

Every vendor and every piece of software has its strengths and weaknesses. Some software is better than other software. Some software is better suited to specific carrier environments than other software. In recent years, vendors have gotten much better at disclosure, but it still is incumbent on the carrier to figure these things out. The carrier that assumes the vendor will tell it what it needs to know will end up in an implementation that looks and feels far different from what it assumed. For an amusing parable along these lines, see "Hell is Not a Night Club" ("Shop Talk," February 2007).

Don't play favorites. This doesn't mean don't discriminate between vendors based on objective criteria and choose one that suits your requirements–this is precisely what you should do. What you should not do is treat vendors differently in terms of access to information or exposure to decision-makers.

Also beware of being "adopted" or of having a team member be adopted by the vendor. Everyone who wants to sell you something tries to be your friend. Friends are trusted and treated differently, so clearly it is in the best interests of the vendor to be your friend. Consider the following true story of a salesman in our market who reported the likelihood of making a sale to a specific carrier was low because, "They don't like us." The terse reply from the boss who reviewed the call report was: "Make them like us."

It's not just that playing favorites is unfair, which it is, but unequal access and information can create a competitive advantage that may skew the search results to the detriment of the carrier. Even if the carrier team doesn't play favorites, it may treat vendors unequally unless it makes an attempt to keep the playing field level. The only way to do this is to build events onto the search process that promote open and equal treatment. For example, kicking off a software search with a vendor call at which all parties hear the same information and instructions is a good start.

The content of "Shop Talk" is the responsibility of the author. Views and opinions are those of the author and do not necessarily represent those of Tech Decisions.

Special Reports /

Whatever You Do, Don't . . .

Related Stories

Recommended For You