IT project failure: Is your supplier owed a result or just an effort?

When an IT project goes awry, deadlines are not met or software does not function as promised, the crucial question often arises: what exactly could you expect from your IT supplier? After all, the legal reality of your contract must match the operational reality of the project. The answer lies in the distinction between a result commitment and an effort commitment, a qualification that determines liability and the burden of proof in a dispute.

The legal context: outcome versus effort

Belgian contract law, enshrined in Book 5 of the Civil Code, makes a fundamental distinction in the scope of contractual obligations. It is important to realize that not the entire contract, but rather each individual commitment within that contract (e.g., meeting a deadline, building a particular functionality) must be evaluated separately.

• Effort commitment (or means commitment): According to article 5.72 of the Civil Code, this is an obligation that obliges the debtor "to provide all the care proper to a prudent and reasonable person to achieve a particular result". The result itself is not guaranteed. As a client, you must prove that your IT vendor committed a professional default and did not act as a normally careful service provider would in similar circumstances. This is often a heavy burden of proof that in practice amounts to obtaining a court expert opinion.
• The result commitment: This is a commitment that obligates the debtor "to achieve a certain result." If that result is not achieved, then the supplier's fault becomes suspect. As a customer, it suffices to show that the promised result is not there. The supplier can only escape liability by force majeure to prove: an extraneous cause that cannot be imputed to him (e.g. a shortcoming of the customer himself).
• The warranty commitment: This is an enhanced result commitment. Here the supplier guarantees the result under all circumstances, including force majeure. The service provider knowingly takes on a risk that is not always within his control.

Court of Cassation decision: A question of fact

In a judgment of November 7, 2024 the Court of Cassation confirmed its settled case law. Although the case itself dealt with a hospital infection, the principle is generally applicable. The Court stated that when the law does not define the nature of an obligation, it is up to the court to determine whether it is an obligation of effort or of result.

To do this, the judge must review the common intention of the parties taking into account all the circumstances of the case. This assessment is a question of fact, which means that the Court of Cassation does not itself rule on it.

Legal analysis and interpretation: the aleatory element as a criterion

The ruling of the Court of Cassation highlights legal uncertainty: if a contract is unclear, the outcome depends on the court's interpretation. In the IT sector, the aleatory element (the degree of uncertainty) is often the decisive criterion.

When achieving a result depends on a essential aleatory element, one is more likely to assume a best-efforts obligation. One suspects then that a professional service provider would not want to commit himself to a result that he does not fully control. Factors that come into play here are:

• The complexity and experimental nature of the technology.
• The dependence on the customer cooperation (timely feedback, testing, decisions).
• Dependence on third-party systems, software or hardware.
• The vagueness or rather the precision of the specifications in the contract. The vaguer the requirements, the more difficult it is to guarantee a specific result.
• The presence of penalty clauses or service credits may in turn indicate an intent to achieve a result commitment.

What this specifically means for your IT contract

Abstract legal principles have major implications for practice. The qualification of commitments can mean the difference between winning or losing a lawsuit. A realistic contract aligns legal qualification with operational reality.

Service Level Agreements (SLAs).

An SLA is the textbook example of a result commitment. It imposes very precise and measurable performance. Nevertheless, the aleatory element is also best taken into account here. A good example is the distinction between:

• Response time: The time within which the help desk responds to an incident. This is entirely within the control of the service provider and is a pure result commitment.
• Resolution time: The time required to resolve the incident. This can depend on complexity, environment and external factors. Therefore, resolution time is often explicitly qualified as a best-effort commitment, requiring the supplier to act professionally to resolve the problem as quickly as reasonably possible.

Agile projects

The "agile" methodology, in which requirements are often vague at the outset and are refined incrementally in close collaboration, by definition lends itself to effort commitments. The end result is uncertain at the outset and depends on intensive interaction between the parties. The supplier commits to pursuing the best possible result within the given, evolving context like a good professional. It is crucial to support this with clear processes for acceptance and feedback.

FAQ (frequently asked questions)

What if our contract expressly calls a commitment a "result commitment," but in practice performance is highly uncertain?
In principle, the explicit will of the parties is decisive. A court can change the qualification given by the parties only if it is incompatible with the contractual terms themselves or with rules of public policy. Thus, an IT supplier who accepts an uncertain project as an obligation of result deliberately takes a greater risk. He can then only free himself by proving force majeure, for example, by proving that the failure was due to a customer's fault.

How is the nature of the commitment determined if our IT contract is silent on this?
If the contract does not specify anything, the court will try to ascertain the common intention of the parties based on the factual circumstances. As discussed above, the court will look at the level of uncertainty (the alea), the role of the client, the complexity of the contract and foreseeable risks. How the parties have anticipated sanctions (e.g., penalties for missing a deadline) may also be an indication.

Is a deadline in an IT project always a result commitment?
Traditionally, meeting a strict deadline without reservation is considered an obligation of result. However, if the feasibility of the deadline depends heavily on the cooperation of the customer or external factors, and the supplier has no control over this, a judge may rule that it was only a best-efforts obligation. It is therefore advisable to contractually associate deadlines with clear conditions and assumptions.

Conclusion

The distinction between an effort commitment and a result commitment is one of the most critical, yet often misunderstood, aspects of IT contracts. A careful and unambiguous contractual arrangement that aligns legal terms with the operational realities of your project is not a luxury but an absolute necessity to avoid disputes and financial losses.