Skip to main content
Back to module
Engineering Practice & Licensure · Codes and Standards

QA/QC and peer review

Reading49mLesson 3 of 3 in this module

Run an independent check of a calculation with a comment log and back-check, and tell quality assurance from quality control.

Why this matters

Every engineer makes mistakes: a dropped factor of ten, a load copied from the wrong drawing, a code clause from the wrong edition. Professional practice does not assume perfection; it builds checking into the process so that errors are caught before documents are issued. Firms with strong quality systems issue fewer revisions, have fewer claims and earn more trust. As a junior engineer you will be checked constantly, and soon you will check others' work.

The core idea: QA plans the process, QC checks the product

  • Quality assurance (QA) is the system: procedures, templates, required reviews, checklists, training and records that make good work likely. It is about prevention.
  • Quality control (QC) is the checking of a specific deliverable against requirements: this calc, this drawing set, this specification. It is about detection.

A typical firm's QA procedure defines which deliverables need which checks, who is qualified to check, how checks are recorded, and when a document may be issued.

Levels of review

levelwhowhat
Self-checkthe originatorre-read, units, arithmetic, sanity check against a rough estimate
Independent checka qualified checker who did not do the workinputs, assumptions, method, arithmetic, conclusions; often line by line
Discipline reviewdiscipline lead or engineer of recorddesign intent, code compliance, judgement
Interdisciplinary coordinationall disciplines togetherclashes and interfaces (structure versus ducts, electrical loads versus mechanical equipment)
Peer reviewan independent senior engineer, sometimes outside the firmapproach and key decisions on complex or high-consequence work; sometimes required by the authority having jurisdiction

How a check is run

A disciplined check follows a loop, often called check and back-check:

  1. Originator issues the calc or drawing for checking with a transmittal: what to check, what references apply, what has changed since any previous check.
  2. Checker reviews against the references, without redoing the work in the same way. Good checkers use an independent method where possible: a different formula, a quick hand estimate, software against a hand calc, or a known textbook case.
  3. Checker marks up. A common convention (firms differ, so follow yours): yellow highlight for "checked and agreed", red for corrections, and another colour for questions or comments. Every comment is specific and cites the source.
  4. Comments are logged in a comment-resolution sheet: number, location, comment, originator's response, status.
  5. Originator responds to every comment: agree and fix, or explain why no change is needed.
  6. Checker back-checks that each fix was made correctly and that no new errors were introduced, then signs and dates.
  7. The document is issued only when every comment is closed.

Worked example: two errors a checker should catch

An originator's calc reads:

Uniform load w = 2 kip/ft, span L = 20 ft
M_max = w L^2 / 4 = 2 × 400 / 4 = 200 kip-ft
M_max = 200 kip-ft × 0.4448 = 89.0 kN·m

The checker's independent estimate and comments:

  1. Formula. For a simply supported beam under uniform load, M_max = w L^2 / 8, giving 2 × 400 / 8 = 100 kip-ft. (w L^2 / 4 does not apply here; P L / 4 is the midspan moment for a single point load P.) Red: change to w L^2 / 8; M_max = 100 kip-ft.
  2. Unit conversion. 0.4448 is not the right factor. 1 kip = 4.448 kN and 1 ft = 0.3048 m, so 1 kip-ft = 4.448 × 0.3048 = 1.356 kN·m. Red: 100 kip-ft × 1.356 = 135.6 kN·m.

Three lines, two errors: the first doubles the moment, and the second shrinks the converted value by a factor of about three. Neither would crash a program or look obviously wrong at a glance. This is why checks exist.

What a checker looks at

  • Inputs: do they match the latest drawings, vendor data and criteria? Are sources cited?
  • Assumptions: stated, reasonable and consistent with the design?
  • Method and references: right formula, right code edition, applicable limits?
  • Arithmetic and units: spot-check by hand; check that units cancel.
  • Reasonableness: does the answer make sense compared with a rule of thumb or a similar past project?
  • Conclusions: do they follow from the results, and are they carried to the drawings?

Common mistakes

  • Checking by re-reading. Reading the same steps again tends to repeat the same error. Use an independent method.
  • Vague comments. "Looks off" gives the originator nothing to act on.
  • No back-check. A fix that introduced a new error goes out unchecked.
  • Checking your own work as the "independent" checker.
  • Taking comments personally. A check is about the document, not the person. Thank your checker.

Quick recap

  • QA is the system that prevents errors; QC is the checking that detects them.
  • Reviews range from self-check to independent check, discipline review, coordination and peer review.
  • Run checks as a loop: issue, mark up, log, respond, back-check, sign.
  • Use independent methods and reasonableness checks; cite sources in every comment.

Try it

Open the Do tab and run a peer check on a short calculation with planted errors, using a comment log.

Also in this lesson: