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.

Reviews can also be performed during the course of a project, at end of phases or iterations for example, in order to benefit from improvements as soon as possible.

Over time, effective project reviews make the difference between an evolving and a stagnating organization by enabling small and meaningful improvements as well as fostering a culture of excellence.

These days there is a lot of talk about "documentation" around me. In the world of software development, documentation is often perceived as an annoyance, a necessary evil at best. This post is a follow-up on my previous post The right amount of documentation.

Documents are not equal, and many people fail to understand that some factors greatly influence how they should be written.

Consider the following types of documents, inspired from software development tasks:

• Notes taken for myself to be used in the following days
• Annotated sketches to be used to brainstorm with two of my colleagues in the following days
• Diagrams to be used to communicate with users in the following weeks
• Technical specifications for a subsystem to be presented to software designers and kept as reference
• The description of a software application to be used as reference in the organization by anyone who needs to understand what the application does
• A conformance document demonstrating that we comply with some ISO standard

Obviously, these documents will be subject to wildly different writing styles.

There are three factors that considerably affect how a document should be written:

1. Readers' knowledge about the topic: We have to understand to what extent the intended readers know the topic and the context. We can omit what readers already know. If you look at documents around you, you will probably notice most are either underdocumented or overdocumented. Assessing the appropriate level of detail is a critical part of efficiency, both for an organization and for an individual. We tend to err toward overdocumenting because it feels safer but actually it's just as damaging as underdocumenting, since maintaining heavy documents generates inefficiencies long after the document is produced.
2. Document lifecycle, or criticality: Most documents are not kept as references; they will be used for a limited period of time, for a specific purpose, then left to "die" (i.e. become obsolete). On the other hand, some documents will live as long as the object they document, and will have to remain up to date, possibly for several years. Long-lived documents are expected to influence the area they address much more than short-lived documents.
3. Adherence to existing standards: Why would someone reinvent how a project status or how meeting minutes look like? In many instances a quick search on internet (or on the company network) will yield decent Word templates for common documents. I have nothing against creativity, unless it's just for the sake of doing things differently.

I believe that standardizing the documentation process can significantly help. More on the tricky issue of standardization in further posts.

Even experience doesn't prevent us from underestimating the effort and the time required to reach an objective.

It all comes down to the definition of "done". Let me illustrate this with a simple example. If I state that "the objective is to implement a new format of project status", most people will assume that once we have a nice template of project status satisfying the needs, the job is done, whereas I expect the project status to be used by the teams, hence a series of tasks for validating, communicating, presenting, and controlling the use of the new project status format. We have a natural bias to focus on (1) analytical work and (2) work than mainly involves ourselves and not others. In other words, we tend to overlook tasks that require collaboration and communication, and more generally how much effort is needed to implement the change in order to reap the benefits.

When estimating how much time and effort are needed, I go through this simple list.

1. Formulate the needs and identify stakeholders. Don't forget to check stakeholders' availability.
2. Validate needs with client
3. Break down into tasks
4. Perform initial analytical tasks (by myself)
5. Adjust deliverables by collaborating with relevant stakeholders
6. Validate final version of deliverables with stakeholders
7. Prepare communication material (ex: PPT, how-to)
8. Publish relevant material
9. Present and promote solution to users
10. Coach users as needed (over specific period of time)
11. Control results, adjust deliverables if necessary
12. Report final results to client

It's like a mini-project, really.

Poor estimates will focus on tasks 3-to-6 and then assume that the work is done. In my experience, in any complex organization the effort for tasks 1-6 seldom exceed 50% of the total effort.

To summarize further the previous list of generic tasks, let's look at the 3 main activities:

1. Initiate (tasks 1-3)
2. Execute (tasks 4-6)
3. Implement (tasks 7-12)

The main effort consists in implementing the solution, i.e. making sure "users" use the solution as intended, without any need for supervision. In this light, we understand that any "small" change, to a process for example, triggers several tasks that go far beyond changing the process in itself. There are actually two dimensions of complexity in any change: analytical and organizational. To me, the organizational dimension is by far the hardest to handle because it involves stakeholders whose reactions (and resistance) is difficult to anticipate.

Many organizations are plagued by half-baked initiatives, things that have been started but never properly completed. They incurred most of the costs, but little of the benefits. Unsurprisingly, it's usually the implementation part that is lacking. Folders of organizations are full of great analyses and recommendations that have not been deployed. Avoid this huge waste: determine what "done" means from day one.

One of the reasons I believe in Agile principles is that it emphasizes what "done" means: it's done when it delivers value to the users. It has been designed primarily for software development but it can be applied to any subject.