From a delay.
A clearer decision.

Start with a delivery question

A supplier says a delivery may be late. Before changing the programme report, the team needs to establish what has actually changed, which tasks depend on it and whether the final readiness date is affected. A fluent summary cannot answer those questions reliably if the underlying plan is incomplete.

For AI-assisted programme delivery, we would start with a clear division of work: people confirm the evidence and own decisions, a calculation applies the scheduling rules, and AI can help explain the result. Our public Programme Intelligence example makes that division visible. It uses a synthetic infrastructure programme, not a customer project or a delivery forecast. [1]

A worked example: two delays, different consequences

The teaching programme contains 15 tasks across architecture, facilities, compute, network and assurance. Its baseline reaches readiness after 37 working days. In the example calendar, that is 25 November 2026. Dates mark the boundary when the next task may start. [1][2][3]

Extending power equipment delivery by 15 working days moves readiness to 52 working days, or 16 December. Five task finish boundaries change: equipment delivery, installation, integrated acceptance testing, operational acceptance and handover. [2][3]

A separate scenario extends network hardware delivery by two working days. Some dependent tasks move, but overall readiness remains at 37 working days. The path has enough scheduling flexibility to absorb that change without moving the final boundary. [2][3]

That difference matters to a delivery conversation. A local delay does not necessarily produce an equal programme delay. Equally, an unchanged final date does not mean nothing needs attention: affected owners still need to check their commitments and remaining flexibility.

These are calculated outcomes under deliberately simple assumptions. The example uses Monday-to-Friday working days and finish-to-start dependencies with no lag. It excludes holidays, resource constraints, costs, probabilistic forecasts and real construction-engineering constraints. It cannot establish a delivery commitment for an actual facility. [1][2][3]

Keep the evidence, calculation and explanation separate

The example retains the original baseline and recalculates a separate scenario. Its evidence register distinguishes the teaching plan, governance assumptions, the selected what-if input and the calculated result. The brief can be produced without an AI model. [2][3]

Optional AI commentary is a separate layer. The documented design gives the model the synthetic scenario and calculated evidence, requires recognised source references and clears the commentary when the scenario is recalculated. The model does not approve a new baseline or instruct a supplier. [1]

A recognised citation is only a starting point for review. It does not prove that the cited source supports every sentence. A reviewer should be able to trace a statement about the delay back to the actual inputs, dependencies and calculation, and identify any extra interpretation the commentary introduces.

Make the decision clear

For a real programme, we would prepare a short decision record alongside the analysis:

• Confirmed change: the source, owner and date of the latest information. Keep an unconfirmed supplier scenario labelled as a scenario.
• Calculated impact: the affected tasks and milestones, with the assumptions that drive the result.
• Unresolved questions: missing dependencies, shared resources, calendar restrictions or disputed estimates.
• Options requiring assessment: for example, resequencing work or considering an alternative supply route. Do not present untested options as feasible commitments.
• Decision and authority: who may approve a change, what they approved and which baseline version remains in force.

This is a proposed working pattern, not a claim that our teaching example integrates with every planning system. In an actual implementation, permissions, approved data sources and change controls would need to fit the organisation.

Test the analysis before relying on the narrative

A useful pilot should include a delay on the critical path, a delay absorbed by available flexibility, a missing dependency and a scenario that is withdrawn. Check whether the calculations are reproducible and whether the explanation changes when the underlying evidence changes.

The public calculation and synthetic input allow readers to reproduce these scenarios. This example does not establish the accuracy of live AI commentary or demonstrate customer outcomes. [2][3]

The value of a pilot should be judged against the existing process. We would measure time to a checked decision brief, errors or unsupported statements, reviewer effort and traceability to the source plan. More reports or faster prose alone do not establish better programme decisions.

Start with one reviewable programme decision

AI Venture X can discuss a focused starting point: a recurring delivery question, its source information, the calculation needed and the person accountable for the decision. The aim is a brief people can inspect and act on, with uncertainty still visible.

Sources and further reading

1. Programme Intelligence: README. Teaching example, optional AI responsibilities and limitations.
2. Deterministic scheduling implementation. Calculation of separate baseline and scenario schedules.
3. Synthetic programme and evidence register. Fifteen tasks, calendar and dependency assumptions.

Source snapshot checked 21 September 2026. This is a synthetic teaching example. The proposed working practices require validation for each organisation.