« How to Use Inch-Pebbles for Building Your Project Schedule - Introduction
Critical Chain Method/CCM of Project Planning and Control »

Project Review = Responsibility

August 9, 2008 | Author: PM Hut | Filed under: Miscellaneous

Project Review = Responsibilty
By Elizabeth Harrin

If you ask a colleague to run a project review for you, chances are at some time they will ask you to return the favour. They will look to you for an unbiased, clear and concise healthcheck of their project. It’s quite a responsibility – but not one to be afraid of.

The objective of a project review is to provide an independent overview of a project and help the project manager better understand where they are facing challenges. Reviews are often scheduled as part of the normal project planning process. Alternatively, one might be arranged because the project manager feels they are starting to lose their grip on the project and could do with a second pair of eyes to help bring things back on track. This is the first thing to understand when you are asked to review a project: is the project already in trouble or is the review just routine? The answer will help you better prepare for the review.

The second thing to establish is what the project manager wants to achieve from the review. The project manager should have an idea about what they want the review to cover. Encourage them to focus on a few key elements to give the review a structure.

To help you answer the fellow project manager’s key concerns you will need to look through the project documentation and talk to the project manager and perhaps members of his/her team. You don’t need to be an expert in the subject matter: the review is to look at how the project is being managed, not if Product X will sell well or whether the IT users have actually asked for what they need. Focus on how you can help the project manager run this project more efficiently. Do they have signed-off documentation? Is the plan up to date? Are their risks being managed effectively? You can prepare a lot of this in advance of your meeting with the project manager, and this pre-work will also help you develop a list of structured questions to ask, based on areas where you need more clarification.

Plan adequate time for the review. Even during a long review you will probably not have time to go sufficiently in depth to produce any recommendations of value. There’s another reason to avoid long reviews too: Normally there are one or two major aspects of a project that if improved, would give disproportionate benefits to future projects. Identifying these aspects is a much better use of your time than coming up with a list of actions that will make a marginal difference to the quality of the project. You will need to establish a balance between what is too long and what is too short to cover the key areas. The more time that can be given to a project review, the more relaxed and creative the team can be in understanding what has happened during the project and how they might improve in the future.

Before you meet the project manager, agree in what format the output will be and who will receive it. In most cases your primary responsibility is to the project manager. Encourage him/her to share the review results with his/her team and hierarchy. These results can be presented in a structured format or more informally.

Finally, make sure your report includes practical, actionable actions. Provide your feedback in a constructive way: there is no point saying that the change management process is not being applied properly unless you also explain what needs to happen to improve the way the project manager is using that process. Help the project manager understand your recommendations and allocate an owner and date to each task.

Once the review is over, the report produced and the results discussed, you can sit back, and watch that project improve, knowing that some day, someone will do the same for you.

Elizabeth Harrin is a project manager and author of Project Management in the Real World (BCS Books, available from Amazon), a case-study based analysis of techniques that can be applied by the time-starved professional to help effectively implement change. Elizabeth lives in London, England, where she writes the irreverent blog A Girl’s Guide to Project Management and has marginal success with her kitchen garden.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Saturday, August 9th, 2008 and is filed under Miscellaneous. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories