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.