Post-Project Debrief Reviews | Knowledge Base

Large commercial projects are among the most complex and time-intensive work EnergyAE undertakes. They span years, involve multiple stakeholders across testing, modelling, certification, and submission — and every project surfaces situations not covered in standard procedures. A structured debrief converts that hard-won experience into documented, shared knowledge before it walks out the door.

Why a Debrief Is Needed

A project spanning 1-2 years may involve:

Unexpected EN 14511 testing delays or non-conformances requiring re-testing
Documentation gaps that caused audit RFIs and submission delays
Client-side changes to system design partway through modelling
Edge cases in scheme regulations requiring direct regulator engagement
Communication breakdowns between the client, testing lab, certification body, and EnergyAE
New product model variants added mid-project that changed the scope
Scheme regulation changes mid-project that affected certificate quantities or eligibility

Without a debrief, those insights exist only in the memory of whoever worked the project. When that person moves on, or the same situation arises on a different project two years later, the team solves the same problem from scratch. The debrief converts personal experience into institutional knowledge.

Debriefs are mandatory for any project that involved:

Project duration greater than six months
Significant client friction or communication breakdown
EN 14511 testing issues (re-tests, anomalous data, non-conformance)
Certification delays or novel certification scope
Multiple scheme RFI cycles or portal rejections
Novel system configurations not previously modelled
Scope changes after quotation acceptance

When to Conduct the Debrief

Run the debrief within two weeks of final submission confirmation. Do not wait — recollection fades quickly after project close.

Using Claude to Generate the Debrief Report

The most powerful approach is to use Claude with Microsoft 365 access to trawl the full project communication history — Outlook emails and Teams messages — and synthesise a structured report. This is particularly effective for long projects where thousands of messages span several years and multiple workstreams.

Claude can search by:

Client email addresses and domains
Product or project keywords
Subject line fragments
Third-party contact email addresses (testing labs, certification bodies)

Step 1: Prepare the Claude Prompt

Open Claude (claude.ai or Claude Code with M365 tools connected). Use the template below, adapted for your project. The more specific your identifiers, the better the search results.

Base prompt template:

Generate a structured post-project debrief report for the following EnergyAE project.

PROJECT DETAILS
Project code: [e.g. AE523_ESW]
Client: [Client full name and trading name if different]
Client contacts:
  - [Name] — [email addresses]
  - [Name] — [email addresses]
EAE team lead: [Name]
Project duration: [approximate years]

SEARCH SCOPE
Search all Outlook emails (sent and received) and Teams messages related to this project.
Use the following identifiers:

Client email domains: [e.g. @chwam.com.au, @esw.net.au]
Product keywords: [e.g. "Flex 18", "Tower 50"]
Project code: [e.g. AE523, ESW]
Testing lab contact: [name and email, e.g. huangkp@cvc.org.cn]
Testing subject line fragment: [e.g. "Large commercial quote for EN 14511 testing - ESW"]
Certification contact: [name and email, e.g. adam.w@iapmooceana.org]

REPORT STRUCTURE
Produce a debrief report with the following sections:

1. PROJECT SUMMARY
   - Systems modelled (HP models, tank models, configurations)
   - Schemes submitted (VEU, ESS, other) and approximate certificate quantities
   - Project timeline with key milestone dates
   - EnergyAE team members involved across the project

2. TESTING PHASE
   - Testing lab(s) used and contacts
   - Number of test rounds; any re-tests required and why
   - Issues encountered and how they were resolved
   - Lessons: what would have made this phase smoother?

3. DOCUMENTATION AND INTAKE
   - Documentation gaps or quality issues found during review
   - Client responsiveness; delays caused by missing or incorrect documents
   - Lessons for future documentation checklists

4. MODELLING
   - System configurations modelled and any non-standard approaches used
   - Issues with TRNSYS or the commercial modelling tool
   - Scheme regulation changes during the project that affected results
   - Gate A review findings — what did peer review catch?
   - Lessons for the modelling workflow

5. CERTIFICATION
   - Certification body and contact
   - Standards covered (e.g. AS/NZS 4692, AS/NZS 2712)
   - Issues or delays encountered during certification
   - Lessons

6. AUDIT PREPARATION AND SUBMISSION
   - RFIs received from scheme administrators — what triggered each one?
   - Any submissions rejected or requiring resubmission
   - Lessons for audit file preparation and Gate B review

7. CLIENT RELATIONSHIP AND COMMUNICATION
   - Communication rhythm and overall effectiveness
   - Scope changes or additions during the project
   - Friction points and how they were managed
   - What the client valued most from EnergyAE's work

8. OVERALL LESSONS LEARNED
   - Top 3–5 things we would do differently from project kickoff
   - New procedures, templates, or checklists that should be created
   - Specific KMS pages that should be updated based on this project's experience

Format each section with clear headings and bullet points. Flag any section where information was sparse in the communications history and may need manual input from the team lead.

Step 2: Worked Example — AE523_ESW

Below is a complete, ready-to-use prompt for the ESW project. Copy this directly into Claude.

Generate a structured post-project debrief report for the following EnergyAE project.

PROJECT DETAILS
Project code: AE523_ESW
Client: Commercial Hot Water & Maintenance (CHWAM) / Energy Smart Water (ESW)
Client contacts:
  - Chun Goh — chun.goh@chwam.com.au, chun.goh@esw.net.au
  - Alvaro Bernarde — alvaro@chwam.com.au, alvaro@esw.net.au
EAE team lead: Finn Petersen
Project duration: approximately 4 years

SEARCH SCOPE
Search all Outlook emails (sent and received) and Microsoft Teams messages related to this project.
Use the following identifiers to find relevant communications:

Client email domains: @chwam.com.au, @esw.net.au
Product keywords: "Flex 18", "Tower 50"
Project code: AE523, ESW
Testing lab contact: huangkp@cvc.org.cn
Testing subject line: "Re:Large commercial quote for EN 14511 testing - ESW"
Certification contact: adam.w@iapmooceana.org (Adam Weggmann, IAPMO Oceana)

REPORT STRUCTURE
Produce a debrief report with the following sections:

1. PROJECT SUMMARY
   - Systems modelled (HP models, tank models, configurations)
   - Schemes submitted and approximate certificate quantities
   - Project timeline with key milestone dates
   - EnergyAE team members involved

2. TESTING PHASE
   - Testing lab(s) used and contacts
   - Number of test rounds; any re-tests required and why
   - Issues encountered and how they were resolved
   - Lessons: what would have made this phase smoother?

3. DOCUMENTATION AND INTAKE
   - Documentation gaps or quality issues found during intake review
   - Client responsiveness; delays caused by missing or incorrect documents
   - Lessons for the documentation checklist

4. MODELLING
   - Systems modelled and any non-standard approaches required
   - Issues with TRNSYS or the commercial modelling tool
   - Scheme regulation changes mid-project that affected the results
   - Gate A review findings — what did peer review catch?
   - Lessons for the modelling workflow

5. CERTIFICATION (Adam Weggmann / IAPMO Oceana)
   - Standards covered and product scope
   - Issues or delays encountered
   - Lessons

6. AUDIT PREPARATION AND SUBMISSION
   - RFIs from scheme administrators — what triggered each one?
   - Any submissions rejected or requiring resubmission
   - Lessons for audit file prep and Gate B review

7. CLIENT RELATIONSHIP AND COMMUNICATION
   - Communication rhythm and effectiveness with Chun and Alvaro
   - Scope changes during the project (new models, additional HP or tank variants)
   - Any friction points and how they were managed

8. OVERALL LESSONS LEARNED
   - Top 3–5 things we would do differently from kickoff
   - New procedures, templates, or checklists to create
   - Specific KMS pages in /kms/10-large-commercial-modelling/ that should be updated

Format with clear headings and bullet points. Flag sections where communication data was sparse and manual input from Finn is needed.

Step 3: Refining the Output

After the initial report is generated, use follow-up prompts to deepen specific sections. Examples:

To expand a sparse section:

“The testing section is thin. Search again specifically for all emails from huangkp@cvc.org.cn and any email with ‘EN 14511’ in the subject line from 2022 onwards. Summarise what happened at each stage of the testing process for the Flex 18 and Tower 50.”

To surface a specific incident:

“There appears to have been a delay in receiving the EN 14511 test report for one of the models. Find the email thread that discusses this delay and summarise the cause and resolution.”

To find overlooked contacts:

“Are there any email addresses or senders in threads tagged AE523 or ESW that haven’t been mentioned yet? List any new contacts and their apparent role in the project.”

To sharpen lessons into KMS actions:

“For each lesson in Section 8, identify the specific file in /kms/10-large-commercial-modelling/ that should be updated and suggest the exact text addition or change.”

To check completeness against known products:

“The project involved two product lines: Flex 18 and Tower 50. Confirm that both product lines are covered in the modelling section. If one is missing, search specifically for it.”

Step 4: Review and Validate the Output

Claude’s synthesis is only as good as what the communication history contains. Before finalising:

Ask the team lead (Finn Petersen in this example) to review each section and annotate gaps or corrections
Pay particular attention to Section 8 (lessons) — this has the highest value and most often needs human nuance
Verify that all system variants are represented in the modelling section
Check that scheme regulation changes mentioned in the report are correctly dated

Saving the Debrief Report

Save the final report in:

C:\Users\[USER]\Energy AE\Files - Review\Commercial project debrief reviews\

Use the naming convention:

[PROJECT CODE]_[CLIENT SHORT NAME]_Debrief_[YEAR].docx

Example:  AE523_ESW_Debrief_2026.docx

One file per project. Use version suffixes (_v2, _v3) for revisions rather than creating separate files. Export from Claude as a Word document, or paste into Word from the Claude output and save as .docx.

Feeding Lessons Back to the KMS

The debrief report is only valuable if the lessons are acted on. After the report is finalised, the team lead works through Section 8 and identifies which KMS pages need updating.

Typical update types

Lesson type	KMS action
A document that was missing and caused delays	Add to `03-documentation-review/01-documentation-required.md`
An EN 14511 testing issue or edge case	Add a note to `02-testing-and-certification/01-en-14511-testing-guidance.md`
A modelling problem and its solution	Update the relevant page in `04-modelling/index.md`
A scheme regulation nuance discovered mid-project	Update `06-submission/index.md`
A client communication lesson	Add to `index.md` or the project workflow
A new step that should be standard process	Update `04-modelling/index.md`
A new audit file requirement discovered from an RFI	Update `05-audit-file-preparation/index.md`

Prompt to generate KMS update suggestions

Once the debrief report is finalised, use this follow-up prompt:

“Based on the lessons in Section 8 of this debrief report, identify which pages in /kms/10-large-commercial-modelling/ should be updated and suggest the specific text additions or changes for each page. Keep suggestions concise and in the same writing style as the existing KMS content.”

Review Claude’s suggestions, then apply edits directly to the relevant markdown files in src/content/kms/10-large-commercial-modelling/.

Debrief Checklist

Final submissions confirmed accepted by scheme administrators
Monday.com item closed and EMO spreadsheet updated with final certificate quantities
Final invoice sent via Xero
Claude debrief prompt run with project-specific identifiers
Team lead has reviewed and annotated the Claude output
Report finalised and saved to Files - Review\Commercial project debrief reviews\
KMS updates identified from Section 8 (lessons)
KMS pages updated
Debrief summary shared with the EnergyAE team at the next team meeting

Common Debrief Findings

Finding	Common root cause	Preventative measure
Missing tank certification at start of project	Not asked for in initial documentation request	Add tank cert status to the quotation checklist
EN 14511 test data gaps (missing temperature points)	Testing lab not briefed on exact data requirements	Send the EN 14511 data template to the lab before testing begins
Multiple scheme portal RFIs for the same field	Metadata requirements not verified pre-submission	Add portal metadata validation to Gate B review
Client scope additions after quotation	Quotation scope not fixed precisely enough	Use a fixed system list in the quote; treat additions as change orders
Certification delay holding up submission	Certification initiated too late in the project	Initiate certification in parallel with modelling, not after
Scheme regulation change mid-project	Regulations updated during long-running project	Track DEECA/DPIE announcements; flag active projects for re-check each quarter