When you have the basic business deal framed out, involve a lawyer who knows the ins and outs of software contracts to make sure you won't get hurt by esoteric legalities. Lawyers are trained to deal with the downside in situations. Their orientation is conservative and tends toward protecting against legal and financial risk. A lawyer's function is to stop bad things from happening rather than to make good things happen. So, do the deal. Then bring in the legal oversight.

A software license agreement provides the terms and conditions under which a carrier gets to use a defined software set. Note: The carrier is (in almost all cases) not buying the software but merely buying the right to use the software. Some of the most important issues in a software license agreement include how long rights to use the software last, what companies have rights to use the software, and what physical machines the software can run on. The license agreement also typically includes the scope of use, for instance, how much business can be processed, with business measured in various ways such as lines of business, writing states, and premiums processed.

While pricing method varies by vendor, it still is most common to pay a one-time fee that reflects some variation on a tier pricing calculation. For obvious reasons, it remains the vendor's preference to receive payment for the full license fee within a short period of the signature of the license agreement. For equally obvious reasons, the carrier should resist this and agree to some form of staged payments that reflect a combination of added value and reduced project risk.

The most important single issue under the heading of "what happens if something goes wrong" is the provision of escrow for the software. This is more an area for the lawyers (as are most types of "what happens when something goes wrong" issues) and involves the frequency of escrow deposits, the triggering events that give the carrier access to escrowed code, how and when code is made available, the nature and location of the escrow agent, and specifics about the exact definition of the code that is made available.

A software maintenance agreement provides for ongoing software maintenance and support. Service usually consists of access to new software releases (both major and bug fixes) as well as help desk support and problem reporting and resolution.

Generally, a maintenance agreement is mandatory for the first support period following the purchase of software and usually lasts for a period of five years. In the past, carriers have chosen at varying points to go off of maintenance, especially when they have heavily modified base systems and no longer can easily take upgrades. Whether this will be true of newer software where client customization and configuration is more isolated from base code is yet to be seen.

In terms of what you get, focus on service-level agreements (SLAs), escalation schemes, and provision of services. Although insurance is not like stock trading or airline booking, it is more a real-time business than in the past, so consider the adequacy of SLAs against the potential impact to your business as it is today and as you envision it in three to five years' time.

Also, understand the maintenance agreement buys you only access to updates. It does not defray the cost of installing and testing an upgrade–work that would be governed by the professional services agreement.

On the subject of costs, annual maintenance fees generally vary between 18 and 22 percent of the initial license cost, meaning the carrier essentially buys the software again every five years. One seemingly innocuous clause in the maintenance agreement to which careful attention should be paid is the provision for annual cost increases or inflation adjustments. Build a spreadsheet and project what happens to these costs before accepting them at face value.

The professional services agreement specifies the terms and conditions under which the vendor will perform various types of service for the customer, most commonly in support of software implementation and upgrade.

The actual agreement usually contains no specific services to be performed. The service specifics are found in appended statements of work (SOW), which detail the work to be done, the resources to be used, and the price to be charged. With the professional services agreement, the business deal is done in the SOW rather than in the body of the agreement. So, leave the agreement to the lawyers and focus on what you are getting for your money as specified in the SOW.

A comprehensive SOW will spell out what work is to be done, when and where it will be done, who will do the work, when the work will start and end, what artifacts will be delivered, how both parties will agree on completion, and how changes in scope will be dealt with during execution of the SOW.

An SOW may be price fixed, estimated on a time and materials basis, or some combination of the two. Vendors increasingly are willing to fix price implementation work, and many carriers get a sense of security from fixed-price agreements by knowing the worst-case scenario in terms of cost. While this is understandable, bear in mind the worst-case scenario in this instance also is the best-case scenario (it is one and the same). Also, realize if the vendor is going to fix price work, your carrier staff must be capable of working at the rate dictated by the vendor to support its planning assumptions.

Further, a fixed-price bid has a significant margin built in for unknowns and carrier issues, so it may not be the "best" price. And in the real worst-case scenario, if a vendor has badly missed the estimation mark or the carrier fails to keep its end of the bargain, a vendor simply may come back for more money. This is not something a vendor will do lightly, but don't mistake a fixed price for a delivery guarantee.

Be realistic. If the vendor previously has done several successful fixed-price implementations, there is reason to have a much higher confidence level than if you are the first. Finally, if you and the vendor agree on a fixed-price deal, be prepared to put the time and energy into rigorously defining and managing the project to keep it on track and to minimize scope creep such that the fixed-price deal can succeed.

The pricing and contracts model used for this discussion still is common in our industry. However, it is not the only one. In recent years, there have been the introduction of per-seat pricing, derived from the personal computer/workstation pricing model, and the "software as a service" model, which has emerged from the outsourcing and Internet worlds.

Finally, some vendors have adopted a hybrid of the traditional model in which there is no initial license fee or annual maintenance charge but rather a periodic charge that blends the two. These pricing models have benefits for both the carrier and the vendor. The carrier gets a more evenly spread payment schedule, where the major initial charge is avoided. Rather than paying upfront and falling immediately into a large cost hole, this arrangement allows the carrier to retain significant ongoing financial leverage as the implementation project progresses. The vendor, in turn, gets a more manageable and predictable revenue stream against which to plan and build its company.

I like these later models for the following reason: They help mitigate the biggest single risk fact in software acquisition and implementation–front-end-loaded costs with back-end-loaded benefits. This so often has led to situations where, by the time it dawns on the carrier things are not well with either the software and/or the implementation, it is so far "in" financially, it cannot think straight about how to proceed. As one client said to me years ago in response to a very sobering assessment of a project's likelihood of success: "You don't understand. We already have spent millions on this project. It has to work."

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.