IT customers are increasingly successfully invoking the “duty of care” owed to an IT provider in IT disputes. The weight that courts give to the duty of care is increasing and the scope of application is widening. An IT customer is regularly awarded damages because the IT supplier failed to comply with its duty of care. As an IT supplier, it is therefore good to have an idea of what this duty of care entails. This is a very multifaceted and dynamic subject which cannot be discussed in full within the scope of this article. However, because of its increasing importance, we nevertheless outline below the developments in case law in this area.
Duty of care
The duty of care has its origins in the law: the contractor must exercise the care of a good contractor in his activities. In addition, the duty of care is often explicitly included in IT agreements. It then states that the IT provider must perform its services in a careful and professional manner. In case law, this duty is laid down in the general standard that an IT supplier must act in accordance with the care that may be expected of a reasonable and competent IT supplier. What specific obligations follow from this standard?
What may the customer and the IT supplier expect from each other?
The IT supplier’s duty of care is largely based on the knowledge gap that the average customer has compared to the professional IT supplier. This knowledge gap occurs as early as the purchase of an IT system and associated services. The sales process plays a major role in the expectations a customer has and may have, because the customer may trust the IT supplier’s expertise and statements.
A professional IT supplier should recommend and deliver an IT system that meets the expectations that an average customer may derive from it. In connection with this, the IT supplier must investigate before concluding an agreement whether the IT solution it offers fits the customer’s business processes and whether there are any missing functionalities that the customer needs. This is called the obligation to investigate. If there are missing functionalities in the software that the customer probably expects or needs, the IT supplier must report this during the sales process. If he does not, the customer may expect those functionalities to be present, even if those functionalities have not been specifically agreed upon. So there is also a duty of information on the IT supplier.
Then, when making the offer, the customer must be informed about the work required and the time involved which is then translated into a realistic planning and budget. If a customer sets a certain (fatal) deadline that the IT supplier knows in advance may not be achievable, then a caveat for meeting that deadline is appropriate.
The duty to inform also plays a major role during the implementation process. Think about adequately informing about progress, achieving milestones and cost control. Disputes over the invoiced work include whether the invoices match the quality and progress of the work. This includes the objectives of the implementation agreement. A judge also wants to know how an overrun of the budget occurred. During the implementation process, a finger must be kept on the pulse in terms of additional work requirements. This involves more than following the agreed extra work procedure. Indeed, the customer must be made explicitly aware of the consequences of extra work requirements for planning, budget and the end result. After all, the customer cannot always oversee the consequences of change proposals. There is therefore an obligation to warn the IT supplier: if necessary, the IT supplier must repeatedly and clearly warn if the customer is in danger of making a mistake in this area. If it turns out that continuing the project will only cost money and no longer bring any direct benefit to the customer, it is important to point this out to the customer. In exceptional cases, the IT supplier should then even push for suspension or termination of the cooperation.
The law offers the IT supplier a way out when there are manifestly unworkable wishes. The IT supplier may terminate the agreement if the customer’s wishes are so unreasonable that the IT supplier cannot be expected to go along with them (any longer). Usually, terminating the cooperation in the middle of the project will not be an obvious step. Nor should an IT supplier simply terminate its services if the software is essential to the customer. This creates a tricky area of tension. In the event of an impending escalation, the customer can at least be reminded that the IT supplier is not obliged to (continue to) go along with unworkable wishes. Judges also seem to expect this from IT suppliers in certain cases. This is all the more true if the project management lies with the IT supplier. If project management rests (entirely) with the customer itself, this is more nuanced.
Under circumstances, poor project management can justify termination of the contract by the customer. Apart from actively monitoring the customer’s wishes and their consequences, good project management also includes urging the customer to move forward if it does not proceed with sufficient speed. Warning about infrastructural problems and incorrect use of the software, if they get in the way of improving the software’s performance, are also part of the IT supplier’s duty of care.
Finally, in case of problems in performing tests, a customer will have to be adequately guided. After all, the proper execution of tests is very important for the success of the project.
When it comes to software security, the IT supplier also has a duty of care. In a previous article, we already pointed out that an IT supplier must intrusively and repeatedly warn about the risks when a customer does not want to pay for security measures and may even have to refuse the order. However, the customer himself is considered responsible for using sufficiently secure passwords, as long as the IT supplier has pointed out their importance.
Only a responsibility for the supplier?
It sometimes seems that the responsibility is placed entirely on the IT supplier. This is not entirely correct. Judges also expect project discipline from customers in the sense that they adhere to the project plan and the agreements made therein on the division of responsibilities and tasks. In addition, customers can be expected to follow advice from the IT supplier. Furthermore, customers are expected to raise the alarm in good time if things do not go as agreed or if the project is in danger of getting out of line.
The weight given to the duty of care also depends on individual circumstances. Among other things, it depends on whether advice is given on the software to be implemented and whether software is being developed. The weight of the duty of care also depends on the scope of the assignment and the likelihood of damage in the event of failure of the project. The IT supplier’s duty of care is (somewhat) relativised when the customer is assisted by an expert, because then the customer is less likely to have a knowledge deficit. Agreements can also be made in the agreement itself that (somewhat) relieve the IT supplier’s duty of care. This concerns, for instance, the stipulation that there are best-efforts obligations and the agreement that project management and testing are the (full) responsibility of the customer. Nevertheless, this cannot wipe away the duty of care. The duty of care is there, only its weight can be nuanced by means of a good contract.
The consequences of breach of the duty of care can be significant. If the duty of care is not complied with, the contract may possibly be dissolved. Without agreements on this in the contract, this means, at worst, that all invoices paid will have to be repaid. In addition, damages can also be claimed, which can be substantial in the absence of a (proper) limitation of liability.
Conclusion and practical tips
Both in the preliminary phase and during the IT project, the IT supplier has a duty of care. In case law, we mainly see the duty to investigate, the duty to inform and the duty to warn in different situations and degrees. Their weight depends, among other things, on the IT expertise a customer has in-house, the content of the assignment and the agreements made between the parties.
Given the increasing importance of the duty of care, it is important to be aware of this, but also to carefully document that the duty of care has been met:
In presentations/demos about the software, also make it clear what the software cannot do. Also document this in the agreement.
- Make clear agreements on the roles and tasks of those involved and indicate what is specifically expected of the customer.
- Stay in control over additional wishes and follow the agreed procedures.
- Document advice and alerts on customer requirements/decisions, project progress and security measures. Collect this documentation in one place.
- Be open to feedback from the customer and see this as an opportunity to evaluate the processes and possibly get an escalating project back on track.
This article was written by Annemarie Bolscher and was previously published as an expert contribution in the IT magazine AG Connect.