Lessons learned and the review and approval plan

By the end, you can

• Define a lessons-learned step and explain why it belongs in a review and approval plan agreed in advance, rather than only happening informally after a project ends (PM-4).
• Assemble review roles, approval gates, audit-trail requirements and a lessons-learned step into one review and approval plan (PM-4).
• Evaluate a project packet against completeness, source quality and governance-fit criteria, and identify a critical omission such as AI self-approval, an unverified assumption presented as fact, or a missing escalation owner (PM-5).

Before you start

This is Module 5, Lesson 3 of the AI-Powered Project Management course, and the last lesson of the course. It builds on Lesson 1's approval gates and review roles and Lesson 2's audit trail, and closes this module — and the course — by assembling review roles, approval gates, audit-trail requirements and a lessons-learned step into one document: a review and approval plan.

Lessons learned: capturing what worked before memory fades

Most of what a project team learns about what worked and what didn't lives, at first, only in people's heads — and heads forget, especially once a project ends and everyone moves on to the next one. APM's project management glossary defines lessons learned as "documented experiences that can be used to improve the future management of projects, programmes and portfolios." The definition is worth reading for what it doesn't say: it doesn't say lessons learned happen automatically, or that a project produces them just by finishing. They exist only if someone deliberately writes them down.

A lessons-learned step works best as a planned point in the review and approval plan, not an afterthought squeezed in if there's time once the project is over. Treated as a standing step — due at each major gate, not just at the very end — it catches things while they're still fresh: which review path actually worked, which gate slowed things down without adding real scrutiny, which audit-trail habit saved someone real time later. Left informal, the same insight often survives only as something someone mentions in passing months later, half-remembered and no longer specific enough to act on.

This course's five final-assessment artifacts, and where each one lives

This course's final assessment asks for five artifacts, one built across each module: an AI-assisted project brief, a task breakdown with dependencies and acceptance tests, a risk and decision record, an evidence-based status update, and a review and approval plan. None of them is new at this point — each was this course's own closing lesson for its module:

• **AI-assisted project brief** — Module 1 Lesson 3's bounded project brief: goal, scope, assumptions, constraints and success measures assembled together.
• **Task breakdown with dependencies and acceptance tests** — Module 2 Lesson 3's reviewed task breakdown: milestones, sliced tasks with estimate ranges, confirmed dependencies and acceptance criteria assembled together.
• **Risk and decision record** — Module 3 Lesson 3's decision/risk packet: a risk register, a decision record and an escalation path assembled together.
• **Evidence-based status update** — Module 4 Lesson 3's evidence-based status update: checked meeting notes, an action log and explicitly named unknowns assembled together.
• **Review and approval plan** — this lesson's own artifact, assembled next.

Assembling the review and approval plan

A review and approval plan has four parts, and a plan missing any one of them is not complete, whatever else it contains:

AI can help draft a first pass at all four, the way this module's earlier lessons have shown — proposing a review-path map, a first-cut audit-trail structure, a lessons-learned prompt for each gate. What makes the plan real is the same discipline this course has applied to every earlier artifact: a named sponsor or governance body checks, corrects and confirms each element using knowledge of the organisation's actual authority and history that no draft has access to, and — as Lesson 1 established — never signs off its own drafted work. The Open Worldwide Application Security Project's (OWASP) guidance on excessive agency is direct that a human should "approve high-impact actions before they are taken"; agreeing the review and approval plan itself, the structure every later decision will be checked against, is exactly that kind of high-impact action.

Completing this course's final assessment with an AI-assisted project brief, a task breakdown with dependencies and acceptance tests, a risk and decision record, an evidence-based status update and a review and approval plan shows that you can carry a project idea through framing, planning, risk and decision work, and honest status reporting, while keeping a named human accountable for every high-impact call along the way. It is not a credential or an accreditation, and it does not promise that a project will succeed, that a career outcome will follow, or that a real governance board will approve everything you bring them — what it shows is that you built the habit of keeping a human in charge of the calls that matter, not that those calls will always be easy.

• Review roles — who has authority to decide at each gate, named specifically, not "the team" (Lesson 1).
• Approval gates — the fixed points where work pauses for a decision, agreed before the project needs one (Lesson 1).
• Audit-trail requirements — what evidence must be kept for each gate, and where it lives, so a later reviewer can actually check a decision was made as claimed (Lesson 2).
• A lessons-learned step — a planned point to capture what worked and what didn't, due at each major gate rather than left to happen informally, if at all (this lesson).

Evaluating a project packet: completeness, source quality, governance fit

Evaluating a finished packet is a different skill from building any one artifact in it, and it's the one PM-5 names directly: checking AI-supported project outputs for completeness, source quality and governance fit. Three questions cover most of what a reviewer needs to check. Completeness: is every required artifact actually present, and does each one itself contain everything its own module defined as required — a brief missing a success measure, or a status update with no named unknowns, fails here even if everything else looks polished. Source quality: is every factual or time-sensitive claim in the packet either genuinely checked, or honestly labelled as an assumption, an estimate or still open — a packet that quietly states a guess as settled fact fails here, however confident it reads. Governance fit: does the packet show real named owners, a real review path, and evidence that AI drafted but did not decide — a packet where AI approved its own recommendation, or where no named person is accountable for a high-impact call, fails here regardless of how thorough the rest of it is.

This lesson's Exercise below is practice for that evaluation step alone — checking a packet against these three criteria — using a project you have not worked on yourself. It is not the final assessment, which asks you to bring your own real project's five artifacts together; it is the one layer of that assessment — evaluation — that this closing lesson lets you rehearse first.

A worked example: reviewing Riverside Food Bank's own packet

Before taking her full packet to the trustee board, Riverside Food Bank's operations coordinator runs her own evaluation pass against these three questions. Completeness: her bounded project brief, reviewed task breakdown and decision/risk packet are all present and each contains its own module's required elements; her evidence-based status update is missing a named unknown she knows is still genuinely open — whether the software vendor's UK data-hosting claim actually holds, which she had meant to check and forgot — so she adds it rather than letting the update look more settled than it is. Source quality: she confirms the vendor's data-hosting claim is exactly the kind of thing that needs checking against the vendor's own current documentation before the packet goes to the board, not repeated from the sales call where someone mentioned it. Governance fit: she checks that her review and approval plan names Priya, the director, and the trustee board by name at each gate — it does — and confirms nowhere in the packet did she let an AI-drafted recommendation stand in as if it had already been approved, catching one line in an earlier draft where an AI assistant's summary had described a decision as "agreed" when it had only been proposed. She corrects it before the board sees the packet.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Project management glossary — APM (Association for Project Management). Defines lessons learned as documented experiences that can be used to improve the future management of projects, programmes and portfolios.
2. AI Risk Management Framework 1.0 — NIST AI Resource Center. Frames an AI system as an engineered system that generates outputs such as predictions, recommendations or decisions — not a self-directing decision-maker.
3. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Recommends human-in-the-loop control requiring a person to approve high-impact actions before an LLM-connected system takes them.