It’s hard not to be susceptible to good marketing, but when it comes to bringing in someone who claims to be an ‘expert’, they need to be serious about their claims.
Why? Because by representing themselves as an expert who can help your organisation surmount its challenges and achieve its objectives, the law implies very specific responsibilities upon them. Even if those responsibilities aren’t in the contract or the attached schedules. Better still (for you) it’s very difficult for said ‘expert’ to ‘contract out of’ these obligations, where the courts will take a dim view of such exclusions. So if you’ve ever found it difficult to delineate between responsibilities in IT project partnerships, this guide should help.
IT vendor responsibilities
-
Your vendor is responsible for ensuring that its service is fit for your intended purpose before they deliver it. For example, before contracting with you for the services and solution it provides, it must identify any material challenges it would reasonably perceive.
-
Your vendor must also validate your requirements before contracting with you. This obligation also rests with it for re-scoping of services. If challenges arise during implementation, your vendor cannot later state that your pre-contractual requirements were ambiguous, because it should have validated those requirements and asked you the ‘right’ questions.
-
Your vendor cannot expect you to validate whether its service and system offerings are appropriate for your requirements. The vendor must make clear what process it will go through itself, to validate whether it can meet your expectations (or not).
-
Your vendor cannot “contract out of” being responsible for its advice as an expert vendor.
These ‘vendor obligations’ are known as “implied” terms, under the Sales of Goods Act 1979, Supply of Goods and Services Act 1982 and the Sale and Supply of Goods Act 1994.
Where your vendor represents itself as a specialist in its field, recent case law shows that these implied terms are usually legally binding, regardless of whether they are actually in the written contract wording. If your vendor insists on contract terms that run contrary to one or more of the above implied terms, then you should ask them how serious they are about your relationship with them.
Your own responsibilities
Whilst your vendor has specific obligations to you, your organisation also has responsibilities to them.
The case of Anglo Group Plc v Winther Browne & Co Limited [2000] 72 Con LR 118, established some clear responsibilities on the client side. So case law shows that you’re both still responsible for maintaining a working relationship.
You need to:
-
Clearly communicate any special needs to your vendor. Although it is up to the vendor to ask you the right questions during its scoping exercise, if you become aware of issues it might have missed, you are obliged to raise this.
-
Take reasonable steps to ensure that the vendor understands those needs.
-
Devote reasonable time and patience to understanding how to work with your vendor.
-
Reasonably work with your vendor to resolve the challenges that will almost certainly occur.
The diagram below summarises your vendor’s responsibilities and how you need to behave, to ensure you do not erode their ‘expert’ responsibilities
Taking on the mantle, by accident.
Another critical but often unappreciated factor is that your on-the-ground behaviour can affect whether the vendor has to (or in fact is able to) abide by its contractual responsibilities. Your client side team will often operate project management frameworks (such as PRINCE2) and contract management processes, to support and measure the implementation’s performance. However, vanilla project management frameworks usually only take account of the project’s operational aspects, not your vendor’s expert responsibilities. In contract law this can result in the majority of your contractual protection being eroded without you realising it.
Ironically, this problem arises because your project managers try to do the right thing from a project management perspective and take control of the errant relationship but in doing so, they metaphorically tie the vendor’s hands behind their back, eroding the vendor’s ability to act on its expert responsibilities from a contractual point of view.
Worse still, the client side project manager ends up becoming the ‘implied expert’ themselves. This is because they have tried to fix the problem themselves or change the functional requirements, instead of managing the vendor to do so. If this happens, your own behaviours have to be changed to be able to rely on the vendor’s expertise for the delivery of your IT project. If you don’t change your own behaviour and instead you insist on ‘taking control’ of the vendor’s activities, the vendor can then attempt to charge you for every change to its solution, irrespective of whether it caused the problem.
Other behaviours that can remove your vendor’s responsibilities include:
Ignoring the vendor’s advice
Not following the issues escalation process documented in the contract
Agreeing to changes outside the contract
Dealing directly with sub-contractors
Senior management interference.
More effective transparency of responsibilities
By being clear about the business outcomes you expect once the system has been implemented, you can significantly accelerate the process of realigning the project implementation and rebuilding trust with your IT vendor. This gives the vendor a fair chance of re-evaluating your business expectations and you can contractually rely on the vendor’s advice, in line with their expert responsibilities.
In this respect, it’s important that as part of the scoping phase, you contract for your vendor’s advice separately to the solution it will deliver. The vendor at this stage should be flying a flag, explaining that they need to complete a due-diligence exercise so that they are certain of your requirements. This will avoid the inevitable issues when further misunderstandings arise, with you perceiving that the vendor is failing to deliver and the vendor claiming that you held back information or miscommunicated an important deliverable or objective. If the responsibilities of the vendor, or your own, are unclear in your project, then this may be one of the root causes of your problem.
Summary
Your vendor, as the ‘expert’, has important responsibilities to you that are implied in law, even if they are not detailed in the contract terms or attached schedules. You need to understand these responsibilities and ensure your organisation behaves in the right way, so you do not erode them and inadvertently take on the aspects of their ‘expert’ role yourself.
Your organisation also has responsibilities to the vendor, for example to tell it if you become aware that it has overlooked issues during its due diligence exercise(s). It is up to both you and your vendor to maintain the correct balance in your working relationship.
During any re-scoping or realignment exercise, it’s important that you contract separately for your vendor’s advice and for the solution it will provide. This will ensure that (a) your vendor has the opportunity to advise you in a more fit-for-purpose manner and (b) you can rely on its ‘expert responsibilities’ in a much more straightforward fashion.
