IPM CPM Level 1
hamburger__close
A lessons learned template is a structured document used by project teams to record, analyse, and share knowledge gained during a project, capturing what went well, what went wrong, the root causes behind each outcome, and the actions recommended to improve future performance. Used consistently, it transforms individual project experience into lasting organisational intelligence. This guide, produced by the Institute of Project Management, goes beyond the artefact itself to explain the full methodology: when to use it, how to facilitate the session professionally, how to complete every field with purpose, and how to ensure the outputs actually change how your organisation manages projects.
A lessons learned template is a standardised form or document that project managers use to systematically capture knowledge generated throughout the project lifecycle. Rather than relying on informal post-project conversations that quickly fade from memory, the template provides a consistent structure that every team member can contribute to, and that the organisation can store, search, and reference when planning future projects.
The document typically records each lesson as a discrete entry, describing the situation that arose, the phase in which it occurred, the underlying root cause, the impact it had on scope, schedule, cost, or quality, and the recommendation that should be applied going forward. Ownership and follow-up status fields ensure the lesson moves from observation to action rather than sitting in a folder that nobody reads.
It is worth distinguishing a lessons learned template from a lessons learned register. The template is the blank form or structure your team uses to capture individual entries. The register is the cumulative, living record of all lessons captured across multiple projects.
The table below summarises every core field found in a professionally structured lessons learned template, giving you an at-a-glance reference before we examine each field in depth.
| Field | Purpose |
|---|---|
| Issue or Observation Description | Describes the situation, event, or outcome being recorded in clear, factual language. |
| Project Phase | Identifies when in the lifecycle the lesson occurred so future teams can anticipate similar risks. |
| Root Cause | Explains the underlying reason the situation arose, moving beyond symptoms to systemic factors. |
| Impact | Quantifies or qualifies the effect on project objectives, time, cost, quality, or stakeholder satisfaction. |
| Recommendation | States the specific action or process change that should be adopted on future projects. |
| Owner | Names the individual or function responsible for implementing or communicating the recommendation. |
| Status | Tracks whether the recommendation is pending, in progress, implemented, or closed. |
Project management is a discipline built on the principle that performance can be continuously improved. Every project, regardless of its outcome, generates valuable data about how an organisation plans, executes, manages risk, and communicates. Without a mechanism to capture and apply that data, organisations repeat the same mistakes across different teams, different sponsors, and different years. The lessons learned process is that mechanism.
The consequences of neglecting lessons learned are well documented in practice. Teams re-scope projects that were already descoped for valid reasons on a previous engagement. Risk registers omit categories of risk that burned a predecessor project. Stakeholder communication plans are built from scratch when a perfectly workable approach already exists in the archive. Each repetition carries a cost, and in aggregate those costs are high.
For project managers operating at a senior level, lessons learned also carry a reputational and governance dimension. Boards, programme sponsors, and auditors increasingly expect evidence that project teams learn from experience. A well-maintained lessons learned register signals professional maturity. Conversely, an organisation that cannot demonstrate a functioning knowledge management cycle exposes itself to repeated delivery failures and eroding stakeholder confidence.
There is also a team culture dimension. When project managers invite their teams to contribute honestly to a lessons learned session, they signal that reflection is valued, that blame is secondary to improvement, and that individual observations have organisational consequence. This builds the kind of psychologically safe environment where problems surface early rather than being hidden until they become crises. Understanding how to build that environment is a core component of Stakeholder Management and Communications, an area of practice that shapes every phase of the project lifecycle.
Master Stakeholder Management with our course, designed to improve communication and resolve conflicts of interest between project stakeholders.
One of the most persistent misconceptions in project management is that lessons learned is a post-project activity. In reality, restricting the process to the closing phase means that most of the valuable detail has already been lost. Teams disband, memories fade, and the political dynamics of a just-completed project colour recollections in ways that reduce objectivity. The professional approach is to capture lessons throughout the lifecycle, at predefined points aligned with phase gates or milestone reviews.
The initiation phase offers a unique opportunity that most teams overlook: the chance to review lessons learned from comparable previous projects before a single line of the project plan is written. A review of the lessons register at this stage can directly inform risk identification, stakeholder engagement strategy, and resource planning. It is the most leveraged moment in the entire process because the cost of applying a lesson is zero when the plan has not yet been committed.
During planning itself, the project manager should establish how and when lessons will be captured throughout the project. This means scheduling lessons review sessions into the project calendar, assigning responsibility for maintaining the template, and briefing the team on the purpose and format of the process. Without this upfront investment, lessons learned default to a rushed retrospective at closeout.
Execution is where most lessons are actually generated, and where they are most commonly lost. The professional practice is to capture significant observations in real time, or at minimum at the end of each major phase or sprint cycle. Many experienced project managers maintain a running log alongside the risk register, noting situations as they arise with enough factual detail to complete the full template entry later. This prevents the cognitive distortion that occurs when teams try to reconstruct events weeks after they happened.
Phase-end reviews are particularly valuable moments for facilitated lessons discussions. At the conclusion of each phase, the team has a shared reference point, the phase deliverables and the phase plan, against which to compare actual performance. The gap between plan and reality is the richest source of lessons. Structured discussion at this point, before the team moves into the next phase, produces far more actionable insights than a retrospective held months later.
The closeout lessons learned session is the most formally recognised part of the process, and it remains important even when lessons have been captured throughout the lifecycle. The closeout session serves a different purpose: it synthesises the cumulative lessons from the project into a coherent picture, validates and prioritises the recommendations, assigns ownership for follow-up actions, and formally adds the entries to the organisational lessons register. It is also the moment at which the team has the fullest picture of project outcomes, making it possible to assess impact with greater accuracy than was possible mid-project.
If you are looking to deepen your capability in the areas most commonly surfaced by lessons learned reviews, IPM offers a range of project management courses covering everything from risk management and stakeholder engagement to PMO design and agile delivery. Each course is designed to build practical competence that you can apply immediately in your projects.
Understanding what to write in each field is as important as knowing which fields to include. A lessons learned entry that says ‘Communication could have been better’ is useless. An entry that describes exactly what communication broke down, in which phase, for what structural reason, with what measurable consequence, and with a specific recommendation tied to a named owner and a follow-up date, that entry has genuine organisational value. This section explains what each field is designed to capture and how to populate it with the rigour it deserves.
This field records what happened. The discipline here is factual precision: describe the situation as a neutral observer would, without attribution of blame and without editorial commentary. A strong description answers the questions who, what, when, and where. For example: ‘During the design phase, the third-party supplier delivered the technical specification four weeks late, triggering a downstream delay to the development milestone.’ That is a usable entry. ‘The supplier was unresponsive and caused delays’ is not, because it lacks the specificity needed to generate a meaningful recommendation.
Recording the phase in which a lesson occurred allows future teams to anticipate where in their own lifecycle similar situations are most likely to arise. It also enables pattern analysis across the lessons register: if an organisation consistently experiences stakeholder misalignment during the initiation phase, that pattern points to a systemic gap in how projects are chartered or scoped. Without phase data, this kind of aggregate analysis is impossible.
The root cause field is where most lessons learned entries fall short. The natural human tendency is to describe symptoms rather than causes. A delayed deliverable is a symptom. The root cause might be an ambiguous contract clause, an under-resourced supplier, a missing approval gate, or a planning assumption that was never validated. Root cause analysis techniques such as the Five Whys or fishbone diagram can be applied directly in the lessons session to push the team from symptoms to causes. This is the most intellectually demanding field in the template, and it is the most valuable.
The impact field quantifies or qualifies what the situation cost the project. Where possible, express impact in concrete terms: two weeks added to the schedule, €15,000 in unplanned expenditure, a reduction in deliverable quality that required a rework cycle, or a stakeholder relationship that deteriorated and required recovery effort. Quantified impacts make the lessons register significantly more persuasive when presented to programme sponsors or PMO leadership as justification for process changes.
The recommendation field states what should be done differently on future projects. It must be specific, actionable, and realistic. ‘Improve communication’ is not a recommendation. ‘Establish a weekly written status update to all Tier 1 suppliers from project week two, using the standard supplier briefing template, with escalation triggered if no acknowledgement is received within 48 hours’ is a recommendation. The test of a good recommendation is whether a project manager on a future project could read it and know exactly what to do.
These two fields transform a lessons learned entry from an observation into an action. The owner field names the individual, team, or function responsible for implementing the recommendation, whether that is updating a process document, briefing a team, revising a template, or integrating the learning into a training programme. The status field tracks progress: pending, in progress, implemented, or closed. Without these fields, lessons learned remains a reflective exercise with no downstream consequence. With them, it becomes a genuine improvement mechanism.
IPM provides a professionally designed lessons learned template available in Excel format, structured for organisations that maintain a running register across multiple projects, allowing sorting, filtering, and aggregate analysis by phase, category, or status. This Excel version additionally includes a summary dashboard tab that automatically counts lessons by status and by phase, giving PMO leaders an at-a-glance view of knowledge capture activity across the portfolio.
The quality of what ends up in a lessons learned template is almost entirely determined by the quality of the session used to generate it. A poorly facilitated session produces vague generalisations, superficial observations, and a room full of people who are reluctant to speak candidly. A well-facilitated session produces specific, actionable insights that the organisation can act on immediately. Facilitation is a professional skill, and it deserves the same preparation as any other project management discipline.
Preparation begins at least one week before the session. Send participants a brief pre-session questionnaire asking them to reflect on three areas: what worked well and should be repeated, what did not work and should be changed, and what surprised them during the project. This serves two purposes. It allows participants to think reflectively rather than reactively, and it gives the facilitator advance sight of the themes likely to emerge, allowing for structured agenda planning.
Review the project documentation before the session: the original project plan, the risk register, change log, budget reports, and any formal correspondence that captures significant events. This contextual preparation allows the facilitator to prompt the team with specific reference points if the discussion becomes too general. It also protects against the common tendency for teams to focus disproportionately on the most recent events while earlier phases of the project fade from discussion.
Open the session by explicitly setting the tone. State clearly that the purpose is improvement, not accountability. Remind participants that findings will be recorded at a process and system level, not attributed to individuals in the organisational register. If the project experienced significant difficulties, acknowledge them directly rather than allowing the tension to sit unaddressed in the room. Teams pick up on avoidance quickly, and it signals that honesty is not actually welcome.
The seating arrangement and facilitation style both contribute to psychological safety. Where possible, avoid a configuration that puts the project manager at the head of the table in a position of apparent authority over the discussion. A circular or workshop-style arrangement signals that every contribution is equally valued. Techniques such as anonymous sticky-note submission before open discussion can lower the threshold for candid contributions in teams where hierarchical dynamics are strong.
Rather than asking the general question ‘what did we learn?’, structure the discussion chronologically by project phase. Begin with initiation, move through planning and execution, and close with the monitoring and closing phases. This structure serves two functions: it prompts recall of events that might otherwise be forgotten as the team’s attention gravitates toward recent experience, and it makes the phase field in the template easy and accurate to complete.
For each phase, use open questions to surface observations: ‘What was the most significant challenge we faced during planning, and why did it arise?’ ‘If we were starting execution again tomorrow, what would we do differently in the first four weeks?’ ‘What process or tool added the most value during this phase, and why?’ These questions are more generative than ‘what went wrong?’ because they invite analysis rather than complaint.
Assign a scribe whose sole responsibility is to capture observations in the template format during the session. The facilitator should not attempt to simultaneously facilitate and document, as this compromises both activities. Where possible, project the template onto a screen so the team can see entries being made, which serves as a shared reference point and allows participants to correct or refine entries before they are finalised.
Do not allow discussion to move on from an observation until the entry is sufficiently complete to be actionable. If the team surfaces a concern but cannot yet articulate the root cause, pause the discussion and work through it using a simple technique such as asking ‘why’ three to five times. The quality of the entry matters more than the speed of the session.
At the end of the session, review all entries together and ask the team to identify the five to seven lessons with the highest potential impact on future projects. These priority lessons should be assigned owners and follow-up dates before the session closes. Lower-priority entries are still recorded in the register, but the prioritisation exercise ensures that the most valuable insights receive immediate attention rather than being buried in a long list of observations.
Distribute the completed template to all participants within 48 hours of the session, while the discussion is still fresh. Invite corrections and additions by a stated deadline. This rapid turnaround signals that the organisation takes the process seriously, and it allows participants to add observations they thought of after the session ended.
Abstract guidance is most useful when it is grounded in a concrete example. The following is a realistic lessons learned entry drawn from a software implementation project scenario. It illustrates how the seven core fields should be populated to produce an entry with genuine organisational value. The project involved the rollout of a new financial reporting system across three regional offices, with a budget of €280,000 and a planned duration of seven months.
Issue or Observation Description: During the execution phase, user acceptance testing (UAT) was delayed by three weeks because the UAT participants from the finance team had not been formally allocated time in their operational schedules. When the UAT window opened, the finance team was simultaneously managing the quarterly reporting cycle and could not dedicate the required hours to testing.
Project Phase: Execution, User Acceptance Testing milestone.
Root Cause: Resource allocation for UAT participants was not formally agreed with line managers during the planning phase. The project plan assumed availability without confirming it through the finance department head. The project manager’s assumption was based on informal verbal agreement with the finance team lead, which did not translate into protected time in the operational calendar.
Impact: Three-week delay to the UAT milestone, consequential four-week delay to the go-live date, and approximately €18,000 in additional project management and vendor holding costs. One of the three regional offices was unable to use the new system at the original go-live date, requiring a phased launch that complicated the change management programme.
Recommendation: All future projects requiring business-side resource participation in testing or review activities must obtain formal written confirmation from the relevant line manager during the planning phase. A resource availability agreement should be added to the standard planning checklist and included as a condition of the planning phase sign-off. UAT windows should be scheduled with a minimum six-week lead time to allow operational calendar adjustments.
Owner: PMO Manager, with implementation through the standard project planning checklist update process.
Status: In progress. Planning checklist revision scheduled for completion by end of Q1 2026.
This entry illustrates how a single well-documented lesson can drive a concrete process change that prevents the same situation from recurring on any future project. Multiply this across twenty or thirty projects in an annual portfolio, and the cumulative improvement in delivery performance is substantial. Understanding how to structure and govern this kind of knowledge cycle at portfolio level is one of the core competencies developed in our Project Risk Pro: Mitigate, Manage, Succeed course, which covers risk and knowledge management as interconnected disciplines.
Learn to identify, assess, and manage project risks effectively with hands-on strategies to ensure successful project outcomes.
The most common failure point in the lessons learned process is not the capture stage but the application stage. Organisations invest time in running sessions, completing templates, and building registers, and then the register sits in a shared drive folder that nobody references when the next project kicks off. Converting captured lessons into actual improvements requires deliberate process design at the organisational level, not just individual project discipline.
The single highest-impact change an organisation can make is to add a mandatory lessons review to the initiation checklist for every new project. Before the project plan is drafted, the project manager should query the lessons register for entries related to similar projects, similar technologies, similar stakeholder groups, or similar risk categories. This review should take no more than a half-day, and the output should be a summary of the three to five most relevant lessons and how they have been incorporated into the project plan.
When this practice is embedded into governance, lessons learned stop being a retrospective exercise and become a prospective planning tool. The register becomes an asset that project managers actively seek out rather than a repository they contribute to reluctantly.
Many lessons, particularly those relating to supplier performance, stakeholder engagement, and technical complexity, are directly translatable into risk register entries for future projects. When a lessons learned entry identifies a recurring risk category, the PMO should add that risk as a standard entry in the organisation’s risk register template, complete with the recommended mitigation drawn from the lesson. This means that future project managers automatically inherit the benefit of previous teams’ experience without needing to independently discover the same risks.
Not all lessons can be implemented at the individual project level. Process changes, template revisions, training needs, and governance amendments require organisational authority that sits above any single project. These systemic lessons should be assigned to the PMO function, which is positioned to own and implement them across the portfolio. The PMO should maintain a separate action log for systemic lessons and report on implementation progress quarterly. This accountability structure prevents systemic lessons from being indefinitely deferred in favour of project-level business.
A mature lessons learned register is also a training asset. Recurring patterns in the register often point directly to skill gaps in the project management community: consistent failures in stakeholder communication planning, repeated scope creep in the initiation phase, or systematic underestimation of risk in fixed-price contracts.
A practical question that arises frequently is what the best format for lessons learned is. The answer depends on how the organisation intends to use the register. For small teams running occasional projects, a Word document provides a familiar, accessible format that requires no technical setup. For project management offices managing multiple concurrent projects, Excel offers the filtering and aggregation capabilities needed to identify patterns across the portfolio.
For organisations with a functioning PMO or project management information system, lessons learned data can eventually be migrated into a dedicated knowledge management system. However, the format is secondary to the discipline of capture and review. A consistently maintained Excel register that is actively consulted during project initiation delivers far more value than a sophisticated system that project teams do not use. Start with the format your team will actually engage with, and build from there.
In relation to language, a question that comes up in professional contexts is what is a better way to say ‘lessons learned’. In formal documentation, ‘project knowledge review’, ‘retrospective findings’, or ‘continuous improvement log’ are all acceptable alternatives that carry professional weight. In programme and portfolio contexts, ‘organisational learning register’ is increasingly used to signal that the process operates at an enterprise level rather than being confined to individual projects. Any of these alternatives is appropriate depending on organisational culture and audience preference.
The difference between a project manager who completes a lessons learned template because governance requires it and one who treats it as a professional discipline is largely a function of training. Certified project managers are taught to understand the knowledge management cycle as an integral part of the project lifecycle, not as an administrative afterthought. They approach the lessons learned process with the same rigour they apply to risk management or stakeholder planning.
At IPM, the IPM CPM Level 1 certification equips candidates with a comprehensive grounding in project management methodology, including the full lessons learned process from template design through facilitation and organisational application. Crucially, CPM Level 1 is not delivered through an exam alone. Candidates are assessed through coursework, assignments, and applied learning activities that reflect real project management practice. This means that certified professionals have actually practised the skills they are assessed on, rather than having memorised answers to multiple-choice questions.
For senior practitioners working at programme or portfolio level, where lessons learned feed into enterprise knowledge management strategy, CPM Level 2 builds on this foundation with coverage of programme governance, portfolio performance management, and organisational learning as a strategic capability. The distinction between project-level and programme-level knowledge management is significant: at programme level, lessons are synthesised across multiple projects simultaneously, patterns are analysed at a strategic level, and recommendations may result in governance changes that affect the entire project delivery function.
Whether you are beginning your project management career or seeking to professionalise an existing practice, formal certification provides the structured framework within which tools like the lessons learned template find their proper context and purpose. The template is not merely a form to fill in; it is an expression of a broader professional commitment to continuous improvement in project delivery.
| Key Aspect | What to Know | Why It Matters |
|---|---|---|
| Timing | Capture lessons throughout the lifecycle, not only at closeout | Preserves detail and accuracy while events are still fresh |
| Template Fields | Seven core fields from description through to status | Ensures each lesson is specific, actionable, and trackable |
| Facilitation | Structured session with pre-work, phase-by-phase discussion, and real-time documentation | Produces candid, high-quality insights rather than vague generalisations |
| Format | Available in Word, Excel, and PDF to suit different team environments | Removes barriers to adoption by fitting existing workflows |
| Application | Lessons feed into initiation checklists, risk registers, and training agendas | Converts reflection into measurable improvement in future project performance |
| Certification | CPM Level 1 teaches the full lessons learned methodology through applied learning | Builds professional competence that goes beyond template completion to systemic improvement |
For project managers who want to formalise their expertise and demonstrate professional credibility, the IPM CPM Level 1 certification provides a rigorous, learning-centric pathway that assesses real project management competence through assignments and applied coursework. It is the qualification that equips you not just to complete a lessons learned template, but to embed continuous improvement as a core professional habit across everything you deliver.
Earn your Project Management Diploma & IPMA® Certification with expert-led training at IPM to confidently manage any project.
A lessons learned template is one of the most straightforward tools in the project management toolkit, but its value is only realised when it is used with professional discipline: at the right moments in the lifecycle, facilitated with skill, populated with specificity, and connected to a process that actually changes how future projects are run. The template is the starting point. The methodology is what makes it matter. If you are ready to build that methodology into your professional practice, explore IPM’s project management courses and certifications to find the right pathway for your career stage.
A lessons learned document is a formal record that captures knowledge generated during a project, including what worked well, what did not, the root causes behind each outcome, and the recommendations that should be applied to future projects. It may take the form of a single completed template entry or a compiled register of multiple entries drawn from across the project lifecycle. Its purpose is to convert individual project experience into reusable organisational knowledge.
The best format depends on how your organisation plans to use the information. A Word document works well for smaller teams needing a straightforward narrative record. An Excel spreadsheet is more suitable for organisations managing multiple projects simultaneously, as it allows filtering and analysis by phase, category, or status. For formal reporting and archiving, a PDF version is appropriate. IPM provides free downloadable templates in the Excel format.
In Excel, set up each row as a single lesson entry and use columns to represent the core template fields: Issue Description, Project Phase, Root Cause, Impact, Recommendation, Owner, and Status. Apply data validation to the Phase and Status columns using dropdown menus to ensure consistency across entries. Add a filter row at the top so the register can be sorted and queried easily. A summary dashboard tab using COUNTIF formulas can provide an at-a-glance view of lessons by status and phase across the portfolio.
In professional and formal contexts, acceptable alternatives to ‘lessons learned’ include ‘project knowledge review’, ‘retrospective findings’, ‘continuous improvement log’, or ‘organisational learning register’. The last of these is particularly well-suited to programme and portfolio environments where the process operates at an enterprise level. The choice of terminology often depends on organisational culture, audience, and the level at which the process is being managed.
Lessons learned should be captured throughout the project lifecycle, not solely at closeout. The most effective practice is to review and record lessons at the end of each project phase or major milestone, while events are still recent and details remain accurate. At initiation, the team should also review lessons from previous comparable projects before the plan is written. The closeout session then synthesises cumulative lessons into a final register entry and assigns ownership for follow-up actions.
The core project team should always attend, including the project manager, team leads, and key contributors from each functional area. Where appropriate, the project sponsor and key stakeholder representatives can add valuable perspective, particularly on whether project outcomes met their expectations and how communication and decision-making could be improved. External suppliers or contractors who played a significant role in delivery may also be invited to contribute, depending on the nature of the project and the contractual relationship.
