The meeting where nobody says anything.

A review that produces a performance instead of the truth is worse than no review at all. It burns ninety minutes and issues a certificate of health to a project that's bleeding.

So this week: how to run one that works, and how to audit whether your own model deserves to be believed.

You are owed three reviews

Most organisations run one kind of review, and think they've covered it.

Status is the one everybody does. Are we on time, on budget, on scope? Everything from Weeks 16 to 22 lives here.

Design asks something much less comfortable: is this still the right thing to build? Requirements age. The client's business changes. The answer might be proceed, or pivot, or — occasionally, honourably — stop. And almost nobody asks it after month three, because by then everyone is too invested to want to hear the answer.

Process asks the question that compounds: how would we have known sooner? This is the only one that makes the next project better, and it's the first one cancelled when things get busy — which is precisely when it's worth the most.

One number to triage

Before the conversation, a screening tool worth knowing.

Multiply your cost efficiency by your schedule efficiency and you get a single blended health number. On our project: 0.79 × 0.75 = 0.59.

Between 0.8 and 1.2, you're in the noise. Document it, don't panic.

Below 0.8, intervene. Below 0.6 — where we are — something has broken that a site manager cannot fix. That's not a variance any more; that's a systemic failure, and it escalates above your head today, not next quarter.

And the counter-intuitive one: above 1.3 is also a red flag. Nobody is 30% better than their own plan. What you're almost certainly looking at is a padded baseline or bad data. The right response is an audit, not a celebration — and the right person to raise it is you, before someone else finds it.

One warning, though, and it follows straight from last week: this number is a composite, and composites hide things. Use it to decide which packages deserve an hour of your attention. Never use it as the answer. The blend tells you where to look; it never tells you what you'll find.

Auditing the model itself

Now turn the review on the schedule — not on the project.

Because your entire reporting stack sits on one file. If that file is structurally unsound, every index in it is a beautifully calculated fiction, and no amount of review discipline will save you.

A schedule audit sorts everything into two piles. There are essentials — sound logic, real calendars, no open ends, no constraints faking a date — and there are the extras that earn a mature model additional credit.

Here's the part that surprises people. The essentials are not weighted. They're a gate. Miss a single one and the model doesn't get a lower score — it gets no score. It's classified as a draft, and nothing calculated from it can be relied on.

That sounds harsh until you remember Week 17. One dangling activity manufactures float out of nothing. One hard constraint absorbs a ten-day delay in silence. These aren't imperfections that shave a few points off a grade — they are faults that make the model lie. There is no partial credit for a schedule that lies quietly.

And one more principle worth pinning up: switching a feature on earns you nothing. Your software has a risk module. Having it is not risk management. Loading resources into fields nobody maintains is not resource management. The credit comes from using the thing properly, and from nowhere else.

An unverified schedule is just a very confident drawing.

Why nobody tells you the truth

Now the hard part, and it's not technical.

The most valuable information on your project lives in the heads of people who have concluded, correctly, that saying it out loud will cost them.

It comes down to one question, asked in one of two ways.

"What went wrong?" is a hunt. Everyone in the room hears it as whose fault is this, and they respond the way anyone sane would: they defend, they hedge, they get quietly vague. Ask it enough times and your people stop bringing you problems while the problems are still small — which is the only time problems are cheap.

"How would we know sooner next time?" is a completely different question, and it produces completely different information. It's about the system, not the person. And it's answerable without anybody having to lose.

The distinction to hold onto: an explanation is not an excuse. An explanation is an honest account of how the system produced this outcome — and it's data. An excuse is a refusal to change anything. Accept explanations gladly. Decline excuses politely. Confuse the two and you'll either be lied to or resented, and usually both.

Keep the feedback concrete, too. "Communication is poor" is unusable and everybody nods. "The revised drawings reached the steel fabricator four days after issue, and cost us a week of rework" is a fact, and it points at a fix.

Fix four things

Reviews fail at the end more often than at the start. You've built an honest list of twenty problems, everyone agrees, and then nothing happens.

Because twenty is the same as zero.

Pick four. No more. Let the team vote on which four actually hurt most — not the ones the loudest person named, and not the ones easiest to fix.

Then give each one a name and a date. Not a department. Not "the team." A person. An action assigned to a team is an action assigned to nobody, and every one of us has watched a well-intentioned improvement list die exactly that way.

Four fixed beats twenty listed, every single time.

Twenty-two weeks of technique, and it all rests on two fragile things: a model somebody audited, and a room where somebody felt safe enough to say the uncomfortable thing. Lose either one and the rest is decoration.

Practical insight

At your next review, change one question and watch what happens.

Instead of asking each package lead for a status, ask them: "What's the thing you're most worried about that isn't on this report?"

Then be very careful with the first answer you get. If the person who says it is thanked, you will get honest reviews for the rest of the project. If they are challenged, corrected, or made to look foolish, you will never get another one — and you'll have taught the whole room exactly what happens to people who tell you things.

Key takeaways

✔ Three reviews, not one: are we on track, is it still the right thing, how would we know sooner.
✔ Cost efficiency × schedule efficiency gives one blended number for triage.
✔ Below 0.6 is systemic — it escalates above the project, today.
✔ Above 1.3 isn't excellence, it's a padded baseline. Audit it.
✔ The blend tells you where to look; it never tells you what you'll find.
✔ Schedule essentials are a gate, not a score — one open end and the model can't be trusted.
✔ Turning a feature on earns nothing. Using it properly is the whole point.
✔ "What went wrong" hunts people. "How would we know sooner" fixes systems.
✔ Accept explanations, decline excuses, and fix four things with four names on them.

What's coming next

The review is honest and the model is sound. Which means the schedule can now do something it was never designed for, and will absolutely be asked to do.

Two years late, in a room full of lawyers, someone is going to ask which delays were the client's and which were yours — and the only witness will be the file you updated every month.

Next week: forensic schedule analysis. Delays, claims, and how the boring discipline of a monthly update becomes the most valuable document on the project.