Good planning, preparation and management are essential to the successful completion of a project on time. However, the law, through the enforcement of contractual obligations, can assist the parties to control time and minimise delay.
A well prepared contract will provide the parties with a readily understood framework in which to work. A less well prepared contract will stay in the bottom drawer of the project manager’s desk and the life of the project may bear no relation to the contractually agreed procedures. A contract should therefore encourage good planning, preparation and management by providing the core of the management procedures that will be used on the project.
Plans and Programmes
IT contracts often append a high level project plan as a schedule to the contract. However, in order to be of any benefit, the plan must be more than simply a sequence of events fitted to the overall desired time horizon. It should reflect an analysis of the project by identified tasks, with dependencies stated and a critical path identified.
The critical path is defined as “the sequence of activities which needs the longest total time to complete the project or an element thereof”. A delay to an activity on the critical path will therefore cause delay to completion of the project.
The use of dynamic critical path methodology (CPM) was developed in the 1950s in the
The plan appended to a contract is only a snapshot. In order to be effective as a management tool it must be dynamically and contemporaneously updated to track progress and to identify the impact of change. The contract should therefore require the supplier to update the project plan by reporting progress and identifying delay or the impact of change.
Notices and Early Warning
Potential delay can be addressed if both parties are aware of the risk that it might occur. One method of managing the impact of such delay is to require the project managers (for both the supplier and the customer) to give early warnings, notifying the other as either becomes aware of any matter which could (amongst other things) delay completion. Once such notice has been given, the parties can attempt to address the potential delay by making proposals or seeking solutions to alleviate its impact. In order to give teeth to such a provision, it can be a precondition that such early warning is given for the supplier to receive an extension of time.
Change Management
The effect of changes to a project can be a significant contributor to any delay in overall completion. A customer must have the ability to make changes but ultimately the customer wants certainty as to the time and cost risks of such change. The contract must therefore provide a clear change control methodology under which the customer can request changes and the supplier is then obliged to provide a binding quotation for the requested change. Suppliers may resist the imposition of an obligation to respond to change requests on the basis that it can divert resources from the delivery of the project but it is always open to a supplier to provide a two-stage response – with the initial response stating the time and cost involved in producing a full detailed response.
Liquidated Damages
Liquidated damages are one of the most common contractual devices for encouraging timely completion. The prospect of having to pay significant liquidated damages acts as an incentive for the supplier to keep to the planned dates.
In order to be enforceable, liquidated damages must be a genuine pre-estimate of potential loss and not an arbitrary sum payable in the event of delay, ie a penalty. A customer must therefore make some attempt to calculate its potential loss in the event of delay. Often, though, it can be commercially unreasonable to impose the true likely loss and the amount specified as liquidated damages is less than the real potential loss. If no attempt has been made to estimate the potential loss, the customer runs the risk that the liquidated damages will be considered a penalty and therefore unenforceable.
Further, it would be unjust for a customer to be able to claim liquidated damages where it is responsible for the delay (the so-called prevention principle) and the courts have refused to enforce liquidated damage provisions in such circumstances. In order to avoid the application of the prevention principle, the contract should allow the time for completion to be extended in such circumstances.
Time and Extension of Time
In the event that a supplier is delayed by something within the customer’s control then, in the absence of any specific provision, the customer can no longer insist that the supplier complete by the contractually agreed date. The effect is that time is said to be “at large” and the supplier’s obligation is to complete within a reasonable time. However, this effect can be avoided if the contract provides a mechanism for the extension of time.
Extension of time clauses are as much for the benefit of the customer as they are for the supplier. They do not prevent or reduce delay but assist the effective management of such delay. The ability to extend time not only preserves the right to claim liquidated damages but allows the customer contractual certainty as to the date for completion.
Acceleration
Acceleration is common in the construction industry but can usefully be applied to IT projects. If completion is going to be delayed (whichever party is responsible) then it may be appropriate for the contract to permit the customer to require the supplier to accelerate progress, usually by applying additional resources in return for additional remuneration. This can be achieved through change control.
The Consequences of Delay
In the event of delay, customers may seek to recover liquidated damages or suppliers may seek extensions of time or additional costs caused by the delay. In the first case, the supplier may argue that it should be entitled to an extension of time sufficient to prevent liquidated damages being triggered. Whatever the circumstances, it is essential to be able to identify the cause of the delay and the impact it had on the contractual date for completion.
Relatively recently it appears that the courts have accepted that the most appropriate way in which to establish the cause and effect of delay is through the use of critical path methodology. The important questions to be answered are: (i) is the delay on the critical path? (ii) if so, is the delay caused by the supplier? If the answer to the first question is yes and the answer to the second question is no, then the supplier should be entitled to an extension of time.
The Importance of Records
Managing the risk of delay also requires competent reporting against a project plan, for which the maintenance of reliable and appropriate records is essential. At first glance, it appears that it should be simple to prepare a record of what was done, when it was done and what resources were used. However, project teams often do not implement and subsequently maintain a rigorous regime.
The use of carefully prepared and accurate records will lead to early identification of issues and should encourage an early solution. Furthermore, the careful retention and management of records will help the process of analysis should a dispute arise and a retrospective assessment of delaying events be required.
The nature and format of the resource based records appropriate for any particular project will differ depending on the contractual provisions in force. The records must fulfil the demands of the contract, provide adequate information for managing delays and, ideally, be able to demonstrate a causal link between changes and the effect to the project plan.
Post Contract Forensic Analysis – Calculating and Analysing the Effects of Change
Good project management and effective record keeping will minimise the risk of disputes as to time. However, if a dispute should arise, delaying events must be resolved retrospectively. A number of options are available to demonstrate disruptive effects of changes on the timing and cost of the project, using CPM analysis. Four such options are explained below.
As Planned -v- As Built
This is the only method which, although often used with CPM, does not actually require a CPM network. It was the method used prior to the development of CPM and, as the title suggests, its origin is in the construction industry.
The method requires the planned programme and completed programme (as built) to be established. The two programmes are then compared in order to identify an effect on progress, from which a cause can be inferred. It is then also inferred that the delay to progress has caused the delay to completion. See Figure 1.
The disadvantages of this method are that it is borne out of hypothesis and inference and does not distinguish between critical and non-critical events. In situations where both parties are to some degree at fault, the analysis will be alleged to support both.
As Planned Impacted (API)
This is the only analytical method that does not require progress records. The method requires the original planned project programme or critical path network to be established, the time and sequencing of changes to be estimated and the activity in the project plan affected by those changes to be identified. Once that has been done, appropriate links and activities to replicate the effect of the changes can be inserted into the project plan and the plan may be rescheduled to identify any shift in the completion date for the project. The difference, if any, between the completion date before and after the impacted event represents the period of delay that could reasonably be attributed to the change. See Figure 2.
As with As-planned v As-built, this method is reliant upon theory: it assumes that the planned programme was realistic and achievable from the beginning and that the project ran according to plan, with the exception of the delaying events. If records are available to identify when activities were carried out, the change in durations and sequencing of activities will be available, and will almost certainly show the basis of the analysis to be false.
On the other hand, the API is a reasonable methodology to adopt if the delaying events have occurred at the start or soon after a recovery plan has been implemented and where the plan can be considered an accurate representation of the intent of the supplier at that time.
As Built But For
The as-built but for method (ABBF), sometimes referred to as the “collapsed method”, is another impact technique and can, when properly used, identify the effect of a causal event. The method comprises establishing the as-built programme (as described above), identifying the logic followed in the project, identifying the delaying activities and linking these into the programme. If the duration of the delaying activities is then reduced to zero, the completion date but-for the missing activity durations represents the effect of the delaying activities. See Figure 3.
One of the most difficult aspects of this methodology is that identifying activities and logical links retrospectively is a subjective process. It is possible, but difficult, to achieve where detailed records of project activity exist. Like the above methods, this method does not examine periods of re-sequencing or acceleration. However, it does examine the impact on the ultimate critical path.
Time Impact Analysis (“TIA”)
TIA is a rigorous analysis and is the most appropriate method for contemporaneous analysis and, arguably, the most comprehensive method for retrospective analysis.
TIA first requires the project plan to be identified and the relevant records and documents gathered together. A chronological list of events thought to have caused delay can then be compiled, together with supporting documentation. The project plan is then updated and re-analysed for each such event, using the progress records for the date, or just prior to the date on which the delaying event occurred. Sub-networks (sometimes referred to as ‘fragnets’) representing the delaying event are then introduced into the updated project plan and it is rescheduled. The difference between the end dates before and after the introduction of the sub-network represents the likely delaying effect of the occurrence assessed. See Figure 4.
The sequence involved in carrying out this type of analysis is similar to the API analysis. However, the important difference is that the progress achieved, and any re-sequencing before the event occurs, is used to recalculate the likely completion date for the project. The effect of a specific occurrence can then be determined by the shift in the completion date before and after the introduction of the delaying event.
Concurrent Delays
One common difficulty in the analysis of delay is the situation in which there are two concurrent delays, one of which is the customer’s risk and the other is not. Whether a supplier is entitled to an extension of time in such circumstances should be provided for in the contract. In the absence of express contractual provision, it is likely that the supplier will be entitled to an extension of time for the period of delay caused by the event that was at the customer’s risk, notwithstanding the concurrent effect of the other delay event.
Conclusions
A well prepared contract with appropriate time and costs control mechanisms can assist the parties to manage time and costs over the life of a project. Equally important, however, is the use of project planning methods such as those described above.
It is in the interest of suppliers to ensure that clients are provided with up-to-date and accurate information on progress of the project. The use of TIA throughout the life of a project can demonstrate both the current position and the effects of change requests on overall completion, reducing the chances of later disputes.
In the event that disputes do arise, the use of the above methods may help to demonstrate the reasons for the project completing later than originally planned, which should in turn assist the early resolution of such disputes.
Jonathan Westwell is a senior associate in the IT/C group of Baker & McKenzie.
Stuart Wilks is an associate director of Pickavance Consulting Limited, specialists in risk management, change management and the analysis of delay and disruption.
Keith Pickavance of Pickavance Consulting will be speaking on the principles and policies in the analysis of delay in IT projects at the next meeting of the SCL Disputes Group. The meeting will be held at
