Project Initiation Checklist (PIC) | Knowledge Base

The Project Initiation Checklist (PIC) consolidates every kickoff confirmation that, in the past, has caused delay or rework when left to be discovered mid-project. It is completed by the lead engineer with input from the client, and signed off by the director before modelling begins.

In the commercial project template folder structure, each project already includes the PIC and Client Kickoff Form in AExxx_Com_HP_Modelling\01-Admin. Use that project-specific copy once the project folder has been created.

Why we do this

Three recent projects ran multi-week delays because PIC-equivalent items were not confirmed at kickoff:

AE523: AS/NZS 2712 per-tank threshold disputed for 16 months; element capacity discrepancy found post-approval; tank drawing sourced from internet by mistake.
AE574: Brand wrong (Hunt Heating vs Mayekawa vs HydroHeat) — all TRNSYS files renamed; registered address wrong on EN 14511 report — discovered day of submission; IPART account / CEO availability not confirmed.
AE632: VEU and IPART portal access regimes changed since previous Stiebel submission — discovered day 12 of the submission window, costing ~2 weeks; document requests sent in three waves over 7 weeks.

The PIC is designed to catch every one of these patterns on day 1.

How to complete the PIC

After quote acceptance, lead engineer opens the project-specific PIC in AExxx_Com_HP_Modelling\01-Admin and fills in Sections A–J using the Client Kickoff Form and any documents the client has already provided.
Send the Client Kickoff Form to the client to fill in the gaps in Sections A, B, C, D, G, H, I.
Verify portal access (Section F) by logging into both VEU and TESSA with the EAE alias before proceeding.
Verify scheme status (Section E) against the latest ESC and IPART method guides; check the scheme and portal watch register.
When all items in Sections A–G are green, request director sign-off.
File the signed PIC in AExxx_Com_HP_Modelling\01-Admin. Mark the Monday.com item “PIC complete”.

Sections

A. Client identity

Registered brand name for the scheme
Legal entity name and ABN
Registered address (this must match the EN 14511 test report address — if not, plan for a corrected address letter at testing stage)
Applicant-of-record: manufacturer or distributor
Company logo file (PNG, transparent background)
Trigger: if applicant ≠ test report owner → Authorisation Letter required (template in /Templates/Declarations/)

B. Product identity

Heat pump manufacturer and model name (per data plate / test report)
Distributor / sales brand if different from manufacturer
Full system model code for each system being submitted
Element capacity per system (intended total — confirm with client; do not infer from manufacturer documents alone)
Tank variants per system (which AS/NZS 4692 report covers which variant — if multiple variants share heat loss, an Equivalence Declaration is required)

C. Control settings (client-confirmed, in writing)

HP setpoint (°C) and deadband (°C)
Legionella temperature and frequency
Boost element setpoint and deadband, if applicable
Confirm these are factory default settings or that the client will configure as such on installed systems

D. Documents on hand (initial document request)

Use the documentation list from 02-documentation-required.md. For each document, record:

File name on receipt
Date received
Status: Received / Requested / Not applicable

The client is sent this list as a single consolidated request — not in waves. New gaps that emerge mid-project are batched into a fortnightly follow-up using the Missing Documents Follow-up Email Template, not asked one at a time.

E. Scheme and tank type

VEU Activity 44 — confirm method guide version (latest as of project start)
IPART IHEAB — confirm method guide version
DEECA threshold check (current minimum HP capacity; AE632 saw a 10 → 12 kW change mid-project)
Tank component: Type 160 by default (includes legionella compliance tracker). If a template suggests Type 60, archive that template and switch to Type 160.

F. Portal access verification

VEU portal: EAE secondary user added; alias confirmed by logging in successfully
TESSA portal: EAE secondary user added; alias confirmed by logging in successfully
Client TESSA Authorised Signatory in place
Date of last successful login for each portal recorded

If portal access fails, see Portal Access Setup and resolve before modelling.

G. Signatory readiness

IPART signatory confirmed (client-side, named individual) — see Signatory and Entity Policy
EAE NZ entity cannot sign IPART — confirm client signatory route in writing
Signatory availability window for submission (no major travel during the planned submission week)
For VEU: applicant signatory confirmed

H. Testing pipeline

Test lab confirmed (see Test Lab Register)
EN 14511 conditions agreed in writing (see EN 14511 Testing Guidance)
Sample shipped date / expected report date
Communication routing: EAE direct contact with lab, or client-mediated with mandatory forwarding agreement (see Section I)
Pre-test client advisory sent (see Pre-Test Client Advisory)

I. Communication agreement

Per-product / per-submission email thread discipline confirmed in writing
Subject line convention: [AExxx] {Client} — {Workstream}
Weekly status cadence (Friday update; use the Modelling Update Email Template)
Daily plan template adopted (lead engineer to director)
Third-party communication routing: if client-mediated, client agrees to forward all relevant technical exchanges within 2 business days
Contacts register saved to AExxx_Com_HP_Modelling\01-Admin\Contacts.xlsx

J. Project closeout plan

Target submission date (VEU and IPART separately if different)
Whitelist advisory plan (sent at submission)
Debrief plan (within 2 weeks of final submission confirmation)
Final invoice trigger condition

Gate condition

The PIC must be 100% green in Sections A–G before any TRNSYS work begins. Sections H–J should be substantially complete; minor gaps acceptable but flagged.

If any item is red, hold the project and resolve before proceeding.