What are the most common problems that you find in your lessons learned sessions?

Question

In most projects you have some sort of lessons learned session. These sessions are both needed and painful to go through. For experience Project Managers, I am curious to know if you find yourself with a problem recurring over and over in different projects.

I will like to get a list of common problems. From this post we can get a list of questions on how to solve this common problems.

Answer 1

The most common problem with lesson learned/post mortems/retrospectives is that people don't really learn from them. They're often done only because PM methodology says you should do them or to make a couple of important people happy and then they're completely forgotten somewhere in local "knowledge base" where no one can really find them, let alone make use of them.

This is actually the worst mistake you can make as you show people that you don't care, so why should they care to share their thoughts another time when you want to make another retro/post mortem?

If you look for more issues I'd also count:

• Getting people involved. There's always a group of people who don't believe in value of retrospective and it's hard to get their involvement.
• Having a good discussion. Where there are a few people there are a few opinion on any given subject thus having discussion should be obvious. Unfortunately people often tend to step back when they see others, especially managers, stating something different than they think. You can always make use of a good meeting facilitator here.
• Compromises. Where there are different opinions you often end up with some kind of compromises. Sometimes they satisfy neither party, but then again, post mortems aren't owned by a single person.

Answer 2

I think one of the most common problems in lessons learned sessions is that the focus is so often and heavily weighted on what went wrong. Often times, identifying what worked well and simply "doing more of that" can help future projects.

Answer 3

Insufficient Planning

In many of the software projects I've seen, there's just not enough time spent on the planning phase before programmers want to 'go to code' and business sponsors want to start seeing results.

Have agreed requirements/specifications and a project plan with clear milestones helps reduce the effects as you can course-correct as you realize you've forgotten something important, but some under-planned areas can be the death of a project, e.g. failing to get appropriate local government permission when extending a house - doesn't matter how successful house-extending project is, the government has powers to pull it down.

Answer 4

Wrong purpose

The most common problem is planning it as a blaming session and not as a meeting to come up with a plan to never repeat a mistake.

Or, in the rare case it's about a success: Plan it as a way to get to the root of why we succeeded, and how to repeat that routinely.

Placing the blame

To be successful, these sessions must not be about blaming (or complimenting) a specific person (or group).

You always want to be focusing on the process and not the person.

Missing timeline

The timeline of what exactly happened and when in chronological order - needs to be agreed upon before the meeting.

If need be, have a pre-meeting to agree on the timeline, with everybody presenting facts (if possible).

Otherwise the meeting focuses on who did what when and why, instead of figuring out how to (not) repeat the process.

Atmosphere

The atmosphere at these sessions must be conducive to freedom-of-speech. As already stated, the purpose is to figure out the problematic (or successful) process, not person (or group).

Similar to a brainstorming session, people should be allowed to say whatever they feel like (politely) without fear of being reprimanded.

(At the post-mortem of our worst catastrophes we always had the biggest cake and best nosh. Everybody knew: The better the food the worse the calamity. But it sets the mood: we're not going to shoot anybody; we want to fix the problem.)

Strict meeting protocol

To be effective, the sessions need to run along an agenda with a fixed (but not rigid) timeline.

Only one person is allowed to talk at a time, and they have to remain on-topic.

You will get nowhere if everybody starts talking at the same time, or worse, start yelling at each other.

Result

The meeting must have a stated purpose - to prevent (or repat) what we are discussing, by creating a new policy/process that most of the team agrees to. (And all have to follow, until it's proven pointless).

There needs to be meeting minutes taken and disseminated, and there needs to be a clear bottom line.

Answer 5

We do projects for 3 reasons:

(1) Regulatory Compliance
(2) $ROI
(3) Political Will

We do postmortems for N* reasons:

• Distance the guilty
• Make everyone feel good, regardless of outcome
• Required step in methodology
• Public humiliation (PM, Client, or both)
• Rationalize the outcome
• Create a dead document
• Input to PM performance review
• Learn from our mistakes (This is only achieved by each, individually, from the project experience. This is not achieved by a post-mortem meeting or document.)

N = any number of...