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.
• "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".
• 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.