First published 17 September 2024. Republished November 2026.
Ask three people on the same job what QA is and you'll get a folder, a department, and a complaint about paperwork. The contract has a more precise answer, and at month-end the contract's answer is the one that counts.
This is the long version: what QA is, why the money depends on it, and what it looks like on a job where it works.
What quality assurance is
QA is the documented system that sets out how work will be proven to meet the specification. In practice that means a quality management plan, an ITP for each work activity, the intervention levels – hold points, witness points, surveillance – and a defined set of records: who inspects, who witnesses, what gets kept. It exists before the work starts, and on most civil contracts the principal's representative approves the ITPs before the activity begins.
The testing itself – the compaction test, the pre-pour inspection, the megger test on a board – is quality control, and the difference matters enough at tender and at claim time that we've written it up separately: QA vs QC in construction. The short version: QA is the plan for what will be proven and to whom; QC is the checking that proves it. The two meet in the record.
Why QA exists: the claim
On AU/NZ contracts QA is a commercial mechanism before it is anything else.
Each month the progress claim goes to the superintendent or engineer's representative, and on QA-gated contracts each line of it is certified against the conformance records behind it – completed checklists, released hold points, test results against the lot. A lot with a missing record is a lot that can't be claimed – it's one of the most common reasons why progress claims get held. The work is done and the cost is spent, but the money stays on the principal's ledger until the record exists in the form the contract requires: no proof, no payment.
The same system also decides the next job. "What is your QA system?" is now a standard tender question, and it is scored – here's how to answer the QA system question at tender. A certificate and a binder of blank templates answer it badly. A live record from a current job answers it well.
What a working QA system looks like
Four things.
A quality management plan people actually open. The plan names responsibilities, the ITP register, document control and the NCR process. On a lot of jobs it is written for the tender and then filed, and the first time a crew hears about hold point requirements is their first day on site. A plan that works is short enough to brief and specific enough that a new project manager can pick up the job without re-deriving it – the core of standardising QA as you scale.
ITPs approved before the work starts. The ITP is the contract's map of what must be proven, to whom, at which points. Getting it approved early means the inspection regime is settled before the first pour, rather than negotiated during it. What ITP software has to do, and how hold points gate the claim, are covered in their own pieces.
Records captured when the work happens. Good verification evidence is attributable to a person, traceable to the lot and the specification clause, and captured at the time of the work. The third property is the one most jobs fail: records rebuilt at month-end from a camera roll and an email thread. Reconstructed evidence costs more to produce, and an experienced reviewer can tell – the hidden costs of a QA system that lags the work add up from there.
NCRs raised and closed. A properly raised and dispositioned NCR shows the system working. An open one holds conformance of the affected lot, and with it the claim line. A non-conformance kept off the record surfaces later anyway, minus the disposition that would have closed it.
The culture part
The usual failure isn't bad intent. Crews treat QA as paperwork that happens after the real work because, the way most systems are set up, that's exactly what it is: the checklist gets filled in at the ute, from memory, at the end of the day.
The fix is in how capture is set up. Make it part of the task – the photo taken at the hold point, the result recorded where the test happened, the sign-off done on the spot. When the record builds as the work proceeds, QA stops being a second job, and the crew can see what the evidence is for: the released hold point, the conformed lot, the claim that doesn't bounce.
One record per lot
Site keeps its own photos. The project office keeps a spreadsheet. Management sees a report compiled from whichever of the two was emailed most recently. Every handoff between those versions is a place where a result goes missing, and the engineer's rep ends up reviewing whichever version happens to reach them. At close-out the same gaps decide whether the QA handover pack is ready or rebuilt.
The principle that fixes it is a single source: one record per lot or unit, that site writes into and the office reads out of. However it's implemented, the test is whether a question from the rep – show me the density results for this lot – gets answered from one place, or starts a search.
Where software fits
You can run all of the above on paper, and plenty of contractors do – spreadsheets vs QA software is a fair comparison of where each holds up. What construction quality assurance software changes is the cost of doing it properly. In CONQA the ITP is the working structure of the job, checklists are completed on site as the QC happens, photos and results attach to the exact item and lot, and the conformance record that supports the claim builds as the work proceeds. How it works covers the mechanics.
Whatever the tool, the test is the one the engineer's rep applies at month-end: can you show the record for this lot.