QA/QC Concepts and Planning

About QA/QC

Quality Assurance (QA) and Quality Control (QC) describe two halves of managing quality on a project. QA is the system intended to make quality happen: processes, standards, responsibilities and planning, agreed before and during the project and written down in a quality management plan. QC is the verification that it did happen: inspections, structural checks, non-conformance reports and checklists, carried out on the physical work and set out in a quality control plan. QC is one activity within QA.

The distinction matters in practice because the two are planned, documented and carried out by different people at different points in a project. In short: QA sets out how quality is to be achieved, QC demonstrates that it was.

Names differ by region, contract and company standard — quality management, construction quality management and simply checklists are all in use — but the underlying distinction stays the same.

What PlanRadar Covers

PlanRadar does not come with a fixed QA/QC process. Forms, fields, roles and statuses are yours to define, so the process in PlanRadar can mirror your company standard, your contract and the requirements of an individual project. You do not have to adapt your quality process to the tool.

Getting the most out of that flexibility means deciding a few things up front. A form built without knowing what you need to report on collects data you cannot use afterwards, so the decisions in Planning Your QA/QC Setup are worth making before you build anything. Several AI features then take the repetitive work out of building and running the process.

What PlanRadar does not do is write your quality management plan, your quality control plan or your ITP. Defining the process is yours. With PlanRadar you run, record, prove and scale it.

Roles and Workflow

Roles

QA/QC involves a small number of roles rather than a fixed number of people. One person often holds several of them — a quality manager who also inspects on site, or a site manager who sets up the forms. The split below is a common one and is the one used throughout these articles.

The role that sets up the process in PlanRadar is usually also the one that owns the quality management plan and the quality control plan. That is why the setup follows from those documents rather than the other way around: the plan decides what has to be inspected, how often and with what evidence, and the form is built to collect exactly that.

Who creates the inspection tickets is a separate decision and not necessarily part of setting up the process. Read more below in Plan the Inspection Tickets.

The scope each role sees usually differs too: the quality manager works across all projects of the account, the site manager in one project, and the subcontractor sees only the tickets assigned to them.

Workflow

The process runs in four stages: set up, run, resolve, prove. Where a check fails, the process loops back through resolve before the inspection can be closed.

Each stage receives something and produces something. Naming both is what stops inspections stalling between roles — the most common way a quality process fails in practice is not a check done badly, but a check nobody has picked up.

The assignee is whoever currently has to act — the inspector on an inspection, and whoever has to fix the problem on a non-conformance raised from it.

The handover back needs no reassignment. Whoever created a ticket is notified when it is updated, so the inspector sees the resolved non-conformance without the subcontractor assigning it to them. Where you want the handover visible on the ticket rather than only in a notification, assign the non-conformance back instead, and treat the assignee as the ball throughout.

The example below is set up and run stage by stage in QA/QC Example: Inspections on a Residential Project.

The Example in These Articles

QA/QC looks different in every company. It depends on project type, company standards, regulation, the trades involved and the customer's own role in the project.

To keep the articles easy to follow, one worked example runs through them: a residential building where each apartment gets a drainage inspection and a ventilation inspection during the installation phase. It is built and run in full in QA/QC Example: Inspections on a Residential Project.

Planning Your QA/QC Setup

You define your quality process: which inspections exist, who signs off what, what evidence is required, and what happens when something fails. That belongs in your quality management plan, quality control plan or ITP. The decisions below determine how well that process runs once it is in PlanRadar.

Make those decisions before building the form. Changing a form once inspections have been created is possible but limited, and some changes cannot be undone cleanly.

Scope the Forms

A form is created on account level and assigned to any number of projects. Inside it, field groups divide the inspection into sections, a checklist field carries one check, shared fields are defined once for the account and reused across forms so they aggregate into one column, conditional visibility shows fields only when they apply, and field permissions decide which role sees and edits what.

The choice is mainly a reporting decision. One form means one comparable data set; several forms mean several that are harder to aggregate, which is what shared fields are for. They are a limited pool, so spend them on what you actually aggregate — phase, discipline, result, inspector, unit.

Word the Checks

The wording of each checklist field decides how usable the inspection is on site and how usable the data is afterwards.

• One check per field. If a check contains "and" or "or", it is two checks. A single response cannot record that one half passed and the other failed.
• Make it objective. State a value, a threshold or a defined defect rather than asking whether something looks acceptable. Objective criteria are what make two inspectors record the same result, and what make the record defensible later.
• Use consistent positive polarity. A positive response means the work meets the required standard. This lets you count failures across every form and project, and means you never have to reverse a check later, which would leave earlier responses recorded under the old meaning.
• Keep the field name short and put the acceptance criterion, the tolerance or the standard in the field description, so the name stays scannable and the detail is there when someone needs it.
• Follow the order of work. An inspector who has to jump back and forth will fill the form in from memory afterwards.
• Try the form on site before rolling it out. One real inspection finds more problems than any review in the office.

Decide What Is Mandatory

A mandatory field has to be filled before the ticket can be saved. On a checklist field, a note, an attachment or a linked ticket can each be required for a particular response — a photo and a note whenever a check fails, for example, or a non-conformance ticket that a failed check cannot be saved without.

Consider which passing checks are also worth a photo — work that later gets covered up, and anything you might have to prove was executed properly if a claim is made years afterwards. A photo of the finished reinforcement before the pour carries more weight than a note recording that someone looked at it.

Make something mandatory only where you would otherwise have to chase it. Every mandatory setting costs time on site, on every inspection.

Plan the Inspection Tickets

One inspection ticket is one inspection, so the number you need follows the inspection frequency in your quality control plan or ITP. Frequencies are driven either by quantity — per item, per unit, per batch, per section, per length or area, or a defined sample — or by time and events: a recurring interval, the duration of an activity such as a concrete pour, or a hold point that work must not pass until it is signed off. The same activity can need several inspections at different moments.

Frequency is what makes the ticket count predictable. Once you know it and the number of items or units, you know how many inspections the project needs — and you can see which of them have not been carried out.

Who creates those tickets, and when, is a separate decision:

Per phase is a good default. It keeps the register meaningful without filling the project with tickets nobody touches for months. An AI agent can create the next batch, or prompt for it, once a phase is fully inspected.

Decide How a Failure Is Closed Out

A failed check needs follow-up work, and how it is attached to the inspection matters. Use a linked ticket, created from the checklist field where the issue was found: the reference records which check and which response triggered it, and traceability runs both ways. A sub-ticket records only that the work belongs to the inspection as a whole, which is fine for something like splitting a re-inspection across two trades, but not for a finding.

Then decide whether corrected work is closed out on the evidence supplied — common for minor, self-evident items — or re-attended and verified physically, which is usual for structural and safety-related work, for hold points, and for anything about to be covered by follow-on work. Where that risk is real, plan the re-check as late as possible before the covering activity.

Finally, decide how the result is recorded once the non-conformance is fixed:

Which one fits depends on what your ITP requires the signed record to show. Whichever you choose, apply it consistently — mixing them across a project makes the records impossible to compare.

Keep the Process Complete and Consistent

Most quality processes are not lost to a wrong answer on a check. They are lost to a stage left early. Five failures account for most of it, and each has a setting or a habit that prevents it.

AI Support for QA/QC

AI features can take repetitive work out of the process: building the form, filling fields on site, and catching the gaps that usually only surface at review time.

What AI Agents Can and Cannot Do

An AI agent reacts to activity in one project and acts on its own, based on instructions you write. It only ever creates something — a ticket, a comment or an email — and never changes, closes or deletes one. Read more in Create & Manage Your AI Agents.

Where AI Helps in the QA/QC Process

Steps to Manage QA/QC in PlanRadar

Additional Possibilities

Beyond the walk-through, four things are worth knowing about:

• Place inspections on a 360° image of a SiteView run, so the record shows the surrounding state of the work on the day it was checked. Read more in SiteView.
• Import your schedule from Microsoft Project, Asta Powerproject or Primavera P6 and compare build progress against inspection progress. Read more in Import & Export a Schedule from/to Microsoft Project and Other Software.
• Have a third party release an inspection with ticket approvals — useful where a client, consultant or developer has to sign off, not only your own quality department. Read more in Approvals and Request Approval for a Ticket.
• Automate recurring steps with PlanRadar Connect or the Open API Overview, for example generating a QC report and filing it automatically.