Why Your Programme Narrative Is the Part Evaluators Actually Read
- Apr 13
- 8 min read
Updated: May 8
By Roman Bazelchuk | NEC Accredited Project Manager | APMG Project Planning and Control
Founder, NEC Planning Solutions Ltd
Most tender submissions include a programme. Fewer include a programme narrative. Fewer still include one that does any real commercial work.
There is a useful distinction that bid teams rarely make explicit: the programme schedule goes to the planner. The programme narrative goes to the decision-maker. The planner will open the P6 or MPP file, check the logic, look at float and critical path. The commercial director, the framework manager or the client's project lead will read the narrative document and use it to form a view of whether this contractor has actually thought through the job.
That asymmetry matters more than it might appear. On competitive tenders, particularly framework bids and NEC4-administered projects, evaluation panels are often scoring your methodology as much as your price. The programme narrative is the primary vehicle for explaining that methodology. If it reads as a description of a Gantt chart, it has failed its purpose. A programme narrative should make an argument, not just a record.
What a programme narrative is actually for
The formal purpose of a programme narrative is to explain the programme to people who may not read programmes every day. It should walk the reader through your sequencing logic, your key constraints, your interface assumptions and your approach to risk. Done well, it answers the questions an evaluator would have if they sat down with the schedule and a planner for an hour.
But the commercial purpose goes further than that. A well-written programme narrative protects the contractor's margin at two specific moments that most bid teams do not think about at tender stage.
The first is the clarification window. On competitive bids, clients regularly raise programme queries during clarification. Without a clear narrative that has already documented your sequencing rationale and assumptions, each query becomes a negotiation. With one, the answer is already in the submission. The clarification question becomes a reference exercise rather than a position-building exercise. That is a meaningful difference in where you end up at the close of the clarification window.
The second is mobilisation. When a project is won, the tender programme and its narrative become the first reference point for the construction team. A narrative that has clearly documented assumed access dates, design information milestones, procurement lead times and interface responsibilities gives the planning team something to build from. One that says "the programme shows a 58-week programme from start on site" gives them almost nothing.
The programme narrative should make an argument, not just a record. It should explain why the sequence is what it is, what assumptions underpin the critical path, and what the contract or client would need to provide for the programme to hold.
What most narratives actually say
In practice, a large proportion of programme narratives submitted with UK tenders do one or more of the following: they describe the Gantt chart in text form ("Phase 1 runs from weeks one to four, during which groundworks will be undertaken"), they list the software used and the WBS structure, or they repeat the scope of works from the invitation to tender in programme language without adding any analytical content.
None of this is worthless. But none of it is what a sophisticated evaluator is looking for, and none of it does the protective work described above.
The root cause is usually that the programme narrative is written after the programme is built, as a description of what is already in the schedule. That inverts the correct relationship. The narrative should be developed alongside the programme, not extracted from it. The logic in the schedule should reflect the argument in the narrative, and the narrative should be the written form of the thought process that produced the programme.
When that relationship is inverted, the narrative reads as a post-hoc commentary rather than as evidence of genuine planning. Evaluators who have read many submissions can tell the difference quickly.
The NEC context makes this sharper
On NEC3 and NEC4 contracts, the programme carries contractual weight that it does not carry under JCT. The contractor is required under Clause 31 to submit a programme showing the information listed in the contract data, and the project manager is required to either accept it or notify the reasons for non-acceptance within the period for reply. Once a programme is accepted, it becomes the reference point for assessing compensation events, for establishing planned Completion, and for tracking progress under Clause 32.
This means that a programme narrative submitted with an NEC tender is not just a methodology document. It is, in effect, the contractor's opening statement of the assumptions and constraints that underpinned the programme. If access is assumed on a particular date, the narrative should say so. If design information is required by a particular milestone for the sequence to hold, the narrative should say so. If third-party or client interfaces create dependencies that could affect planned Completion, the narrative should say so.
Those documented assumptions become commercially important later. Under NEC, a compensation event can arise where the project manager gives an instruction, where access is not provided by the access date, or where certain other events occur. A well-constructed tender narrative that has clearly stated the assumptions under which the programme was built gives the contractor a documented starting position when those events arise. It is not a contract in itself, but it forms part of the commercial record of how the job was priced and planned.
Most programme narratives on NEC bids say none of this. They describe the programme rather than arguing it.
What a strong narrative covers
The specific content will vary by project type, contract form and the evaluation requirements in the invitation to tender. But across NEC4 ECC tenders, the following areas consistently appear in narratives that do the right commercial work.
Sequencing rationale explains why the programme is structured as it is. It covers the logic behind the chosen sequence, the critical path drivers, and the constraints that shaped the order of operations. This is not a description of what happens in what order. It is an explanation of why that order was chosen over the alternatives.
Interface and dependency mapping identifies the points at which the contractor's programme depends on something they do not control: client access, design information, procurement of employer-supplied materials, approvals, third-party works, or the completion of a preceding package. Each dependency should be named, with the assumption documented clearly.
Key dates and milestones lists the contractual and programme key dates in a way that is meaningful to a non-specialist reader. This is often the section that the client's project manager reads most carefully, because it is where the contractor's proposed sequencing connects to the dates the client cares about.
Risk and float explains how risk time has been included, where float sits in the programme, and what the contractor's approach is to managing programme risk through the project. This is also the section where a contractor can articulate, briefly and without overclaiming, what the client would need to do to protect the programme.
Contract alignment confirms that the programme meets the Clause 31 requirements for the specific NEC form being used, including the information required by the contract data. This section is sometimes omitted because it feels administrative, but on a framework bid or regulated procurement, it reassures the evaluator that the contractor understands the contractual obligations around the programme.
The clarification defence argument
One of the most consistent frustrations for bid directors on competitive NEC tenders is the volume and nature of programme clarification queries. Many of these queries arise not because the programme is wrong but because the logic is not visible. The evaluator has a question about sequencing, access or timing that the programme does not answer clearly, and the narrative has not answered it either.
A programme narrative written with clarification in mind is structured to prevent those queries. Every assumption that could generate a question is documented. Every constraint that a reader might challenge is explained. The rationale for the critical path is written out rather than left for the reader to infer from the Gantt.
This does not mean the narrative should be exhaustive. Evaluators read many submissions and long-form documents that pad around a thin argument are worse than short documents that make a clear one. The discipline is to be specific about the things that matter and brief about the things that do not.
When to involve a programme narrative consultant
Many contractors have in-house planning teams who can build a sound programme. The question of when to involve a specialist in the narrative is slightly different. The programme is a technical document. The narrative is part technical, part commercial writing. The skills that make someone a strong planner do not automatically make them a strong programme narrative writer, and the reverse is also true.
The cases where external support adds the most value tend to be: complex or high-value tenders where the narrative will be scored and the margin of difference between submissions is small; framework bids where the same evaluators will read multiple submissions and will recognise both quality and formula; NEC-administered projects where the contractual weight of the programme means the narrative assumptions carry real downstream significance; and situations where the programme has been built to a high standard but the team does not have the time or writing resource to produce a narrative that does it justice.
A programme narrative consultant UK-side working on NEC tenders should bring two things that an internal planning team may not have time to provide: deep familiarity with what evaluators look for on competitive NEC bids, and the ability to translate a technically complex programme into a document that makes a clear commercial argument without requiring the reader to be a planner.
The output should be submission-ready, client-branded where required, and written to a standard that means the team can issue it without a final round of editing. That last point matters more than it might appear. On tight tender timelines, a narrative that needs significant reworking at the end is a risk to the submission quality of the whole document.
The relationship between programme and narrative
It is worth closing on the point where most narratives go wrong, because it applies at every stage of a project, not just at tender. The programme and the narrative should be developed together, not sequentially. The narrative is not a description of the programme. It is the written argument that the programme expresses visually.
When a programme is built first and a narrative written afterwards to describe it, the result is usually a document that answers questions the reader was not asking and misses the ones they were. When the narrative is developed alongside the programme, with the key arguments identified early and the programme structured to evidence those arguments, the result is a submission that reads as coherent, considered and commercially intelligent.
That is the standard a competitive NEC tender requires. It is achievable, and it is consistently underdelivered.
About the author
Roman Bazelchuk is the Founder of NEC Planning Solutions Ltd, a UK project planning and controls consultancy supporting contractors with NEC programme compliance, compensation event assessments and live project controls. He is an NEC Accredited Project Manager and holds the APMG Project Planning and Control qualification, with a BSc in Mechanical Engineering and postgraduate training in Planning and Control.
NEC Planning Solutions provides contract-aware planning support through a QA-governed delivery model, helping project teams keep programmes accepted, current and commercially useful from tender through to live delivery.
Need a tender programme and narrative that can survive clarification?
We prepare tender programmes and supporting narratives that do more than describe the schedule. Sequencing logic, assumptions, dependencies and interface mapping are documented clearly enough to support bid evaluation and protect your position through clarification and into mobilisation. Scope confirmed in writing before billing.
