QA/QC Example: Inspections on a Residential Project

Overview

This article builds and runs one complete QA/QC process in PlanRadar, from the two forms it needs to the signed inspection record it produces. It follows the example introduced in QA/QC Concepts and Planning.

It is one set of choices, not a standard. Every decision below is one of the decisions described in QA/QC Concepts and Planning > Planning Your QA/QC Setup, and Adapting This to Your Own Process at the end says what to change when yours differ.

Access & Permissions

The Project and the Decisions

A residential building: 48 apartments over six floors. During the installation phase each apartment gets two inspections, one for drainage and one for ventilation. One quality manager runs the process from the office, two site managers inspect, and three subcontractor companies fix what fails.

That produces 96 inspections for the phase. Here is how the six planning decisions were answered for it.

Set Up the Lists and the Form

Three lists are created first, because the form's fields refer to them: Phase (Installation, Commissioning, Handover), Unit (1.01 to 6.08) and Trade (Drainage, Ventilation, Electrical). Read more in Create & Edit Lists.

Then one form named Installation inspection, created on account level and assigned to the project.

The quality manager builds the form and, when the inspection tickets are created, fills what identifies them: unit, inspection type, trade, phase, assignee and due date. The site manager fills everything from the checks downwards — the checklist fields, the result and the inspection date. The status moves with the work, from open when the ticket is created to closed once the inspection is signed off. Read more in QA/QC Concepts and Planning > Roles.

The checks themselves are checklist fields inside the two field groups. Four drainage checks stand in here for what a real ITP would list at greater length:

The name is what the inspector reads down the form, and what a filter, a report and a statistic are labelled with later, so it stays short. The acceptance criterion goes in the field description, where it is available to whoever fills the check and whoever reviews it afterwards.

Your ITP decides what these checks are and how many there are — the shape of the form does not change with the number of them.

Findings need somewhere to go, so a second form named Non-conformance holds them: a severity, a description of what is wrong, and an attachment for the proof of the fix.

Three settings do the work of the process:

• Mandatory. Unit, Inspection type and Result must be filled before the inspection can be saved. On Joints sealed and pressure test passed, a photo is required for either response — the pressure gauge is the evidence that the test happened, and it is worth having whether or not the joint passed.
• On every checklist field, a Fail response requires a note and a linked ticket, and the linked ticket has to use the Non-conformance form — so a failed check cannot be saved without a documented finding, and every finding on the project is the same kind of ticket.
• Conditional visibility on the two field groups, keyed to Inspection type, so an inspector only ever sees the checks for the inspection in front of them.

Field permissions let the quality manager fill the identification fields and the site manager fill the results, with the subcontractor seeing the inspection but editing nothing on it.

Create the Inspection Tickets

The quality manager creates the 96 inspections when the installation phase starts, not before. The ITP already lists them, so they are imported from that spreadsheet rather than created one at a time: one row per inspection, carrying Unit, Inspection type, Trade, Phase and the due date.

Each ticket is then placed on the floor plan at the apartment it belongs to, so the inspector on site opens it from the plan rather than searching a list.

Run an Inspection

The site manager works through a floor with the mobile app, one apartment at a time.

1. Open the inspection for the apartment from the floor plan — "Apt 3.02 — Drainage".
2. Record a response on each of the four checklist fields, in the order the work is checked.
3. On the third check the pipe supports are 1.2 m apart where the specification says 0.8 m. Record Fail.
4. Add the note — "Supports at 1.2 m, specification 0.8 m" — and a photo showing the run with a tape in frame.
5. Create the linked ticket for the non-conformance. The form will not let the inspection be saved without it.
6. Assign the non-conformance to the drainage subcontractor with a due date.
7. Set Result to Pass with findings, fill Inspected on, and save.

The non-conformance is saved the moment it is created, so it reaches the subcontractor while the inspector is still in the building. The app works offline; risers and plant rooms sync later.

Resolve and Verify a Finding

The non-conformance is an ordinary ticket with its own assignee, due date and location, so it appears in the subcontractor's list with nothing else around it.

1. The subcontractor fixes the issue.
2. They upload a photo of the corrected run as proof and set the status to Resolved.
3. The quality manager opens the non-conformance, sees which inspection and which check raised it, and compares the photo against that check's acceptance criterion.
4. Because pipe supports are covered by the ceiling later in the programme, this one is re-attended rather than closed on the photo alone. The site manager confirms the spacing on the next visit.
5. The quality manager closes the non-conformance and updates the response on the inspection from Fail to Pass.

The journal keeps the history of that change — recorded as changed from Fail to Pass, with the user and the date — so the inspection reads as conforming at sign-off without the failure disappearing from the record.

Close, Sign and Report

An inspection is closed once every checklist field has a response and every non-conformance raised from it is closed. The quality manager then signs it, which locks the ticket together with who signed it and when.

At the end of the phase the 96 signed inspections are the QC record for it. Filtered by Phase and produced as a PDF ticket report, they become the document handed to the client; as an Excel file they become the data the client's own quality team can work with.

Because Trade, Result and Phase are list fields on a shared form, statistics answer the phase-level questions without any extra work: how many inspections passed first time, which trade produced the most non-conformances, how long a finding stayed open.

Adapting This to Your Own Process

Nothing above is a requirement. Each choice has an alternative, and the alternative is right whenever the reason behind the original does not hold for you.

• The checks are the part that does not transfer. Four drainage checks appear here because the article has to show something; your ITP decides what is checked, to what criterion and how many times. The form's structure is unaffected by how many checks it holds.
• One form or several. One form works here because drainage and ventilation share everything except their checks. Where inspection types differ in their fields, their responsible roles or their result sets, separate forms are easier to report on.
• One inspection per unit suits apartments. A concrete pour needs three inspections at different moments, a pipe run one every hundred metres, a weld register one per weld.
• Creating tickets per phase suits a project with clear phases. Where the design is still moving, create them at the inspection instead and accept that you lose the register of what was not inspected.
• Updating the response after a fix suits a signed record that is expected to read as conforming. Where you need failures countable on the inspection itself, keep the original response, or record the re-check as its own inspection.

Each of these is set out with its trade-offs in QA/QC Concepts and Planning > Planning Your QA/QC Setup.