Learn from experience

The second principle states that PRINCE2 project teams learn from experience: lessons are sought, recorded and acted upon throughout the life of the project. The three verbs matter. Seeking means looking actively for lessons at the start, rather than waiting for them to appear. Recording means writing them down so they survive the team. Acting means changing plans, approaches or behaviour as a result. A lessons log that is full of entries but never changes anything is not evidence that the principle is being applied.

Why projects forget

Projects are temporary. A team forms, works intensely for months and then disperses. People move to other projects, contractors leave, and the knowledge that made the difference walks out of the door. The next project in the same organization often makes the same mistakes because nobody told it what happened last time. Organizations that run many projects without learning pay repeatedly for the same lessons.

Projects are also unique. Each has something new about it: a new product, a new supplier, a new location or a new technology. Uniqueness makes it tempting to assume that previous experience does not apply. In practice most project problems are not unique at all. Optimistic estimates, unclear requirements, late supplier deliveries, poor handover to operations and weak stakeholder engagement recur across sectors and decades. Learning from experience is the principle that stops a project treating familiar risks as surprises.

When lessons are sought, recorded and passed on

The principle applies throughout the project, but the emphasis shifts.

PRINCE2 provides two main management products for this principle. The lessons log is a project repository for lessons that apply to this project or future projects. A lessons report passes lessons on to others: to the corporate organization, to a programme, or to future projects. A lessons report may be produced at the end of a stage, after an exception, at closure, or whenever a lesson is significant enough to share immediately.

What makes a good lesson

Not every observation is a lesson. "Testing was hard" is a complaint. A useful lesson describes what happened, why it happened, what effect it had and what should be done differently, in enough detail that someone outside the project can act on it. Good lessons are specific, actionable and tied to a cause.

Lessons can be positive as well as negative. A technique that worked well, a supplier arrangement that prevented problems or a meeting format that sped up decisions are all worth recording. Projects that only record failures miss half of what they could pass on.

Prioritizing lessons

A busy project may record dozens of lessons. Not all of them deserve the same attention. A simple way to prioritize is to score each lesson for the likelihood that it recurs on similar projects and the impact if it does, then act first on the highest scores. The scoring is the same idea as risk assessment, because a lesson is in effect evidence about a risk.

Acting on lessons

The test of this principle is whether lessons change anything. Lessons can act on almost every part of the method:

• Plans: adding contingency or extra tasks where earlier projects struggled.
• Risk: lessons often become risks in the risk register, with responses based on what worked before.
• Quality: lessons about defects lead to stronger quality criteria and review methods.
• Organization: lessons about decision delays lead to clearer delegation or a different board composition.
• Tailoring: lessons about bureaucracy or gaps lead to changes in how the method is applied.
• Contracts: lessons about supplier performance lead to better terms in future procurements.

When a project manager documents the project approach during initiation, a short note on how key lessons have been applied is good evidence of the principle in action. Assurance reviewers look for exactly that link.

Organizational learning

A single project can only do so much. Lasting learning needs the organization to collect lessons across projects, analyse them for patterns and change its standards. A project management office, a centre of excellence or a programme office often maintains a lessons library. The most useful libraries are searchable, tagged by topic and project type, and curated so that outdated lessons are retired.

There is a well-known gap between identifying lessons and learning them. Many organizations produce lessons reports that nobody reads. Learning happens when lessons change processes, templates, training or contracts. A lesson about weak acceptance criteria is truly learned when the organization's product description template prompts for measurable criteria and reviewers reject descriptions without them.

Learning from public-sector projects

Public inquiries and audit reports are rich sources of lessons. In Canada, the Phoenix pay system, launched for the federal public service in 2016, produced widespread pay errors affecting a large share of employees. A 2018 independent lessons-learned review by Goss Gilroy and reports by the Auditor General found, among other things, that functions and testing were reduced to hold cost and schedule, that the system was launched without an adequate pilot, and that warnings were not escalated effectively. Those findings have been used in later federal guidance, and the Treasury Board Directive on the Management of Projects and Programmes stresses independent review and governance. The project to replace Phoenix has itself been the subject of further audits that draw on these lessons.

Whatever the sector, the most valuable lessons from such cases are rarely about technology. They are about decisions: who had authority, whether warnings were heard, whether testing was cut to meet a date, and whether the business case was honestly reviewed. Each of these connects to one or more PRINCE2 principles, which is why studying them is part of learning from experience.

Barriers to learning

Even well-intentioned teams struggle to learn. The common barriers are cultural rather than technical. People fear blame, so they hide mistakes. Teams are rushed at closure, so retrospectives are skipped. Lessons are written in vague language, so nobody can act on them. Lessons libraries are hard to search, so nobody looks. The project manager who wants to apply this principle needs to create a climate in which raising a lesson is normal and safe, and to schedule time for learning at the start, at stage boundaries and at closure.

Short, regular retrospectives help. Agile teams hold them at the end of every sprint, and a PRINCE2 project can use the same habit at checkpoints or stage ends. A good retrospective asks three questions: what went well, what did not, and what will we change? The third question turns observation into action.

Lessons from outside the organization

Lessons do not have to come from your own organization. Industry associations, professional bodies, published case studies, supplier experience and peers in other organizations are all valuable. A hospital planning a new records system can learn from hospitals that have already implemented one; a municipality planning a library renovation can call the project manager of a similar project in a neighbouring town. External lessons are particularly useful when the organization has never done this kind of project before, which is exactly when internal lessons are scarce.

Suppliers are an underused source. A supplier who has delivered similar products many times often knows the common failure points better than the customer does. Asking the supplier at initiation, "what usually goes wrong on projects like this?", costs nothing and frequently surfaces risks that would otherwise appear only in delivery. The answer belongs in the lessons log and, where relevant, in the risk register.

Learning during the project, not only between projects

Some lessons should change the current project immediately. If the first quality review of a set of product descriptions finds that criteria are vague, the project manager should not wait until closure to record that lesson; the remaining product descriptions should be improved now. If a supplier's first delivery reveals a misunderstanding about formats, the next work package should be clarified straight away. Learning within the project is often worth more than learning for the next one, because the people who benefit are still in the room.

Stage boundaries are a natural point to pause and review lessons from the stage just ending. The end stage report includes a review of lessons, and the next stage plan should show how the important ones have been applied. A board member who asks "what did we learn in this stage, and what are we doing differently in the next?" is applying this principle at the directing level.