Failed software project: who is liable and what are your options?

If your software project fails, the supplier is only liable if it did not deliver what was agreed and that failure can be attributed to it (Article 6:74 of the Dutch Civil Code, BW). In practice responsibility is often shared: if the client changed its wishes, decided late or did not provide test data, the court can reduce the damages for contributory fault, and delay caused by the client does not count against the supplier at all.

This article explains the common causes of failure, the legal assessment, the client’s duty to cooperate, the role of a court-appointed expert, the possible outcomes, and what clients and suppliers should check to prevent or win a dispute.

Why do software projects fail?

A few causes recur, and they often reinforce one another. A project that first only runs late can end up failing completely.

• Scope creep: the requirements keep growing without a change procedure that settles the effect on planning and budget.
• Unclear or incomplete functional specifications, so that it is unclear later whether the result complies.
• A system design that does not fit the actual load, the interfaces with other systems or future growth.
• Underestimated complexity and lead time, especially when several existing systems must be connected.
• Late or limited cooperation from the client.

When is the supplier liable?

When it has failed to perform and the failure is attributable to it. Under Article 6:74 BW, the debtor must compensate the loss caused by a failure to perform, unless the failure cannot be attributed to him, for example in case of force majeure (Article 6:75 BW).

The client must therefore show that the supplier did not deliver what was agreed, for example software that does not meet the recorded specifications. As long as performance is still possible, the supplier must usually also be in default, after a written notice of default with a reasonable period (Article 6:82 BW).

What if the client contributed to the failure?

Then the damages are reduced. Under Article 6:101 BW, the loss is divided between the parties in proportion to the extent that circumstances attributable to each contributed to it; fairness can lead to another division or to no compensation at all.

Typical client contributions are late decisions on requirements, changing wishes without accepting the effect on planning and cost, and the lack of a usable test environment. Document throughout the project who decides what, which changes are made and when information is supplied.

What does the client’s duty to cooperate mean?

A software implementation is a joint effort. The supplier depends on the client for timely and complete specifications, usable test data, quick decisions and timely acceptance of delivered parts.

If performance is prevented because the client does not give the necessary cooperation, the client is in creditor’s default (schuldeisersverzuim, Article 6:58 BW). The supplier is then not in default for that delay. In iterative projects, where each phase builds on feedback from the previous one, missing input is often decisive in attributing delay.

For clients: criticism of progress carries little weight if your own decision-making is slow. For suppliers: report delay caused by the client immediately and in writing. Afterwards, it is often impossible to reconstruct who caused which delay.

What role does a court-appointed expert play?

Often a decisive one. Whether the software met the specifications, where the delay arose and whether extra work was justified are technical questions, so the court can order an expert report (deskundigenbericht) at the request of a party or on its own initiative (Article 186 of the Dutch Code of Civil Procedure, Rv).

Before proceedings start, a party can also ask the court for a preliminary expert report (voorlopig deskundigenbericht) to assess its position (Articles 196 and 202 Rv). The expert usually needs:

• the contract, its annexes and the applicable general terms;
• the functional and technical specifications and the change requests;
• the project planning, progress reports and test reports;
• the correspondence about delay and acceptance;
• the source code and documentation.

If documents are missing, the expert often cannot answer the question, and that harms the party that relies on the facts concerned. Keep the project file in order during the project, not only once a dispute arises.

What can the court decide?

If only part of the project failed, for example one module that does not work while the rest is usable, the court can order partial rescission (Article 6:265 BW). Partial rescission reduces both parties’ performance proportionally (Article 6:270 BW), so the working part remains in place.

The court can award damages under Article 6:74 BW, reduced for contributory fault under Article 6:101 BW. It can also mitigate a statutory duty to pay damages if full compensation would lead to clearly unacceptable consequences, for example where the claim is out of all proportion to the contract value (Article 6:109 BW); courts use this power sparingly.

Many failed projects end with a restart at another supplier. That raises its own questions: who gets the source code, who holds the intellectual property rights, and is there an escrow arrangement? Settle these points at the start of the project.

How can arbitration help in IT disputes?

Many IT contracts refer disputes to the Foundation for the Settlement of Automation Disputes (Stichting Geschillenoplossing Automatisering, SGOA), which offers arbitration, mediation and binding advice with arbitrators who know the IT sector. Arbitration is only possible if the parties have agreed it, usually through a clause in the contract or the general terms.

Without such a clause, the dispute goes to the ordinary courts: the subdistrict court for claims up to €25,000 and the commercial chamber of the district court for larger claims (Article 93 Rv).

What should you check as a client?

• Are the functional specifications and acceptance criteria recorded, and do they match what you now expect?
• Have you provided specifications, test data, decisions and acceptances on time, and can you prove it?
• Have you sent a written notice of default with a reasonable period before claiming damages or rescinding?
• Does the contract cap the supplier’s liability or exclude consequential loss?
• Do you have access to the source code and documentation, or an escrow arrangement, for a restart elsewhere?
• Does the contract contain an arbitration clause, for example for the SGOA?

What should you check as a supplier?

• Have you recorded every change request in writing, with its effect on planning and price?
• Have you reported delay caused by missing client input immediately and in writing?
• Can you show with test reports and acceptance records which parts were delivered and accepted?
• Do your general terms apply, including the liability cap?
• Is your project file complete enough for an expert to reconstruct the course of the project?

How can you prevent a dispute?

Most disputes can be prevented by the contract set-up. Five measures help:

• divide the project into releases or milestones, each with its own acceptance criteria;
• agree formal acceptance tests before an invoice falls due;
• record a change procedure: who may request a change, who decides, and how planning and price are adjusted;
• agree an escalation ladder: project group, steering committee, mediator, and only then arbitration or court proceedings;
• include an arbitration clause if you prefer an IT-specialised forum such as the SGOA.

What can we do for you with a failed software project?

Our IT lawyers advise clients and suppliers on IT projects in trouble. We can:

• assess your contract and project file and determine who is responsible for which delay;
• draft a notice of default or a written warning about missing cooperation;
• negotiate a settlement or an orderly exit, including handover of source code;
• request a preliminary expert report or draft the questions for a court-appointed expert;
• conduct proceedings before the court or in arbitration about rescission and damages.

Read more about what an IT lawyer does.

Summary

• A failed project is not automatically a failure to perform by the supplier; the failure must be attributable to it (Article 6:74 BW).
• Contributory fault of the client reduces the damages (Article 6:101 BW); missing cooperation can put the client itself in default (Article 6:58 BW).
• A court-appointed expert often decides the technical questions, so keep the project file complete.
• The court can order partial rescission so that the working part remains.
• Phased delivery, acceptance tests, a change procedure and an escalation ladder prevent most disputes.

Frequently asked questions