Why most project reviews arrive too late

Most organisations only call for a project review when something has already gone wrong.

Budget is slipping. The schedule has been rebaselined once too many times. There's noise around the team that won't go away. By the time an executive sponsor is seeing those signals clearly enough to act on them, the program has usually been in trouble for a while.

The symptoms are visible. The underlying causes are not.

Triggered by pain, designed around availability

That's the problem with traditional project reviews. They're triggered by pain, designed around availability, and take long enough to complete that the situation keeps moving while the review is still in progress.

Course correction is a lot cheaper than damage control. But the review that enables course correction has to sit inside the regular rhythm of a program, a pulse check rather than a post-mortem, giving leaders a clear and current picture before the symptoms force the conversation.

The wrong questions, taken at face value

Timing is only half the problem. Most project health checks ask the wrong questions. Not because the questions are bad, but because the answers are taken at face value.

We always ask whether the project objective is clear. Almost everyone says yes. Then we ask them what it is. The answers are rarely the same. People who believe they are aligned often aren't. That gap, between what people think is true and what is actually shared, is where most delivery risk lives.

Knowing what to listen for

Spotting that gap isn't just about asking the question. It's about knowing what to listen for. Recognising the version of "yes, we're aligned" that means something is being avoided. Understanding which role in a program is most likely to be carrying an assumption that hasn't been tested. Knowing which silence matters.

That comes from having sat in a lot of those rooms, across capital projects, infrastructure programs and large organisational change. You develop a feel for when the surface answer and the real answer are different things.

The framework we've built over those years means we don't miss anything. But the framework doesn't do the seeing. The people using it do. That's the part that can't be templated. And it's the part that determines whether a review produces a report or actually changes something.