The Five Questions You Need to Ask in a Project Review
By Payson Hall

Rookie project managers often dread project reviews the way children dread a trip to the dentist. They aren’t sure what to expect. Everyone knows it is easier to criticize work than to do work, and we all have heard tales of reviewers who fixate on trivial matters. But an effective project review can be healthy and constructive.

Read more stories about software project management at

When I review a project, I have five basic questions:

  1. Is there a clear definition of the project? The definition of “done” should be written down, and budget and schedule goals should be clearly described. Significant changes should be approved by project sponsors.
  2. Is there a credible plan to achieve the goal? Credible doesn’t mean perfect, but it does mean complete enough to be reviewed, plausible, and consistent with project history.
  3. Is timely and accurate information about status, risks, and issues available and being conveyed clearly and consistently to project sponsors?
  4. Does the business case for the project make sense based on the best information available?
  5. Do the project manager, project sponsors, and project team members all believe that the first four things on this list are adequately addressed?

As projects get larger and more complex, there are details that must be reviewed, but I should be able to link any findings or recommendations back to fulfilling one of these goals. Otherwise, it’s a sign I’m getting bogged down in minutiae and bureaucracy.

We don’t need estimates of time and cost because some project management book says we need them; we need these estimates so we can build credible schedules and budgets. We need credible schedules and budgets because we need to be able to tell the sponsors whether we think the business objectives will be met within their cost and schedule expectations. Only the sponsors can decide if our best current prediction of cost and schedule are consistent with their business case.

Effective project management is about doing the things that need to be done to manage the project’s progress and support sponsors’ decisions. All projects have issues. When issues arise, a reviewer should only be troubled if the issues aren’t acknowledged and communicated to project sponsors. (Unless the same issue bites a project repeatedly, which tells me risks aren’t being managed.)

A good reviewer should have the experience and wisdom to know what’s important and what’s necessary. Everything that is important is necessary, but not everything that is necessary is important.

Review findings also should offer suggestions on priority. I have a list of items that I look for during a review, but the list is always adapted to the context of the project. Size, complexity, business case, and business risk must all be considered before making suggestions. Should a project have a cogent way of identifying, monitoring, and reporting on risk? Yes. Is having formal risk management plans more important for a space shuttle project than an employee holiday party? Certainly.

Project reviews can be your friend. Be honest and don’t downplay the consequences of issues, but do point out what was learned or what has changed in response to issues. Above all, be prepared to demonstrate that continuing the project is a conscious sponsor decision based on credible information about project progress.

Related TechWell Insights
Know the “Why” behind Your Projects
Agile Methods for Tackling the Work You Don’t Want to Do
The Difference between Plans and Planning

Originally published at