Skip to content
← All expertise

IT Project Disputes

Disputes arising from failed or delayed technology projects are among the most common matters in technology litigation. I provide expert evidence on the root causes of project failure, delay analysis, and the allocation of responsibility between the parties involved. My work in this area focuses on tracing what went wrong, when, and why, drawing on project management records, development artefacts, and technical evidence to reconstruct the project timeline and identify the factors that contributed to failure or delay. My experience spans proceedings in the UK High Court, JAMS, LCIA, DIAC, and US proceedings.

What This Involves

Delay analysis in IT projects involves tracing the project timeline from inception to the point of dispute, identifying the critical path, and assessing where and why delays occurred. This typically requires review of project management records (including plans, status reports, sprint or iteration records, change requests, and correspondence), together with an understanding of the development methodology in use. In some cases, the methodology itself may be at issue, for example where an agile approach was adopted but the governance and documentation expected of a waterfall project were not adapted accordingly. The analysis must account for concurrent delays and shared responsibility, and avoid attributing fault on a simplistic basis.

Root cause investigation of project failure requires a systematic examination of the technical, organisational, and contractual factors that contributed to the outcome. In my experience, IT project failures are not typically attributable to a single cause. Contributing factors may include inadequate requirements definition, unrealistic timelines, insufficient resource allocation, poor change control, and breakdowns in communication between the parties. The expert analysis must identify and weigh each of these factors, distinguish between those that were within the control of each party, and assess their relative contribution to the failure. This requires careful handling of the evidence to avoid the application of hindsight.

In disputes involving multi-party responsibility, the analysis may need to address the conduct of the client (for example, in providing requirements, making decisions, and accepting deliverables), the vendor (in managing the development process, escalating risks, and meeting milestones), and any third parties involved (such as subcontractors, platform providers, or integration partners). I set out the analytical framework and the evidential basis for my conclusions in my report so that they are transparent and can be evaluated by the opposing expert and the court.

Typical Instructions

  • IT project and programme delay analysis
  • Root cause investigation of project failure
  • System integration and migration failures
  • Critical path analysis and concurrency assessment
  • Project management methodology evaluation
  • Change control and scope creep analysis
  • Agile vs waterfall governance assessment
  • Multi-party responsibility and contribution analysis

Representative Experience

Selected from anonymised matters.

  • Delay analysis in a government software implementation dispute, assessing project management methodology and root cause of failure.
  • Root cause investigation of a failed enterprise system migration, involving multi-party responsibility analysis across vendor and client organisations.

Related Insights

Related Expertise

Considering instructing a technology expert?

For a preliminary discussion about whether technology expert evidence may assist your matter, or to discuss the scope of a potential instruction.

Discuss an instruction