Chapter 05
Revisions as the project evolves
Why a capture plan is a living document, how to schedule revisions so it stays aligned to the project, and which triggers should bring a section of the plan back to the table immediately.
01
Why the plan drifts
A capture plan written at mobilisation is correct for week one. It begins to drift as soon as the project starts to evolve: a new package mobilises, a work front moves, scaffold reconfigures the 360 routes, the safety profile shifts as the structural phase ends and the fitout phase begins, the commercial position changes when a delay event lands and a claim becomes live. A plan that is not revised becomes a record of what the project intended at the start, not what the project needs now. The drift is gradual and largely invisible until the workflows start missing — a 360 walk that no longer captures the active front because the route has not been redrawn, a fixed camera that now points at finished work, a gate camera at a gate that closed last month. The team works around the drift until the workload becomes intolerable, then complains that the plan is broken when in fact the plan was correct and was simply never revised.
02
Scheduled revision cycles
A scheduled revision cycle keeps the plan current. Quarterly is the usual cadence on a multi-year contract, with shorter cycles in the first three months when the project shape is still settling and during major phase transitions. The revision is not a redrafting from scratch; it is a structured walk through the existing plan against the current programme, package register, and workflow log, with adjustments made and recorded. Most quarterly revisions touch four or five sources out of twenty — a 360 route redrawn for the new fitout floor, a fixed camera repointed as the cladding rises, a drone cadence stepped up because the external works moved into peak. The cumulative effect over a thirty-month contract is a plan that still describes the project, rather than one that describes the version of the project that existed at mobilisation.
03
Trigger-based revisions
Some revisions cannot wait for the next quarter. A new package mobilising with significant capture needs — a façade contractor whose progress claims will hinge on time-aligned views, a commissioning phase that needs MEP 360 routes — should bring the relevant section of the plan back to the table within the week. A significant safety event should trigger a review of the safety-related sources, because the workflow has just shown what it actually needs. A change order with cost or programme implications should prompt a check on whether the existing capture covers the new evidence horizon. A regulatory change — a new permit regime, a planning condition — should prompt the same. The discipline is to recognise the trigger early enough that the workflow does not run on a stale plan for any length of time. Naming the triggers in advance, on the plan itself, makes the response automatic rather than discretionary.
04
Recording revisions so they survive a handover
A revised plan that is not recorded is a plan that gets argued about at the next dispute. Each revision should produce a dated minute: which sources changed, why, and which workflow drove the change. The minute lives with the capture plan, not in a separate folder. Two years later, when a delay event has triggered a claim and the question becomes whether the relevant front was covered at the relevant time, the minute is what allows the project to answer. Without the minute, the project answers from memory, and the memory is unreliable. The minute also makes the plan auditable — a reviewer at handover can see how the plan evolved and why, which strengthens the closeout archive against any later challenge.
05
Failure modes from infrequent revision
The most common failure is annual revision on a multi-year project, which produces a plan that is twelve months out of date for most of its life. The second is event-only revision with no scheduled cadence, which means the plan is updated when something has gone wrong rather than to prevent the next thing going wrong. The third is undocumented revision — the plan changes informally, the sources move, the routes are redrawn, and no minute exists, so the audit trail breaks. Each of these is fixable by introducing a quarterly cadence with a named owner on the digital construction lead role, plus a short list of named triggers that bypass the cadence when the project changes shape between cycles.
Practice
01. Schedule the next four revisions for a current capture plan. Assign the revision owner, the agenda, and the inputs. Identify which inputs the team currently does not collect routinely and how to start.
Look for: A typical schedule places revisions at the start of each quarter, owned by the digital construction lead, with agendas built from the workflow log, the package register, and the safety incidents log. Inputs that are not routinely collected often include the time-to-find metric per workflow and the per-source contribution log, both of which need a small amount of tagging discipline before the first revision.
02. List the trigger events that should bring a section of your capture plan back to the table immediately. For each trigger, name the section affected and the response window.
Look for: A defensible list usually names five to seven triggers: new package mobilisation (capture sources within seven days), significant safety event (safety sources within forty-eight hours), change order with programme impact (claims sources within the change-order window), regulatory or permit change (compliance sources within the notice period), gate or access reconfiguration (logistics sources within the same week), and major phase transition (whole plan within the month).
Checkpoint
When was your capture plan last revised, and what would trigger the next revision before the scheduled cycle?
Recommended reading