What Is QA/QC in Construction?

The two halves get conflated constantly, and the conflation is expensive. Quality assurance is what you build before the work starts: the quality plan, the procedures, the standards, the review workflows, the training. Quality control is what you do to the work after it exists: inspect it, test it, measure it against the requirement.

A project with strong QC and weak QA finds a lot of defects. A project with strong QA finds fewer, because fewer were created. Both are necessary, but they are not interchangeable, and a quality program that is all inspection is a program that has decided to pay for rework.

The fastest way to tell them apart on a live project is to ask what the activity produces. If it produces a document that tells somebody how to work, it is quality assurance: the project quality plan, a procedure, a qualification of a supplier, a checklist written before anyone uses it, a review of the drawings before they are issued. If it produces a record of whether something already built meets the requirement, it is quality control: an inspection report, a test result, a punch item, a nonconformance.

The second question people really mean when they ask "QA or QC" is who owns it. QA is typically owned above the project, because consistency across projects is the point and a procedure rewritten per job is not a procedure. QC is owned on the project, because the work being verified only exists there. A firm whose QA lives entirely in individual project managers' habits has quality control and calls it a quality program, which is a distinction that stays invisible until a defect repeats on a third project.

There are four, and a project missing any of them has a gap worth naming. The project quality plan states who is responsible for what, which standards apply, and how nonconformances get resolved. The Inspection and Test Plan breaks that down per activity with hold and witness points. Inspection and test records are the evidence each check was done and what it found. Nonconformance reports capture what deviated, why, the corrective action, and the verification that closed it.

On the design side the equivalents are the drawing review checklist, the markup record, and the back-check confirming comments were incorporated. These get skipped more often than the field documents because nobody inspects them, which is exactly why errors that should have been caught in review turn up later as RFIs. Owners increasingly ask for the design-side records too, and a team that cannot produce them is relying on the reviewer having remembered.

The Inspection and Test Plan is where QA and QC meet in practice. It lists each activity, the standard it is checked against, who performs the check, what evidence gets recorded, and — critically — which points are hold points where work stops until the inspection passes.

Rebar before a pour is the classic example: once the concrete is placed, an error that would have taken an hour to fix becomes a demolition problem. Getting hold points right is the highest-leverage quality decision on most projects, and it happens on paper months before anyone pours anything.

The nonconformance report is the mechanism. An NCR records what deviated, why, and what the corrective action is, and it stays open until the correction is verified. It is the paper trail that proves a defect was found, addressed, and re-checked.

The discipline that separates a functioning quality system from a paperwork exercise is whether nonconformances feed back into the QA side. If the same nonconformance recurs across three projects, the problem is not the crew — it is the procedure or the documentation that led them there.

The same logic applies to documents. Before a set is issued, someone checks that plans, sections, elevations and schedules agree with each other, that keynotes point to the right specification sections, that the fire rating on the plan matches the assembly in the spec, and that code-driven requirements actually appear in the drawings rather than only in the code analysis.

This review is the cheapest quality intervention available on any project, and it is the one most often compressed when a deadline moves. Errors that survive it do not disappear — they reappear as RFIs, as change orders, and occasionally as failed inspections.