Lessons Learned in Project Management: Techniques and Best Practices

This article explores when and how to run lessons-learned sessions, facilitation techniques that uncover real insights, and practical steps to turn lessons into measurable improvements.

What is lessons learned? TL;DR

What is it? Lessons learned in project management are documented insights (positive and negative) from project experiences. These insights are identified and discussed during dedicated review sessions.

What does it cover? Lessons learned apply to project management processes and tools, performing the technical work required by the project, business processes, leadership, and teamwork. They don’t apply to highly standardized procedures (e.g, compliance checks or security protocols).

How to run sessions? Lessons learned sessions should be held regularly and involve core team members, leadership, and key stakeholders to ensure a well-rounded perspective on the project. Each session should be structured around three essential questions:

• What did we do right?
• What did we do wrong?
• What do we need to improve?

For better results, choose someone other than the project manager to facilitate.

How to document the outcome? The data captured during the sessions should be reported to stakeholders in a structured format. The report should summarize the process and highlight key insights: what went well, what didn’t, and what should be improved. Use a clearly defined template to ensure data consistency (you’ll find an example in the “How to document” section).

How to use lessons learned? Analyze, store in a dedicated, easy-to-search repository, and retrieve for use on the current phase/iteration/project, as they help to adjust and create mitigation strategies.

Now, we’ll dive into detail.

How to run lessons-learned sessions

A lessons learned session is designed to identify both project successes and failures, and to generate practical recommendations for improving future performance. A project manager is responsible for organizing these sessions.

Who should participate: Invite those with meaningful insights – typically core team members, leadership, and key stakeholders. Diverse perspectives (technical staff, business owners, end users, etc.) help uncover hidden issues. Limit group size for manageability (e.g., 7–10 people).

Who should facilitate: Lessons learned sessions are most effective when led by a neutral facilitator rather than the project manager, ensuring the discussion remains unbiased, open, and focused on insights rather than personal accountability.

When to run sessions: Run lesson reviews regularly, not only at final project closeout. Key times include the end of each project phase (so earlier-stage lessons aren’t forgotten) and after major milestones or releases.

How to prepare for the session: Provide a pre-meeting “lessons learned survey” and share it with all attendees to gather initial views. Organize the survey into categories—such as project management, technology, communication, and testing. Use scored questions to help participants clearly identify what went well and what didn’t, providing a structured, data-driven input for the session.

Use the responses to guide and focus the discussion.

A practical agenda to follow: To guide the review, discuss the key questions: what happened, why it happened, and what should change. If the project had particular issues (e.g., a major risk event, a process change, or a tool rollout), add tailored questions on those topics.

While discussing, use any available data to anchor lessons in evidence: project metrics (schedule vs actual, defect rates, budget variances, quality metrics, stakeholder feedback), bug tracker logs, support tickets, or satisfaction surveys.

Don’t blame, learn: If people fear criticism, sessions yield only polite or superficial comments. Stress in advance that the meeting is blameless. Anonymize sensitive feedback if needed.

Here is an approximate agenda you may follow:

• Project recap: review scope, milestones, budget, and metrics.
• What went well: participants share successes.
• What didn’t go well: discuss problems and pain points.
• Root cause analysis: pick a couple of key issues and apply facilitation techniques (we’ll talk about them later) to find causes.
• Action Ideas: brainstorm improvements and prioritize top actions.
• Next steps: assign action owners, clarify who will finalize documentation, and schedule any follow-up.

How to document, report, and store lessons learned: template example

A lessons learned session only creates value if its outputs are captured in a form that teams can reuse. A robust structure typically includes the following elements:

• ID – a unique identifier for tracking and referencing
• Lesson learned – a concise statement of the issue or success
• Description and cause – what happened and why, including root cause
• Area – the domain affected (e.g. scope, delivery, communication, testing)
• Recommendation – a clear, actionable change
• Identified by – the person or role who raised the lesson
• Date raised – when the lesson was captured
• Recipient/owner – the person responsible for acting on it

Every entry should answer the same three questions: what happened, why it happened, and what should change.

After insights are captured, a project manager or other responsible person should create a detailed report, validated by participants, and distribute it to the entire project team. Different report formats should be used for different audiences, including a concise leadership summary.

Store lessons learned in a centralized, easily accessible repository. It can be the same tool your organization already uses for technical documentation: SharePoint, Notion, Jira, or any other. Such a tool must include a standardized template, simple data entry, strong search functionality (keywords, categories), and the ability to generate clear reports and metrics — otherwise, the data will never be reused.

If you are interested to learn more about high-quality software documentation, read our dedicated articles on acceptance criteria, functional and nonfunctional requirements specification, product requirements document, and nonfunctional requirements best practices.

How to analyze lessons learned: from insight to impact

A project manager or a dedicated team should evaluate lessons learned, recommend solutions to prevent similar problems in the future, and ensure that best practices are incorporated into existing workflows and procedures.

Use a structured decision process: evaluate each recommendation by impact (benefit of fixing) and effort/risk, and prioritize those with the highest value (for example, using

Once priorities are set, integrate changes through a mini change management plan. Steps include:

1. Validate and plan: Present top lessons and recommendations to affected process owners. Refine the proposed solutions and set acceptance criteria. For major changes, draft a project/process change request.
2. Assign owners: Each approved action should have a responsible owner and target date (an action log is useful). Owners could be process leads or project managers of upcoming projects.
3. Embed in processes: Update project management standards, templates, checklists, or policies.
4. Communicate: Share lessons and approved actions in relevant forums, such as PMO newsletters or kickoff meetings. Tie the improvements to organizational goals (e.g. “Client feedback used to arrive too late to act on. After adding mid-project check-ins, satisfaction scores improved, and rework decreased.”)
5. Implement: Apply fixes on projects in flight if possible. For instance, enforce new code review checklists or scheduling buffers in the next phase.

PMs should track KPIs and update the status. Collecting lessons and not using them is like writing notes you never read again.

How to dig deeper: facilitated techniques

To uncover real causes during lessons learned sessions, you can use structured techniques. These methods are widely used in problem-solving and are especially effective for facilitating lessons-learned sessions.

Root cause analysis (5 Whys)

For each identified problem, ask “Why?” repeatedly (typically 5 times) to peel back the symptoms and uncover the underlying causes.

Pros: simple, encourages depth over blame.

Cons: may stop too soon or pinpoint a single cause in a complex situation.

Use when: you have a specific failure to analyze.

Fishbone (Ishikawa) diagram

Draw a “cause and effect” diagram with the issue as the “head” and major cause categories (e.g. People, Process, Tools, Policy) as branches. Team members suggest possible causes for each branch.

Pros: visual organization of multiple factors, encourages team brainstorming of cause categories.

Cons: can become cluttered or biased by initial categories.

Use when: tackling a complex problem with many potential causes.

Nominal group technique

It’s a variation of brainstorming. Each person writes ideas independently, then all are shared one by one, followed by group discussion and voting.

Pros: ensures equal participation, avoids early dominance.

Cons: somewhat more structured/time-consuming.

Use when: you need to ensure quieter members contribute or to prevent groupthink.

Affinity mapping & Dot voting

After generating many ideas (from brainstorming or a survey), cluster similar items (affinity mapping) to reveal themes and patterns. Then use dot-voting for prioritization: give each person a set of “dots” (votes) to allocate to the ideas or clusters they find most important.

Pros: quickly surfaces highest-impact issues, democratizes prioritization.

Cons: may overlook low-vote but critical issues, needs an initial idea list.

Use when: prioritizing actions or understanding which themes resonate most with the group.

Regardless of technique, keep the focus on actionable outputs. Once problems are identified, formulate them as “Lesson: [Issue] – Root Cause – Recommendation”. Or, in other words: what happened, why it happened, and what should change. Encourage specifics (e.g., “We underestimated review time due to lack of early feedback” rather than “communication issues”).