Glossary
Lessons Learned
project retrospective, post-project review, lessons learned workshop
Lessons learned are the experiences from a project that a team records so that later projects benefit from them. The team collects them in a review, usually a workshop at the end of a phase or project. A single insight is a "lesson learned"; the documented collection is often called the lessons learned register or report.
Lessons learned belong to the closing process, but not only there. If you only ask what went wrong at the end of a long project, you get memories instead of facts. Plan a short round after every phase or major milestone as well.
How Does a Lessons Learned Workshop Work?
- Prepare: The project manager gathers facts: planned and actual dates and costs, risks that occurred, status reports. Every participant notes their three most important observations in advance.
- Set the frame: A neutral facilitator explains the goal. The team looks for causes and improvements, not for someone to blame.
- Collect: Each person names what went well and what did not. The facilitator clusters the input by topic, such as planning, communication or technology.
- Analyze causes: For the most important topics, the team keeps asking why until a cause appears that it can change next time.
- Record actions: Every insight gets a recommendation, a person responsible and a storage location where the next project team will find it.
Set a fixed time frame, for example 90 minutes, and if in doubt shorten the collecting phase, not the actions.
Questions for the Project Review
Copy these questions into your workshop invitation:
- What worked well and should become standard?
- What went badly, and why?
- What would we plan differently with what we know today?
- Which risks occurred? Did the prepared responses work?
- Which estimates were clearly off, and why?
- Did the work breakdown structure contain all necessary work packages?
- Did communication with the sponsor and the team happen on time and in full?
- What advice would we give a project manager taking on a similar project?
Example: A Lessons Learned Entry
| Field | Content |
|---|---|
| Topic | Delivery of Wi-Fi hardware for the office move |
| Observation | The hardware arrived nine days later than promised. |
| Cause | Ordered only after the floor plan was approved, no buffer before the moving date. |
| Impact | Two days of work without a network, rented equipment for 1,200 euros (example values). |
| Recommendation | Ask about long lead times at project start and order critical hardware before detailed planning. |
| Owner | Head of IT, for all future site projects |
A good entry describes a concrete situation and ends with an action. "Improve communication" is not a lesson learned; "Weekly status report to the sponsor from project start" is.
Common Mistakes
- Only at the end of the project: Many details are forgotten by then, and the team has moved on.
- Blame instead of causes: People who fear accusations do not name mistakes.
- No storage location: Minutes in a personal inbox never reach the next project.
- No follow-up: At the kickoff of the next project, check which recommendations were implemented.
How Do You Record Lessons Learned in Merlin Project?
Merlin Project stores insights directly in the project document:
- For risks: In the risk attachment, use the Risk Closing area. Select Did Occur, enter Closing Delay and Costs, and record under Lessons Learned what went well and what you would do differently. These entries do not affect the time or cost calculation. More in risk management.
- General insights: Select the top-level activity or the closing milestone and add an attachment for decisions and minutes with Insert › Attachment › Information. Alternatively, write in the activity's Notes in the Inspector.
- For the next project: The built-in Documentation report (View › Report › Documentation) lists the titles, tags and notes of all activities. Save proven project structures in the Library.
