Nobody said no
A sequence change is needed. It saves three weeks, everybody at the coordination meeting can see that it saves three weeks, and it affects the scope of three companies.
Nine weeks later it has not happened. Nobody has refused it. It went to one company's regional office for a commercial view, to another's board because it crossed their delegation limit, and to the third's technical authority for review. Those three bodies meet monthly, on different weeks, and none of them was waiting for the others.
There was no obstruction and there is no one to chase. The three weeks the change would have saved were spent obtaining permission to save them.
Agreement isn't authority
The coordination meeting is where this goes wrong, and it goes wrong pleasantly.
Everybody in the room agrees. They are the right people, they understand the problem, and their agreement is genuine. What none of them has is authority to bind their own company to something that changes its scope or its price.
So the meeting produces a consensus, the minutes record it as agreed, and everybody leaves believing a decision has been taken. What has actually happened is that three separate approval processes have been started, informally, by three people who will now have to explain the proposal to somebody who was not in the room.
On a single contract that gap barely exists: the Engineer determines, or the employer instructs, and the authority sits inside the process. Across organisations the authority sits inside each company, and the project has no visibility of it at all.
Three gates, three calendars
What determines how long this takes isn't goodwill. It is the shape of each party's internal governance, and it is knowable in advance.
Each company has a delegation limit — a value above which the site can't commit and something more senior has to. Each has a body that takes those decisions and a cycle on which it meets. Each has its own view of what constitutes a change worth escalating.
A proposal that sits below every party's threshold is decided on site in a day. The same proposal a little larger crosses one party's limit and waits for their monthly board. Larger still and it crosses all three, at which point the lead time isn't the sum of the three cycles but the worst case of them — and worse if any one of them asks a question that sends it round again.
None of that is dysfunction. It is three companies each running a normal approval process, and the project is the place where the three calendars collide.
The failure with no signature
Here is what makes this different from an ordinary delay, and it is the reason the week exists.
When somebody refuses a decision, the refusal is an event. It has a date, a person and a reason, and there are mechanisms for what happens next — escalation, determination, a claim. It is unwelcome and it is visible.
A decision that is merely waiting produces none of that. There is no document recording that it has not been taken. Nobody has failed to do anything, because everybody is doing exactly what their own company requires. The programme slips by an amount nobody authorised, and afterwards there is no event to point at.
Which is why it survives so long. Every other cause of delay on a project generates paper of some kind. This one generates silence.
Lead time is a planning object
The useful move is the one Reporting Week 15 made for approvals: stop treating it as administration and put it in the programme.
A decision has a lead time. That lead time depends on which parties it crosses, what each of their thresholds is, and when their bodies meet. All three are findable before any particular decision is needed, and they change rarely.
Once they are written down, two things become possible that were not before. A decision needed for a March start can be raised in January rather than in March. And a proposal can be shaped to stay below a threshold when the saving doesn't justify the wait, which is a planning judgement rather than a commercial one.
What to record
The decision register from Reporting Week 24 needs two more columns on a multi-organisation job.
Which parties it crosses, because that determines the route. And which body in each party will take it, with the date that body next meets, because that determines the date.
With those two the register stops being a list of open items and becomes a forecast. An entry can be read as: this decision is required by the fourteenth, it crosses two parties, the later of their two boards sits on the ninth, and therefore it has to be lodged by the twenty-fifth of the previous month. That is a date somebody can work to, and it is the only form in which this problem is manageable.
System design
The first two rows are gathered once and change rarely. Everything else on this page depends on having them.
| Record | Produced by | Required quality | Verified against | Feeds |
|---|---|---|---|---|
| Delegation limit per party | Project controls | The value above which site can't commit, per company | Each party’s own procedure | Which route a decision takes |
| Approval cycle per party | Project controls | Which body decides and when it next meets | Their meeting calendar | The required-by date |
| Decision register | Project controls | Route, approving body, and lodge-by date — not just an owner | The two rows above | Look-ahead · programme |
| Agreed versus authorised | Project controls | What a meeting agreed, and whether anybody could bind it | The minutes | What is actually decided |
The third row is what turns a decision log into something a programme can use. An owner and a due date describe an intention; a route and a lodge-by date describe when the answer can physically arrive.
Practical insight
Take the oldest open item on your own decision log and find out where it actually is.
Not who raised it — who is holding it now, which body has to approve it, and when that body next meets. There is a fair chance your answer is that nobody is considering it at all, because the person who took it away is waiting for a paper somebody else in their own company has to write first.
Then do the part that pays. For each party on your project, write down their delegation limit and their approval cycle. Three phone calls and an afternoon, and from then on every decision you raise carries a date you can plan against instead of an open one you have to chase.
Key takeaways
- A decision crossing three companies isn't refused. It waits, in three separate approval processes.
- Agreement in a coordination meeting is genuine and isn't authority to bind a company.
- The minutes record a decision. What started was three informal escalations to people who were not in the room.
- Lead time is set by each party's delegation limit and the cycle on which its approving body meets.
- Crossing several parties gives the worst case of their cycles, not the sum, and worse if anybody sends it round again.
- A refusal is an event with a date and a mechanism. A decision that waits produces no document at all.
- Every other cause of delay generates paper. This one generates silence, which is why it survives.
- Record which parties a decision crosses and when their bodies meet, and the register becomes a forecast.
Records born here. The delegation limit and approval cycle for each party · the decision register with its route and its required-by date · the note of what was agreed in a meeting and what was actually authorised.
What is coming next
Everything so far has treated the employer as one party with one interest. On a financed project it is a vehicle with lenders behind it, and they appoint their own adviser.
Next week: when the employer is a vehicle, and the second Engineer nobody planned for.
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.