Jeremy Holt says that many small and midsized businesses don't handle the legal side of their IT procurement very well. They often cut corners and don't take proper advice, or even get enough detail of the deal in writing – and come to regret the failing.
The commercial solicitor – a partner of Clark Holt and the author of A Manager's Guide to IT Law – says it can be particularly painful when they've paid for the development of bespoke software and find they have no ownership rights over the source code.
"Often I get heart rending calls from people where they've employed a software house to get something ready, then there's a row and they realise the software house has them over a barrel," he says.
"They've got no proper rights to use the software that's been created. Although they've paid for some development work they don't own it, everything is on the software house's machine, and they say 'Unless you pay my charges I'm not doing any more work to keep things going'."
Book and tips
It was dilemmas such as this that prompted him to write the book, which is published by the Chartered Institute for IT (BCS), and draw up its 10 tips on the issues that IT managers should know about. His advice is to take some simple steps to stay clear of the problem.
"Firstly they should set out in writing what they expect to happen. A lot of these things happen without any written record of what's going on.
"Secondly it would be sensible to agree that the developer either provides the source code so they could move it elsewhere, or to agree in the contract that they would allow the customer to have other people develop the software if they don't want to use them any more."
Holt says most buyers would be well placed to do this before anything is signed, but that once the deal is struck or money paid "the genie is out of the bottle", and the software supplier can name their price.
He also advises trying to avoid bespoke software and buying the commoditised packages, even if it involves changing some internal processes to match the software. It may cause some internal friction but it's much less risky.
Another step that could be taken up front is to include a mediation clause in the contract, so that if there is a dispute with a supplier they can be forced to go to an independent mediator before anyone takes it to court.
The mediator listens privately to each side's point of view and doesn't tell the other what was said. They often have different priorities that are not mutually exclusive, which means both can obtain what they really want.
"I've been quite impressed by a number of the mediators I've met, and they are independent," Holt says.
"Often when you have two people in dispute it's best to find a middle way, because it's going to be a lot cheaper than if you go off to court."
Buying hardware is much more straightforward as a supplier will usually repair or replace anything that isn't working, but there are also problems in the growing business of cloud services.
"With cloud computing you're putting an enormous trust in the supplier," Holt says. "You're putting all your data with them and they could if they wanted look very closely at the data, and it could be seen by your competitors.
"When people are entering into a cloud contract the things I would concentrate on are how reliable is the company, who would see your information, whether it's going to be kept on a separate server, and whether the company has agreed to assist you to move to another cloud computing company if you want."
He also has advice around emails: to ensure that the company and contact details are correct, at least for the first message in a conversation so there will be always a record of it in the thread. If someone is sending an email on behalf of the company they should make it clear, and if they don't it could create confusion over who is entering into an agreement.
Long disclaimers on emails are not necessary. Holt says "they don't count for a jot" and that it's better not to have a disclaimer at all.
He recommends that any small firm uses the 10 tips as a starting point to understand the legal requirements of its IT activities. These take in some of the points mentioned above, along with issues such as the need for policies on computer use and data destruction, and a warning that there has to be an agreement on licensing terms to use open source software.
But if there's one point Holt emphasises above all others it's importance of getting an agreement in writing.
"You do need written contracts," he says. "You can't just rely on understandings that are not written down."
Article continues below