What do I need to perform quality control?

Performing quality control in a project demands far more than a final inspection or a quick comparison against a specification. To perform quality control effectively, a project manager needs a defined set of inputs that establish what is being measured, how it is measured, and what standards apply before a deliverable can be accepted or rejected. Those inputs range from the project management plan itself to work performance measurements, approved change requests, deliverables, and organizational process assets. Without them, quality control becomes guesswork dressed up as inspection.

In most established project management frameworks, quality control belongs to the monitoring and controlling process group. That placement matters because it tells you the activity is not something you bolt on at the end. It runs alongside execution and feeds directly into decisions about whether work remains on track. The inputs described here give the project manager and the team the raw material needed to assess actual performance against planned performance and to verify that approved modifications have been implemented. Quality control is not simply finding defects; it is systematically proving that deliverables meet the defined quality requirements.

A common misunderstanding is that quality control and quality assurance are interchangeable. They are not. Quality control focuses on inspecting and testing the actual deliverables against specifications, while quality assurance is more concerned with whether the processes themselves are adequate. The inputs you need for quality control therefore tend to be very concrete: metrics, checklists, measurements, change requests, and the actual outputs of project work. Each input plays a distinct role, and missing one usually weakens the entire evaluation.

The following sections break down the required inputs in detail. Each one contributes a specific piece of the quality control picture, and each one can fail in predictable ways if misunderstood or applied too mechanically. Think of these inputs as the evidence file a project manager assembles before making the call that a deliverable is fit for use or must be reworked.

Quality Control Essentials: Key Topics Summary

What You Need to Perform Quality Control: The Project Management Plan

The project management plan is the first input because it contains the quality management plan, which describes exactly how quality control will be performed on the project. Without this embedded component, the project manager lacks the procedural backbone for inspection, testing, and acceptance. The quality management plan does not merely state that quality control will happen; it specifies the approach, roles, responsibilities, tools, and decision thresholds the team will use when evaluating deliverables.

Within the broader project management plan, the quality management plan links quality control to scope, schedule, cost, and risk. For example, if the scope baseline defines a particular performance requirement for a software module, the quality management plan should state how that requirement will be tested and what level of deviation triggers a defect report. The integration is critical because quality control findings often feed back into change requests, which then modify one or more baselines. A project manager who treats the quality management plan as a standalone document misses those connections.

In practice, the quality management plan also addresses the timing of quality control activities. Some projects require inspection at every major milestone, while others use sampling approaches or rely on continuous integration and automated testing. The plan should make that timing explicit so the team knows when to schedule inspections, who performs them, and how the results are documented. This prevents the common problem of quality control becoming an afterthought performed only when a deliverable is nearly complete.

The plan also identifies the quality tools that will be used during control. These might include statistical sampling, cause and effect diagrams, control charts, or checklists. The choice of tools matters because each tool surfaces different kinds of information. A control chart helps distinguish between common cause variation and special cause variation, while a checklist simply verifies presence or absence of required steps. A well-written quality management plan aligns the tool with the nature of the deliverable and the risk profile of the project.

How the Quality Management Plan Guides Inspection and Testing

When the team begins inspecting deliverables, the quality management plan functions as the reference point for acceptable performance. It answers questions like who has authority to accept or reject work, what measurements must be recorded, and how nonconforming items are escalated. Without this guidance, inspection results become subjective and inconsistent across team members.

The plan also clarifies the distinction between prevention and appraisal activities. Quality control primarily involves appraisal, which means measuring completed components or final deliverables. The quality management plan ensures that appraisal does not happen in isolation. It connects inspection results to process improvement discussions, which are more the domain of quality assurance. This linkage matters because recurring defects often signal a process problem rather than isolated human error.

Another important aspect is the definition of pass/fail criteria. The quality management plan should specify tolerances for each critical quality attribute. If the allowed variance is not stated in advance, the person performing quality control may apply personal judgment that differs from the customer's expectations. Defining those thresholds before inspection begins removes ambiguity and makes the control process defensible.

Key Takeaways on the Quality Management Plan

Procedural backbone for control

The quality management plan defines the evaluation approach, roles, responsibilities, tools, and decision thresholds the team applies to deliverables, moving beyond a simple intent to perform quality control.

Links quality to other baselines

As part of the broader project management plan, this component links quality control to scope, schedule, cost, and risk, ensuring that quality findings translate into change requests that update project baselines.

Guides inspection and acceptance

During inspection and testing, the plan defines acceptable performance by specifying who may accept or reject work, which measurements to record, and how nonconforming items are escalated for resolution.

Quality Metrics and Checklists as Measurement Tools

After the plan, the next concrete inputs for quality control are quality metrics and checklists. Quality metrics operationalize the quality requirements by defining what will be measured, how it will be measured, and what target values or allowable ranges apply. Quality checklists, by contrast, provide a structured list of steps or attributes that must be verified for a given deliverable or process.

The relationship between metrics and checklists is often misunderstood. A metric is not the same as a checklist item. Metrics quantify performance against a threshold, such as defect density per module, percentage of requirements traced to tests, or reliability under load. Checklists are binary verification tools: an item either exists and meets the specified attribute, or it does not. Both are inputs to quality control because they guide the person doing the inspection and ensure consistency across multiple inspection events.

In real project work, quality metrics are often derived from the quality management plan but maintained as separate artifacts because they change less frequently than the plan itself. A metric might specify that customer-reported defects after release must remain below a certain number per thousand lines of code. During quality control, the team collects actual defect data and compares it against that target. If the number exceeds the threshold, the deliverable triggers a nonconformance report.

Checklists are useful for complex deliverables where human memory cannot be trusted to remember every required attribute. For example, a quality checklist for a physical product might include dimensional checks, surface finish requirements, safety labeling, and packaging condition. For a software release, the checklist might include installation verification, configuration file completeness, security patch application, and user acceptance sign-off. The checklist does not replace professional judgment; it ensures that no critical item is skipped during the inspection.

One common pitfall is building checklists that are too vague. If an item says "check functionality," different inspectors may check different functions and produce inconsistent results. Effective checklists contain enough specificity to make repeatable verification possible. Similarly, metrics that are not tied to customer requirements create measurement noise. A metric that is easy to collect but irrelevant to the product's intended use adds little value and may distract the team from more meaningful indicators.

Business Value-Oriented Project Management adds a useful perspective here by emphasizing defect analysis with predefined root-cause categories. Rather than simply counting defects, teams categorize them to understand whether quality problems stem from design, requirements, workmanship, or tooling. That approach turns quality metrics into diagnostic inputs, not just scorekeeping. It also helps avoid the trap of managing quality solely through aggregate numbers that hide underlying patterns.

Applying Quality Metrics and Checklists During Quality Control

When a project manager is preparing to perform quality control, the metrics and checklists must be selected before inspection begins, not improvised at the moment of testing. Selecting them early prevents the temptation to adjust thresholds after seeing the results. It also allows team members to understand what is being measured and why, which improves cooperation during inspections.

For deliverables that are received from external suppliers, the contract or procurement statement of work often references the quality metrics that will be used for acceptance. The project team brings those same metrics into the quality control process to verify that the supplier has met the agreed performance levels. In that context, metrics serve as an objective basis for accepting or rejecting a purchased component. The checklist then confirms that all contractual and technical requirements have been addressed.

A practical challenge arises when metrics conflict with schedule pressure. A team may be tempted to relax a metric or shorten a checklist when the delivery date is tight. That is a dangerous pattern because it changes the meaning of the quality baseline without an approved change. The project manager must treat any modification to quality metrics or checklists as a change request that requires appropriate review. Otherwise the project loses the ability to compare quality performance across time.

Work Performance Measurements for Quality Control

Quality control requires work performance measurements because they provide the actual progress data needed to evaluate whether the project is still meeting its technical, schedule, and cost objectives. These measurements compare planned values against actual values and give the quality control process a performance context that goes beyond simple defect counts. Without them, an inspector might know that a deliverable has defects but not whether those defects reflect a deeper schedule or cost problem.

The source material identifies three specific types of work performance measurements used in quality control: planned versus actual technical performance, planned versus actual schedule performance, and planned versus actual cost performance. Each one answers a different question. Technical performance asks whether the product is performing as designed. Schedule performance asks whether the work is being completed on time. Cost performance asks whether the resources consumed match the budget. Together they reveal whether quality issues are isolated or systemic.

Planned versus actual technical performance is perhaps the most directly tied to quality control. It measures the degree to which a deliverable's functional and performance characteristics match the specifications. For a software system, this might mean comparing planned response time under a given load against the actual measured response time. For a construction project, it could mean comparing the specified compressive strength of concrete against test results. Large deviations in technical performance often trigger the quality control process to reject the deliverable or initiate a defect repair.

Schedule performance measurements are relevant because quality problems frequently cause delays. Rework consumes time, and the need to investigate defects pulls resources away from other tasks. If a project is experiencing numerous quality issues, schedule variance often widens as well. The project manager uses planned versus actual schedule performance during quality control to determine whether late deliverables are a symptom of underlying quality failures or a separate schedule management problem.

Cost performance measurements matter for similar reasons. Rework increases labor costs, replacement materials raise procurement costs, and extended testing consumes budget. When quality control reveals a high defect rate, the project manager can check planned versus actual cost performance to understand the financial impact. In this way, quality control connects to the project's earned value management system, where cost variance and schedule variance are standard indicators.

Why Work Performance Measurements Matter to Perform Quality Control

These measurements are not simply progress reports pasted into a quality report. They provide the comparative baseline that turns raw inspection results into meaningful quality judgments. A defect count of five in a module tells you little unless you know the planned defect tolerance, the schedule impact of those defects, and the cost of repairing them. Work performance measurements supply that missing context.

In practice, teams often collect work performance measurements during execution through time tracking systems, inspection logs, and automated testing dashboards. The quality control process then pulls those measurements into a consolidated view. The project manager reviews the measurements alongside checklists and metrics to determine whether the deliverable meets requirements and whether any corrective or preventive actions are needed.

A potential pitfall is treating work performance measurements as purely historical data. If the measurements are collected too late or reviewed only at the end of a phase, the project loses the ability to make timely corrections. Quality control works best when these measurements are available at frequent intervals, allowing the team to identify trends before a minor deviation becomes a major failure. The frequency of measurement should be defined in the quality management plan and tailored to the project's risk tolerance.

Approved Change Requests and Deliverables

Two additional inputs often arrive together during project execution: approved change requests and deliverables. Approved change requests can include modifications such as defect repairs, revised work methods, and revised schedules. The quality control process must verify that these approved changes have been implemented in a timely and correct manner. Deliverables, meanwhile, are the actual outputs of project work that must be inspected against the quality requirements.

The connection between approved change requests and quality control is sometimes overlooked. A project manager may assume that once a change is approved, implementation will follow automatically. That assumption is risky. Quality control provides the verification step that confirms the approved change actually appears in the deliverable and performs as intended. If a defect repair was approved, quality control checks that the repair has been made and that it has not introduced new defects. If a revised work method was approved, quality control checks that the new method is being used and that it is producing the expected quality results.

Revised schedules are a slightly different type of approved change. They impact quality control because the timing of inspections and testing may shift. When a schedule is revised, the project manager must ensure that quality control activities are rescheduled accordingly and that resources remain available. A revised schedule that compresses the testing window can directly reduce the thoroughness of quality control, so the change itself needs to be assessed for quality risk.

Deliverables are the most visible input to quality control because they are the items being inspected. A deliverable can be a physical product, a software release, a report, a prototype, or any other verifiable output defined in the project scope. Quality control subjects each deliverable to measurement against the quality metrics and checklists. The result is either acceptance, rejection, or conditional acceptance with specified rework. The project manager must be careful not to blur the line between a deliverable and work results that are not yet complete.

In many industries, deliverables go through multiple inspection points before final acceptance. A partially completed component may be inspected at an intermediate stage to catch defects early. That early inspection still uses the same quality metrics and checklists but applies them to a subset of the final deliverable's characteristics. The goal is to find deviations while correction is still inexpensive. That is why quality control is not a single event at the end of the project; it is a recurring process applied to deliverables as they emerge.

Verifying Approved Change Requests in Quality Control

Verification of approved changes requires traceability. The project manager needs to know which change request corresponds to which deliverable and which quality control test will confirm its implementation. Traceability matrices can support this by linking change requests to requirements, design changes, test cases, and inspection results. Without that traceability, a team may believe a change has been implemented when in fact the work was never completed or was completed incorrectly.

Another practical challenge is managing the cumulative effect of multiple change requests. A deliverable may be affected by several approved changes, each of which alters one or more attributes. Quality control must verify the combined result, not just each change in isolation. A defect repair may solve one problem but interact with a revised work method in a way that creates a new failure mode. The inspection approach must therefore evaluate the deliverable as an integrated whole after all approved changes have been applied.

When approved changes are not verified, the project accumulates hidden rework. A team may report that a change has been implemented because the work was assigned, but the deliverable may still fail acceptance testing later. Timely verification during quality control prevents that hidden rework from surfacing at the end of the project when it is most expensive to correct. The phrase "timely implementation" from the source material is important; verification delayed is verification weakened.

Organizational Process Assets That Influence Quality Control

Quality control does not happen in a vacuum. The project operates within an organization that has accumulated organizational process assets, and those assets directly influence how quality control is planned and performed. The source material identifies three relevant categories: quality standards and policies, standard work guidelines, and issue and defect reporting procedures with associated communication policies.

Quality standards and policies are organizational rules that shape what the project team is expected to achieve. They may include industry standards adopted by the organization, internal quality policies, regulatory requirements, or customer-specific quality expectations. During quality control, the inspector checks deliverables against those standards in addition to project-specific metrics. If an organizational policy requires a certain level of traceability or a particular test documentation format, the quality control process must comply.

Standard work guidelines are the organization's documented ways of performing common tasks. They can affect quality control by specifying how inspections are conducted, how measurement instruments are calibrated, how samples are taken, or how test data are recorded. These guidelines provide consistency across projects and reduce the variability that comes from individual inspector habits. A project manager should review the relevant standard work guidelines before quality control begins to ensure the team follows organizational expectations.

Issue and defect reporting procedures and communication policies are particularly important because quality control findings must be communicated to the right stakeholders in a consistent format. If the organization has a standard defect tracking system, the project must use it. If there are defined escalation paths for critical defects, those paths must be followed. Communication policies determine who receives quality reports, how often they receive them, and what level of detail is appropriate. Adhering to these assets ensures that quality control outputs are not lost or ignored.

Organizational process assets can also include historical quality data from previous projects. While the source material highlights standards, guidelines, and reporting procedures, many organizations also maintain databases of past defect rates, common failure modes, and lessons learned. Those historical data can inform the selection of quality metrics and checklists for the current project. They are not a substitute for the required inputs, but they strengthen the team's ability to anticipate where quality problems are likely to arise.

Practical Considerations for Using Organizational Process Assets

One common mistake is assuming that organizational process assets are always directly applicable without tailoring. A standard work guideline developed for a large construction project may not fit a small software development effort. The project manager must review the assets and determine which parts are mandatory, which are advisory, and which need modification to fit the project context. That tailoring should be done in coordination with the organization's quality function to avoid creating conflicts with policy.

Another consideration is the timing of asset review. If the team discovers a relevant quality policy only after inspections have begun, the quality control process may already be noncompliant. The project manager should identify and review applicable organizational process assets during planning, then confirm their continued applicability during execution. This is not a one-time activity; new policies or updated guidelines may emerge while the project is underway.

Reporting procedures often receive less attention than they deserve. A defect that is found but not reported through the correct channel may never reach the person responsible for approving a fix. Communication policies that define who must be informed about nonconforming deliverables protect the project from delays caused by unresolved defects. The quality control process should produce records that are complete, traceable, and stored in a location accessible to authorized stakeholders.

Bringing the Quality Control Inputs Together

Each input to quality control becomes more valuable when combined with the others. The project management plan provides the rules, quality metrics and checklists provide the measurement instruments, work performance measurements provide the current status, approved change requests provide the verification targets, deliverables provide the objects of inspection, and organizational process assets provide the organizational context. A project manager who understands these relationships can run quality control as a coherent system rather than a disconnected set of inspections.

The sequence in which these inputs are used matters less than their completeness. Some teams start with work performance measurements to see where the project stands, then move to metrics and checklists to evaluate specific deliverables. Others begin with the deliverable and work backward through the checklist and metrics against the plan. The important point is that every input is available and understood before acceptance decisions are made. Missing inputs produce incomplete quality judgments.

Quality control outputs then feed directly into other project processes. Nonconforming deliverables may generate change requests for defect repair. Work performance measurements that show repeated technical failures may trigger a review of the quality management approach. Approved change requests that were not correctly implemented may lead to additional corrective actions or even a reassessment of the change control process itself. The inputs described here are not static documents; they interact continuously throughout the project lifecycle.

For a project manager, the practical discipline is to assemble these inputs early, keep them updated, and resist the temptation to skip verification steps when time is short. The cost of quality control is real, but the cost of poor quality is usually higher. When quality control is performed with the right inputs, the project team gains the confidence that deliverables will meet requirements and that approved changes will actually deliver the intended benefits. That confidence is not a matter of optimism; it is built from documented evidence collected through a structured process.

Every project faces pressure to deliver faster and spend less. Quality control inputs are sometimes seen as overhead, especially when the schedule tightens. But the inputs described here are precisely what allow the project manager to make defensible decisions under pressure. They convert subjective opinions about quality into verifiable facts. A deliverable that passes inspection with complete metrics, checklists, and change verification is far more likely to satisfy the customer than one that is rushed through with a quick visual review.

Ultimately, what you need to perform quality control is not a single tool or technique. You need a structured set of inputs that together define the standard, measure the work, verify the changes, and record the results. Mastering those inputs is the difference between inspecting for appearance and controlling for actual quality.