The best analysis I ever did changed nothing

Twenty-six weeks. A model that doesn't lie. Numbers that forecast the ending. Evidence that survives a courtroom. A report someone will actually act on.

And all of it can be defeated, completely, by one person who has decided in advance not to hear it.

So let's finish with the half of this job that nobody teaches.

Every planner learns this the same way. You build something rigorous, you present it, it is correct — and nothing happens. Not because anyone disputed the maths. Because the room wasn't ready to hear it, and you had spent your energy on the analysis instead of on the room.

Everybody moves

Start with the mistake almost everyone makes: drawing the stakeholder map once, at kick-off, and filing it.

THE MAP YOU DREW IN MONTH ONE IS WRONG DESIGN PROCUREMENT CONSTRUCTION TESTING HANDOVER The regulator neutral neutral neutral against neutral The neighbours against neutral against neutral for The client's ops team neutral neutral for for against Power, interest and stance all move. Every one of them. The quiet regulator becomes the whole project, the week you start testing. A stakeholder map is not a document. It is a habit.
Figure 1 — Influence is fluid. Power, interest and stance all move through the life of a project. The stakeholder who barely registered at design can become the entire project by testing.

The regulator was fine. Neutral, uninterested, barely present through design and construction. Then you reach commissioning — and suddenly that quiet person holds your handover date in one hand, and has questions nobody prepared for.

The neighbours were furious at planning, then forgot about you, then rediscovered you when the piling started. The client's operations team loved the project right up until they realised they'd have to run the building, and now every detail is a negotiation.

Nobody's position is stable. Power moves, interest moves, and support quietly becomes opposition while you're looking at a Gantt chart. A stakeholder map isn't a document you produce. It's a habit — a question you ask yourself every month, along with all the others.

Who your red numbers are for

Now the relationship that determines whether any of this matters.

For twenty-six weeks we've built machinery that produces uncomfortable truths — the float is gone, the efficiency is 0.79, the baseline is unrecoverable, we need a decision by the 14th.

Every one of those needs somewhere to go.

TWO JOBS THAT ARE NOT THE SAME JOB You You run the project. Is it being built well? The sponsor Makes sure it is worth running. Should it be built at all? Only one of you can release the money, move the date, or stop the job. Every red number you have produced for 26 weeks needs somewhere to go. That somewhere is a person, with authority, who will take a decision. No sponsor, no escalation path. Your analysis dies on your desk, and the project fails on schedule.
Figure 2 — The sponsor. You run the project. The sponsor makes sure the project is worth running — and holds the authority to release money, move dates, or stop the job entirely.

Here's the distinction worth being precise about: you run the project. The sponsor makes sure the project is worth running.

You cannot authorise more money. You cannot move the completion date. You certainly cannot stop the job. Those powers sit with one person, and if that person is absent, disengaged, or purely ceremonial, then you have no escalation path — and every red number you produce dies quietly on your desk while the project fails exactly on schedule.

Which makes the sponsor relationship the highest-leverage thing you own. Not the model. The model only matters if somebody acts on it.

So brief them before the meeting, not in it. Never let a sponsor discover a crisis in front of their peers — do that once and you'll have an enemy who used to be your route to a decision. Bring them the problem early, with options and costs, and let them do the thing only they can do.

The thermometer in your change log

And here's a measurement most planners never think to take — using data you already have.

CHANGE REQUESTS ARE A THERMOMETER M1 M2 M3 M4 M5 M6 M7 M8 change requests this is not a process problem A spike here means you missed the agreement months ago. They are not changing their mind. They are telling you what they always wanted.
Figure 3 — The alignment thermometer. A sudden spike in change requests is rarely a process failure. It is the sound of an agreement that was never really reached.

Plot your change requests by month. A steady trickle is normal — that's a project in contact with reality.

But a spike is a signal, and it's almost never about change control. It means the client is discovering, in month five, what they actually wanted — because nobody made them say it in month one.

This is the uncomfortable arithmetic behind most overruns: more than half of all project failures are seeded in the requirements, not on site. The building was built beautifully. It was just never quite the building they had in their head, and nobody found that out until it was standing.

The gap is a language problem. Clients speak in operational pain — "the loading bay is chaos every morning." You need parameters: how many vehicles, what turning circle, by when. Nobody is being difficult. You are simply two professions with different vocabularies, and the translation is your job, not theirs.

So when the change requests spike, don't reach for a stricter process. Go and ask what was never properly agreed. They are not changing their mind. They are finally telling you what they always wanted.

Speak the organisation's language

Two shorter things, both of which cost nothing and change everything.

Mirror the culture. In a flat, informal organisation, a rigid twelve-page monthly report is a wall between you and the people you need. In a hierarchical one, a casual message that skips a level isn't refreshing — it's a discourtesy someone will remember. The same information, delivered against the grain of an organisation, arrives as noise.

Your team are stakeholders, not headcount. They are the only people who know what's really happening on site — and whether they tell you depends entirely on what happened to the last person who did. We built this in Week 23, and it belongs here too: the psychological safety of your team is not a soft nicety. It is the raw data supply for every number in this series.

"Flawless technical execution cannot save a project with fractured relationships."

— THE GOLDEN RULE OF ENGAGEMENT

The last thing in this series, and the first thing to remember

Build the systems with mathematical rigour. Manage the people with genuine human empathy. Twenty-seven weeks, and that sentence is the whole job.

Where this leaves you

Look back at what we've built.

You can take a charter and turn it into a structure. You can build logic that survives contact with a site, estimate durations honestly, find a critical path by hand, level a plan against the crew you actually have, and tell a client that their date has a four percent chance.

You can keep a model honest through eighteen months of updates. You can say, in month six, what a project will cost in month twenty-four — and what efficiency a recovery would truly require. You can protect a baseline, survive a review, and hold your own in a room full of lawyers.

And now you know the part that makes all of it work: that a number only matters when it reaches a person who can act on it, at a moment when they are able to hear it.

That's the job. Not the software. Not the certificate. The judgement.

The plan will still be wrong. It always is. But you will now know it is wrong early, you will know by how much, you will know who needs to hear it, and you will be able to prove it two years later.

That is what a planner is for.

Practical insight

One last thing, and then you're on your own with it.

Take the single most uncomfortable number on your project right now — the one you have been slightly softening in the reports, because saying it plainly would cause a difficult conversation.

Work out who can actually do something about it. Go to that person, before the next meeting, and say it plainly. Bring the options and what each one costs.

That conversation is the whole of project controls. Everything in these twenty-seven weeks exists to make sure that when you finally have it, you are right.

Key takeaways

✔ Technical excellence cannot repair a broken relationship — and it will never try.
✔ Power, interest and stance all shift: the quiet regulator owns your handover date.
✔ A stakeholder map is a monthly habit, not a document you produce once.
✔ You run the project; the sponsor makes sure it's worth running. Only they can decide.
✔ No sponsor means no escalation path — your analysis dies on your desk.
✔ Never let a sponsor discover a crisis in front of their peers.
✔ A spike in change requests is missed alignment, not a broken process.
✔ Most failures are seeded in requirements, not on site. The translation is your job.
✔ Mirror the organisation's culture, or your information arrives as noise.
✔ Your team's safety is the raw data supply for every number you will ever report.

Thank you

Twenty-seven weeks ago this started with a claim: that planning is not scheduling software, and that the discipline behind it can be taught.

If you've read this far, you now have the whole of it — the structure, the logic, the mathematics, the evidence, the message, and the people. It took me fifteen years and several bruising projects to assemble. You got it in twenty-seven Wednesdays.

Go and build something, and know where it stands.

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.