The document that answers when nobody agrees
Last week ended on a problem rather than a solution. A decision can leave a meeting with an owner and a date against it and still decay, because nobody said what its output looks like or how anybody would notice its absence.
There is a document whose whole purpose is to close that gap. The standard calls it the project management plan and describes it as the thing that says how the project will be executed, monitored, controlled and closed. On construction and engineering jobs the same document goes by project execution plan.
It is also the document nobody opens after approval — and the one that answers when two parties disagree about how something should have been done.
What it is supposed to contain
Not the work. The plan is about method, not scope: how progress will be measured, how change will be handled, how information will move, who approves what, what the reporting cycle is, which procedures govern which activity.
In standard terms it is a container for subsidiary plans — scope, schedule, cost, quality, resource, communications, risk, procurement, stakeholder — each answering the same shape of question for its own subject. And it is meant to be progressively elaborated, refined as the project runs, rather than written once and filed.
Set that against what actually happens to it and the distance is the subject of this week.
One thing to notice before going on. Everything in that list is a choice rather than a fact. There is no correct reporting cycle, no correct approval threshold, no correct way of measuring progress on a concrete package. Each has several defensible answers and the project has to pick one, which is why the document exists at all.
Assembled, not decided
A plan is needed by a date. There is one from the last job. It is good, it was approved before, and adapting it takes a fraction of the time that writing one takes.
So it gets adapted: names changed, client changed, a few sections rewritten where the contract is obviously different. It goes for approval, and it is approved, because it is a competent document and nothing in it is wrong.
What has happened is that the plan now records a set of decisions that nobody on this project made. The reporting cycle is the last job's cycle. The approval thresholds are the last job's thresholds. The communication matrix names roles that exist on this project and describes flows that were designed for a different contract with a different number of parties.
Nothing about that is dishonest and it isn't laziness either. Under time pressure, adapting a good document is the rational move. The failure is that the output looks identical to a plan that was decided, and nobody downstream can tell the difference.
The test that separates the two
There is a single question that tells you which kind of plan you are holding.
Read any sentence and ask whether it could have gone the other way on this project. If the answer is no — if the sentence would be equally true on any job of this type — then it recorded no decision, and the words are describing practice rather than choosing it.
“Progress will be reported monthly” is that kind of sentence. “Progress against the concrete package will be measured by poured volume from the batching plant tickets, reconciled weekly against the surveyor’s measure, and the surveyor’s figure governs where they differ” is the other kind. It could have gone another way, somebody chose, and the choice is now checkable.
The standard has a word for what produces the second sort: tailoring. Adapting the approach to the specific needs of this project rather than applying a generic one. A plan with no tailoring in it isn't a bad plan. It is an empty one.
Six links, and the plan is where they live
The planning engineer whose account runs through this phase states what has to stand behind a decision as a chain: owner, format, source, deadline, validation, reporting. Leave any link out and the decision dissolves over time.
Read that chain against the contents of an execution plan and it is the same list. Not the decision — the meeting made the decision. The plan is where it acquires an owner, a shape, an origin, a date, a check and a destination.
Two of the six are the ones templates lose first. Source is where a figure comes from, and a plan adapted from elsewhere carries the previous project's sources. Validation is what makes a number usable rather than merely present, and it is the link that has no natural home in any other document.
Which reframes the document usefully. It isn't a description of the project. It is the conversion mechanism between what was agreed and what can be operated, and a version copied from elsewhere performs that conversion for somebody else's agreements.
It also explains why the plan isn't read. A document understood as a description is optional — you already know what your project is. A document understood as the place where four missing things get supplied isn't optional at all, and the two look the same on a shelf.
And the timing is against it. The plan is written in the same weeks as the initial programme and the kick-off, by the same short-handed team, and it is the only one of the three with no external deadline attached. Nothing in the contract asks for it by a date.
The matrix in the title
The communications section is the part that survives a template adaptation intact, because there is nothing obviously contract-specific in it to trigger a rewrite. It is also the part with the most daily consequence, because it is what you consult when you don't know who to send something to or where a piece of information is supposed to come from.
Done properly it says, for each thing the project needs: which source it comes from, which named person supplies it, in what format, by when, to whom, and what happens when it doesn't arrive. That last clause is the one that goes missing, and it is the control mechanism.
Where it is absent, information routes itself. It arrives through whichever channel is fastest for the sender, which on a live site means a phone call, a message, a photograph. The channel isn't the problem — a photograph of a completed pour is good evidence. The problem is that no record was created by the transaction, so the same question has to be asked again next month, of a person who may have left.
System design
Row two is the row nobody keeps and the one that decides whether row one is worth anything. A tailoring decision recorded with its reason survives the person who made it; the same decision recorded as a finished sentence doesn't, and the next project inherits it without knowing it was ever a choice.
| Record | Produced by | Required quality | Verified against | Feeds |
|---|---|---|---|---|
| Execution plan | The project, in its first weeks | Every section answers a question that could have gone the other way | This contract, not the last one | How every later disagreement is settled |
| Tailoring decisions | Whoever adapted the template | Each change carries the reason it was made | The document it was adapted from | Whether the plan decided anything |
| Communication and data matrix | The plan’s communications section | Source, named person, format, due day, and what happens when it is missing | Who actually holds each input | Whether you can produce anything weekly |
| Approval thresholds | The same plan | Stated for this contract’s values and parties | The contract and the delegation behind it | Every instruction and variation |
| Your compliance list | You, in one afternoon | What the plan obliges you personally to produce, and when | The plan as issued | Your calendar for the whole job |
Row three has the same required quality the whole phase has been circling — the clause covering what happens when something doesn't arrive. Weeks 8 and 9 asked for a basis and an open list. This asks for a check. All three exist to make an absence visible.
Practical insight
Read it once, properly, in the first month. It takes an afternoon, it is the only afternoon anybody will ever spend on it, and you become the person in the room who knows what it says.
Read it with a pen and two marks. One for anything you personally have to comply with — a report by a date, a submission in a format, an approval needed before doing something. The other for any flow of information you depend on that has no named person against it.
The first list is your calendar. The second is your problem, and it is the more valuable of the two.
Then build the row the plan is missing. For every input needed weekly — manpower, plant on site, quantities produced, deliveries received — write one line: the source, the named person, the format, the day it is due, and what happens when it doesn't come. Five columns, one page. If the plan already has it, twenty minutes are gone. If not, you have just written the part of it that governs whether you can produce anything at all.
Key takeaways
- The execution plan is about method rather than scope: how progress is measured, how change is handled, how information moves, who approves what.
- It is meant to be progressively elaborated as the project runs, not written once and filed.
- It is the document that answers when two parties disagree about how something should have been done, and the least-read one produced in these weeks.
- Adapted from the last project, it records decisions nobody on this project made — and looks identical to one that was decided.
- Under time pressure adapting a good document is the rational move, so the failure is structural rather than anybody’s laziness.
- The test is whether a sentence could have gone the other way here. If not, it described practice instead of choosing it.
- A plan with no tailoring in it isn't a bad plan but an empty one.
- A decision needs a chain behind it — owner, format, source, deadline, validation, reporting — and the plan is where all six are recorded.
- So the plan is a conversion mechanism between what was agreed and what can be operated, and a copied one converts somebody else’s agreements.
- The communications section is the most inherited and the most consequential, and the clause it is missing is what happens when information doesn't arrive.
- Where that is absent, information routes itself through whatever is fastest and no record is created by the transaction.
Records born here. The execution plan and its approval · the subsidiary plans it contains · the tailoring decisions, with the reason each was made · the communication and data matrix, including what happens when something doesn't arrive · the approval thresholds actually applying to this contract · your own list of what the plan requires of you personally.
What is coming next
The plan names roles. An approval sits with the project manager, information comes from the client's planning team, a submission goes to the Engineer.
Every one of those is an office rather than a person, and on a live job the distance between the two is where the delay lives. The next question is who is actually who — which organisation each name belongs to, what each one is allowed to decide, and what happens when the person who controls something you need has no obligation to you at all.
Enjoyed this lesson?
Join with Google to get each new lesson the moment it's published — and help me see which topics matter most to you. No spam, one email a week, unsubscribe anytime.
Already following on LinkedIn works too — this is just for the weekly email.