Most technology disputes settle before the parties have a chance to fall out because they are typically catered for in the project agreement via specific clauses which govern the dispute resolution process during the life of the project.
However it is not always easy to foresee the issues that might arise in a project that could well run for many years, especially considering that nobody enters into a contract for services expecting to fail from the outset.
In very large projects there are typically many “disputes” being handled at any given time. These range from decisions about whether a piece of functionality is a contractual deliverable (as opposed to a change) through to a refusal to sign off a stage of the project due to test failures. Some of the most common themes are set out below.
The most difficult of dispute themes arises when expectations have not been properly mismanaged. Issues may lay dormant until a system enters User Acceptance Testing (UAT) and the “Users” essentially don’t like what they see. By this point a significant amount of work would have gone into a typical project, and relationships can break down very quickly because (a) the customer will feel they have paid huge sums of money for a product that has not met their expectations and (b) the supplier will feel that they have spent a great deal of time and resources producing that product to what they understood the specification to be.
Software defects or “bugs” present an immediate challenge. There are schools of thought that say no bugs are acceptable, and in some controlled applications this may be right. However with the explosion of software enabled products and the invasion of Microsoft, Apple and Google operating systems into such a variety of devices, it is no longer reasonable to suggest that software has to be free of defects in order to be fit for its purpose. This naturally generates a tension when it comes to gauging the acceptability of a new system and avoiding dispute.
Defects are often reported and subsequently categorized as “User Error”, and lack of training or appropriate documentation are common scapegoats once the user error is explained. Either way in a formal litigation, training and documentation are often difficult areas – with each side citing a strong argument that is typically difficult to assess. The supplier will say that the customer failed to devote sufficient time to training, was ill-prepared and did not select people of the right skillset. The customer will say the training was insufficient, was interrupted by defect fixing and unfinished commissioning and so on.
It is often delay itself that precipitates a termination on the grounds of repudiatory breach or a specific contract clause, but it is seldom delay that is the underlying problem. All technology contracts have to account for change, and most have to accommodate rectification and re-test. It is when these and other common elements combine in too great a volume that one side or the other terminates on the grounds of delay (either in delivery or in payment).
While the specific reasons for the instruction of an IT expert in commercial disputes may be many and varied, the common themes set out above recur time and time again in various guises.