AI Adoption GuideConsultingClose
Lessons Learned Synthesizer
LLM compiles a structured postmortem from project artifacts, timesheets, and meeting notes without manual facilitation.
Consulting processSellScopeStaffKickoffAnalyzeRecommendDeliverClose
By Don, DoneThat’s AI coach · updated
Compile the file. Still run the room.
The LLM's job is a structured draft from what the engagement left behind. A human still runs the conversation that accepts or rejects each row. Compilation without a facilitator is not the same as skipping the retro.
A generated retrospective that nobody attends looks like learning. It is not. Close already fails in two directions: nobody books the session, or the session produces a slide that would fit any engagement ("communicate more," "staff earlier," "manage scope"). Neither can seed a risk register bootstrapper on the next similar SOW, because neither names an event.
Use the model to assemble an agenda the room can argue with. Hours against the estimate, missed dates, the issue log, change orders, steering notes, and delivery flags that actually materialized are the corpus. Memory is the correction pass, not the source.
If you skip the meeting, stop. The generated document will be retrieved as if the firm already learned.
Name the event, the cost, and what contained it
Compile candidate rows from three sources that already exist.
Artifacts. The signed SOW and change orders. The live risk register, including rows nobody reviewed. Steering packs. The issue or RAID log. Flags a workstream delivery risk predictor raised that later came true. A flag the team contained is a lesson about containment. A flag that sat amber until the milestone moved is a lesson about what failed.
Timesheets. Hours against the estimate, by workstream and by week, not a utilization total. Idle time, rework, and senior-time drop-off are events. The gap between quoted and actual hours is computed. Do not ask the room to remember it. If people recoded waiting time as billable, treat the hours as a lower bound.
Meeting notes. Steering minutes, working-session notes, and client email already in the project space. Use them to date when a problem became visible. A soured sponsor rarely appears as a ticket. Notes can show the week the deputy started taking the steering pack. They cannot tell you the sponsor had already checked out. If the notes are only action items, put that limitation at the top of the draft.
Force every candidate into four fields:
- Event. A specific thing that happened, tied to a workstream. Not "stakeholder alignment."
- When it showed. A week or a date, cited from a note, a ticket, a timesheet spike, or a predictor flag.
- What it cost. Language from the file: idle weeks, a rework loop, a slipped milestone, a change order, senior hours that never arrived. If the file has no cost language, leave the cell blank.
- What contained it or failed. The action that was tried. If nothing was tried, write that.
Group issues by cause, not by log order. Ten extract tickets are often one access event.
Do not ask the model for "what we should do next time" on the first pass. Tried containment is evidence. Advice is the team's job after they accept the row.
Bid-stage themes and named blame are a different file
Do not mix this corpus with win/loss pattern synthesis. That work runs on buyer interviews and submitted proposals for Closed-Won and Closed-Lost pursuits. A delivery postmortem runs on this engagement's hours, issues, and notes. Mixing the two contaminates both files.
A proposal that under-scoped data access is a bid-stage finding if the submitted SOW or the buyer said so. It is a delivery finding if, after award, extracts arrived late and analysts sat idle. Those facts can be related. They are not the same row. If the model pulls the proposal folder into the retro and clusters "we underpriced complexity" or "we lose on price," cut that block. Send it to capture.
The other contamination is blame. A draft that names a partner, a workstream lead, or a client counterpart as the cause will not be discussed honestly, and it must not be published. Rewrite before anyone sits down. "The staffing plan promised a named partner one day a week; timesheets show that day vanishing after week four" is a process fact. "The partner checked out" is a review. Reviews get buried. Process facts can travel to the next kickoff.
If the corpus is thin, say so on the draft. Confident prose from hollow timesheets and empty notes is fiction.
Illustrative example: Pell & Ash closes Harborline
This is a worked example with made-up firms, written to show the cuts, not a case study with results.
Pell & Ash is closing a 14-week store-operations engagement with Harborline Retail. Three workstreams: labor-hours baseline, exception-process redesign, and a 90-day store cadence. Priya Shah is the engagement manager. Nobody has booked a retro.
She does not open a blank lessons page. She feeds the signed SOW, two change orders, timesheets by workstream and week, the issue log, steering minutes, and predictor flags from week six onward. She asks for at most twelve candidate rows in the four-field shape, each cited from those files.
The draft returns nineteen rows. Catalogue language (communicate more, manage scope, staff to the plan) gets deleted. Two rows name the delivery partner as the reason senior time dropped. She rewrites them before the team sees them: the staffing plan promised one partner-day a week; timesheets show that day gone after week four; steering notes stop listing the partner as present.
One block is bid-stage. The model ingested the proposal folder and clustered "we underpriced complexity" from an internal chase note written before award. Priya cuts it. That sentence belongs in a win/loss pack.
What remains is specific. Timesheets show analysts waiting, or recoded as billable, in weeks two and three while "data access granted" was still not a working extract. Steering minutes date the first complete file to week five. The issue log clusters rework after exception workshops ran in week four, before the baseline was agreed. A predictor flag on the redesign workstream sat amber for three weeks; the milestone still moved. One change order bought extra baseline weeks. Nothing in the file describes containment for the access delay, because nothing was tried except chasing the original contact.
Priya takes eight candidates into a forty-minute session. They accept five: working access versus granted access, workshop sequencing against the baseline, senior-time coverage after week four, an amber flag that never became a conversation, and a fee-logic assumption the SOW treated as known. They rewrite the senior-time row so it names the staffing plan, not the partner. They reject "client culture" because it cites no artifact, and a row that restates the change order as a lesson.
The live postmortem has five accepted rows.
File only the rows the team accepted
Book the session against the draft. For each row: accept as written, rewrite the event or the cost language, or cut. "Noted" is not allowed. Email is how rows survive without anyone owning them.
Park the accepted file where the team already writes close notes. Tools in the Notion, Confluence, Smartsheet, and Jira class all hold a retro or a close pack. Use the one this engagement already lives in. Do not stand up a second lessons page in a slide appendix. Two copies diverge, and the next kickoff will retrieve the wrong one.
Do not auto-index the generated draft. A reusable IP extraction agent is a different job: method, templates, and models stripped of this client's exhibits. Harborline's process map must not travel. The lesson "workshops before baseline caused rework" may. A project knowledge base ingestion agent should see only the accepted postmortem, with access boundaries, after blame and bid-stage mix-ins are gone. Indexing the raw draft is how another account retrieves a named partner's failure.
Feed accepted rows, not the catalogue, into the next similar kickoff via the risk register bootstrapper. The test is whether that team can keep or cut a risk because this file named an event, a cost, and a containment. If they open a slide that says communicate more, the synthesizer did not run.
Trial it on one close you are already running. If the file went to the archive with nobody in the room, stop.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first