Draft a Lessons Learned Report
Structure a lessons learned report from project completion data, capturing what went well, what could improve, and actionable recommendations.
Editor: Owen HaggerLast updated
Overview
This workflow helps Project Managers compile a structured lessons learned report at project completion or key milestones. It organises feedback into categories and produces actionable recommendations that can be shared across the business.
Want more templates like this?
Get new AI workflows and construction templates delivered weekly. Free.
Subscribe Free
No spam ever.
Prompt
You are a UK Construction Project Manager compiling a Lessons Learned Report at the end of a project. Using the raw data below, structure a comprehensive lessons learned document: Project Details: - Project Name: [NAME] - Client: [CLIENT NAME] - Project Type: [TYPE, e.g., Office refurbishment] - Contract Value: [ORIGINAL VALUE] / Final Account: [FINAL VALUE] - Original Programme: [START] to [PLANNED END] - Actual Completion: [ACTUAL END] - Project Team Size: [NUMBER, e.g., 12 site-based staff at peak] Project Outcomes: - Programme Performance: [e.g., Completed 3 weeks late due to design changes in Months 4-6] - Cost Performance: [e.g., Final account £120K over original contract sum, mainly due to unforeseen asbestos] - Quality Performance: [e.g., 142 snagging items at PC, 95% closed within 4 weeks] - Safety Performance: [e.g., Zero RIDDOR, 2 minor first-aid incidents, 14 near-miss reports] - Client Satisfaction: [e.g., Generally positive, concerns raised about communication during design changes] Key Observations (raw feedback): [PASTE RAW NOTES, e.g., - Subcontractor procurement started too late for M&E package - BIM model was not maintained after RIBA Stage 4, caused coordination clashes on site - Weekly client meetings worked well, kept issues visible - Material deliveries from Europe had longer lead times than planned - Site induction process was praised by HSE inspector] Structure the report as: 1. Executive Summary: 3-4 sentence overview of the project and key outcomes 2. What Went Well: categorised by Design, Procurement, Construction, Commercial, H&S, Client Relationship 3. What Could Be Improved: same categories 4. Root Cause Analysis: for the top 3 issues, identify the underlying cause 5. Recommendations: numbered, actionable recommendations with suggested owner (e.g., "Pre-construction team", "Commercial department") 6. Metrics Summary Table: programme, cost, quality, and safety KPIs in a simple table Keep the tone constructive and forward-looking. Focus on actionable improvements rather than blame.
Typical result
~2hby hand~45mwith AI
A cautious typical estimate, including the time to gather the inputs and check the output. It varies with the job.
What it replaces: Writing up lessons learned from meeting notes.
What you still check
- Lessons are specific and have an owner
- Positive and negative points are both captured
- The report is shared with the next project team
Use Case
Use at practical completion or after any significant project milestone. Gather raw feedback from the project team and paste it in: the AI will organise it into a professional lessons learned report.
When not to use it
Don't use it in place of an accident investigation. A RIDDOR incident or a serious near miss needs its own investigation by competent people, and the lessons learned report should only refer to the outcome.
Be careful if the project is in dispute or heading that way. A frank internal report about what went wrong could be disclosed if the dispute goes formal. Check your contract and take advice before you write it, and keep the facts separate from opinion.
Common mistakes
- Writing it from the project manager's notes alone. Get the site team, the QS, the designers and the key subcontractors involved, even if it's just a call.
- Lessons too vague to act on, like "communication could be better". Say what happened, why, and what to do differently next time.
- Recommendations with no owner or date, so nothing changes.
- Naming and blaming individuals or subcontractors in a document that gets circulated. Focus on the process, not the person.
- Filing it and never feeding it back into estimating, tendering and the next project's execution plan.
Frequently asked questions
- When should lessons learned be captured on a construction project?
- Throughout the job, not just at the end. Capture them at key stages such as the end of design, frame completion, a watertight envelope and handover, while people still remember the detail. A short review at each stage makes the final report far easier to write.
- How do you run a lessons learned session?
- Get the right people together, set a clear agenda and keep it about the process, not individuals. For each area, ask what went well, what didn't and what you'd do differently. Agree the actions and owners before anyone leaves the room.
- How do you write a good lessons learned statement?
- Make it specific and actionable. State what happened, the effect it had, the underlying cause and the change you recommend, with an owner. "Appoint the M&E subcontractor in time to coordinate the design before the frame goes up" is far more useful than "procure earlier".
- What is the difference between a lessons learned report and a closeout report?
- The closeout report records how the project performed on programme, cost, quality and safety. The lessons learned report explains why, and what the business will do differently. The closeout report usually summarises the main lessons and points to the full report.
- Can AI write a lessons learned report?
- It can organise raw notes into a clear structure and suggest root causes worth discussing. It can't tell you which lessons matter most to your business. Take names out of the notes first, and use a business account your company has approved.
Free newsletter
Get AI Tips Weekly
New construction AI workflows, prompts, and templates delivered to your inbox every week.
Subscribe FreeNo spam. Unsubscribe anytime.