The ideal project review

“Wow, that was a terrific project! A success from start to finish!” Or: “Unfortunately we couldn’t reach our project goal. We hadn’t defined one!” Two different statements at the end of a project. Two statements that might be made in the course of a project review. According to the definition, a project review is a retrospective of a completed project phase or a completed project. The goal is to learn from the past in order to design projects even better in the future. What went well, what could have gone better and what can be learned from the experience gained?

Unfortunately, a project review sounds much easier in theory than it often is in practice. Dirty laundry is easily washed, details are blown up in discussions and the central theme and thus the goal is lost sight of. How can this be avoided? How important is moderation, a coordinated approach and the timing for a successful project review? And when is it a successful review at all?

The purpose and benefits of project reviews

The primary benefit of a project review usually lies in increasing efficiency, i.e. in the question of how we can implement such or similar projects even faster, more cost-effectively and/or with better results in the future. If one takes a look behind this rather general statement, different advantages can be noted:

• The increase in effectiveness, starting with the prioritisation and selection of projects. First of all, it is important to do the right thing, then it is important to do the “things” right.
• More clarity about procedures, organisation, planning, tasks and goals.
• The identification of methodical weaknesses such as, for example, the collection of requirements, the implementation of brainstorming sessions or the handling of impediments.
• Improvement of internal cooperation, i.e. within and between teams; also improvement of communication, including channels, frequency and duration.
• Optimisation of external cooperation, i.e. with clients, partners, customers. Or in other words: improving stakeholder management.
• The derivation of best practices or ideally good practices and the identification of worst practices.
• Identification of defined metrics.

This list can be continued at will. However, in order for a project review to fulfil its purpose, organisations should discuss and agree on it individually at the beginning of the exchange, possibly even in advance. As a result, the composition of the participants, for example, could change. If, for example, it is an internal team review, no members of other teams or representatives of the specialist departments will be invited. If the review addresses the entire internal organisation, external stakeholders will not participate in the exchange.

A possible process of a review

Of course, there are many different ways to conduct project reviews. In addition to purely organisational aspects – who participates, when does it take place and where, how long does it take, who moderates it, who visualises and documents the findings, how is the handling of technical equipment during the exchange, etc. – as well as the determination and communication of the purpose or goals, there are usually four phases in a project review:

• The collection of information.
  Sometimes the collection of information takes place in advance through interviews or questionnaires. On the one hand, this offers the great advantage that the interviewees do not feel affected by colleagues or superiors present – always provided that open and honest communication is desired and actually possible in the company at all. Especially introverted employees get the chance to express their opinions. However, conducting interviews and/or designing questionnaires is very time-consuming, especially since the results have to be evaluated and prepared for the subsequent dialogue. This relatively large effort therefore often leads to a collection of information on site, together in a team.
  The moderator is in demand for the joint collection of information live and in colour. He gives the process a structure and explains it to the participants. For example, he could orient himself to project phases such as preparation, planning, implementation, project completion, commissioning, etc. Or he addresses the respective disciplines such as requirement management, project management, change management, reporting. Which structure is best suited depends on the specific project. However, it is advisable not to create an “artificial” structure, but to use one that was also used in the project itself. And of course it is not a question of separating the findings, but of a structured determination. Therefore, the moderator should also pay attention to connecting elements between the structuring elements, for example by asking: “What worked well in the cooperation between the project manager and the sales manager as representative of the customer, what can we improve?
• The collaborative exchange of information.
  Here, too, the moderator is important, because every participant has to be involved and listened to. Ideally, all participants should be given similar parts of the speech, hierarchies in the company should take a back seat, and the focus should be on togetherness, exchange and learning from one another. Of course, negative aspects must also be addressed, but this should be done in a respectful manner and at eye level; anything else would not only be detrimental to the purpose of the project review but possibly also to future cooperation.
• The derivation of consequences, measures or suggestions for improvement.
  An open and honest exchange about strengths and weaknesses of the project work often feels good for many participants. But this is not enough. What results from the findings? What should be tried out, adapted or simply omitted next time? Ideally, there is room for group work and discussions, or for visualisations such as those used in a Starfish retrospective.
• The documentation and administration of findings and measures.
  Anyone who has ever managed a project like an annual event and documented the lessons learned knows that this is not all. Who will ensure that the lessons learned are also used next year, when the event is planned and implemented again? The documentation of the findings and measures is important, but without any kind of memory, a visualisation of the experiences from the previous year, it is useless. Everything begins anew. Memories are used, new considerations are made, but the concrete ideas are forgotten. Sounds funny, but is much more the case than one would think.

In fact, there should even be a fifth phase, because the question “What’s next?” or “What are the next steps, who is responsible and when will they be reviewed?” is often left unanswered. It is not enough to “only” develop ideas, it is necessary to put them into practice and then evaluate them: Does the measure or idea work as intended? What would have to happen for it to unfold its full effect? Etc. Of course, this also presupposes that in the foreseeable future – in the course of new projects – there will be corresponding possibilities for implementation.

The evaluation of projects

It is not so easy to judge a project by its success. Is a project successful if it is completed on time and within budget, but the developed solution does not appeal to the market? How important is time and budget if both are not adhered to but the solution becomes a bestseller? In the sense of the project review, you can approach the topic by answering two essential questions:

1. Would you carry out the project again with your current knowledge?
2. If you were to do it again, would you do it the same way?

If the team honestly believes that both questions can be answered with “yes”, then you have successfully completed a project. You have achieved your goals. Very good. Answer the second question with

• “yes, but with some adjustments”,
• “yes, but with many adjustments”, or with
• “No.”

then your project was only in parts a success or a failure. Now you should consider the “yes, but…” answers and find out the desired adjustments. For example, you could ask,

• how good was the project organisation, the roles and the understanding of roles, how clear were the responsibilities and obligations to cooperate? Were all roles occupied, lived and accepted?
• what conflicts were there in the project, how did the exchange of information work and how were changes and ambiguities dealt with?
• what were the priorities and availability of individual employees and/or managers, customers, experts?
• how did the project planning take place, how was the employee utilisation and was there room for creativity?
• what went well or what could be improved from the point of view of the project manager, the employee, the client, the product owner, the Scrum Master, the development team …

This list can also be easily extended. You will find numerous examples of possible questions on the Internet. It is always important to consider the specific context; of course, you can only ask a Scrum Master if there is one in your project.

The ideal time for a project review

When is the ideal time for a project review? “Short feedback loops” are considered a great advantage of agile project procedures. Scrum knows the concept of retrospectives to improve cooperation. After a sprint, which lasts between one and four weeks, the development team, which also includes the Scrum Master and the Product Owner, meets and discusses findings, learnings and suggestions for improvement. These “short feedback loops” enable continuous optimisation of cooperation. In many classic projects, however, such a frequency cannot (or at least not so easily) be implemented.

In principle, the ideal time for a project review depends on the concrete project. In the case of a project with a duration of one week, a formal review in the current project probably makes little sense. Of course, communication between the participants during the week is also essential, but a formal review is usually only carried out after the project has been completed. In the case of a project with a duration of two years, it would probably not be a good idea to discuss lessons learned for the first time after the end of the project.

Even if there is no rule of thumb for the right time for project reviews, the orientation towards the lessons learned or the temporal focus helps to answer the question: “Do you want to and can you already profit from the experience gained in the current project? If so, then initiate a project review today rather than tomorrow. In this way, a project review can also be carried out after each project phase, e.g. after each iteration or release.

Sometimes it also makes sense to schedule a situational review if problems arise. However, this usually does not involve general questions, but concrete challenges that are essential for further project design. In such a case, the four or five phases of the project review will of course run much faster.

Conclusion

There is still one question to answer: When is a project review successful? It is successful when everyone learns something from the past for themselves, the team and the organisation and has the chance to use this experience. These can be small things that promote mutual understanding. It can be evolutionary aspects, like reducing meetings. Or revolutionary ideas like … well, I can’t tell you everything here …

Notes:

Michael Schenkel has published more articles in the t2informatik Blog, for example 

t2informatik develops and modernises software as a service provider. Click here to learn more.