Enter a search term such as “mobile analytics” or browse our content using the filters above.
That’s not only a poor Scrabble score but we also couldn’t find any results matching
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
The best time to review a project is probably months ago, when all seemed well.
It doesn't look good. The project has missed a major milestone. The team is working seven-day weeks. The project manager is off with stress-related illness. Quality has gone out the window.
And as for our customer, not at all happy.
We need to find out what’s really going on. It’s time to schedule a project review.
Actually, now is a bloody awful time to set up a review. The project team is already overloaded. Where are they going to find time to prepare, to meet with reviewers? A review will almost certainly create further delay, and stress.
And it won't be easy to conduct an effective review. Relationships have started to break down, so there’ll be a lot of accusations flying around. People will be trying to protect themselves. Reviewers will need to dig deep to find out what’s really happened. Yet more delay.
We also need to consider the wider messaging. This review is going to look like an announcement of failure. A sign that we don't trust the team to get the project back on course themselves. That’s going to make everything even more sensitive. Our reviewers had better be consummate diplomats.
Of course, now is a bloody awful time to do anything with this project. It’s in a mess. If we're going to fix it, we need a clear picture of what's gone wrong. A review will help untangle the mess, give us a firmer basis for action.
But the best time to review this project was probably months ago. People would have had time to talk to us. They wouldn’t be so defensive. The review would be much less painful all round.
It’d also be more effective. Reviewers would have time to think about what's going on. To generate hypotheses and drill down. If they find issues, we’d have time to fix them before they blow up.
The best time to review a project is when all’s well. When it doesn't seem to need reviewing.
How do we set up such reviews? here are two common ways.
When we set up the project, we can identify key points in its lifecycle. Times when we make major decisions, to approve the budget, to appoint an agency, to sign off on designs, etc.
These are good times to hold reviews. If we’re making a decision, we want good information. We want to ground it in a clear understanding of the project’s status. If anything isn't right, we want to clear it up before we proceed.
This approach tends to lead to a small number of substantial reviews. On a big project, each review may take several days.
We’ll probably try to look deeply at every aspect of the project. We might bring in external reviewers to ensure we get an independent view.
Gate reviews can cause a fair amount of disruption. Teams need to prepare for them. We need to pull reviewers off other projects. The payback is good decision-making: we make well-informed choices.
The alternative is to schedule reviews on a regular pattern throughout the project, say every month or six weeks. (I’ve even seen projects reviewed on a weekly cadence.
They were very lightweight reviews, but they helped bring issues into the open. One project manager called them her “weekly confessional”.)
Such reviews carry very little overhead. They’re very easy to coordinate: if we all know that the review happens at 2pm on the first Monday of every month, then we set up our diaries accordingly. And because we all get to know each other, we quickly slip into a rhythm at each meeting.
Meetings will be fairly short – perhaps a couple of hours. That’s time to look at major risks and key deliverables, and maybe spend a little time reflecting on what is and isn't working. These reviews don't delve deep into the entire project.
But they do pick up trends. Reviewers get a feel for the project, so they spot small deviations as they start to develop.
More importantly, project teams develop the habit of reflection, of stopping to think about what’s going on. Thus they become more adept at spotting impending issues for themselves.
You can combine these modes. Scheduling gate reviews at major milestones, with regular, lightweight reviews in between, is probably worthwhile on large, complex projects.
The key point is to set up the schedule in advance, as the project is being initiated. People can then plan for reviews – for preparation time, meetings, etc. The overhead is manageable when you expect it.
This has a useful side effect. When people are expecting reviews, they keep things tidy. They maintain risk registers. They update timesheets and other records. They get into the habit of stopping to reflect. They resolve issues as they arise.
So the project often ends up running pretty smoothly by itself. The more you review a project, the less it needs reviewing.