3.2 Learn from Experience

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:

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:

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.