Select Page


12 Tips for Effective Project Reviews

12 Tips for Effective Project Reviews
By Bruno Collet

Too often, project reviews are nothing more than empty conformance documents that take dust on a company server, when they are not skipped entirely. That’s a shame, because project reviews are one of the most powerful tools for improvement. The main reasons people neglect project reviews are that “nobody reads them” and that “we got assigned to another project right away”.

How can we design a project review process that entices the organization into giving it the attention it deserves?

Here are 12 tips for effective project reviewing:

  1. Cost-effective: the expected benefits exceed the effort required to perform the project review;
  2. Applied when it makes sense: make the project review mandatory or optional based on criteria such as level of risk, degree of novelty, and budget;
  3. Organizational asset: store and communicate the project review so that it brings benefits not only to the project team but also to other teams and possibly other parts of the organization; it helps accumulating know-how and improving organization-wide;
  4. Part of the project management process: the project review process is a part of the closing phase; the project is not finished until the project review is done;
  5. Standardized (but flexible): there is a template and a guide to support project managers in writing effective project reviews;
  6. Based on information known to the team: writing the project review doesn’t require the participation of people outside of the project team – no need for research, surveys, or other tedious tasks;
  7. Team participation: the team is involved in the project review process to collect qualitative feedback;
  8. Based on available metrics: writing the project review relies on standard metrics that are located in project management documents accumulated throughout the project;
  9. Comparable: the project review format enables comparing projects results thanks to objective scoring based on standardized metrics;
  10. Action-oriented: the project review proposes an action plan to implement the lessons learned;
  11. Follow-up: someone manages the implementation of the action plan and makes sure that target stakeholders have the opportunity to implement the suggested improvements;
  12. No fault: the project review is not an evaluation of the project manager or of the project team.
Read the Complete Article

How to Prioritize Your Backlog and Go Live ASAP

How to Prioritize Your Backlog and Go Live ASAP
By Bruno Collet

We will look at a 7-step technique to prioritize a product backlog in order to release a working system in the shortest possible timeframe. This article is presented with a methodology-neutral point of view; it can be used with any Agile-style framework.

Step 1: Describe the Target Release

The goal of prioritizing the product backlog is to to release the desired product as soon as possible. The key here is to define the “desired product”. Before even starting the prioritization, every stakeholder has to agree on the the objective of the release. For example, it can be a prototype, a public beta, or a update to an existing commercial version. The characteristics of the release must be expressed in a few lines in the form of benefits or high-level features that deliver value to users and/or clients.

An example for the first private beta of a job searching website would be:

It allows users to search and apply for jobs in the most basic way. Read the Complete Article

Organizational Paradigms to Scale Agile

Organizational Paradigms to Scale Agile
By Bruno Collet

This article provides an overview of issues that arise when scaling agile projects and organizational paradigms that help solve these issues. The analysis is based on personal experience and some research (see references at the end).

To preserve agile strengths, all agree that the team size should be limited (upper limit is 8-to-12 depending on opinions). Consequently, scaling agile necessarily implies setting up a multi-team organization.

Additional needs for multi-team agile include (but are not limited to):

  • Handling cross-team impediments
  • Ensuring alignment with strategic objectives
  • Dividing the work among multiple teams
  • Integrating the work of multiple teams in cohesive product releases
  • Maintaining a common foundation of practices and tools across multiple teams
  • Facilitating the emergence of a sound product-level architecture

We will explore a few organizational structures that may help cope with these extra needs. These structures are provided as a starting point and should be adjusted and combined according to the context. Read the Complete Article


PM Hut currently has 570 contributors! Please contact us in case you’re interested in publishing your Project Management articles on PM Hut and joining the list below!

An article published on PM Hut may be eligible for PMI PDU credits under the Category D of the CCR Program (Giving Back to the Profession). This category is capped to 45 PDUs per 3 years. Authors claiming their PM Hut published articles for PMI PDUs are required (by PMI) to supply PM Hut’s physical address in their application. Please contact us for this information.

Please note that it is the responsibility of the author to handle the whole process for claiming the PDUs, PM Hut’s role is currently only limited to supplying its own physical address to the author.

1 – A1 Enterprise 286 – Karl Fischer
2 – Aaron Sanders 287 – Kathlika Thomas
3 – Abdulla Alkuwaiti 288 – Katy Whitton
4 – Abhijat Saraswat 289 – Kay Wais
5 – Abhilash Gopi 290 – Kaz Young
6 – Adam Leggett 291 – Keith Custer
7 – Ade Miller 292 – Keith L.
Read the Complete Article

Recommended PM App

Recommended PM App