ProjectManagement.com - What Happens to Your Lessons Learned After the Meeting Ends?
Project Management
Home<br>Blogs<br>The Young Project Manager
What Happens to Your Lessons Learned After the Meeting Ends?
From the The Young Project Manager Blog
by William Meller
Practical growth for project managers in the early stage of their careers.
career |
Career Development |
show all posts
About this Blog
RSS
Recent Posts
What Happens to Your Lessons Learned After the Meeting Ends?
The Longest Project You Will Ever Manage
Project Manager: Stop Waiting for Good Work to Speak for Itself
The Real Reason Your AI Project Is Going Nowhere
Why Systems Thinking Will Change How You Run Projects
Categories
Agile ,<br>Artificial Intelligence ,<br>career ,<br>Career Development ,<br>Career Development ,<br>Change Management ,<br>Education ,<br>Stakeholder Management
Date
June 2026
May 2026
April 2026
March 2026
February 2026
January 2026
December 2025
November 2025
October 2025
September 2025
August 2025
July 2025
June 2025
May 2025
April 2025
March 2025
February 2025
January 2025
December 2024
November 2024
October 2024
September 2024
August 2024
July 2024
June 2024
May 2024
April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
The finding gets filed, named, and forgotten. The owner, deadline, and sign-off that turn a lessons learned note into a fix the next project actually uses.
Have you ever left a lessons learned session feeling like something actually changed?
I have sat through ninety-minute reviews where people took turns listing complaints dressed up as feedback.
I have also been the one facilitating, trying to keep the energy up while watching everyone mentally check out.
You write the document. You give it a name. You file it. And somewhere in the back of your head, you already know nobody is opening that folder until the next project.
Which will repeat the same mistakes anyway.
So we check the box. And we move on.<br>Or? Maybe not? What do you do?
The problem is not that we skip the review. Most teams run one. The problem is what we think a review is supposed to do.
Chris Argyris, working with Donald Schön, described two types of learning that I think explain exactly why most post-project reviews fail.
Single-loop learning fixes the error. Double-loop learning asks why the system produced the error in the first place.
Argyris used a thermostat as the example.
A thermostat set to 21 degrees does its job perfectly well. Room gets cold, it kicks the heat on. Room warms up, it shuts off. It corrects the gap, over and over, all day long. What it never does is ask whether 21 is the right number. Or whether someone left a window open. That is single-loop. Reliable, tireless, and completely blind to its own assumptions.
Most lessons learned sessions live exactly there.
"The vendor was late."<br>"Communication broke down in week four."<br>"The scope changed too many times."
All true. And almost useless for stopping the same thing from happening again, because they describe what happened without ever asking what in the process allowed it to happen.
The shift from symptom to system is the whole game.
Why did they use the wrong specs? Keep asking.
Let me make this concrete with something that will probably sound familiar.
An integration fails testing for two weeks, late in the project, when everyone is already tired. The typical review lands on: "The development team used the wrong specifications." The fix? "Make sure everyone uses the right specs next time."
That is not a fix. That is a wish.
A diagnostic review keeps pulling the thread.
Why did they use the wrong specs? Because the updated version was filed in the wrong place. Why was it in the wrong place? Because nobody owns document control on this team. Why does nobody own it? Because we never assigned it.
By the fourth or fifth why, you are no longer talking about...