A software project that grinds to a halt is a serious blow for both parties. The client invested in a system meant to improve its operations and watches deadlines pass without a working result. The supplier often sees a different picture: a client that keeps introducing new wishes, postpones decisions or supplies too little information.
So who bears the loss? Four points at the outset:
- A failed software project is not automatically a failure to perform on the supplier's part.
- The client's cooperation can also be legally relevant.
- Good project records and contractual arrangements limit litigation risk.
- An expert investigation can be decisive for the technical assessment.
Below we address in turn the common causes, the legal assessment, the client's duty to cooperate, the expert investigation, the possible outcomes of proceedings, what practical examples show, and which measures can prevent a dispute.
Common causes
A handful of causes recur in practice.
- Scope creep, the gradual expansion of the assignment. The requirements for the system keep growing without a formal change procedure addressing the consequences for planning and budget.
- Unclear or incomplete functional specifications. If it is not established in advance what the system must do, a dispute about whether the delivered result complies will follow later.
- Poor system design. The architecture is not built for the actual load, the interfaces with other systems, or future expansion.
- Underestimation of complexity and lead time, particularly on projects where several existing systems must be connected.
- Late or limited cooperation from the client.
These causes rarely stand alone. They often reinforce one another. A project that initially only runs late may as a result fail entirely.
Legal assessment: failure to perform and contributory fault
The first legal question is whether the supplier is in attributable breach. Article 6:74 of the Dutch Civil Code obliges the debtor to compensate the loss the creditor suffers through a failure to perform, unless that failure cannot be attributed to it.
A successful claim therefore requires it to be established that the supplier did not deliver what was agreed, for instance because the software does not meet the recorded functional specifications. And the failure must be attributable to it, meaning there is no force majeure.
In practice, responsibility is often shared. The client provided clarity on certain requirements late, changed its wishes during the project without accepting the consequences for planning and cost, or made no usable test environment available.
In such a case the court may reduce the supplier's obligation to compensate under Article 6:101 of the Dutch Civil Code, in proportion to the extent to which circumstances attributable to the client contributed to the loss. This doctrine of contributory fault can reduce an award considerably, and in exceptional cases lead to its dismissal altogether.
Practical advice for both parties: document throughout the project who takes which decisions, which changes are made, and what information is supplied when. In proceedings, that record often makes the difference between full liability and a heavily moderated outcome.
The client's duty to cooperate
A software implementation is a joint effort. The supplier builds and configures, but depends continuously on the client: timely and complete specifications, usable test data, prompt decisions on open questions, and timely acceptance of delivered components.
Where that cooperation is absent, the supplier cannot do its work. The law attaches consequences to this. Article 6:58 et seq. of the Dutch Civil Code governs creditor's default, which arises where performance by the debtor is prevented because the cooperation required from the creditor is not forthcoming.
Translated into practice: if the supplier is delayed because the client does not supply what is needed in time, the supplier does not fall into default and is not liable for that delay. It is the client that may itself be in default. Because software projects are generally iterative, with each phase building on feedback and approval from the previous one, absent input is regularly used in case law to attribute delay wholly or partly to the client.
For clients this is a point to note: criticism of progress carries little weight where your own decision-making is slow. For suppliers the reverse applies: flag delay attributable to the client immediately and in writing, for instance with a clear warning or a notice of default as soon as necessary input fails to materialise. If that does not happen, it is often impossible to reconstruct afterwards who caused which delay.
The expert investigation
Software projects are technical in nature. Did the software delivered meet the specifications? Did the delay lie with the supplier or the client? Was the additional work invoiced justified? Questions about architecture, source code, the traceability of requirements through the development process and the content of test reports call for technical knowledge that cannot be expected of a judge.
For that reason a court-ordered expert report is often commissioned in these disputes, under Articles 194 to 207 of the Dutch Code of Civil Procedure. An independent expert then assesses whether the software met the agreed terms, where the delay arose, and whether the costs incurred were reasonable. In practice the outcome weighs heavily in the court's judgment.
An expert will generally need the following documents:
- the contract and its annexes;
- the functional and technical specifications;
- the change requests;
- the project planning and progress reports;
- the test reports;
- the correspondence about delays and acceptance;
- the source code and documentation.
If part of this is missing, the expert often cannot answer the question. That works through into the evidential position of the party relying on those facts. It therefore pays to keep this file in order during the project, not only once the dispute has arisen.
Possible outcomes of proceedings
Where only part of the contract has gone wrong, for instance because one module does not function while the rest is usable, the court may order partial rescission under Article 6:265 read with Article 6:270 of the Dutch Civil Code. The successful part then remains in place.
Damages may also be awarded under Article 6:74, which can then be reduced for contributory fault under Article 6:101. Finally, the court may moderate the damages under Article 6:109, for instance where the amount claimed bears no relation to the original contract value. Courts apply that power of moderation sparingly.
In practice a failed software project often ends with a restart at another supplier. That too rarely proceeds without discussion. Who gets the source code? Who holds the intellectual property rights in the system built? Is there an escrow arrangement, under which the source code is deposited with an independent third party? Anyone who settled none of this at the outset notices it precisely at this moment.
What practical examples show
Alongside the ordinary courts, the Foundation for the Settlement of Automation Disputes (SGOA) plays an important role in the IT sector. This independent dispute institute has existed since 1989 and offers mediation, arbitration, arbitral summary proceedings, binding advice, expert reports and conflict prevention. Its arbitrators are industry practitioners, which explains why many IT disputes take this route rather than proceedings before the courts.
The published SGOA decisions reveal a few recurring lessons that are useful outside proceedings too:
- responsibility is rarely placed entirely with one party; the allocation follows from what each of them actually did and failed to do;
- specifications that change as the project progresses are among the most common points of dispute, and the absence of a formal change procedure generally counts against the party relying on the original agreement;
- the quality of the project records is often decisive, because it determines which facts can still be established.
For anyone drafting a contract these are useful signals: they are precisely the subjects best settled in advance.
Preventive measures
Many disputes can be prevented with the right contractual set-up.
- Work with phased contracts. Divide the project into releases or milestones, each with its own acceptance criteria. That avoids assessing the whole only after months.
- Agree formal acceptance tests before invoicing. It is then established what a delivered component must satisfy before payment falls due.
- Record a change procedure setting out who may request a change, who decides, and how the consequences for planning and price are processed.
- Agree an escalation ladder: first discussion within the project group, then a steering committee at a higher level, then a mediator, and only then proceedings before the courts.
- Consider dispute resolution through the SGOA. Note one practical point: arbitrators can only hear a case where the parties have conferred jurisdiction on the foundation in advance, so that clause must be in the contract. The SGOA makes model clauses available for this.
An escalation ladder ensures that conflicts are discussed at an early stage and at the right level, rather than only once relations have broken down. For situations where a project stalls at a critical point and one party will not cooperate, the SGOA's arbitral summary proceedings offer swift relief.
In closing
A failed software project is rarely the result of a single mistake. It usually arises from a combination of unclear specifications, changing wishes, technical underestimation and poor cooperation. Dutch law offers a nuanced framework for establishing who bears the loss, through failure to perform, contributory fault and creditor's default, but applying it requires knowledge of both the law and the technology.
Is your software project stalling? Law & More advises clients and suppliers on liability, project records, contractual prevention and dispute resolution. Contact us for an assessment of your contract and your project file.
Frequently asked questions
Below we answer the questions we are asked most often on this subject.
Is my supplier liable if the software project fails?
Not automatically. It must be established that it did not deliver what was agreed and that this is attributable to it. In practice, responsibility is often shared between both parties.
What if, as the client, I contributed to the delay myself?
The court may then reduce the supplier's obligation to compensate under Article 6:101 of the Dutch Civil Code, in proportion to how far your own conduct contributed to the loss. That can lower an award considerably and, in exceptional cases, lead to its dismissal.
What does the duty to cooperate involve?
As the client you must supply specifications, test data, decisions and acceptances in good time. If that does not happen and the supplier cannot perform as a result, it does not fall into default and you may yourself end up in creditor's default (Article 6:58 et seq. of the Dutch Civil Code).
Why is an expert often appointed?
Because questions about architecture, source code and test reports require technical knowledge that cannot be expected of a judge. Under Articles 194 to 207 of the Dutch Code of Civil Procedure a court-ordered expert report can be commissioned, and its outcome weighs heavily.
Which project documents should I keep?
The contract with its annexes, the functional and technical specifications, the change requests, the project planning and progress reports, the test reports, the correspondence about delay and acceptance, and the source code with documentation. Without those documents an expert often cannot answer the question.
Why does a change procedure matter so much?
Without a formal procedure the assignment grows unnoticed while planning and budget stay the same. In a dispute it is then impossible to establish when and why the scope changed. Record who may request a change, who decides, and how the consequences for planning and price are processed.
What is the point of acceptance criteria?
They establish objectively when a delivered component complies. That makes clear when payment falls due and largely prevents later argument about whether delivery was sound. Preferably tie them to releases or milestones with formal acceptance tests.
What happens to the source code on a restart with another supplier?
That depends on your contract. Without arrangements on release of the source code, on the intellectual property rights in the system built, and on any escrow arrangement, a restart can be considerably delayed. Settle this when entering into the contract, not afterwards.
What outcomes can proceedings have?
Partial rescission where only part has gone wrong (Article 6:265 read with 6:270 of the Dutch Civil Code), damages under Article 6:74, reduction for contributory fault under Article 6:101, and moderation under Article 6:109. Courts apply that moderation sparingly.
Can I resolve a dispute outside the courts?
Yes. The SGOA offers mediation, arbitration, arbitral summary proceedings, binding advice and expert reports, with industry practitioners as decision-makers. Arbitrators can only hear a case where the parties conferred jurisdiction on the foundation in advance, so include that clause in the contract.
How do I avoid a long-running dispute?
Work with phased contracts and acceptance criteria per release, agree formal acceptance tests before invoicing, record a change procedure, and agree an escalation ladder running from project group to steering committee, mediator and only then proceedings before the courts.
Do you have a dispute with an IT supplier, or would you like an IT contract reviewed? Our IT lawyers are happy to help.
