The Daily Delay Measure: Maintaining an As-Built Programme for Construction Disputes
The daily delay measure (DDM) is an as-planned versus as-built technique used to compare the planned performance of a project with its actual progress.
By tracking each activity over time, it builds and maintains an as-built programme that records how delays and the critical path evolve as the works proceed. Although developed for forensic delay analysis, it can also support related methodologies, including “collapsed as-built” and “windows.” In essence, DDM measures delay against the baseline programme and identifies when one activity displaces another on the critical path.
DDM compares the planned dates in the original baseline programme with the actual start and finish dates of the same activities. It assumes that the baseline programme is reliable, complies with the contractual requirements, and accurately reflects the intended sequence and duration of the works. In some circumstances, the analyst may need to adjust an earlier programme by removing subsequently added activities or stripping out recorded progress so that it more accurately reflects the original plan.
Why DDM is a better way to maintain a programme
Conventional programme updating is essentially a re-forecast. Progress is recorded and the scheduling software recalculates the remaining work and a revised completion date, projecting the programme forward from its current status. Because the focus is on predicting the future rather than recording the past, that process can absorb or move past earlier delays. DDM works the other way: it compares the planned dates against the actual start and finish of each activity, step by step, so that the programme becomes an as-built record of what occurred rather than a rolling prediction.
Two advantages follow. First, DDM captures how the critical path migrates as the works proceed — one activity displacing another — which a forward-looking update tends to obscure once its logic is re-baselined to fit current status. Secondly, because the method is anchored to actual dates and contemporaneous records, it is more difficult to manipulate and the analyst’s reasoning is exposed and able to be tested. As noted above, ordinary programme updates may be adjusted to emphasise or obscure activities, or simply updated incorrectly; an as-built measure built from real events is far harder to massage.
Maintaining the programme in this way also produces a stronger evidentiary base. By rebuilding the actual timing and reading the float, DDM distinguishes concurrent, staggered, near-critical and truly critical delays more objectively than a comparison of successive projected dates, and it ties each delay to identifiable events as they emerge. That makes it considerably more useful than a conventional update when an extension of time, or a question of responsibility, later falls to be determined.
The method is, however, more labour-intensive and depends on expert judgment, which is why it is not how most contractors run day-to-day programme control. Its strength lies in maintaining an accurate as-built record and in resolving disputes — the purpose with which this paper is concerned.
Identification of the critical path
The daily delay measure identifies the critical path by comparing planned dates with actual dates on a step-by-step basis from project commencement to completion. Expert judgment is required to determine the true critical path, particularly where the baseline programme contains defective logic or where the sequence of the works changed during the project.
Because the analyst determines the critical path, DDM is sometimes criticised as being overly dependent on professional judgment and not readily reproducible. However, where that judgment is informed by expertise, grounded in a careful review of the programme and the underlying facts, and supported by detailed analysis of actual events, it may yield a more accurate result than a purely mechanical reliance on programme logic or computer modelling.
The use of DDM also reduces subjectivity and makes the analyst’s reasoning more transparent. The analyst’s task is to identify the actual events that governed the project’s progress, even if those events were not recognised as controlling at the time. As this may differ from contemporaneous programme updates or the recollections of project participants, the expert must test all available evidence before reaching a concluded opinion.
Programme updates are not invariably reliable. They may be adjusted to emphasise or obscure activities, or they may simply be updated incorrectly.
As the project progresses, the logic of the programme also changes to reflect events that have already occurred. Where those changes are material, the analysis should proceed with reference to a new or re-baselined programme. In any event, DDM seeks to identify the as-built critical path. That path begins with the original project logic and then accounts for actual changes to the sequence of the works and ordinary departures from the plan. Ultimately, the critical path is determined by what in fact occurred, rather than by what was originally expected to occur.
Identification of responsibility
DDM requires expert evaluation of facts if a determination as to culpability for delays along the critical path is to be made. The analyst should review the events on the critical path, identifying delay events, and determining the reasons for the delay. While the mechanics of quantifying delay may vary slightly between methodologies, the process of determining responsibility is largely identical.
The role of concurrency
Concurrency is often important in delay disputes, so it is useful to identify multiple critical paths where they exist. DDM can do this. By rebuilding the actual timing of events and confirming the programme dates, the analyst can identify the critical path or paths and the delay affecting each one by looking at float. This helps show which delays are concurrent, staggered, near critical, or truly critical, with less subjectivity than relying only on projected dates. Even so, the expert may still need to form a final view on what was driving the critical path at a given time and by how much. That judgment is often criticised, but similar judgment is required in other delay analysis methods as well.
Under DDM, the expert’s role is more visible because the method relies less on technical modelling.
Contract Management
A daily delay measure is only as reliable as the records on which it is built. Because DDM reconstructs the as-built programme from what occurred on site, its persuasiveness in a dispute depends on the contemporaneous records, programmes and correspondence the parties keep as the works proceed. Sound contract management is therefore the foundation of any credible delay analysis.
Preparation for disputes
Effective contract managers anticipate disputes by maintaining sound records and complying closely with contractual procedures from the outset.
Typical checklist items include:
Identify all contract documents. If there is uncertainty about which documents form part of the contract, seek agreement on that issue early.
Review the contract carefully or obtain advice from someone suitably qualified. Prepare a procedural checklist identifying the steps required for each relevant issue.
Ensure that relevant personnel understand their roles in each procedural step and, where possible, confirm those responsibilities in writing.
Hold regular meetings to review progress, plans and programmes. Record the outcomes and monitor progress against the programme of works. The programme manager should keep a basis of schedule document updated and maintain a “live” as-built programme. A “live” as-built programme means a programme that is not updated using actualised dates in the planning software. Rather, activities and logic are added or modified to reflect changes and delays. This means that an as-built critical path is preserved.
Ensure programme acceptance from the principal. Test the programme of works internally. Detail high risk activity networks as a priority (rolling wave), ensure procurement marries up with contract administration (CA) procurement registers. In my experience, this represents a common delivery disconnect, where contract administrators procure plant and equipment based on an out-of-date programme.
Maintain clear photographic records of the site and the works in progress. And organise the photos by work package or delaying event.
Address emerging problems promptly. Issues are usually easier to manage when dealt with as soon as they arise.
Communicate openly with the superintendent about delays and programming issues to help avoid protracted disputes.
Programming and Extensions of Time
DDM requires a reliable baseline programme and a clear understanding of the critical path. This section explains the programmeconcepts that support DDM, including how projects are programmed, how critical activities are identified and how extensions of time are typically assessed prospectively, and how they can better be assessed retrospectively using the DDM method.
The typical EOT claim process
Contractor delay often occurs because emerging problems are not identified early enough. If employer-caused delay is not recognised promptly, the contractor may also fail to give the notices required to claim an extension of time or delay damages.
The contractor should prepare its programme before contract and provide it to the principal or superintendent before tenderacceptance. Then the contractor typically has a defined period to submit a baseline programme or, depending on the contract, a “contract programme” that constitutes a logic linked activity network that incorporates the projects constraints and demonstrates a clear critical path from project commencement to completion.
Once delay occurs, retrospective analysis becomes more difficult. Superintendents and tribunals may then treat the contractor’s original programme as the best evidence of how the works would have proceeded but for the delay, so the contractor should preserve it as the baseline.
Extensions of time are usually assessed by reference to their effect on practical completion, rather than by the period of actual delay alone. Depending on the contract’s extension of time clause wording, this can be the date of, or for practical completion.
A typical method for giving notice of the extent of delay under AS 4000 for example, is to:
Update the programme to reflect actual progress immediately before the delaying event. This identifies the projected completion date that would have applied if the event had not occurred.
Insert the delaying event into the programme and identify the revised projected completion date.
Use the difference between the two projected completion dates as the prima facie extension of time for that delay.
Depending on the contractor’s relationship with the principle or superintendent,
If the delay obviously impacted the planned sequence of works, practical completion, and the delay was a claimable delay, the superintendent may grant an extension of time. However, typical reasons for the superintendent rejecting an EOT claim are:
The contractor concurrently delayed the works prior to, or at the time of the alleged delaying event
The contractor contributed to the delay event
The baseline (or “contract”) programme was not accepted by the superintendent
The contractor has not taken reasonable steps to mitigate the delay
Why the DDM method is superior
DDM is not a forecasting tool in the same way as a conventional programme update. That is central to its value: it keeps the construction programme anchored to what occurred.
DDM records what occurred, rather than producing a revised forecast. A conventional programme update records progress, recalculates the remaining work and projects a new completion date, which can obscure earlier delay. By contrast, DDM compares planned dates with actual start and finish dates, creating an as-built programme rather than a rolling prediction.
DDM records how the critical path changes as the works progress. Where one activity replaces another as the controlling activity, conventional programme updates may obscure the change by re-baselining the logic to reflect current status. DDM is intended to make that movement visible over time.
DDM is harder to manipulate and more transparent. Because it is anchored to actual dates and contemporaneous records, there is less room to massage the outcome, and the analyst’s reasoning is exposed and testable rather than buried inside software recalculation.
DDM handles concurrency more objectively. By rebuilding the actual timing and reading the float, it distinguishes concurrent, staggered, near-critical and truly critical delays with less subjectivity than comparing projected dates from successive updates.
DDM gives a stronger evidentiary base. A programme maintained in this way ties delay to real events as they emerge, supporting extension-of-time and responsibility analysis more effectively than a forward-looking update that assumes the original plan still holds.
The trade-off is that DDM is more labour-intensive and relies on expert judgment, so it is not how most contractors manage day-to-day programme control. Its advantage lies in maintaining an accurate as-built programme for disputes.
At Accura Consulting, our team of experts work with clients to create a tailored solution to problems. If you have an issue and want expert support, get in touch.
Back to News and Insights
Related News and
Insights from Accura
