Data & Analytics, CRM, Collaboration, ERP

The project manager did something totally unexpected. You won't believe what happened next!

Peter Burghardt07/17/2019
cc_picture_blog-The project manager did something totally unexpected

Ok, granted, this time there’s actually something substantial behind the clickbait title.

Imagine the following setting: A room with a big conference table, several people are sitting around it and sharing their negative experiences from the last 1 to 2 years. The leader presents facts and figures. At the end, everyone’s relieved to have made it through the meeting without getting blamed for anything.

What sounds like a self-help group is actually a lessons learned workshop after a project. I may have exaggerated a tad in the description, but I think we’ve all been through one or more workshops similar to this. So why do lessons learned workshops tend to come out like this? Why do we often fail to achieve the intended goals of the workshop?

Poor timing

When is the lessons learned workshop typically held? At the end of the project. You work on something for one or two years, and at the end, you talk about the things that didn’t go too well. Never mind that it’s hard for the participants to recapitulate the entire project history and identify the problem areas – these problems aren't even discussed at the time they come up. There are several disadvantages to this:

  1. There’s no guarantee that the same mistake will not be made again in the project.
  2. There’s no guarantee that the same mistake will not meanwhile be made in a different project.

Even though the disadvantages are pretty obvious, people insist on saving the lessons learned workshop for the end of the project. Frankly, I have no idea why this is.

What have we learned?

Oftentimes, you sit down and compile everything that went badly. And that’s usually where it ends. People neglect to work out why it went badly and, even worse, they neglect to work out what they can do in the future to avoid making the same mistake.

Just knowing that something wasn’t ideal doesn’t mean that I’ve learned anything from it. In order to learn, you have to understand the causes behind the problem and then derive steps or behaviors that would help prevent the issue from reoccurring.

More on this topic

Click here to learn about project management!

Learn more

Transferring lessons to the organization

Oftentimes, something gets written down in documents that are then filed in the project portal and sit there, anxiously waiting to be rediscovered. The attempt to carry over actions from the project to the organization is difficult and tends to fail in most cases. Usually, the problem reoccurs sooner than the documentation from the lessons learned workshop is rediscovered.

The way I see it, this is because the lessons learned workshop is held at such a late stage, long after the point when the problems actually occurred. By this time, they just aren’t as critical as they were when they happened – out of sight, out of mind. So, no one’s focusing on them, and people aren’t likely to notice when they hear about a problem that has already been discussed in the past.

How can we do it better?

Retros. What the brains behind the Agile Manifesto realized is that it’s pretty pointless to wait until the end to talk about what you should have done differently. That’s why they defined the following agile principle:

At regular intervals, the team reflects on how they can be more effective and adjusts its behavior accordingly.

It’s not about increasing work performance – it’s about improving yourself. Scrum uses Retrospectives at the end of each Sprint to do this. This approach is much more comprehensive than the “normal” lessons learned workshop. The idea isn’t to whine about everything that went badly. It’s about making targeted improvements. Of course, this does involve going over the problems that occurred or mistakes that were made. But it also involves optimizing processes and procedures that may have worked well so far.

The advantage of an outside perspective

Retrospectives also demonstrate the advantage afforded by the role of the Scrum Master or Agile Coach who moderates the meeting and provides an impartial outsider’s perspective. This factor is also missing from most conventional lessons learned workshops, because it’s normally the project manager who moderates, even though he/she is actually supposed to be involved in the work itself.

We’ve been using agile methods in our product teams for several months now, and we’ve had very good experiences with the Retrospectives and the use of a Coach. The teams have made noticeable progress. We’ve been able to address mistakes and problems and find ways to solve them or prevent them in the future.

Retrospectives also positively affect and promote team-building processes. Even after a particularly “heavy” Retrospective, the team usually comes out stronger and more cohesive as a result.

Setting up the right conditions

In order for Retrospectives to be effective, you need to create the right framework conditions. Any disruptive elements have to be avoided. This includes having members of Management at the meeting, because this could make the staff less candid with their feedback. Be sure to leave enough time, so that discussions don’t have to be cut short. The moderator must prepare and structure the Retrospectives, leaving enough leeway for the unexpected. Retrospectives are not simply meetings for talking about problems. These are actively designed creative meetings. On the website “plans for retrospective”, you can find excellent tools to help you make your Retrospective interesting.

The first Retrospectives that you’ll conduct at your company will probably not be very effective and efficient. Teams have to learn how Retrospectives work and really engage with them. After two or three meetings, you’ll start to notice that the results of the Retro are getting better and the entire process is going more smoothly.

However you choose to design your Retrospectives, there are two basic rules that you always need to follow:

  • What happens in the Retro stays in the Retro. Only if the whole team agrees that something should be outsourced it is possible to make an exception. This usually pertains to issues that the team cannot solve on their own.
  • No playing the blame game. Problems exist, and mistakes are made. It’s not about finding the guilty party and putting them in the stocks. Retrospectives are about finding solutions and focusing on the future.

The effect of these two basic rules is to make the participants more open and to create (in conjunction with the conditions mentioned earlier) a stress-free environment that enables the project team and even the company to improve.

Share post

Leave comment

Contact us
Author:
Peter Burghardt
Project Manager