Delays in IT Projects and Delay Analysis

Mehmet Karakoc and Edward Williams give an overview of widely-used delay analysis methodologies in engineering projects.

Delay in engineering projects is not a new phenomenon. In Henry VI, when Reignier said ‘Defer no time, delays have dangerous ends’ he was definitely not worried about the impact of delay to IT projects, but he was nevertheless aware of the difficulties that delay can create. Whilst technology has advanced significantly and IT is now one of the fastest growing fields of engineering, the consequences of delay to projects remain a serious cause for concern. After all, ‘time is money’ and delays may inflict the most ‘dangerous ends’.

Given the impact delay can have on the costs and timings of major projects, it is hardly surprising that so many disputes involving IT projects involve delay in some way. In the 2016 International Dispute Resolution Survey, a staggering 61% of the Technology, Media and Telecommunication (TMT) companies surveyed considered that a perceived delay in performance of works and/or services was a ‘very common’ reason for IT disputes. A further 29% of respondents indicated that delay was a ‘somewhat common’ cause of such disputes.[1]

The purpose of this article is to highlight the issues associated with delay in IT disputes and the benefits of using delay analysis techniques to help resolve them.

The issue of delay to IT projects

The reasons for delays in IT projects will naturally vary from case to case. Common causes include:

  • scope creep;
  • badly defined system requirements and objectives;
  • ambiguities in the specifications;
  • technology advances during the execution of the project;
  • limited access to the customer’s existing systems;
  • lack of assistance by the customer;
  • lack of communication between the parties;
  • late and/or disrupted transition from the incumbent supplier to a new supplier;
  • poorly drafted contracts (eg responsibilities of the parties);
  • lack of meticulous testing plans to ensure quality;
  • incompetent interface management;
  • unrealistic programmes and inaccurate progress reporting;
  • insufficient qualified resources; and
  • poor project management.

Whatever the potential causes of delay, the parties involved in major IT projects will be equally concerned with the likely consequences of delay. This is particularly so given the frequency of delays to large-scale IT projects and the associated impact this can have on cost. These issues were highlighted by the results of a survey conducted by McKinsey & Company and the University of Oxford which looked at more than 5,400 IT projects. The survey found that 33% of the projects examined which had a budget of over US$ 15 million had schedule overrun and 66% of those projects were also exposed to significant cost overruns. A similar pattern emerged in another study conducted by the University of Oxford which highlighted that 28% of the large government IT projects examined required 47% more budget and 38% more time when measured against the project parameters set at the beginning of the projects. In particular, data projects (such as data warehouse and electronic data interchange) and software projects were identified as ‘high-risk’ projects.[2]

IT disputes and the importance of delay analysis

Almost without exception, when delays occur in IT projects the customer will want to recover any additional costs or losses associated with the delay from the contractor, either by way of liquidated damages or via claims for damages based upon the actual costs and losses flowing from the delay. The customer will also be concerned to ensure that the contractor remains obliged to deliver the project in accordance with a defined programme, rather than have time for completion put at large, and to retain the right to recover further liquidated damages or eventually terminate the contract in the event that further delays occur. The contractor on the other hand is likely to claim relief from its obligations to meet contractual deadlines, as well as seeking compensation for any additional costs incurred as a result of the delay. The likely success of these respective arguments will often depend upon a number of factors, including the factual cause of the delay, the terms of the contract between the parties and the application of any applicable legal principles (such as the prevention principle and rules relating to causation).

It is now common for complex IT contracts to include comprehensive extension of time clauses and liquidated damages regimes, ensuring that contractors can be held to account for delays for which they are responsible (whether by way of liquidated damages, service credits, general damages claims or termination rights), whilst being granted an extension of time for performance in circumstances where the project has been delayed as a result of the customer’s failure to comply with its obligations (or on the occurrence of other specified relief / force majeure events). The recent construction case of North Midland v Cyden Homes [2018] EWCA Civ 1744 examined such a particular extension of time clause and found it to be enforceable even though it was potentially inconsistent with the common-law prevention principle, and general principles of causation, by allocating full responsibility for a period of delay to the contractor notwithstanding the fact that the customer was also in delay at the same time, meaning the project would have been delayed by a certain amount irrespective of the contractor’s performance failures. This kind of forward planning at the contracting stage can help to clarify the parties’ responsibilities and the consequences of any delays, thereby reducing the scope for costly disputes if issues arise during project delivery.

Good contract management is also crucial when it comes to resolving IT disputes. Ensuring comprehensive records are kept can be key to proving what has gone wrong, the impact the relevant issue has had on the project, and that all contractual governance and notice provisions have been complied with in relation to both the issues causing the delay and any agreed remedial steps. As with careful contract drafting, good contract management can help reduce the scope for arguments as to the causes of delays and the status of the parties’ rights under the contract relating to such delays. The ability to demonstrate compliance with contractual governance, notice and remediation provisions will reduce the potential for the other party to argue that the terms of the contract have been varied, or important rights have been waived (whether as a result of a variation to the contract, a collateral agreement, or some form of waiver or estoppel).

However, no matter how carefully a contract is drafted, or how well the parties manage the contract, when a complex IT project is delayed there will almost inevitably be disputes as to which elements of the overall period of delay (and the overall costs associated with that delay) are attributable to failures by the contractor, failures by the customer, actions of third parties, events of force majeure, or the result of combination of these factors.  It can often be difficult to link a given period of delay to a particular causative event, making it incredibly challenging to allocate responsibility for the delay (or particular elements of the delay) under the relevant contractual provisions.

Given the complex factual matrix which can often surround IT disputes, expert delay analysis is often essential in order to establish responsibility for specific periods of delay. Indeed, early engagement with an expert delay analyst can help parties to understand more clearly their potential liabilities at an early stage and thereby facilitate the resolution of disputes without the need to pursue claims through litigation or arbitration. The remainder of this article focuses on the techniques used by delay analysts to unpick the causes and duration of delays impacting IT projects and to highlight the benefit of early engagement with such experts to help clarify thorny issues of causation and liability. 

Choosing analytical techniques

There are various techniques which may be employed to analyse the causes of periods of delay to IT projects and establishing the most appropriate technique to use in any given dispute can be something of a vexed question.

IT contracts are usually silent as to the specific methodology to be employed when conducting any form of delay analysis and limited assistance is to be gained from decided cases. Although a number of judgments in disputes in other fields of engineering, such as construction, provide a source of direction on the assessment of delay, disruption and extension of time entitlements, the guidance as to which specific analytical methodology should be used in different scenarios is, at best, high-level.

In John Barker Construction v London Portman Hotel (1996) 83 BLR 31, the method used by the defendant to calculate the extension of time due to the claimant was criticised on the basis that it was ‘an impressionistic, rather than a calculated, assessment’. The defendant should have carried out ‘a logical analysis in a methodical way of the impact which the relevant matters had or were likely to have on the [Claimants’] planned programme.’ The importance of a logical, methodical, calculated analysis was also stressed in Mirant Asia Construction v Ove Arup & Partners [2007] EWHC 918 (TCC), where the judge approved of the use of critical path analysis techniques based upon a proper mathematical analysis of the project programme but noted concern that ‘a number of witnesses were convinced, without the benefit of any such analysis, that they knew where the critical path lay’ (at [122]).

The clearest practical guidance as to the type of analytical techniques which should be used in delay cases can be found in Fluor v Shanghai Zhenhua Heavy Industry [2018] EWHC 1 (TCC), where it was recognised that different approaches to delay analysis could result in different answers. In that case, the judge held that a prospective analysis - in other words considering the critical path at any particular point in time as viewed by those on the ground at that time - is the correct approach when considering matters such as the award of an extension of time. However, in cases where the issues relate more to the historic cause of particular periods of delay, or the impact they had on other aspects of the programme and associated costs, some form of retrospective analysis is likely to be required.

Given the nature of the guidance to be gained from previous cases with regard to the appropriateness of specific delay analysis methods, and the fact that IT contracts are usually silent on which delay analysis techniques should be deployed, when a dispute arises the parties will often have a reasonable amount of leeway as to which analysis techniques to employ. When making this decision, as well as bearing in mind the guidance set out in the cases referred to above, it will be important to understand the contractual provisions relating to the assessment of delay, the nature of the services and the dispute, the project management methodology used by the parties, the time, tools and resources available to conduct the delay analysis, the quality and extent of the project records and programmes available for analysis, and the complexity of circumstances giving rise to the delays. Taking these factors into account, an experienced expert should be able to help identify the most appropriate delay analysis methodology for any given project. In essence, the approach to identification and quantification of the delay that has been suffered ought to be systematic, pragmatic and should reflect common sense. More importantly, the delay analysis method ought to be appropriate for the individual circumstances of the project.

Commonly used methodologies of delay analysis 

IT contracts, including software development and outsourcing, are akin to construction and energy contracts in terms of time obligations and programme management. Hence, delay analysis techniques that are widely used in these industries can be equally adopted to determine the delays in IT projects, perhaps with certain modifications to take into account the nature of unique IT issues and project methodologies.

Delay analysis techniques are typically classified in two categories; ‘prospective’ and ‘retrospective’ by reference to the assessment of delay impact. The prospective approach considers the future and seeks to determine the likely impact of a potential delay event on completion. The retrospective approach evaluates the historic events with a view to determining the actual impact of the events upon progress and completion of the works. When it comes to the determination of relative criticality, the critical path can also be established by a third approach which requires a contemporaneous assessment of the progress and delays as the delays arise or are mitigated during the course of the contract considering the changes in the execution strategy.

Whilst there is a plethora of subordinates to the conventional delay analysis techniques, almost all of them apply a critical path method and require a baseline programme and/or an as-built programme/data. A baseline programme is typically prepared and agreed prior to or shortly after the commencement of a project, representing a supplier’s planned intention for sequencing the works.  The most common delay analysis methods generally conform to the one of the following categories.

‘Impacted as-planned’

This is considered to be the simplest form of delay analysis and seeks to establish the hypothetical impact of a delay event(s) on the baseline programme prospectively. It requires a reasonably achievable baseline programme which is ‘networked’ and suitable for dynamic analysis (i.e. through using functionality of project management software). This method has limited scope for the disputes that occur at the later stages of the contract and it is often deployed where the delays in question happened at the outset of the project.

‘Collapsed as-built (or ‘but for’)

This method seeks to establish the hypothesis of what the completion date would have been but for the delay event. The starting point for this method is preparation of a detailed as-built programme. The activities are then ‘logic-linked’ to create a dynamic schedule retrospectively. Once the delay events are identified and extracted from the programme, the programme is rescheduled to determine whether an earlier completion date could have been achieved but for the delay event(s). There is an element of subjectivity with modelling of the collapsed as-built programme hence this methodology appears to give relatively more accurate results when it is used to assess the criticality of a potential delay event which occurred towards end of the project.

‘Time slice /snapshot analysis’

The time slice or snapshot method requires both a logic-linked baseline programme and a number of regular programme updates or as-built information captured regularly at different stages of the work. The progress and critical path is identified at the end of each time slice/interval contemporaneously and the extent of each critical delay incurred within each time slice is calculated retrospectively on the basis that the critical delays must be located upon the actual critical path of each time slice. Then, the causes of the delays are investigated forensically.

‘Time impact analysis’

This method establishes the postulated impact of a delay event on the programme prevailing at the time when the impact of a delay event was felt. This method requires a baseline programme and a number of updates of the baseline programme, ideally updated right before the occurrence of each delay event contemporaneously. Following measurement of the delay to the completion as at the inception data of the event (or as at data date of each update), the delay events are introduced to the programme updates and the delays to the completion are recalculated prospectively in order to find the difference between two sets of completion dates measured before and after the addition of the delay event to the programme updates.

‘As-planned v as-built window analysis’

Using this method, the focus is on establishing the incidence, extent and subsequent causes of delay through a comparison of the as-built dates against the planned dates shown in the baseline programme in manageable periods, ie windows. This method does not involve any major iterative computer calculations and is based on common sense – hence it is static. It seeks to determine the actual critical path contemporaneously and the causes of delay and/or mitigation to the actual critical path in each window are forensically investigated through factual analysis of the issues and actual progress information.

Case studies

The practical applications of a selected number of these delay analysis methodologies are illustrated below with a number of hypothetical case studies.

Case 1

A software developer was engaged to develop and supply software under a contract which stipulated payment of liquidated damages for the late completion of key project milestones. The system requirements and design parameters were well-defined under the contract so the developer prepared a baseline programme demonstrating provision of services in a linear manner with a fixed plan of works, known as ‘waterfall methodology’, including sequential phases of planning, analysis, design, development and implementation, testing and deployment.

After development of the prototype according to the functional specifications, at the approval stage of the functional specifications, the customer’s representative issued a Change Control Note instructing certain changes in the initially agreed customer requirements. Further, during the early days of the software development stage, a number of queries arising from the ambiguities inherent in the functional specifications were raised by the supplier and the customer did not provide the required clarification for a considerable amount of time.

Within the updated ‘networked’ baseline programmes of the developer, the key milestone dates did not appear to slip following these delay events. The service provider claims acceleration costs on the basis that it had significantly increased its resources to mitigate the impact of delay events whereas the customer contends that the foregoing events would not have caused any critical delay to the key milestones.

Solution: Considering that the as-built records prior to the delay events and regularly updated dynamic programmes are available, the time impact analysis appears to be a more appropriate methodology to demonstrate that the project completion would have been delayed, had it not implemented the mitigation measures.   

Case 2

A retailer entered into an agreement with a small IT outsourcing provider for the development of a bespoke IT system and the agreement included a transition phase from the current IT service supplier to the new supplier. The parties jointly prepared an achievable dynamic schedule before the commencement of the services. Also the contract required the service provider to notify the customer of any potential delay event as soon as practicable and provide an assessment of the likely impact of the delay event.

Prior to the new supplier taking over the operation of the service from the current supplier, the customer informed the new supplier that the taking over date would be delayed. It also advised that the access to the customer’s building would not be available at the weekends due to the recently increased security measures, although the agreed programme was prepared on the basis of 7 days/week calendar.

Hence, the IT provider now requests additional time for the completion of the services.

Solution: Given that no tasks have been undertaken as at the date of the events and delays are required to be assessed prospectively according to the contract, the supplier may consider using the impacted as-planned technique to request an extension of time if it needs a simple and cost-effective assessment at high-level.

Case 3

An IT supplier was awarded a contract to design and deliver software for a supply chain management system through an agile development approach (an adaptive system development lifecycle methodology that delivers development of the software in collaborative incremental phases known as ‘iterations’ or ‘sprints’) for a fixed price. The parties agreed to follow a number of iterations (an iterative development concept that provides a short time frame to deliver certain features of software and which allows incorporation of changes in ongoing cycles) to make the system ready no later than a fixed completion date.

The supplier prepared a detailed baseline programme identifying its planned intent and various contemporaneous records such as progress reports, correspondences and minutes of meetings were issued throughout the project, although the programmes were not updated regularly.

A number of concerns were raised due to various delay events, including lack of timely information by the customer, unavailability of the key personnel of the customer, allocating resources to capture the high number of non-functional requirements and slow progress of the software developer.

The developer delivered the software three months later than planned and sought to recover its losses associated with delay. The customer alleges that an element of the delay was attributable to the developer and the remainder of the potential customer delays was either concurrent or did not impact the critical path of the project and therefore it has an entitlement to recover liquidated damages.

Solution: It is relevant to assess the delays retrospectively as the project has been completed and the supplier has a claim for damages for breach of the contract. There is a dispute over the criticality and concurrency of the delays. Therefore, mindful of the availability of a detailed baseline programme, various as-built records and also in the absence of regular programme updates, an as-planned v as-built window analysis appears to be the most appropriate approach for the assessment of delays in this dispute.


Delays do indeed have ‘dangerous ends’ and, in the context of IT projects, they are often costly. The reasons for the delays may vary due to the unique nature of the IT projects and the prevailing lightning speed of technological evolution.

IT contracts generally provide remedies which contemplate interventions where the customer’s enforcement of liquidated damages, or other remedies for delay, would be unfair and unreasonable. However, regardless of the sophisticated solutions offered by the contracts, there will often be disputes regarding the cause and responsibility for the critical delay(s) when a complex IT project has schedule overruns. Delay experts and legal advisors experienced in IT disputes are likely to be able to assist in clarifying complex issues of causation and liability when resolving complex disputes related to delay and associated damages arising from that delay.

Whilst IT contracts often do not prescribe a certain methodology for the assessment of delay, a logical and methodical assessment of the cause and effect of the relevant events should be undertaken by the delay analyst. Indeed, a number of universally accepted delay analysis methodologies for engineering disputes are available for this purpose, which employ different means of assessing the delays.

In the absence of a coherent answer emerging from the contract as to the agreed method of delay analysis, it is recommended that all relevant factors of a dispute should be taken into account to decide on the most appropriate delay analysis methodology in each case and common sense should be applied in reviewing the multi-faceted factual matrix associated with the project delays.

Mehmet Karakoc is a Managing Director in the Forensic and Litigation Consulting team of FTI Consulting and acts as an expert on the matters of delay and scheduling with a particular focus on engineering projects.

Edward Williams is a Principal Associate in the Commercial Dispute Resolution team of Eversheds Sutherland, specialising in IT disputes and disputes within the TMT sector more generally.


[1] Pre-empting and Resolving Technology, Media and Telecoms Disputes, International Dispute Resolution Survey 2016

[2] Overspend? Late? Failure? What the Data Say About IT Project Risk in the Public Sector by Alexander Budzier and Bent Flyvbjerg BT Centre for Major Programme Management, University of Oxford 2012

Published: 2018-09-24T12:00:00


      Please wait...