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.

  • I don't understand fully your question. What is "lessons learned session"? Commented Feb 8, 2011 at 2:50
  • 3
    Maybe I should re-phrase the question. The purpose of lessons learned is to bring together any insights gained during a project that can be usefully applied on future projects. Is also called Post-Mortem (I personally hate that one), or just feedback.
    – Geo
    Commented Feb 8, 2011 at 2:55
  • I also hate 'Post Mortem' as it implies the subject is dead. A better phrase is "Post-Implementation Review". I've asked Mods to edit the title, so post here what you want it changed to. Commented Feb 8, 2011 at 11:15
  • I propose that the term "lessons learned" should be erased from the project management lexicon. Why? Because it is too easy for people to write nice text under the report sub-heading "lessons learned" and not to apply the so called "lessons". If nothing changes then no lessons have been learned. All that matters is what has changed!
    – Ken Evans
    Commented Jan 17, 2019 at 16:00
  • I'm voting to close this question as off-topic because it's list-generating.
    – Sarov
    Commented Jan 21, 2019 at 14:00

5 Answers 5


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.
  • 2
    +1 for the forgotten "knowledge base". This stage is meaningless except its results are utilized for future improvement. But would you mind providing some of your own example/situation? I think that's the best way to convey experience, and I'd learn much more from that. Commented Feb 8, 2011 at 7:06
  • The best retrospectives I've ever had: blog.brodzinski.com/2010/12/kanban-retrospectives.html (they won't work in big, distributed teams though) Commented Feb 8, 2011 at 7:11
  • In our business, we hold PM's following serious incidents and there's always a set of changes put in place afterwards, whether this is adding safety valves or meters to the system or refining methodology. Commented Feb 8, 2011 at 11:16

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.


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.

  • +1 to insufficient planning. Would add a corollary of lack of communication to sponsor as things are uncovered on the project that would make the project off-scope, off-budget or off-schedule from original expectations. Commented Feb 9, 2011 at 4:13

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.


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.


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.


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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.