Software buyers beware

16 December 1999: The usual rules of procurement simply cannot be applied when buying software. Bill Monk of Sema Group offers a guide through the buying process.

16 December 1999: The usual rules of procurement simply cannot be applied when buying software. Bill Monk of Sema Group offers a guide through the buying process.

Software is a unique commodity. But every day software-buyers demonstrate by their actions that they think the opposite is true. "Let the buyer beware" was never better directed at a commodity than at software.

Elaborate and highly skilled sales efforts give buyers a comfort factor that often turns the procurement process into a seemingly simple operation that revolves around little more than purchase price and payment options. Many software purchases are thus completed on a very simple commodity basis and the real issues are ignored.

So why is software so special? Compared with buying a car, for example, the purchase may appear similar. A discount is possible, a warranty is required, breakdown/maintenance service is a consideration, as is length of useful life and trade-in value.

The same cautions apply – check the dealer's history, understand build quality and reputation and ask other buyers about their experience. However, some major differences do emerge. Firstly, a piece of software is infinitely copyable. Every copy has the same features and quality as the first, and without proper copyright authorisation, copying is a universally illegal process. Many buyers or users do not understand the implications of copyright and the penalties for non-compliance.

Next comes the contract, which is very different from that for a car. Most software contracts include usage clauses. These usually contain some kind of restrictions on software usage relating to users, locations and computers.

While a car insurance policy may contain something similar, it is unlikely to feature the - sometimes well-hidden – restrictions that appear in many software agreements and that render your licence null and void.

Another feature of buying software is that inviting competition between suppliers for price/features invariably ends in disaster, whereas it works well when buying a car. The first and simplest principle is to understand and keep in mind the sales motivation and objectives.

There are a handful of major software suppliers that plan on opportunist income based on loopholes in the agreements they have with clients. This process is pre-planned stiffing. After you have paid, it is too late to start negotiating detailed terms. Even if you get a really good price in a last-minute deal, you will pay later in any lack of favourable terms.

At the point of entering into the contractual discussion, the buyer should be absolutely clear what products are wanted, from which supplier and in what operational environment they will be used. The key to effecting the most productive and durable software agreements then lies in the relationship with the supplier and the contents of the contract itself. In isolation, neither is sufficient.

The basic premise on which any contract is constructed is one of defining the objectives and aspirations of the contracting parties. The objectives of both parties are likely to be quite different at the outset, so there is a need for compromise but never abdication. Both sides need to be reasonable and the resulting contract should simply reflect the agreement reached. The contract should be a firewall to be used in the event of a last-ditch disagreement where all normal discussions have failed.

If you have to refer to a contract more often than you need to make changes, it is likely that both the contract and the relationship are wrong. A contract should be a means of writing the outline of an agreement – the detailed day- to-day requirements should be in a service agreement, terms of reference or other operations documentation. The relationship flows from the spirit of the agreement. If this is not there and you are not happy, don't do the deal.

Year-end deals done on a discount-now-terms-later basis are likely to be regretted by the purchaser. However, the same last-minute, period-end deal completed with agreed and documented terms could be ideal.

The first step to success is to have either a checklist or a specialist advisory resource to help. This includes legal advice on appropriate wording and checking for the completeness of the terms. For example, is it clearly stated what will happen in the case of unexpected events - takeovers, moves and structural changes in your company's structure?

Ideally, any contract should exist merely as a fallback. Relationships based on a process of regular recourse to contractual clauses and strict interpretation and implementation are doomed.

This does not mean that the contract is unimportant - a clear, accurate and complete contract is vital as a reference for key points agreed during the negotiation. Secondary documentation that describes the day-to-day service principles is also important, and should be maintained through an ongoing relationship.

Bill Monk has 30 years' experience in IT and manages Sema Group's IT compliance services team, with responsibility for third-party software licence integration during service transition. He has previously managed technical services, resource planning and data centres for GEC, Varity, Massey-Ferguson and Rolls-Royce

Essentials of a good contract

• Do you have the flexibility that you need? You may want to employ contractors that have access to the software, but does the agreement permit this?

• Will there be a cost for moving office locations, allowing other staff to gain access to the software etc? Does your contract permit this?

• Establish your operational requirements and service terms well before you sign the commercial agreement. Understand what support you will receive, where you get it from and at what times

• Make absolutely sure that the product upgrade path is covered. There is no point in doing a lifetime deal for a product that will become obsolete

• Ensure that you know what it will cost when you upgrade your processor or environment. The ideal is a "ceiling" clause that limits the amount you have to pay

• Keep the wording simple. If you have to ask the meaning of a clause, rewrite it

• Be wary of suppliers that will not let you change the contract – chances are you are a candidate for stiffing

• Get specialist advice and do not rely on standard procurement methods – they do not work for software purchase Bear in mind that: 

  • The salesperson wants your money – this quarter
  • The best time to get the protection you want is while the money is still in your pocket
  • Keep your contract simple, be thorough and check everything
  • Check with other users, try and find your own contacts, ask what the service and after-sales support is like
  • Take care of the relationship with your supplier

Back to stiffing homepage >>

Read more on Antivirus, firewall and IDS products

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close