23 July 1998: Are you the proud possessor of a piece of
expensive third-party software? Then odds are you have been
stiffed, and it is a safe bet to say the experience was not
pleasant or cheap.
Stiffing is the unpleasant slang for the practice carried out by
the suppliers of third-party software to make money out of their
users whenever the users want to change anything about the way they
use the software.
The problem of stiffing is due to the way software is made
commercially available to those who did not author it. Software of
course is not sold but only licensed and users are entitled to use
the software they acquire from third parties only in so far as
their licence specifically sets out. And the emphasis is on the
term 'specific'.
If a licence says the software can only be run on Tuesday
afternoons when it is raining the user had better be pretty sure
they have a clear definition of the term 'rain'. Scattered showers
or drizzle may not count – and the user may abruptly find
themselves beyond the protection of their software licence.
Going beyond that protection can be painfully expensive easily
costing many thousands of pounds and more simply because the user
has now discovered himself to be exposed to a rock and a very hard
place.
The rock is the power of the supplier to crack a punitive whip
over the user's head without legal let or hindrance and the hard
place is the user's reliance on that software for the continuation
of core business processes.
It is both the vulnerability of users to the practice of
stiffing and to the software they run that makes the practice so
invidious.
Unscrupulous suppliers can sit back and wait for the user to
make a move that the software licence precludes such as upgrading
or changing machines or location or adding more users. Any excuse
will do it seems to trigger an unwelcome call regretfully informing
the user that he has just changed the terms and condition to his
cost.
Users often feel it necessary to cloak the experience of being
stiffed in secrecy. Not only are users understandably reluctant to
stand up and be counted among the "I've been stiffed" brigade but
it can also be politically essential to conceal the occurrence even
from the user's own company.
Looking a fool is one thing – looking commercially incompetent
in front of top management is another.
The urge to conceal the experience makes it difficult to tell
just how prevalent it is. "Users are very cagey about talking about
it but it does go on," says Diane Finn head of membership at the
National Computing Centre which is experiencing a surge in interest
in the whole area of IT procurement among users. "Who wants to
admit it when they are over a barrel?" she adds.
A recent informal show-of-hands survey at an IBM Computer Users'
Association meeting indicated that nearly all had experienced
stiffing.
Some experts feel that stiffing is on the up as software
suppliers increasingly regard it as a nice little earner -
especially when as in the US according to the Gartner Group's Pat
Cicala they are under perpetual pressure from the stock analysts to
show remorselessly bullish growth every quarter. Another reason
cited for the upturn in stiffing is that favourite fall guy the
year 2000 problem.
Suggests Geoff Petherick commercial director of the IBM Computer
Users' Association with large chunks of the IT budget diverted to
fixing the millennium bug software suppliers began to feel the
pinch in their sales. "It became very difficult to sell software,"
he says "so suppliers looked for another source of revenue."
Fixing the date can also be a time to change software and
therefore an opportunity for suppliers to bring in compliant
versions at less favourable terms and conditions – and a few
stiffs. Sema Group's Bill Monk sees stiffing being formalised by
suppliers. "For one supplier it formed a substantial part of target
income for the year," he says.
Cicala claims it is also spreading down from the big boys:
"Smaller companies have learnt how to get revenue through these
techniques."
Despite all the bad news for users about stiffing is it really a
serious burden on the average user's IT budget? Probably not
estimates Petherick. "The average user has about 50 contracts for
software running over five years or so which means that most stiffs
are isolated incidents," he says though he admits he was surprised
to find so many instances.
However, one major user disagrees. "It is a huge problem,"
asserts that user's procurement manager. "But it's essentially
confined to the mainframe software suppliers rather than in Unix
networking or PCs."
So is stiffing just something users have to accept as part of
the way the computer industry works?
Users can fight back. Without a doubt the Computer Weekly
anti-stiffing campaign has hit a nerve with a great deal of
feedback coming in from users consultants lawyers – and even
suppliers.
But although the way forward should be by a general clean-up of
software licensing and the development of industry guidelines which
prevent suppliers getting away with stiffing there is still much
that individual users can do to protect themselves
pre-emptively.
The bottom line is to formalise the procurement process with the
help of external legal expertise and then draw up standard software
contracts say by setting up some sort of internal central
procurement department which handles all software acquisition.
When it comes to buying software shrewdly it is caveat emptor.
But users should also have the protection of doing business with a
responsible ethical and above all fair software industry. Perhaps
it would be as well for users to bear one other point in mind –
that a fair contract cuts both ways. Users who act to force
suppliers into underbidding just to win contracts should not be
surprised if that supplier then wants to make some money back by
stiffing later.
A commercial transaction is always a two-way street.
Avoidance tactics
• "Prevention is better than a cure. Most stiffs are about poor
contracts," says Petherick. "My advice is to get a lawyer
involved." A company lawyer will do fine as long as they understand
peculiarities of software contracts.
• Set up a corporate centre of IT software procurement
expertise. This doesn't have to mean putting all software
procurement through a central procurement office.
• This can be self-defeating because it inspires business users
to go outside the IT department and buy independently - and
naively. But it does mean having a pool of expertise developing
software contract best practice.
• Produce an internal corporate standard contract for all your
software procurement – do not just accept the supplier's contract.
Publicise these to business so it understands the reason and the
risk.
• Take a leaf from procurement practices in the public sector
where organisations such as the Central Computer and
Telecommunications Agency have highly codified standards.
• Keep the competition in the game until the very last moment to
keep the pressure on suppliers.
• Do not buy software in a hurry – suppliers can smell
desperation a mile off.
• Do buy software at quarter ends when salesmen realise they are
under quota. They will be more likely to offer you good deals. But
warns one procurement manager you will have to have everything in
place from business approval to typed up contracts ready to sign
without delays.
• Ensure your procurement team mixes technical experts with
procurement and legal specialists so the former can understand the
mindset of the salesman.
• Accept that there is a management overhead to be paid in
ensuring your contract does not leave you exposed.
• Plan ahead. Take into account any organisational changes that
could affect your software contract. Foresight saves money.
• Ensure suppliers set out all the conditions under which they
will trigger extra charges and what those charges will be. Then you
will know the cost and risk of change.
• Just say no. Will a supplier really risk the bad publicity and
the loss of custom by suing you?
• Go up the food chain. Greedy salesmen or account managers
cracking stiff whips may not be popular with their own bosses if
they jeopardise the customer relationship for their
commissions.
• Conversely beware suppliers that love 'business alliances'
also known as cosy relationships with your IT- ignorant top
managers.
• Shame them in the glare of bad publicity. Tell Computer Weekly
they are trying to stiff you.
• Finally, says one procurement manager: "Don't be afraid of
them."
Stiff wrap and roll
The private and public stance of software suppliers may differ
dramatically. Although Computer Weekly's anti- stiffing campaign
has been endorsed by user-based groups such as Visual the IBM
Computer Users Association the National Computing Centre the
British Computer Society IMIS and the UKCMG at whose annual meeting
IBM recently lifted the lid on stiffing most major software firms
also publicly condemn stiffing.
But privately suppliers may not be so supportive of
anti-stiffing campaigns.
One consultant reported having been accused of being "an
activist" by a software salesman phoning him at home after he had
posted comments on the supplier's pricing levels to a
newsgroup.
And one substantial software company Computer Weekly has learnt
regards stiffing as a way of compelling users to sign new long-term
contracts with worse terms and conditions than before especially
when the original licensor was taken over by the new software
supplier. This practice is known as "stiff wrap and roll".
Top stiffs
Charging
• more when dropping a product from a bundled contract
• for a few days' parallel running on test and production
machines during a machine upgrade
• lots more when the machine is upgraded
• per parallel sysplex node
• for running development on a PSX node
• for moving to a CMos machine
• when the company demerges to a 'new' firm
• when the company sells off the division using the software
• when the systems are outsourced
• for trying to integrate the product with new software
Thinking behind the guidelines
The principle underlying the guidelines currently being drawn up
for Computer Weekly by law firm Hammond Suddards and all the major
UK industry organisations are underpinned by the premise that what
is needed is value-based pricing.
Charges by suppliers for their software and its maintenance
should be based always on the value of that software to the user.
If the user makes changes which result in getting more value out of
the software say by adding more users then it is fair to charge
more money.
If no benefit accrues such as moving location or outsourcing
letting contractors use it or selling off that line of business –
then it is not.
The guidelines also enshrine the principle that users should be
clearly informed what conditions will trigger charges and what
those charges will be. Inventing telephone numbers on the spot once
an unknown offence has been committed is not acceptable.
The guidelines are in preparation and Computer Weekly welcomes
comments and suggestions on their content.
Back to stiffing
homepage >>