Delays in IT Projects and Delay Analysis

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.

Conclusion

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.