How to run a project review that people actually find useful

Why most reviews fail

Most project reviews are a waste of time. The team sits in a room, someone reads through a list of what happened, everyone nods, and nothing changes. The next project makes the same mistakes.

A good review does two things: it identifies what actually caused problems, and it produces specific changes the team commits to.

Separate what happened from why

Most reviews spend all their time on the what — deliverable X was late, feature Y had bugs, client Z wasn't happy. That's just a recap. Push past it. Ask why deliverable X was late. Was the scope unclear? Was the owner juggling too many projects? Was there a dependency nobody accounted for?

Limit to three wins and three improvements

Not ten, not fifteen — three. When you force prioritization, you focus on what actually matters instead of creating a long list nobody reads.

Make every improvement actionable

For each improvement, assign a specific action to a specific person with a specific deadline. "We should communicate better" is not an action. "David will write a project brief template by Friday and we'll use it for every new project starting next sprint" is an action.

Keep it to 30 minutes

If it takes longer, you're going too broad. A focused review that produces three real changes beats a two-hour session that produces a document nobody opens again.

The point of a review isn't to document the past. It's to change the future. If your reviews don't produce visible changes in how the next project runs, they're theater.