Study guide
3.2 Learn from Experience
PRINCE2 Practitioner Version 7
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Exam Strategy & Open-Book Technique
2 PRINCE2 7 Method Overview
2.1 The PRINCE2 7 Method 2.2 What Changed in PRINCE2 7 2.3 Performance Targets, Tolerances & Project Context
3 PRINCE2 Principles (1–4)
3.1 Continued Business Justification 3.2 Learn from Experience 3.3 Defined Roles, Responsibilities & Relationships 3.4 Manage by Stages
4 PRINCE2 Principles (5–7) & Applying Principles
4.1 Manage by Exception 4.2 Focus on Products 4.3 Tailor to Suit the Project 4.4 Applying Principles in Context
5 People Management in Projects
5.1 Organisational & Project Ecosystems 5.2 Leadership in Projects 5.3 Team Culture & Diversity 5.4 Communication, Stakeholder Engagement & Change Management
6 Practices Overview & Business Case
6.1 The Seven Practices & Tailoring 6.2 Business Case: Desirability, Viability & Achievability 6.3 Business Case Lifecycle & Management Products 6.4 Business Case Application & Tailoring Scenarios
7 Practices: Organising & Plans
7.1 Organising: Roles & Accountability 7.2 Organising: 5-Step Ecosystem Technique 7.3 Plans: Three Levels & Product-Based Planning 7.4 Plans: Techniques, Tolerances & Tailoring
8 Practices: Quality & Risk
8.1 Quality: Planning, Control & Assurance 8.2 Quality Techniques & Management Products 8.3 Risk: Threats & Opportunities 8.4 Risk 5-Step Technique & Application
9 Practices: Issues
9.1 Issues Practice: Issue vs Change & Categories 9.2 Issues 5-Step Technique & Supporting Techniques 9.3 Change Control, Configuration & Priority/Effort Assessment
10 Practices: Progress, Sustainability & Application
10.1 Progress: Controls, Tolerances & Reports 10.2 Sustainability as the 7th Performance Target 10.3 Tailoring the Practices 10.4 Practices Application Scenarios (BL4)
11 Processes: Model, Starting, Directing & Initiating
11.1 The Seven Processes & Process Model 11.2 Starting Up a Project 11.3 Directing a Project 11.4 Initiating a Project
12 Processes: Controlling a Stage & Product Delivery
12.1 Controlling a Stage 12.2 Managing Product Delivery 12.3 Stage Control & Exception Scenarios (BL4) 12.4 Work Packages & Reporting Cycle
13 Processes: Stage Boundary, Closing & Tailoring
13.1 Managing a Stage Boundary 13.2 Closing a Project 13.3 Tailoring the Processes 13.4 Process Application Scenarios (BL4)
14 Tailoring, Management Products & Exam Technique
14.1 Tailoring to Project Environment, Scale & Agile 14.2 Management Products & the v7 Project Log 14.3 Final Exam Technique, Full Scenarios & Common Traps
3.2 Learn from Experience
Key Takeaways Explain This Topic AI
PRINCE2 projects seek and record experience at three points: before start (from similar past projects), during delivery (captured as the project proceeds), and at closure (follow-on action recommendations).
Lessons are recorded in the Lessons Log, which in v7 sits within the Project Log , and must be acted on — a lesson logged but not applied is worthless.
The exam distinguishes "lessons learned" (merely recorded) from "lessons applied" (acted upon); a PM who logs but never changes behaviour is failing the principle.
Last updated: August 2026
What the principle means
PRINCE2 v7 retains learn from experience as a foundational principle. Projects do not exist in a vacuum: comparable projects have been run before, the running project generates its own experience, and closure is the moment to pass that experience on. The principle therefore operates at three distinct points :
- Point Activity Source
- Before start Seek experience from similar past projects Corporate/programme knowledge, previous Lessons Logs
- During delivery Capture lessons as the project proceeds Issues, risks, quality results, team retrospectives
- At closure Record follow-on action recommendations for future projects End Project Report, Lessons Report
At Starting Up a Project the team is expected to look outward — what can be learned from similar past projects — and feed that into the Project Brief and initial risk thinking. This is not a box-ticking exercise: the principle assumes that seeking experience is an active verb, not a passive one.
Where lessons are recorded
In PRINCE2 v6 and earlier, lessons were recorded in a standalone Lessons Log . In v7 this log is consolidated into the Project Log (a single living register that also captures issues, risks, and daily notes). Either way, the recording mechanism is only the first half of the principle. The critical distinction the exam probes is:
Lessons learned — the lesson has been identified and recorded.
Lessons applied — the lesson has actually changed behaviour, plans, or process.
A lesson that is logged but never applied satisfies the paperwork but fails the principle . The PRINCE2 guidance is blunt: a lesson not acted on is worthless.
Application in exam scenarios
At Bloom's Level 4 the exam will test whether you can analyse a scenario and spot the gap between recording and acting. Typical scenarios:
A Project Manager who faithfully logs every issue in the Lessons Log but never changes the Stage Plan, quality checks, or team instructions. The correct analysis: the PM is not applying lessons and therefore not honouring the principle — the register is full, the behaviour is unchanged.
A team that begins work at Starting Up without checking whether the organisation has run a similar project before. The correct analysis: the seeking step at initiation was skipped; the principle applies from the very first process, not only at closure.
A question on what to do with a captured lesson: route it into the relevant plan or checklist (action), not just into the log (record).
The follow-on action recommendations
At project closure the Lessons Report (a v7 output) records follow-on action recommendations — lessons that should be picked up by subsequent projects or operational use. This is how experience propagates beyond the single project and is the third point at which the principle bites.
Common traps
Treating "lessons learned" as the end state. The exam expects you to push to "lessons applied".
Assuming the principle only fires at closure. It fires at start, during, and end.
Confusing the Lessons Log with the Issue Register. Issues are current problems; lessons are generalised experience derived from resolving them.
How lessons feed the Risk Register and Quality Register
A captured lesson is not an end state; it must be routed into the project's active controls. A lesson about a recurring integration defect should become a new risk entry (or an update to an existing risk's probability and impact), and may also produce a new quality check entry in the Quality Register . A lesson about an unreliable third-party vendor should update the relevant entry in the Project Log and inform the next Work Package's acceptance criteria. The exam tests this routing: a lesson that sits in the log but does not change the Risk Register, Quality Register, or a Stage Plan has not been applied.
Worked scenario: seeking lessons at Starting Up
At Starting Up a Project, a university is planning a new student records migration. A comparable project ran in the same faculty 18 months earlier and overran by 40% due to data cleansing problems. The correct action under the principle is to actively seek that prior project's Lessons Report and feed its findings into the Project Brief, the outline Business Case risk section, and the initial risk thinking — not to wait until initiation or stage 1 to "see what happens". A PM who skips this step because "this project is different" is failing the seeking duty that the principle imposes from the very first process.
Lessons Report versus End Project Report
The two closure outputs are often confused:
Output Focus
End Project Report Did the project deliver what it promised? Actuals against the Project Plan and Business Case
Lessons Report What should future projects do differently? Follow-on action recommendations
Both are produced at closure, but they answer different questions. A scenario that has the PM writing only an End Project Report and no Lessons Report is failing the third point of the principle — experience is not being propagated forward.
Corporate and programme knowledge
The principle assumes the project sits within a wider organisational memory. Corporate, programme, or customer-level knowledge bases are the source from which pre-start lessons are drawn, and the destination to which closure lessons are returned. If the host organisation has no central lessons repository, the project should still capture lessons in its own Project Log and pass them up via the Lessons Report — the absence of a corporate system does not excuse the project from the principle.
Common traps
Treating the Lessons Log as a "lessons learned register" that exists for its own sake.
Deferring all lesson capture to closure; the principle fires at start, during, and end.
Recording a lesson but leaving the Risk Register and Stage Plan untouched — paperwork without application.