Joanna Goodman reports on the SCL meeting of 19 October where Sir Vivian Ramsey, Head of the Technology and Construction Court, shared his perspective on IT disputes
The SCL meeting IT Disputes – A Judge's View, presented by Sir Vivian Ramsey, was originally to be held at the offices of Teacher Stern, but attracted such a lot of interest that it required a bigger venue, The Royal College Surgeons in Lincoln's Inn Fields.
Bill Molloy, head of the contentious side of Teacher Stern's technology and communications group, chaired the event and introduced Sir Vivian, who was called to the Bar in 1979 following a successful career in civil engineering and was appointed to the High Court Bench Division in 2005.
Sir Vivian began by explaining that just a tiny percentage of IT disputes actually reach court. He devoted most of his talk to analysing why IT disputes occur and how to avoid them, devoting only the last few slides to how they are handled in court. Here is a summary of the main points.
Navigating the minefield: procurement, performance, time and money
Most IT disputes relate to procurement and/or performance difficulties and issues over time and money.
Procurement issues arise from:
· urgency of IT projects – clients want systems up and running as quickly as possible
· the tendering process and contract – work regularly starts during contract negotiations
· clients' uncertainty – they are not necessarily IT-savvy and struggle to define their requirements
· IT providers' uncertainty – the solution is not defined at the start of the project
· false certainties relating to the work, cost and time – because neither party is clear about the scope and delivery of the project.
Performance issues relate to:
· clients' lack of IT knowledge and unwillingness to admit this
· scope - changes and scope creep, often related to the initial lack of clarity about client requirements
· implementation – did the solution meet the clients' expectations?
· poor quality/performance – in construction, it is easy to see immediately when one element of the job is not up to scratch; whereas with an IT project, problems with functionality and performance are not easily identified until the system is rolled out to users
· inadequate solution - fundamental defects, bugs, maintenance, patches and updates that can have consequences for other parts of the system - Sir Vivian gave an example of a banking system designed for a Middle East bank that only operated in US$.
Time and money create problems due to:
· lack of realistic milestones – unlike construction projects, where it is possible to define clear milestones, IT projects are difficult to break down into clear stages - approval processes can cause delay
· expenditure against progress – it is sometimes difficult to relate costs to a specific element of the project; monitoring and testing can take longer than originally anticipated, especially if it is necessary to adjust functions and processes; the go-live date needs to be a flexible horizon.
The IT procurement process is a minefield!
· Invitation to tender and response – especially when clients make vague requests for 'world-class' systems to help achieve a 'world-leading recognition'. These definitions create problems later! If the invitation isn't clear, the responses will be vague too.
· Letters of intent, which Sir Vivian believes should be banned, allow projects to start while the contract is still being negotiated.
· Contracts that ask the impossible are also asking for trouble! Sir Vivian quoted woolly statements referring to 100% availability, massive scalability and proven technology.
· Price – to some extent costs have to be estimated but, unsurprisingly, uncertainty relating to scope, time and price leads to disputes.
Lessons from the construction industry
IT projects have some synergy with construction and engineering projects, where staged tenders address the uncomfortable interface between urgency and uncertainty. The invitation to tender needs to include a clear general definition of the clients' requirements and the response needs a defined outline of the proposed solution. Interactive procurement involving the joint development of both the requirements and the solution helps to avoid or minimise misunderstandings.
Potential challenges to effective interactive procurement include uncertainty over the scope of the project; personal wishes of individual clients, who may or may not have sufficient IT expertise to direct the project; staff changes among clients and developers; difficulty in monitoring the status of the solution; and inability to assess factors that impact on the time and cost of the project until it is too late to do anything about it.
Minimising 'known unknowns and unknown unknowns'
An obvious way of avoiding disputes is to aim for as much clarity as possible in respect of functional and non-functional requirements (eg response times).
It is important to look at the requirements in the context of the solution and establish the best fit between standard off-the-shelf packages, framework applications and bespoke programming (which often creates difficulties later due to the need to interface with upgrades and new versions of standard products). Another key consideration is the ability to introduce systems that require new ways of working. Some providers are reluctant to address this, either because they have preferred solutions/suppliers or simply because they do not think to ask why a client works in a particular way, when by making minor changes they could use an off-the-shelf solution. It is therefore important to allow software solutions to shape the project, in that new developments in technology can improve the clients' operations.
Disputes arising from uncertainties around the work, time and price involved of an IT project can be avoided by assessing resources carefully. Sir Vivian referred to function point counting and estimating lines of code. Experience of similar projects is useful and, although the client may not have undertaken a similar project, there is always the option of employing a consultant with relevant experience.
It's about minimising the known unknowns and the unknown unknowns, quipped Sir Vivian, referring to the famous Donald Rumsfeld quote.
The core elements of the contract need to define an outline solution while accepting the concept of change. This means developing processes for dealing with revised scope and timing. When it comes to costs, it is worth negotiating a guaranteed price cap and agreeing gain and pain sharing between the client and the provider.
Secondary elements of the contract include notice clauses, limited liability and insurance bonds and guarantees and methods of dispute resolution. Sir Vivian believes that many IT disputes end up in court because the initial contracts pay too little attention to this.
Disputes that go to court
IT disputes are most common around the following issues:
· performance – inadequate solution, non-compliance
· delays, price and scope changing
· inadequate project management
· lack of cooperation or hindrance by clients
· unrealistic pre-contract promises by suppliers
· changing technology during the course of the project
· termination claims – there are more of these in IT than in any other sector.
Finally, Sir Vivian offered some insights into the judge's perspective on IT disputes and lessons learned, advocating better use of technology in the procedural aspects of IT disputes, notably acceptance of service by e-mail, electronic document management and e-discovery. In response to a question, he added that the court appreciated electronic submissions that included hyperlinks and were presented in a user-friendly way.
To minimise the likelihood of a dispute, Sir Vivian suggested engaging a technology consultant at the outset, to fill in any gaps in expertise and bring experience of similar projects to the procurement process.
Sir Vivian supported the development of a standard form of IT contract, similar to the standard contracts used in the construction industry. This would avoid many of the more common pitfalls that lead to litigation.
Expert evidence is critical in IT disputes, so it is worth checking the qualifications of expert witnesses.
Other questions related to analogies between IT and mechanical and engineering projects and the possibility of introducing adjudication; new roles in IT project management and project management education within the IT industry; agile methodology; standard wordings and clauses; and dealing with consequential loss.
Sir Vivian explained the issues with insight and clarity, and it was a useful summary but, as a technology journalist, I would have liked to have heard more about the contentious side, as opposed to a reiteration of the general disconnect between IT suppliers and their clients.
Joanna Goodman is a freelance business and technology journalist with particular expertise in legal and legal technology matters. She can be contacted via firstname.lastname@example.org