GPM First

GPM First Aid

When is the best time to review a project?

The best time to review a project is when it doesn't need reviewing, suggests Graham Oakes.

Things don’t look good. The project has missed several milestones. The customer is complaining about the quality of the deliverables. The project manager is working a 70-hour week. Key team members are off with stress-related illnesses.

It’s time to find out what’s going on. Perhaps we should schedule a project review?

Actually, this is a pretty awful time to schedule a review. The project manager and team, already overloaded, will almost certainly need to take time out to prepare and meet with the reviewers. That’s going to create further delay, and stress.

And the team will probably see this as an announcement of failure; a sign that you don't trust them to sort out the project themselves. So they may resist the review – try to put a positive gloss on things, for example, or redirect blame towards other teams. Reviewers are going to need extra time to dig through this finger pointing.

Of course, this is probably a pretty awful time to do anything with this project. But one thing is certain: you can't act effectively without a clear picture of the project’s status and issues. So a review will probably help you untangle the mess.

But the best time to review this project was probably a long time ago.

If you review projects when they’re still looking good, then you have a chance of unearthing incipient issues before they blow up. You can fix them before they have too much impact.

So the best time to review a project is when it doesn't (visibly) need reviewing.

There are two common ways to do this:

  1. Review at pre-defined points (gates) in the lifecycle. Identify key decision points in the project lifecycle – initial approval of the budget, appointment of lead contractors, commitment to major design options, etc. – and schedule reviews as a precursor to deciding. That ensures these decisions are grounded in a clear understanding of the project’s status and options. And it gives you the chance to identify and fix issues before proceeding to the next stage.
  2. Review frequently, on a regular cadence. Schedule reviews on a regular pattern – perhaps every month or six weeks – throughout the project. Such reviews can be very easy to coordinate: if people know that reviews happen at 2pm on the last Thursday of every month, then they can keep that time slot available.

The first approach, gate reviews, tends to lead to a small number of substantial reviews. It may involve bringing in external reviewers in order to obtain an independent view of the project. These reviewers need time to get up to speed. They then try to delve deeply into the project, to ensure they understand exactly what is going on.

So those reviews can take several days, or even weeks. They cause a fair amount of disruption. But they give a lot of confidence that we understand just where the project is at.

The second approach often leads to a more lightweight style of review. A small, stable review team meets with key members of the project team, with each meeting lasting no more than a few hours – enough time to examine major risks and issues, reflect on what is or isn't working, and assess overall status. There’s no time to delve deeply into the entire project.

What frequent reviews do well is pick up trends. Reviewers get to understand the project, so they can spot small deviances as they start to develop. And project teams develop the habit of stopping to think about how things are going.

Or you can do both – schedule gate reviews at key milestones, with regular, lightweight reviews in between. That’s probably a good strategy for large, complex projects.

Either way, you still need to manage the impact of the reviews themselves. Each review creates an overhead – time to prepare, time to participate, time to act on findings. But this overhead is small when the review is expected, a normal part of the project lifecycle.

When people are expecting regular reviews, they create reviewable artefacts. They keep their plans up to date. They maintain their risk registers. They ensure that timesheets and other records are accessible. Reviewers can get the information they need without asking too much of the project team.

Perversely, this often means that the project runs more smoothly. Teams that take time to reflect on their plans and suchlike tend to spot issues themselves.

So the more you review a project, the less likely it is to need reviewing.

 

Submit your own content for publication

Submit content