The business side of civil engineering, from RFQ to closeoutText or WhatsApp (808) 600-9260Richard@FamilyBusinesses.com
CivilEngineers.com

Guide 12 · 12 min read

How to set up a project quality plan

A project quality plan (PQP) describes how a civil engineering team will meet the project’s requirements and check its work. It should connect the contract and technical criteria to assigned responsibilities, review points, records, and a clear path for resolving problems. The plan is useful when the team can use it to answer practical questions: What must be delivered? Who checks it? What happens before it goes to the client? Where is the evidence kept?

A practical starting point

For a firm owner or principal, the PQP is also a way to establish accountability. It gives the project manager and discipline leads a common reference, helps the firm see quality risks before they affect delivery, and gives the responsible professional engineer (PE) a structure for oversight. It does not replace professional judgment, design criteria, contract terms, or a firm’s broader quality management system.

A good plan is specific to the project. A small drainage study does not need the same review structure as a multi-discipline transportation program with phased design packages and construction support. The right level of detail depends on the services and client requirements, as well as project complexity and delivery method. It also depends on schedule and the consequences of an error.

Start with the scope and the information already available. Then define who owns each part of the work, what must be reviewed, when coordination occurs, and how the team will document decisions. Keep the plan usable: project staff should be able to find the relevant requirement, identify the person responsible, and show that the planned check took place.

1. Define the scope and boundaries

Begin by describing what the firm is responsible for delivering. Refer to the executed agreement, amendments, approved task orders, and the current project schedule. Summarize the services in plain language, then identify the limits of the assignment.

The scope section should state:

  • The project name and client, along with the location and contract or task order identifiers.
  • The services and deliverables included in the firm’s work.
  • Any defined phases, milestones, options, or authorized work packages.
  • Work assigned to subconsultants and interfaces with the client or other consultants.
  • Exclusions and assumptions, plus dependencies that affect quality checks.
  • The person authorized to approve changes to the scope or plan.

Be careful with scope summaries. A vague phrase such as “provide civil design” does not tell a reviewer whether the team is producing a feasibility layout, permit drawings, final design documents, or construction-phase services. Name the actual deliverables and their intended use. If the agreement leaves a boundary unclear, record the question and obtain direction through the project’s approved communication path.

Describe the project’s design basis and key constraints. Depending on the assignment, these may include survey control, existing utilities, geotechnical information, environmental conditions, design criteria, codes, permits, right-of-way, utility coordination, or owner standards. Identify assumptions that could affect the work, who is responsible for confirming them, and when confirmation is needed.

A PQP should also explain how the team will handle scope changes. A new deliverable, changed design criterion, revised client direction, or additional review cycle can affect staffing and quality risk. Record the change, its approval, and any update to the plan, schedule, or review assignments. Do not let informal requests silently change the work basis.

2. Assign roles and authority

Quality responsibilities should be assigned by name or clearly defined role. A chart can help, but it needs to show decision authority and handoffs, not just reporting relationships.

Typical roles include:

  • Principal-in-charge: Maintains executive awareness of risk, staffing, contract exposure, and significant quality concerns.
  • Project manager: Owns delivery of the plan, tracks actions and reviews, manages client interfaces, and raises issues that need leadership attention.
  • Responsible PE: Provides professional oversight for engineering work within the PE’s area of responsibility, including appropriate review and decisions on technical issues.
  • Discipline leads: Direct discipline work, confirm criteria, coordinate interfaces, and assign qualified reviewers.
  • Independent or peer reviewer: Reviews designated work with enough independence from production to provide a useful technical check.
  • Document control or project support: Manages current versions, transmittals, records, and review status when assigned.
  • Subconsultant leads: Perform agreed services and provide the inputs and checks defined in their agreements and the project plan. They also provide the required records.

One person may hold several roles on a smaller assignment, but the plan should still make each responsibility clear. If the project manager is also a discipline lead, say so. If one reviewer cannot provide an independent check of their own work, assign a second qualified person or explain the applicable review arrangement.

State who can release work externally. Technical approval, project management approval, and client transmittal are distinct actions. The PQP should identify which role confirms that reviews are complete, comments are resolved or dispositioned, required signatures are in place, and the package is authorized for issue.

Make escalation direct. Staff should know whom to contact when they find a design concern, missing input, conflicting requirement, or possible safety issue. Include a path to the discipline lead, project manager, and responsible PE, with principal involvement when the issue affects significant risk, scope, schedule, or firm commitments.

3. Capture applicable client requirements

The client’s requirements may be distributed across more than the main agreement. The project team should build a controlled list of the sources that govern its work and identify which provisions apply to each deliverable.

Review the agreement and amendments, scope documents, client design manuals, technical specifications, submission checklists, data standards, CAD or BIM requirements, quality clauses, permit conditions, and written directives. Include applicable agency requirements and local codes identified for the project. Confirm the governing version and effective date where that information is available.

A requirements register can make the information actionable. For each requirement, record:

  • The source document and section.
  • The deliverable or discipline affected.
  • The responsible person.
  • How the requirement will be addressed or verified.
  • The review point or evidence that demonstrates compliance.
  • Any open question, interpretation, or client decision.

Avoid copying an entire manual into the PQP. Point to the controlled source, then summarize the project-specific obligations the team must act on. This keeps the plan readable and reduces the chance that an old excerpt will be treated as current.

When requirements conflict, do not resolve the issue by choosing the easier option. Document the conflict, identify the relevant contract or technical sources, and obtain direction from the authorized client representative. The responsible PE should assess the technical implications and determine whether work needs to pause while the issue is resolved.

Client review does not transfer the firm’s responsibility for its work. A client’s acceptance, comment, or lack of comment should be recorded accurately, but it does not replace the review and professional oversight assigned to the consultant.

4. Set review gates that fit the deliverables

A review gate is a planned point where the team checks that work is ready to advance. Gates give the project manager visibility into quality before a package is submitted or used to support the next phase. They also make review timing easier to coordinate with staffing and schedule.

Select gates based on the actual work sequence. A project may use checks at criteria confirmation, preliminary design, intermediate design, final design, permit submission, or issued-for-construction documents. A study or planning assignment may instead use gates for data validation, alternatives analysis, draft findings, and final recommendations. Name the deliverable or decision that each gate covers.

For each gate, define:

  • What material must be ready for review.
  • Who performs the technical and discipline checks, along with the project-level checks.
  • What criteria or reference documents apply.
  • How comments are recorded and assigned.
  • Who decides that comments are resolved or accepted for follow-up.
  • Who authorizes progression or external issue.

Schedule review early enough to allow correction. A review that starts after the package is promised to the client creates pressure to treat comments as paperwork. The project manager should coordinate reviewer availability with production milestones and flag schedule changes that threaten review time.

Use different review depth for different work products. A calculation, drawing, specification, model, narrative report, and permit form can each require a different check. The reviewer should know what to examine, such as design assumptions, calculations, consistency between drawings and specifications, constructability, code criteria, or alignment with client standards.

For larger packages, use a review checklist tailored to the deliverable. A checklist should prompt a careful review, not substitute for one. Comments need enough detail for the author to understand the issue and make a correction. The reviewer should also identify whether the comment is technical, coordination-related, editorial, or a request for clarification.

Record the review status in a way the project team can verify. A marked-up file, comment log, review form, or approved workflow may serve this purpose. The plan should identify the official record location and how the team will distinguish working drafts from approved issue versions.

5. Coordinate across disciplines and interfaces

Many quality problems arise where one team’s assumptions meet another team’s design. Set regular coordination points for the disciplines and organizations that affect the deliverables. The meeting format can be simple, but the team needs a place to identify dependencies, resolve conflicts, and assign actions.

List the disciplines involved and their key interfaces. A civil package may rely on survey, geotechnical, structural, traffic, environmental, utility, landscape, or architectural inputs. Identify what each discipline provides, when it is needed, and who confirms that it is suitable for the project’s intended use.

Coordination should address both technical details and document consistency. The team may need to check:

  • Shared design criteria and common assumptions.
  • Existing conditions, survey control, and base files.
  • Utility locations and proposed crossings.
  • Drainage paths, grading, and access, plus site constraints.
  • Conflicts between plans and profiles, as well as details and models. Check specifications too.
  • Interfaces between consultant and client work, along with contractor and agency work.
  • Open decisions that affect more than one discipline.

Use an interface or action log for unresolved items. It should identify the issue, owner, due date, affected work, decision needed, and status. Carry open actions forward until they are resolved, accepted with a documented basis, or raised for a decision. Do not close an item merely because it was discussed.

Subconsultant coordination deserves explicit treatment. Confirm the scope, schedule, required format, review expectations, and information exchanges in the agreement and project plan. The project manager should make sure that subconsultant deliverables receive the planned review and that their assumptions match the project’s design basis. A consultant’s work should not be treated as coordinated solely because it arrived on time.

6. Control documents and project records

Records show what the team knew, what it checked, what decisions were made, and what was issued. The PQP should establish a simple, consistent method for storing and retrieving those records.

Identify the project’s official repository and the person responsible for its setup or administration. Define file naming, revision control, access, transmittals, and retention practices in line with the firm’s system and client requirements. Make clear which location holds the record copy when working files are stored elsewhere.

Common quality records include:

  • The approved PQP and revision history.
  • Requirements and design criteria registers.
  • Review assignments, markups, comment logs, and closeout records.
  • Coordination notes and decisions, plus action logs.
  • Calculation, model, drawing, and specification versions.
  • Client instructions and approvals, along with transmittals.
  • Nonconformance reports and corrective action evidence.
  • Subconsultant deliverables and review records.
  • Final issue records and applicable sign-offs.

Record decisions while the context is available. A short note that identifies the question, options considered, decision maker, basis, date, and affected deliverables can prevent later confusion. Preserve significant client direction in the project record, even when it began in a meeting or call.

Records should be clear and useful, and tied to the work they support. Avoid keeping multiple files that appear final with no indication of which one was issued. When a package is revised, preserve the history needed to understand what changed and why, consistent with the firm’s retention rules and contract obligations.

7. Handle nonconforming work and corrective action

A nonconformance is a failure to meet an applicable requirement, approved design basis, or established process. The PQP should explain how staff report and address it without delay or blame. Early reporting gives the project team a chance to contain the effect before the issue reaches a client, permit agency, contractor, or the field.

A practical process has several steps:

  1. Identify and report. Describe the observed condition, requirement, affected work, and date found. Notify the project manager and responsible PE when the issue may affect technical decisions, safety, compliance, or an issued deliverable.
  2. Contain the issue. Hold affected work or prevent further use when needed. Identify drawings, calculations, models, submissions, or field activities that could be affected.
  3. Assess impact. Determine the technical and contractual implications, including whether previously issued work needs review. The responsible PE should direct engineering assessment within the PE’s area of responsibility.
  4. Correct and disposition. Document the correction, approved disposition, or reason for accepting a deviation through the proper authority. Obtain client direction where the contract or client process requires it.
  5. Verify and close. Have an appropriate person confirm the correction and record the evidence, approvals, and affected versions.
  6. Look for recurrence. Consider whether a process change, additional check, training, or broader review is warranted.

Distinguish correction from corrective action. Correction addresses the specific affected work. Corrective action addresses why the failure occurred and how the firm will reduce recurrence. Not every minor comment needs a formal corrective action, but repeated or consequential issues deserve a look beyond the immediate fix.

The team should not conceal, relabel, or informally waive a nonconformance to protect a milestone. Escalate when the issue remains unresolved, when the proposed disposition exceeds someone’s authority, or when work may have been relied on outside the project team. Follow contract notice requirements and the firm’s incident and records procedures.

8. Provide responsible PE oversight

The PQP should state how the responsible PE will remain informed and exercise oversight appropriate to the work. Oversight is an active part of project delivery. The PE needs access to the design basis, key decisions, significant review findings, and unresolved technical issues within the PE’s responsibility.

Specify the PE’s involvement at meaningful points, such as confirming design criteria, reviewing technical approaches, resolving material comments, evaluating changes to assumptions, and authorizing or approving engineering work as applicable. The scope and timing depend on the assignment and the PE’s role.

A PE’s name on a plan should not become a substitute for involvement. Assign responsibilities that match the person’s skill and authority, as well as their actual participation. If staffing, scope, or schedule changes affect the PE’s ability to provide oversight, raise that promptly and revise the plan or assignments.

The PE should have a clear route to stop or hold affected work when a technical concern needs resolution. Project management remains responsible for coordinating delivery, but schedule pressure does not decide engineering questions. The firm should retain records of material technical decisions, review outcomes, and required approvals.

9. Tailor the plan to project risk

A PQP should focus attention where an error could have the greatest consequences or where uncertainty is highest. Tailoring is not a reason to omit needed checks. It is a way to match the review method, reviewer expertise, coordination effort, and documentation to the project’s conditions.

At kickoff, discuss factors such as:

  • Project complexity and novelty, plus the number of disciplines.
  • Public safety, service continuity, and construction consequences.
  • Uncertain or incomplete survey, geotechnical, utility, or environmental data.
  • Tight schedule, phased releases, or extensive client review.
  • Permitting, regulatory, or third-party interfaces.
  • Subconsultant dependence and handoffs.
  • Use of proprietary systems, specialized software, or unusual design methods.
  • Potential effects of errors on cost, operations, maintenance, or future work.

Record the main risks, the planned response, the owner, and the point at which the response will be checked. A higher-risk package may need an independent technical reviewer, earlier PE involvement, focused interdisciplinary review, or additional field verification. A lower-complexity task may use a concise criteria check and documented project manager review.

Review the risk assessment when the basis changes. New site information, a revised client requirement, a design change, a missed input, or a schedule shift can alter the quality risks. The project manager should update the plan and make sure affected staff know what changed.

10. Approve the plan, communicate it, and maintain it

Prepare the PQP early enough that it can guide the work. The project manager can draft it with discipline leads and the responsible PE, then route it for the firm’s required approval. Submit it to the client when the contract requires one. Record approval status, revision date, and the people who need to use it.

At kickoff, walk the team through responsibilities, review gates, record locations, escalation routes, and open requirements. Confirm that subconsultants understand the applicable parts. Keep the plan accessible, and revise it when scope, personnel, schedule, design basis, or client requirements materially change.

A plan that nobody consults creates little value. Keep it concise enough for the team to use, with links to controlled registers and procedures where detail belongs elsewhere. Periodically compare planned checks with actual work. If a review gate is repeatedly missed or a record cannot be found, correct the process while the project is active.

See the quality assurance resources, browse engineering guides, and use the checklists to support project delivery.

General education only, not engineering, legal, tax or investment advice. Licensed PE judgment and local codes govern.

Richard C. Wilson

Backed by

Richard C. Wilson and the Family Office Club team

Family Office Club
19MSocial followers
17MRegistered members
$1BDeals closed between members
15-personTeam
19 yearsExperience
340Events hosted

The $1B figure reflects member-reported transactions. Network experience does not assure capital, a buyer, or a particular result.

Questions or corrections? Email Richard@FamilyBusinesses.com

Text or WhatsApp (808) 600-9260 · WhatsApp