Moving a date is not the same as re-planning

A programme misses a date. Everyone involved understands why, and the reasons are usually real. A recovery plan is produced. Somebody opens the schedule, moves the affected activities out by the length of the delay, and the completion date moves out by about the same amount.

That operation has a name in mathematics, and the name is translation. Every point moves the same distance in the same direction, and the shape of the thing is preserved exactly. It is a defensible way to move a triangle across a page. It is not a way to re-plan a programme, because a programme is not a shape. It is a set of dependencies between parties with their own calendars, their own crews and their own prices, and moving all of it six months into the future changes what those dependencies cost.

The consequence is not that revised dates are optimistic in the ordinary sense. It is that they are unexamined in a specific way, and the examination that was skipped is one somebody has already done at scale.

The number that is missing from the revised paper

Flyvbjerg and colleagues modelled the relationship between cost overrun and the length of the implementation phase, using a large dataset of major construction projects.

Read that slowly, because it is easy to absorb as a general warning about delay being bad, which is not what it says. It says the relationship has a slope, and the slope has been measured. Delay is not a state a programme enters. It is a quantity with a price per year, and the price is roughly knowable before the delay has finished happening.

To put it in the terms a sponsor uses: on a programme of 10bn, the average relationship puts the cost consequence of a one-year extension in the region of 460m. That is before anybody has argued about who caused it.

Now consider what a typical revised programme paper contains. It contains the new date. It contains the reasons for the change. It frequently contains an assurance that the revised plan is achievable. It very rarely contains a number for what the extension itself will cost, because the extension is being treated as a change to the schedule rather than as a change to the estimate.

Why the arithmetic does not translate

The reason a shifted programme understates is not mysterious. It is that several of the things a schedule depends on are fixed to the calendar rather than to the programme, and translating the programme does not translate them.

Resource contention. The crews, cranes, testing houses and specialist subcontractors allocated to a window were allocated on the assumption the window was when it said. Move the window and it lands on top of somebody else's, including, on a multi-package programme, your own other packages.

Interface dates that did not move. A programme rarely slips as a whole. One package slips and the others do not, so the interfaces between them stop lining up. Every one of those misalignments is a new piece of float consumption that did not exist in the original network.

Seasonal and regulatory windows. Concrete pours, marine works, possessions, shutdowns and environmental restrictions are fixed to the year, not to the programme. A three-month delay that steps over a seasonal boundary is not a three-month delay.

Escalation. Later work costs more, and the estimate that supported the original date did not price the later year.

The contractor's cash position. This is the one most often left out of the owner's analysis, because it appears to be the contractor's problem. It is not, and the reason is covered below.

None of these is exotic. Each is the kind of thing a planner will identify in an afternoon if asked. The question worth sitting with is why they are so rarely asked, and the answer is usually that the revised date was needed for a meeting before the analysis could have been finished.

What the guidance already says

This is not a gap in the published guidance. It is a gap between the guidance and practice.

GAO goes further and describes the mechanism directly, observing that schedule variances are typically followed by cost variances, and that management tends to respond to schedule delays by adding more resources or authorising overtime. It identifies schedule risk analysis as the instrument that lets management account for the cost effects of slippage, and notes that a schedule can serve as a warning that a programme may need an overtarget budget.

That last phrase is worth holding. The guide treats the schedule as an early indicator of a budget problem. A great deal of practice treats the schedule and the budget as two reports produced by two teams, which is precisely the arrangement in which a date can move without a cost moving with it.

How the compounding actually happens

Put the pieces together and a sequence appears that anybody who has worked on a large programme will recognise.

A delay occurs. The date is moved by the length of the delay. Because the move was a translation, it did not price the contention, the interfaces or the season, so the new date is optimistic by an amount nobody calculated. The programme misses the new date too, usually by less than it missed the first, which is read as improvement. The date moves again.

Meanwhile the cost consequence has been accruing at something like the rate the evidence describes, and it has been accruing since the first delay rather than since it was recognised. By the time it is acknowledged it is large, and by then it is also contested, because what has changed is not one decision but a chain of them.

Each revision promises the date the last one missed

The dark bar is the plan as issued. The dashed extension is what the shift did not price. Liquidated damages, when they are applied, are still measured against the original commitment on the left.

Two causes that sit on the owner's side

The trigger for the first shift is frequently one of two things, and both belong to the owner rather than to the contractor.

The first is a physical condition that was not known at award, most commonly something buried. That deserves its own treatment and has an article of its own.

The second is payment. A contractor whose valuations are certified late, or certified and paid late, is financing the owner's programme out of its own working capital. There is a limit to how long any contractor does that, and the response is not usually a formal notice. It is a quiet reduction in the resources committed to the site, which appears in the progress report as poor performance by the contractor.

This matters for the compounding argument specifically. Late payment depresses progress, depressed progress extends the programme, and the extension carries the cost consequence described above, a share of which the owner will later seek to recover from the contractor as liquidated damages. The owner is, in the strict sense, paying twice for the same delay and attributing both payments to somebody else.

Where it ends

The endgame is the least surprising part and the most expensive. The completion date has moved several times. The contract carries liquidated damages tied to a date that is now three revisions old. The owner applies them. The contractor, which has been financing the works and absorbing the consequences of an extension it did not cause, has by this point assembled a records-based case that the delays were the owner's.

Neither party set out for this. It arrives because the first shift was recorded as a date change rather than as an event with a cost, and because no document in the sequence ever put the extension and the money on the same page. By the time somebody does put them on the same page, it is a pleading.

What to ask

Three questions, none of which requires new data.

What does the extension itself cost, before attribution? Not who pays. What it costs. Attribution is a separate and later argument, and conducting it first is how the cost question gets lost.

Was the revised date produced by re-running the logic, or by moving the dates? The distinction is visible in the file. A schedule re-run against retained logic behaves differently from one whose activities have been dragged.

What is the confidence level of the new date? If the original date was a commitment and the revised date is also a commitment, then either the risk has genuinely gone or nobody has looked. A revised date produced without a schedule risk analysis is, on GAO's own test, not yet credible.

Sources. Bent Flyvbjerg, "What You Should Know About Megaprojects and Why: An Overview", Project Management Journal, 2014, available as a free preprint at arXiv:1409.0003, for the iron law of megaprojects and for the reported finding of Flyvbjerg, Holm and Buhl (2004) that a one-year delay or other extension of the implementation phase correlates on average with an increase in percentage cost overrun of 4.64%. The same paper reports that nine out of ten megaprojects have cost overruns, that overruns of up to 50% in real terms are common, and that performance has not improved over the 70-year period for which comparable data exist. Note the relationship reported is a correlation, not a demonstrated causal mechanism, and it is drawn from major construction projects rather than from all programmes. US Government Accountability Office, GAO Schedule Assessment Guide: Best Practices for Project Schedules, GAO-16-89G, December 2015, for the statement that a cost estimate cannot be considered credible if it does not account for the cost effects of schedule slippage, for the observation that schedule variances are typically followed by cost variances and that management responds by adding resources or authorising overtime, and for schedule risk analysis as the means of accounting for those effects.