Avoiding Software Disputes

Carrying out software development without a contract leaves both customer and supplier exposed to the risk of software disputes.

Matt Worsnop of BHW Solicitors in Leicester writes about an all-too familiar scenario.

You’ve just won a major contract to deliver bespoke software development – great! The customer needs the new system urgently and requires you to hit some challenging milestones – not so great but you’re confident you can re-assign developers off another less-urgent project and still meet the deadlines.

Then the customer mentions that, because of the aggressive schedule, there’s just not going to be time to negotiate a detailed written contract. “We’ll just sit down and work out roughly what you need to deliver for each milestone and sort out the detail as we go” says the customer. This makes you a little nervous but the customer has a good reputation, it’s a big contract and you don’t want to let it go. Reluctantly you agree.

The project starts off well. Both sides are excited and positive. You hit the first milestone only a day past the deadline and the customer seems happy.

A week into development of the second milestone, the customer contacts you. They’ve now had time to review the first deliverable and though they’re still happy, they’ve thought of some other things (which they didn’t tell you about before) that they’d like to add.

If you’d had a written contract, you’d have almost certainly had a formal change control process – you’d be telling the customer how many extra days the changes would take and how much extra it was going to cost them. But as soon as you mention the words “extra cost” the customer becomes defensive – the customer thinks the “new” features aren’t new at all – you should have realised they wanted them from the general description they gave you. Worse still, the customer can’t let the schedule slip so expects you to do the extra work for no extra money and without removing any content from the next milestone.

It’s an impossible position but the project is still in the early stages and you desperately want to keep the customer happy. So you grit your teeth and somehow manage to find the extra resource and absorb the costs yourself.

After the next milestone, things go downhill even further. This time, the customer isn’t asking for new content – they’re telling you that you haven’t delivered what they asked. There was no formal specification or project plan so it’s near impossible to prove either way but you’re adamant that you’ve delivered what you were asked and the customer is adamant you haven’t.

Not only that, but the customer is suggesting that some areas of functionality aren’t performing correctly. There was no formal procedure for carrying out acceptance tests and there were no written acceptance criteria. You insist that the software performs acceptably; the customer insists it doesn’t.

Several weeks later and lines of communication between you and the customer have almost entirely broken down. The customer has stopped paying your invoices, you’ve stopped doing work and the project has ground to a halt.

You tell the customer that they need to pay your invoices or you’ll “take things further”. The customer insists you haven’t delivered what you were contracted to deliver and they’re within their rights to withhold payment.

The customer then tells you that, because of your breach of contract, they might need to talk to their lawyers about their options.

Of course, when they do talk to their lawyer, he tells them that it will be difficult to prove breach because of the lack of any written contract, agreed specification or project plan.

At the same time, your lawyer tells you it will be difficult to sue for unpaid invoices for the same reason: it’s as difficult for you to prove you’ve delivered the work as it is for the customer to prove you haven’t.

Stalemate.

What you can do to avoid software disputes

Wherever you can, get a contract in place before software development starts. Make sure you have the contract reviewed by a solicitor experienced in software development issues.

If you can’t get a contract signed, then make sure your customer agrees the content of each deliverable in writing (even if it’s just an email). If you haven’t got the time to draw up formal specifications, then make sure you write up the notes of all your meetings and telephone conversations with the customer and get them to agree (by email or in writing) that they’re correct.

Resist changes to the specification unless they’re agreed in writing. Remind the customer that cost, timescales and content are all linked – you can’t vary one without affecting one of the others!

Remember the golden rule – get everything in writing. That way, even if the project deteriorates into a software dispute, you’ll have the ammunition you need to bring a claim or defend your position.

Matt Worsnop is an Associate Solicitor at BHW Solicitors in Leicester. He is an expert on the legal issues affecting software development: before qualifying as a solicitor, he worked for 15 years in the software development industry. Contact Matt on 0116 281 6235 or by email at matt@bhwsolicitors.com.