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 >>