IT Project Delay: How a Technical Expert Approaches Delay Analysis

Introduction

Delay is at the centre of many IT project disputes. A system is delivered months or years behind schedule. The client contends that the developer failed to meet its contractual obligations and seeks damages for the late delivery, the cost of interim workarounds, and the business opportunities lost during the period of delay. The developer responds that the timeline was affected by factors outside its control: late decisions by the client, changes in scope, dependencies that were not provided on time, or requirements that were not adequately defined at the outset.

These competing narratives are common in technology litigation, and the court will need assistance in determining what actually happened, why the project ran late, and which party (or parties) bears responsibility. The technology expert’s role is to reconstruct the project timeline from the available evidence, identify the causes of delay at each stage, and assess the extent to which those causes are attributable to each party.

This article sets out the approach a technology expert takes to delay analysis in IT project disputes in England and Wales, the types of evidence that inform the analysis, and the practical challenges that arise in this area.

Delay analysis in the IT context

Delay analysis has a well-established methodology in construction disputes, where techniques such as as-planned versus as-built analysis, impacted as-planned analysis, and windows analysis are routinely applied to assess the causes and effects of delay on a project timeline. These techniques can be adapted for IT project disputes, but the nature of software development introduces distinct challenges that the expert must address.

Construction projects typically follow a defined critical path, with activities, dependencies, and durations set out in a programme that is updated periodically. Software projects may follow a similar structure where a waterfall methodology is used, with sequential phases for requirements, design, development, testing, and deployment. In these cases, the expert can apply established delay analysis techniques in a broadly comparable way, examining the planned programme against what was actually achieved and identifying where and why the timeline diverged.

Where the project followed an agile or iterative methodology, the analysis is more complex. Agile projects do not have a single baseline programme in the same sense. Work is organised into short iterations (sprints or similar), with scope and priorities adjusted at regular intervals. The concept of a critical path may be less clearly defined, and the relationship between individual work items and the overall delivery timeline is more fluid. The expert must adapt the delay analysis methodology to account for this, which may involve examining sprint plans, velocity data, backlog changes, and iteration reviews to reconstruct what was planned, what was delivered, and where delays accumulated.

In my experience, it is not uncommon for IT project disputes to involve projects that used a hybrid approach, combining elements of waterfall and agile methodologies, or that started with one approach and shifted to another as the project progressed. This can complicate the delay analysis, as the baseline against which delay is measured may not be consistent throughout the project lifecycle.

Reconstructing the timeline

The starting point for delay analysis is establishing what was planned and what actually occurred. This requires the expert to construct two parallel timelines: the planned programme (as it existed at the relevant points in time) and the as-built record of what was actually delivered and when.

The planned programme may be documented in a project plan, Gantt chart, statement of work, or contractual milestone schedule. In practice, IT projects may have multiple versions of the plan, reflecting revisions made during the project. The expert must determine which version of the plan represents the appropriate baseline for the analysis, and whether subsequent revisions were agreed between the parties or imposed unilaterally.

The as-built timeline is reconstructed from contemporaneous project records. These may include sprint or iteration records, project management tool data (from systems such as Jira, Azure DevOps, or similar platforms), meeting minutes, status reports, correspondence, commit histories in version control systems, and deployment logs. The granularity and completeness of these records varies considerably between projects. Some organisations maintain detailed records of progress against plan. Others have limited documentation, particularly where the project was managed informally or where project management tools were not used consistently.

Where records are incomplete, the expert should identify the gaps and indicate the degree of confidence that can be placed in the reconstructed timeline. In some cases, it may be possible to infer progress from indirect evidence (such as code commit dates or test execution records), but these inferences should be clearly identified as such.

Identifying causes of delay

Once the timeline has been established, the expert examines each period of delay to identify its cause. In IT project disputes, the causes of delay tend to fall into several categories, and it is not uncommon for multiple causes to be present at the same time.

Developer-side delays may include inadequate resourcing, poor estimation of effort, technical difficulties that were not anticipated or managed effectively, defects that required rework, or failure to follow the agreed development methodology. The expert assesses these by examining the developer’s performance against the plan, the quality of the work produced, and whether the developer took reasonable steps to manage and mitigate delays as they arose.

Client-side delays may include late provision of requirements or design decisions, delayed feedback or sign-off on deliverables, failure to provide access to systems or test data within agreed timeframes, or changes to scope or priorities that disrupted the development schedule. These are assessed by examining the obligations placed on the client under the contract and project plan, and whether those obligations were met in practice.

Scope changes can be a significant factor in IT project delay. Changes to requirements, whether formally documented through a change control process or informally agreed through correspondence or meetings, can affect the timeline in ways that are not always immediately apparent. The expert must assess whether changes were properly managed under the contract’s change control provisions, whether the time and cost implications were communicated and agreed, and whether the cumulative effect of changes materially contributed to the overall delay.

Third-party dependencies may also be relevant. IT projects can depend on external factors such as the availability of third-party software or APIs, regulatory approvals, or the performance of subcontractors. Where delay is attributed to a third party, the expert may need to assess whether the dependency was identified and managed appropriately, and which party bore the contractual risk for it.

Concurrent delay

A recurring challenge in IT project delay analysis is concurrency: situations where delays attributable to different parties overlap in time. The client may have been late in providing test data during the same period that the developer was behind schedule on development. The developer may have experienced technical difficulties at the same time that a scope change was being processed.

The treatment of concurrent delay is a matter of law (and the subject of ongoing judicial consideration), but the expert’s role is to identify, on the facts, whether concurrent delay exists and to present the analysis in a way that enables the court to apply the appropriate legal test. This requires the expert to examine each cause of delay independently and to assess, where possible, whether the project would have been delayed in any event even if one of the concurrent causes had not occurred.

Concurrent delay is not uncommon in IT project disputes, and the analysis requires careful attention to the chronology and the interaction between different causes. The expert should avoid the temptation to attribute all delay to one party where the evidence supports a more nuanced picture.

The baseline question

A threshold question in any delay analysis is whether the original programme was realistic. If the contractual timeline was unachievable from the outset, then delay measured against that timeline may not be a reliable indicator of fault on either side.

The expert may be asked to assess whether the planned timeline was reasonable, having regard to the scope of the work, the resources allocated, the complexity of the technical requirements, and the state of the technology at the time. This assessment should be made by reference to what was known or reasonably foreseeable at the date the programme was agreed, not with the benefit of hindsight.

Where the expert concludes that the original programme was unrealistic, this does not necessarily resolve the question of responsibility. It may indicate that the developer should have raised the issue before agreeing to the timeline, or that the client imposed an unreasonable deadline that the developer accepted under commercial pressure. These are ultimately matters for the court, but the expert’s technical assessment of the programme’s feasibility provides the factual foundation for that determination.

Evidence considerations

Delay analysis in IT disputes depends heavily on the quality and completeness of contemporaneous project records. The expert will need access to project plans and any revisions, sprint or iteration records, project management tool exports, status reports and meeting minutes, correspondence relating to delay events, change requests and their processing, and any notices of delay or extension of time claims made under the contract.

One of the practical challenges in IT project delay analysis is the volume of data involved. A project that ran for two years may have generated thousands of Jira tickets, hundreds of status reports, and extensive email correspondence. The expert must work through this material systematically to identify the events that caused or contributed to delay, and the analysis is necessarily document-intensive.

Solicitors should consider engaging a technology expert at an early stage to advise on what project records exist, where they are held, and what steps are needed to preserve them. Project management tools may be subscription-based, and access can be lost if subscriptions are not maintained. Development environments may be decommissioned. The earlier these records are secured, the stronger the foundation for the delay analysis.

Conclusion

IT project delay disputes require the expert to reconstruct what happened over the life of the project, identify the causes of delay, and attribute responsibility on the basis of the available evidence. The analysis draws on established delay analysis principles, adapted for the specific characteristics of software development, including the challenges posed by agile methodologies, evolving requirements, and the volume of contemporaneous project data.

In my experience, the matters that proceed most efficiently are those where contemporaneous project records have been preserved, the questions for the expert are clearly framed, and the legal team engages technical expertise early enough to shape the approach to delay analysis before the evidential picture becomes more difficult to reconstruct.