Programme, delay & EOT
A real critical-path programme with a baseline that cannot be quietly re-cut, a four-week lookahead the site actually uses, and a delay register that builds the EOT case as it goes.
- Planning engineer
- Project manager
On a contractor's desk. An EOT claim lives or dies on whether the baseline was fixed and the delays were recorded contemporaneously. A programme re-baselined informally three times is not evidence of anything — which is why the baseline here is locked by the database, not by policy.
What it holds
WBS to critical path
Activities, logic, durations and float computed with cycle detection — a network that fails loudly if it is malformed rather than producing a confident wrong date.
Baseline immutability
Once published, the baseline is enforced as read-only at the database. A revision is a new baseline with a reason, and the variance is always measured against the one that was live.
Four-week lookahead and resources
A rolling lookahead generated from the programme, with resource and material-requirement schedules so procurement and manpower follow the plan rather than the panic.
Delay and EOT dossier
Events with cause, evidence, affected activities and computed impact on the critical path — assembled into an EOT submission with its programme analysis attached.
What it produces
- Variance report against the live baseline
- Schedule-quality checks before a programme is issued
- EOT submission with the delay analysis and evidence index
What it will not allow
- Editing a published baseline
- A circular activity network
- An EOT with no delay events behind it