Experience shows there are several common characteristics a carrier will "traditionally" focus on in a vendor search. These are less than the full spectrum that should be considered for a partnership. For example, if a carrier is looking to replace its current policy administration system, it probably would focus on the available business functionality and technical compatibility of the software, the general track record and viability of the vendor, and the price of software and services. While these certainly are important characteristics, they do not provide a complete partner profile.

Let's consider a candidate list of characteristics that might offer a more complete view of the potential partner and, per our example, the software being considered. This list usually includes:

o Business functionality. This is what you focus on when you gather business requirements, for instance, for inclusion in an RFP. Many requirements are relatively concrete and measurable. In our example of the carrier looking for a new policy administration solution, the requirements list almost certainly will include the ability to structure insurance products, especially those products the carrier writes or intends to write; quote, rate, and issue policies; perform life-cycle transactions, such as endorse (including the dreaded out-of-sequence endorsement), cancel, rewrite, reinstate, renew, and audit (for commercial lines); generate or integrate to printed output; create statistical records; and talk to numerous other systems in the legacy environment.

o Support for business drivers. Many carriers fail to distinguish between business requirements and business drivers. Support for business drivers is oftentimes harder to define, identify, and measure. It is relatively easy to verify a system can endorse a policy. It is more difficult to establish whether the system will increase speed to market, enhance the agent's experience, reduce expenses, or increase customer satisfaction. And yet these factors almost always are what are used to "sell" major system replacements to senior management.

o Technical compatibility. The goodness of fit of a new software product into a current, evolving, or target technical environment usually is based on a laundry list of questions concerning operating systems, database management systems, languages, and communications and transport methods. In the current era, the questions pretty much boil down to: Microsoft or Java, and Microsoft or Oracle? Larger IT shops often don't have too much at stake with the answers to these questions because they probably already support some of both. Smaller shops will view the internal support requirements and financial implications as being significant.

o Development capabilities. Few carriers actually focus on whether the candidate partner is good at developing software. If your intention simply is to buy code, bring it in-house, and supply all maintenance, support, and enhancements internally, you may not be overly concerned about the vendor's development capabilities. However, if the system was poorly designed, coded, and tested, it subsequently will be harder to debug and implement and more difficult to maintain and enhance. And what about the case where you want the vendor to provide maintenance and enhancement services? Or when you are buying one of the newer core systems you expect (and probably need) to have the ability to continue to expand and mature functionally over time? In this instance, the vendor's development capabilities may be as important, or even more important, to you than the system's current functionality set.

Another important characteristic of a software solution that is harder to gauge is its flexibility. We all know two things about the current policy administration environment. First, changes are constant: regulatory changes, rate changes, data calls, and new market and product opportunities. This is one reason maintenance eats so much of the property/casualty IT budget. Second, legacy systems do not cope well with change. Some changes are hard, while others are excruciating. Think of the nine-month rate change you either have requested or implemented–one more reason for the maintenance budget problem.

So, how do we know and measure flexibility when we find it? There are some obvious indicators. One is the extent to which rules and data, rather than coding changes, drive system behavior. Another is the extent to which functions are isolated such that change can be contained and localized to minimize development and testing. In this way, software flexibility is a result of good design, development, and implementation choices.

We have focused on the ability of the vendor to write software that is functional, flexible, and capable of supporting your business. But for vendors to be good "partners," they must be more than just a bunch of bright people who can build software. They also need to know how to implement their software successfully and preferably have a track record of success in doing so. This requires project management expertise, a repeatable methodology, domain knowledge, integration skills, and an understanding of the complexities and inconsistencies of insurance data. Also, it would be reassuring if the potential partner could demonstrate implementation success in a business environment similar to yours in terms of products, geographies, and distribution channels. If you are an E&S carrier and the partner's implementations are exclusively in personal lines, proceed with caution.

A major partner choice is based on a risk/reward assessment that is not always explicitly understood. First, the carrier may not have thought through its tolerance for risk. If you are a large carrier with deep pockets and relatively unique requirements, you probably will have a higher risk tolerance than a small "ISO vanilla" carrier. Second, the major elements that define the partner's risk profile are not always considered. These include:

o Stability. Is the company owned and/or run by a long-term group of key managers? Is the company for sale or an acquisition target?

o Growth. Is the company growing in a way that is sustainable? This is a bit like the story of the three bears. Little or no growth is bad; too rapid growth is bad; but sustainable, profitable growth is just right.

o Profitability. Is the company making money?

o Legal. Is the company subject to any major legal action(s) that could divert the company focus, modify the product or services offerings, or impact growth and profitability?

o Mission. Is the company's stated mission in line with the carrier's assumptions, and is it subject to change?

If you are looking for a long-term partner, then are you interested not only in its long-term viability but also whether it is a company you would feel comfortable with. Successful partnerships are based on trust and goodwill. Projects have dark days. Good people make mistakes occasionally. Misunderstandings arise. Assumptions prove to be misplaced. Unfortunate events occur. What gets a partnership beyond these events and moving forward are trust and goodwill. Ask yourself some very simple, gut-check questions: Does this company have my best interests at heart? Can I trust it to do the right thing when I lack control or oversight? Will our people work well together?

There are a couple of things that don't seem apparent when search teams initially consider price. First, price on its own doesn't mean much. The issue is price for what? We need to consider the terms and conditions of a contract in relation to the price. Also, the fairness and transparency of contractual language will tell you a lot about the partnership orientation of its author. Second, experience shows price alone is not one of the more important selection criteria for most carriers. Would you rather have your project be a $2 million failure or a $3 million success?

A final point to consider is it takes two to make a partnership.

The carrier has to be prepared to deal with the vendor in a way that is more cooperative and less formal or, even, adversarial. For example, a partnership can be based on the co-development of software where the carrier may bring value to the partnership through domain knowledge, being a reference client, and funding.

In turn, if a vendor truly aspires to be your partner, then it needs to: expect and welcome broader scrutiny and assessment; perform at a consistently high level and deliver fair value; and put the interest of the "client partner" first.

Otherwise, that vendor/partner just is jumping on the bandwagon of another linguistic fad.