How to Remove Fear and Blame from Your Project Reviews

Lately, I’ve been thinking and writing about project reviews and agile retrospectives. I explored why I think traditional lessons learned exercises are a waste, and several posts on how to improve retrospectives when you have them.

This post is going to focus on how to lead a project review or retrospective without pointing fingers or blaming others. We’ll look at why fear and blame are so harmful, and then specific steps you can take prior to a review and during the review to reduce or eliminate fear and blaming.

Why Project Reviews should be Free from Fear and Blame

Here is why I think this is an important topic. If people fear reprisal or blame, they are not going to be open and honest and that will undermine the effectiveness of the process.

The team will either collude together (I won’t bring up anything negative about you if you don’t bring up anything negative about me), or they will be busy grandstanding or spinning the facts to make others look bad while making themselves look good.

And let’s be honest here, we all like to blame. It is always easier to point out the faults of others vs. sharing our own shortcomings or issues. It is part of the human condition and it at least goes back to the story of the speck and the log.

We like to attribute our success to hard work and grit and our failures to bad luck, and we reverse this when we judge others. (I’ve written extensively on blame in my book, Emotional Intelligence for Project Managers; the People Skills You Need to Succeed.)

It’s also important to remove the fear from the retrospective discussion because when people are fearful, they cannot be creative. Fear and creativity don’t co-exist. So if people are afraid, we’ve removed the possibility for creative thinking about underlying root causes as well as creative ideas for improvements.

How Can We Set Up Our Lessons Learned Meetings to Remove Fear and Blame?

Recognizing that fear and blame are harmful, we need to think about how to reduce or eliminate them in our lessons learned exercise. What follows are some ideas based on my past experience as well as on Norman Kerth’s book, Project Retrospectives.

• Acknowledge Fear and Blame – It is often a good idea to acknowledge that people might feel fearful of the retrospective process. How do you do this? Simply ask. You can ask specifically if there are topics or concerns that people have. You can do this through in-person meetings or through surveys. If there is a high risk of fear and blame, you can make your surveys anonymous.
• Remove managers from the discussion – Generally, people will be more open if they are with their peers or teammates, and not in front of their own manager. They also won’t be open and candid if they feel that there is a risk that the information they share will be used against them in an upcoming performance review.So we generally recommend that the lessons learned meeting not include managers. If you can’t avoid it, sometimes you can structure the discussion to separate team members from their managers in breakout sessions.
• Control the Participants – Similar to the previous point, you need to make sure you have the right people in the room. You don’t want people who had only a fringe role (or no responsibility at all) on the project to dominate discussions or lead the process astray.
• Communicate the Purpose – There can be many reasons to hold a retrospective, including improving the organization, identifying systemic issues, and helping the team do better in the future. I believe that the team improvement is far and away the most important. If we go into a retrospective or lessons learned meeting with the attitude that this is for the benefit of the team, then there should be less fear and blame.
• Cultivate a learning culture – I received a great comment on a recent post that there is a difference between lessons observed and lessons learned. We need to translate what we discover in a retrospective into learnings, not just observations.We can do that by cultivating an environment of curiosity and learning among our teams. If you aren’t failing you aren’t learning and taking enough risks. Help people to be curious about what happened and why vs. being defensive and afraid of getting in trouble.
• Schedule them In – Reviewing how we did and how we can improve just needs to be part of the way we operate. We should plan for reviews throughout our project, talk about them at the kickoff, and schedule them in our project schedule.Twenty years ago I was at Unisys and I was responsible for project reviews. I oversaw a portfolio of projects and led project quality reviews every quarter for projects that were “green”, and monthly for projects that were “yellow” or “red”. Similarly, with Agile teams, we generally have a built-in feedback loop and retrospectives are planned every sprint. Doing reviews often builds trust in the process.
• Work on Changing the culture of the Organization – If you find that there is always fear and blame during retrospectives, it is probably because fear and blame live in your organization’s culture. You won’t successfully remove fear from your project reviews if it is in the DNA of the organization. This is not trivial, obviously, but it is important work.

What techniques can you use during the Project Review?

During the meeting or exercise itself, we want to do all that we can to create a feeling of safety among participants. We want them to feel confident in speaking up and sharing their thoughts and perspective.

• Use Kerth’s Prime Directive – My first Agile Coach taught me about Norm Kerth’s prime directive. It is essentially a statement that says, we all agree to not blame each other since everyone did the best they could given the situation they faced. By reading this statement up front, we set the tone for blame-free behavior in the meeting. We can return to the statement throughout the exercise if people forget.
• Use ground rules  – This is a great first exercise within a retrospective. Orient to the company value statements, or work as a team to generate ground rules together that everyone agrees on. No blaming is a key ground rule, as is ‘focus on the positive’.
• Create a Positive Environment – It is often helpful to spend some time celebrating the accomplishments of the project. Even the most deeply troubled projects usually have some accomplishments or things that went well that can be celebrated. If learning is part of our team goal, then teams can even think of things they learned that did not work as a success. Don’t shortchange this part of the process and spend all the time talking about what people did wrong.
• Keep it About You – One thing that I find helpful is for each person to talk about themselves and their experience, rather than orienting to the work of others on the team. I encourage them to avoid “you statements” and instead use “I statements”. When we focus on others, we often layer our own story on the facts, or we ascribe malicious intent to actions that others take, rather than using empathy to place ourselves in their shoes.
• Remind the team that Review is for them and it is Optional – Participating in the retrospective or review should be optional. We don’t want people to feel like they have no choice.
• Set the Tone – Kerth suggests having a senior leader in the organization kick off the session. That leader can set a positive tone for the group, ask them to participate and to learn. The leader can also share a personal story about a failure or challenging project as a way to show that we all make mistakes and can learn and grow.
• Engage a skilled facilitator – A strong project leader will often do a great job in a review or retrospective. Sometimes you may need someone who is more skilled or experienced to effectively lead the team through a lessons learned exercise. A strong facilitator can bring a variety of exercises, set the discussion up well, and help the team get unstuck when they are stuck. Facilitators generally know how to use participatory decision-making techniques like dot voting or fist of fives to solicit everyone’s input or feedback. They can also create and maintain a safe environment for everyone by calling out and stopping any negative behaviors. They know how to engage everyone in the discussion.

I hope you found these ideas helpful and that you’ll take the time to incorporate them into your current project review or retrospective process. I’d love to hear your thoughts and reactions as well as what you have tried in order to help eliminate fear and blaming from your project reviews and lessons learned exercises.

In my next post, I am going to share my ideas for how to make the investment of time for a project lesson learned meeting worthwhile. I’ve already shared about why I think that most are a waste and this will focus on what can be done to make sure your next retrospective is not.