Orchard Rollout: Lessons Learned
Lessons learned presentation that names the causes, not the people
Orchard Rollout was a warehouse ERP project planned for 20 weeks that took 26 and cost 12% more than approved. This is the closing review deck: it puts planned against actual on slide two, walks the timeline of what happened, and ends on five lessons each attached to a change the business has already made.
Every slide, in order
The whole deck as it renders, one slide after another. Read it the way the audience would.
The structure
What each slide is doing, so you can reuse the order even with different content.
- Slide 1cover
- The project name and nothing defensive: a close-out review owns its numbers from slide one.
- Slide 2comparison
- Planned against actual on slide two. Every later slide explains one of these rows.
- Slide 3timeline
- What actually happened, in six milestones, slips included with their week counts.
- Slide 4metrics
- The budget bridge from $840k approved to $941k spent, overrun by named cause.
- Slide 5framework
- The fishbone asks why the project ran late, with causes on the bones, never names.
- Slide 6pillars
- What went well, with evidence, because a review that only lists failure teaches half.
- Slide 7checklist
- The five lessons, written as instructions to the next project, not observations.
- Slide 8comparison
- The changes already adopted, was and now, so the review provably produced something.
- Slide 9takeaway
- Four rules for the next rollout, stated as imperatives on a dark slide.
- Slide 10qa
- Discussion, and where the full report lives, because ten slides summarise forty pages.
How to adapt this deck
A sprint retrospective keeps slides two, five and seven, planned versus actual, causes and lessons, and drops the budget bridge; twenty minutes, team only. An incident review swaps the milestone road for a minute by minute timeline and tightens the fishbone to the single failure, which is the postmortem shape the SRE literature describes. For a project that went well, the deck matters even more and almost nobody writes it: keep the same slides, and let the fishbone explain why it worked, because unexamined success is how the next project inherits luck instead of method. Orchard is the same fictional project the project kickoff deck example opens, so the two pages bracket a full project life. Whichever version you run, write the lessons as instructions rather than observations. A lesson that reads we should communicate better changes nothing, and a lesson that reads the site survey happens before the quote goes out changes the next project.
What makes this deck work
Planned versus actual opens the deck
Slide two states 20 weeks planned against 26 actual, $840k against $941k, 40 tolerated defects against 118 logged. Every later slide explains one of those rows: the timeline explains the weeks, the bridge explains the dollars, the fishbone explains both. A review that buries this table is managing perception, not learning.
The fishbone carries causes, not names
Five bones, data, process, vendor, people and governance, each with two specific causes like the 9,000 duplicate items and the fortnightly steering cadence. Not one bone is a person. That is what makes the five lessons presentable in a room containing everyone who worked the project.
Every lesson has a change already made
The five lessons map one to one onto the was and now slide: profile before pricing became a funded spike, one UAT round became two with entry criteria, the staffing handshake became a contract clause. A review that ends in adopted changes rather than recommendations has already paid for its meeting.
Questions people ask
What is a lessons learned presentation?
The closing review of a project, presented to the team and its sponsors: what was planned, what happened, why the gaps opened, what went well, and what the organisation changes as a result. This example reviews a late, over budget ERP rollout in ten slides without naming a single culprit.
How do I structure a lessons learned meeting?
Follow the deck order: the honest numbers first, then the narrative timeline, then cause analysis, then the positives, then lessons and changes. Sixty to ninety minutes with the whole delivery team present. Circulating the planned versus actual table beforehand stops the meeting starting in dispute.
How do I present failure without blame?
Put causes on systems and artefacts, never on roles or names, the way this fishbone hangs the delay on an unprofiled item master and a fortnightly steering cadence. Blameless does not mean consequence free; it means the fixes land on contracts, templates and cadences, which are the things that persist.
What should planned versus actual compare?
Duration, budget, scope and quality at minimum. This deck adds training hours because the overrun there was a good decision worth seeing. Include a row where the plan held, scope stayed at three sites here, so the table reads as measurement rather than confession.
How soon after the project should the review run?
Two to six weeks after close: late enough for hypercare data like the defect count to settle, early enough that memories and the team are still in place. Orchard closed hypercare in week 26 and reviewed in week 30. A review scheduled next quarter is a review that never happens.
Is this the same as a sprint retrospective?
Same intent, different scale. A retrospective inspects a two week window with the team only and skips the money; this reviews a whole project with sponsors present, so it carries a budget bridge and contract changes. The adaptation notes below cover shrinking this shape to sprint size.
Build your own in about a minute
The button below opens the generator with this use case already described. Change the wording to match your own, generate, then edit anything you like.
Make my lessons learned presentation that names the causes, not the peopleOther presentation examples
Thesis defence presentation with one slide per results chapter
This is the 30 minute defence deck for a fictional thesis on how street tree canopy changes summer surface temperature across 14 suburbs. It gives each of the three results chapters exactly one slide, and it puts limitations before the contribution, because examiners trust a candidate who raises the weaknesses first.
Conference talk deck
A nine slide conference talk deck for a thirty minute reliability engineering slot, titled with the claim that the team deleted its own database on purpose. It follows the shape most good talks use: one incident, what the postmortem really found, nine months of deliberate failure drills, a before and after table, then six rules the room can take home.
Project kickoff deck
A nine slide project kickoff deck for Orchard, an invented rollout replacing four warehouse systems with one platform by March 2027. It opens with why now, draws the scope line on slide three, names an owner for each workstream and ends with five decisions the room must make before anyone leaves.
Want the steps in the builder? Read Add charts, maps and diagrams to slides, then Edit your deck with the AI assistant. For everything this generator can do, see the presentation maker.
Written and checked by the OneCraft team. Last checked .