← Blog
Practical Guide·7 May 2026·10 min read

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 seven-section narrative skeleton 1 Executive position Three sentences: where we are, what moved, what happens next 2 Progress vs planned Earned against planned this period; milestones hit and missed 3 Critical path Where it runs now, and what changed it since last period 4 Changes log Logic, durations, calendars added or removed — and why 5 Delay & mitigation Events, notices raised, recovery actions and their owners 6 Look-ahead Next period's critical activities and the decisions needed 7 Appendices Milestone table, float report, quality metrics trend
Fig 1. Seven sections, one job each. If a paragraph does not belong to one of these jobs, it probably does not belong in the narrative.

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.

SectionKey question it answersData source in the update
Executive positionAre we on time, and if not, what is the plan?Completion forecast vs contract dates
Progress vs plannedHow much of what we promised this period happened?Statused activities vs baseline; earned schedule
Critical pathWhat is driving completion, and did it change?Longest path comparison, this update vs last
Changes logWhat did we change in the model, and why?Schedule comparison: logic, duration, calendar diffs
Delay & mitigationWhat went wrong and who is fixing it?Event register, notices, recovery actions
Look-aheadWhat must go right next period?Near-critical activities in the next window
AppendicesWhere 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.

The same slip, written two ways (illustrative) HOW CONCEALMENT READS “The project continues to progress broadly in line with expectations. Minor delays have been experienced in some areas and are being closely monitored. Completion remains under review.” Says nothing. Could describe any project in any month. Reads badly in a dispute. HOW COMPETENCE READS “Planned Completion slipped 9 working days this period. Cause: piling rig breakdown, Area B (EWN-014, 3 May). Mitigation: second rig mobilised 18 May; 5 days recoverable. Forecast completion 11 Nov against 31 Oct.” Specific, dated, owned. Reads as a team in control — now and years later.
Fig 2. Both snippets are invented, and both describe the same nine-day slip. Only one of them will help its author — this month with the client, and later with a tribunal.
The hindsight test. Before issuing, read each paragraph as a delay analyst will read it in three years, with the as-built record open beside it. Anything that proves untrue or evasive against that record does not just fail to help — it actively damages the credibility of everything else you wrote.

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.

SCHEDULE NARRATIVE — [Project] — Period ending (data date): [DD Mmm YYYY] Update ref: [P6 file / revision ID] · Baseline: [baseline ID + date accepted] · Author: [name] 1 · EXECUTIVE POSITION Forecast completion is [date] against a contract date of [date] ([n] working days [ahead/behind], [+/−n] vs last period). The movement this period was driven by [cause, one clause]. In response, [action + owner + date]. 2 · PROGRESS THIS PERIOD Completed [n] of [n] activities planned for the period ([n]%). Milestones achieved: [list + dates vs baseline]. Missed: [list + cause, one line each]. Earned schedule: [n] weeks earned in a [n]-week period (SPI(t) [0.00]). 3 · CRITICAL PATH The critical path (longest path) runs: [area → area → completion]. Last period it ran through [area]; it moved because [logic change / slippage / acceleration — name the activity]. Near-critical (< [n] days float): [paths/areas]. 4 · CHANGES TO THE MODEL Logic: [n] relationships added / [n] deleted — [reason]. Durations revised: [n] activities — [reason]. Calendars/constraints: [changes + justification]. (Nil returns stated as nil.) 5 · DELAY EVENTS & MITIGATION [Event][date] — notice [EWN/CE ref] — impact [n] days on [path] — mitigation [action, owner, date] — residual [n] days. 6 · LOOK-AHEAD (next period) Critical: [activities]. Becoming critical: [activities]. Decisions/inputs required from [party] by [date]: [item]. 7 · APPENDICES A — Milestone variance table · B — Float report · C — Schedule quality trend · D — Changes register

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

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.

← PreviousNEC4 clause 31: getting your programme accepted (and why most aren't)