The schedule narrative: the report everyone requests and nobody enjoys writing
Every month, on most large projects, a planner sits down to write the schedule narrative report — and most of what gets written is boilerplate nobody reads. That is a double failure, because the narrative has two jobs that genuinely matter, and a structure exists that does both in a few pages.
What the narrative is actually for
The schedule narrative exists to do two things. First, it translates the update for people who will never open P6. The project director, the client's commercial lead, the board — the people making decisions about money and resources — will not read a 4,000-line schedule, and should not have to. The narrative is the interface between the model and the decision: where the project stands, what moved this period, and what is being done about it, in language that survives being forwarded.
Second, and less obviously, it creates the contemporaneous record. When a dispute crystallises in three years' time, the analysts on both sides will line up the monthly updates and read the narratives alongside them. Observational delay analysis methods — as-planned vs as-built, windows analysis — feed directly on this material: the narrative is often the only document that explains why the critical path moved in a given window, not merely that it did. A well-kept chain of narratives, like a well-kept baseline record, is the difference between proving what happened and arguing about it.
Write for both readers at once — the executive this month and the analyst in three years — and most of the stylistic decisions below make themselves.
Timing matters more than teams realise. The narrative should issue with the schedule update it describes, against the same data date — a narrative written ten days after the update describes a project that no longer exists, and a narrative written without the update in front of you describes one that never did. On contracts that require a programme submission each period (NEC's revised programme cycle is the obvious example — see our piece on clause 31 and 32), the narrative is the natural covering document: it is the contractor's chance to explain the model before the reviewer forms their own theory about it.
The skeleton that works
Seven sections, in this order, each doing one job. The order matters: it front-loads the answer, then supplies the evidence.
The executive position is three sentences at the top: where the project stands against the contract dates, what moved this period, and what is being done about it. It is the only part some readers will see, so it carries the whole truth in miniature — including the bad news. Progress this period compares achieved against planned: activities completed versus baselined, milestones hit and missed, and ideally an earned schedule measure, because "we earned 3.1 weeks of schedule in a 4.3-week period" says more than any percentage.
Critical path commentary is the section analysts will mine later: where the critical path runs now, where it ran last period, and what changed it — a logic revision, a slipped delivery, an accelerated section. If the path jumped from piling to procurement, say so and say why. The changes log records what was edited in the model itself: logic added or deleted, durations revised, calendars changed, with reasons. Undocumented model changes are where forensic suspicion concentrates; documented ones are unremarkable. Delay and mitigation lists the events of the period, the notices raised against them (early warnings, compensation events, or their equivalents under your form), and the recovery actions with named owners. The look-ahead tells the reader what becomes critical next period and what decisions or supplies the team needs from them — the section that makes the narrative useful rather than merely historical. Appendices carry the tables: milestones, float, and the schedule quality trend.
| Section | Key question it answers | Data source in the update |
|---|---|---|
| Executive position | Are we on time, and if not, what is the plan? | Completion forecast vs contract dates |
| Progress vs planned | How much of what we promised this period happened? | Statused activities vs baseline; earned schedule |
| Critical path | What is driving completion, and did it change? | Longest path comparison, this update vs last |
| Changes log | What did we change in the model, and why? | Schedule comparison: logic, duration, calendar diffs |
| Delay & mitigation | What went wrong and who is fixing it? | Event register, notices, recovery actions |
| Look-ahead | What must go right next period? | Near-critical activities in the next window |
| Appendices | Where is the evidence? | Milestone table, float report, quality metrics trend |
The narrative is not the basis document
One conflation worth killing early: the schedule narrative and the schedule basis document are different artefacts with different lifespans. The basis document — formalised in AACE's Recommended Practice 38R-06, and covered in its own article — records how the schedule was built: the assumptions, calendars, methodology, productivity rates, exclusions and constraints behind the model. It is written when the schedule is created and revised when the basis genuinely changes. The narrative records what happened this period and is rewritten every cycle.
Both are living documents, and both end up as evidence, but they answer different questions: the basis explains why the plan looked the way it did; the narrative explains why reality diverged from it. Teams that merge them produce a monthly report nobody can navigate, and a basis that silently mutates with each update — which is precisely the property a basis document exists not to have.
Writing craft: how to say it
Three habits do most of the work. First, state changes in time units, not value or sentiment. "Planned Completion moved nine working days right" is information; "the programme has experienced some pressure" is noise. Days, dates and activity names are the currency — a reader should be able to reconstruct the period from the narrative alone.
Second, never bury bad news below the fold. The slip goes in the executive position, with the cause and the response attached. This is not just ethics; it is self-interest. The narrative that admits the slip and shows the plan reads as a team in control. The one that hides it behind "broadly on track" reads — when the slip inevitably surfaces — as evidence of concealment, and every other claim in every other narrative you wrote is discounted accordingly.
Third, keep opinions out; facts and actions in. "The subcontractor's performance remains disappointing" will be quoted back at you in proceedings and proves nothing. "Steelwork erection achieved 41 of 60 planned tonnes; recovery plan agreed 14 May, second crane on site from 21 May" proves everything you need without editorialising.
A fourth habit, smaller but worth naming: keep the period's numbers consistent across sections. If the executive position says nine days, the critical path commentary must explain the same nine days, and the milestone table in the appendix must show them. Narratives drafted by different authors, or partly recycled from last month, routinely contradict themselves — and a self-contradicting contemporaneous record is worse than none, because it hands the other side a credibility argument they did not have to earn.
The boilerplate trap
The worst narratives are not dishonest; they are empty. "The project continues to progress in accordance with the programme. Procurement activities are ongoing. The team continues to monitor risks." Paragraphs like these survive from month to month by copy-and-paste precisely because they are never wrong — and never informative. The test is brutal and simple: if a paragraph could describe any project in any month, delete it. What remains after the cull is the actual narrative, and it is usually two pages long, which is exactly the right length.
The honest reason boilerplate happens is that assembling the inputs is tedious: pulling milestone variances, float movements, logic diffs and quality trends out of P6 takes most of the writing day, and the prose gets whatever energy is left. That is a tooling problem with a tooling answer — ScheduleInsight's report builder assembles the metrics, comparisons and trend charts from the XER directly, so the planner's time goes into the only part a human must do: the thinking. However the inputs are gathered, the principle stands — automate the assembly, never the judgement. A generated sentence reads like one, and the readers who matter can tell.
A template you can lift
Below is the skeleton as a fill-in template — section headings, prompt lines, and the phrasing patterns that survive both the boardroom and the tribunal. Replace the placeholders, delete the prompts, and keep the discipline: days and dates, bad news first, no adjectives.
Two rules make the template work harder than it looks. State nil returns explicitly ("no logic changes this period") — silence reads as omission three years later. And keep section 1 honest enough that nothing in sections 2–6 surprises a reader who stopped there.
Key takeaways
- The narrative has two readers: the decision-maker this month and the delay analyst in three years. Write for both at once.
- Seven sections, one job each — executive position first, evidence after. Front-load the answer.
- The narrative is not the basis document (AACE RP 38R-06): basis = how the schedule was built; narrative = what happened this period.
- State changes in days and dates, put bad news in the first paragraph, and keep opinions out. Admitted slips read as competence; hidden ones read as concealment.
- If a paragraph could describe any project in any month, delete it.
Spend the day on the thinking, not the assembly
Drop your XER in the browser and get the milestone variances, float movement, changes log and quality trend ready to write against — parsed locally, never uploaded.