Errors & Omissions (Information Technology)

The purpose of this policy is to protect professional people against legal liability to pay damage to a person who has sustained financial loss / damages arising from their own professional negligence or that of their employees in the conduct of the business
Quote on
Request

Characteristics of a Typical IT Contract

  • Build software according to an agreed specification.
  • Install and test it within a certain time.
  • Charge a fixed price for the work.
  • Not to use code that infringes someone else’s copyright.
  • Not to disclose any of the client’s confidential information. 
  • Provide documentation and training to client’s employees.
  • Maintenance over a period of time.
  • Provide upgrades.

Understanding an IT Risk

It is not...
  • Based on perfect industry data – e.g. satellite launch.
  • Based on virtually identical risks – e.g. life.
  • Based on large volumes of risks to create virtually flawless rating – e.g. motor.
It is…
  • An emerging class with limited loss histories fragmented across many insurers.
  • Highly diverse in the nature of the risks as no two businesses are the same.
  • Highly subjective, with different underwriters taking a different interpretation on the same risk.

Features of a typical failed IT Contract

  • The problem Begins
The client says it wants a system and imagines a luxury product. The client’s requirements are poorly documented. The supplier’s glossy brochure is written in general “sales” language and promises a high quality product and service.

  • The typical response
The supplier hears the word “system” and imagines a simple solution, still good quality but much smaller and a lower specification than the client believes it is getting.

  • The rush to get started
Both are keen to get started, so work starts before requirements are properly documented, or success criteria are agreed.

  • Overdue and still not working
A later release of the software still has some bugs in it.  Again this is nothing unusual, and is normally resolved. However, the customer’s confidence in the supplier falls even further and their patience runs out.

  • The resulting delay
One year on and the poor requirements gathering at the start is causing progress to slow while some of the detail is worked out. The parties now start to argue about what was included in the original quote. Supplier wants more money to deliver the luxury model the client thought he was getting.

  • The loss of confidence
Customer begins to lose faith in the supplier because it truly believes it was clear at the start that the car should be a luxury model.

  • The unhappy compromise
They reach a compromise but the customer is now annoyed and the supplier is worried about the profit it will eventually make.

  • The “Buggy” first release
Tests on the first release of the software indicate a large number of bugs. Confidence plummets among the customer’s staff. Yet this is not so unusual. It is how the bugs are fixed that determines whether a claim will be made or not. A further long delay follows in which fixes are made to the software. The supplier is under immense pressure to fix quickly and at minimal cost to keep the client happy and maintain his profit margin.

  • The dying plea
Supplier asks for more money to complete the project. This time the customer refuses. Customer then terminates the project and claims damages for breach of contract. The alternative is that the client accepts the software late and deliberately fails to pay one or more invoices as compensation for the delay.

Enquiry

Download