Project Quality Planning

Introduction and Context

Project quality planning is the disciplined process of deciding what “quality” means for a project, how it will be measured, who is accountable for achieving it, and how evidence of conformance will be produced. It converts broad expectations—such as reliability, safety, usability, regulatory compliance, or customer satisfaction—into controlled requirements, acceptance criteria, inspection activities, review points, records, and decision rules.

Quality planning is not the same as producing a quality document. A useful plan connects the project’s intended benefits with its deliverables and work processes. It also recognizes that quality is created primarily through sound design and controlled processes, while inspection provides evidence and detects failures. Excessive reliance on final inspection is costly because defects may have already been embedded in design, procurement, construction, software, or organizational processes.

In contemporary project governance, the quality management plan is normally integrated with the project management plan. It interfaces with scope, schedule, cost, risk, procurement, resource, communications, change, configuration, and stakeholder management. Its central question is not merely “How will we test the output?” but “How will we make it probable that the right output is produced correctly and consistently?”

Learning Objectives

By the end of this chapter, learners should be able to:

1. Distinguish quality requirements, standards, metrics, tolerances, verification, validation, assurance, and control.
2. Translate stakeholder and regulatory expectations into measurable quality objectives and acceptance criteria.
3. Design a project quality management plan, including responsibilities, inspection and test plans, reviews, resources, reporting, change control, and configuration management.
4. Select appropriate metrics and interpret variation, defects, trends, and nonconformities.
5. Evaluate trade-offs among prevention, appraisal, internal failure, and external failure costs.
6. Apply quality planning principles to a complex project and critically assess limitations and governance risks.

1. Foundations of Project Quality Planning

1.1 Quality as conformance and fitness for purpose

Quality has two complementary dimensions. Conformance means that a deliverable satisfies specified requirements, standards, drawings, contractual clauses, or regulations. Fitness for purpose means that it performs acceptably in its intended operational context and creates the value users require. A product can conform to a specification yet fail in use if the specification was incomplete or misunderstood.

Project quality therefore involves at least four questions:

• What outcomes and deliverables are required?
• Which characteristics make them acceptable to users, sponsors, regulators, and other stakeholders?
• What evidence will demonstrate conformity and performance?
• What controls will prevent unacceptable variation or recurrence of defects?

Quality is distinct from grade. Grade describes a category or rank of features; quality describes the degree to which requirements are fulfilled. A low-grade product can be high quality if it reliably meets its lower-grade requirements, while a premium product can be poor quality if it fails to conform.

1.2 Quality management, quality assurance, and quality control

Project quality management includes the policies, procedures, responsibilities, and resources used to direct and control quality. Three related activities are often distinguished:

• Quality planning identifies applicable quality requirements and determines how they will be achieved and demonstrated.
• Quality assurance evaluates whether the project’s processes are suitable and followed. It is primarily process-oriented and may include audits, independent assessments, process analysis, and lessons-learned reviews.
• Quality control monitors specific results, compares them with requirements, identifies causes of nonconformity, and supports corrective action. It is primarily deliverable- and data-oriented.

The distinction should not create organizational silos. A failed inspection may reveal a defective process; an audit may reveal a deliverable risk. Effective systems connect process evidence with product evidence.

1.3 Prevention, appraisal, and failure costs

The cost of quality is often analyzed through four categories:

The categories are managerial rather than strictly accounting classifications. Their value lies in revealing trade-offs. A modest increase in prevention may reduce expensive internal or external failures. However, “more checking” is not automatically better: poorly designed tests can create false confidence, delay work, or consume resources without addressing root causes.

1.4 The process view and systems thinking

A project is a temporary system of interdependent processes. Quality problems often cross functional boundaries: an ambiguous requirement affects design; design ambiguity affects procurement; procurement substitutions affect installation; installation defects affect commissioning and operations. The quality plan must therefore identify interfaces, handoffs, assumptions, and feedback loops.

A useful planning logic is:

need → requirement → design criterion → work process → verification evidence → acceptance decision → operational validation

Each arrow can fail. For example, a stakeholder need may be translated into an incomplete requirement, or a valid test may be performed on the wrong configuration. Quality planning is consequently a translation and traceability discipline, not only a testing discipline.

2. From Stakeholder Expectations to Quality Objectives

2.1 Identifying quality requirements

Quality requirements originate from several sources:

• contractual and procurement documents;
• laws, regulations, permits, codes, and professional standards;
• organizational policies and management-system procedures;
• user needs and service-level expectations;
• engineering, architectural, technical, or cybersecurity specifications;
• lessons from previous projects and operational incidents;
• assumptions, constraints, and risk responses.

Requirements should be unambiguous, testable where possible, prioritized, traceable to a stakeholder or source, and assigned an owner. Statements such as “the system must be user-friendly” are meaningful intentions but weak control requirements until usability dimensions and evaluation methods are defined.

A practical transformation is:

The numerical values in such examples are not universal standards; they must be justified by the business case, risk, contract, and applicable regulation.

2.2 Quality objectives

A quality objective states the desired level of performance and its measurement basis. A well-formed objective identifies:

1. the object or deliverable;
2. the quality characteristic;
3. the target or acceptance limit;
4. the measurement method and source;
5. the time or stage of measurement;
6. the responsible owner;
7. the response if the target is not achieved.

Objectives should be limited to characteristics that matter. Measuring everything produces administrative volume rather than managerial insight. Objectives should also be balanced: speed, cost, reliability, safety, usability, maintainability, and sustainability may conflict.

2.3 Metrics, measures, indicators, and acceptance criteria

A measure is an observed value, such as the number of failed tests. A metric is a defined measure with a method, unit, population, and interpretation. An indicator is a metric used to signal condition or trend. Acceptance criteria are the conditions that must be satisfied for a deliverable or phase to be accepted.

For count data, a defect rate can be expressed as:

The numerator and denominator must refer to the same inspection population and period. A “unit” must be defined—for example, a component, transaction, document, or test case. The metric is meaningful only when inspection coverage and sampling conditions are understood.

For a set of measured values, the arithmetic mean is:

where xᵢ is observation i, n is the number of observations, and x̄ is the sample mean. The observations must be measured on a compatible scale and represent the population or sampling plan being analyzed. The mean alone can conceal variation and outliers; it should not be used as proof that every item meets a tolerance.

A common measure of dispersion is the sample standard deviation:

Here s estimates variation in a sample. The divisor n − 1 is used when estimating population variance from a sample under conventional statistical assumptions. Project teams should not infer process capability or predict future performance from a small, biased, or unstable sample.

2.4 Tolerances and control limits

A tolerance is an allowable range specified for a product or deliverable characteristic. If a dimension must be between 9.8 mm and 10.2 mm, those are specification limits. A control limit is a statistically derived boundary used to assess process stability from observed process data. Specification limits and control limits answer different questions:

• specification limits: Is the result acceptable to the customer or requirement?
• control limits: Is the process behaving consistently over time?

A stable process can consistently produce unacceptable results if its average is poorly centered. Conversely, an unstable process may occasionally produce acceptable results but remain risky. Control charts and capability analysis require adequate, time-ordered data and assumptions appropriate to the process; they should not be used mechanically.

3. Selecting Standards and Defining the Quality Baseline

Standards provide agreed criteria, methods, terminology, or management-system expectations. They may be international, national, sector-specific, contractual, organizational, or project-specific. The plan should identify which standards are mandatory, which are guidance, and which take precedence when requirements conflict.

A quality baseline is the approved reference against which quality performance is assessed. It may include:

• approved requirements and acceptance criteria;
• specifications, drawings, models, and interface definitions;
• approved methods, procedures, and inspection points;
• applicable codes, regulations, and permits;
• approved product or process configurations;
• measurement, calibration, and recordkeeping requirements.

Standards do not eliminate judgment. A project team must establish applicability, edition or revision, jurisdiction, equivalence, and evidence requirements. It must also manage conflicts: legal requirements normally override internal preferences, while contractual obligations may impose stricter criteria than a general standard.

4. Designing the Project Quality Management Plan

A quality management plan should be proportionate to risk, complexity, regulatory exposure, supply-chain structure, and stakeholder consequence. A small internal project does not require the same documentation as a safety-critical infrastructure project, but both require clear acceptance criteria and accountable decisions.

4.1 Recommended contents

The plan should state interfaces with other plans. For example, quality risks may be recorded in the risk register, quality-related changes may follow integrated change control, and supplier quality evidence may be linked to procurement administration.

4.2 Responsibilities and independence

A responsibility matrix can clarify who is responsible for performing work, accountable for decisions, consulted for expertise, and informed of results. Responsibility must be accompanied by authority and competence. Assigning an individual accountability without granting access to records, suppliers, laboratories, or escalation channels creates nominal rather than real governance.

Independence is especially important for high-consequence acceptance decisions. The person who performs an activity may not be the appropriate person to approve its result. Independence does not always require a separate department; it requires sufficient objectivity, competence, and freedom from inappropriate pressure.

Typical roles include:

• project sponsor: approves quality objectives and accepts major residual risk;
• project manager: integrates quality with scope, schedule, cost, risk, and change decisions;
• quality manager: designs the quality system, facilitates assurance, and reports quality performance;
• technical or process owner: defines criteria and validates technical adequacy;
• work-package manager: controls execution and evidence within a package;
• inspector or tester: performs defined checks and records results;
• supplier: provides conforming products, process evidence, and corrective action;
• customer or authorized representative: verifies acceptance and confirms fitness for use.

4.3 Inspection and test plans

An inspection and test plan (ITP) translates requirements into executable control points. It commonly includes:

• activity or deliverable;
• characteristic to be checked;
• requirement or acceptance criterion;
• method, instrument, or test procedure;
• responsible performer and witness or approver;
• timing and prerequisite conditions;
• sampling basis or inspection extent;
• required records;
• hold, witness, surveillance, or review point;
• treatment of failed results.

A hold point requires formal authorization before work proceeds. A witness point allows an authorized party to observe the activity, while work may proceed if the party does not attend under agreed rules. A surveillance point involves monitoring without necessarily stopping work. These terms must be defined in the contract or plan; ambiguous use creates disputes.

Inspection should occur at risk-significant points, including before concealment, before irreversible work, at interfaces, after critical installation, and before release or handover. Sampling can be efficient, but its confidence depends on population definition, sampling method, lot homogeneity, consequence of failure, and the applicable standard. Convenience sampling is often weak evidence.

4.4 Reviews and audits

Reviews are structured evaluations at decision points. Examples include requirements reviews, design reviews, readiness reviews, code reviews, test-readiness reviews, procurement reviews, and operational acceptance reviews. A review should define entry criteria, participants, evidence, decisions, action owners, due dates, and closure rules.

Audits examine whether arrangements are defined and followed and whether they are effective. An audit is not merely an inspection of outputs and should not be used as a substitute for continuous management. Findings should be classified consistently, linked to evidence, assigned to owners, and verified for closure. Root-cause analysis should avoid stopping at symptoms. Techniques such as the five whys, fault-tree analysis, causal mapping, and Pareto analysis are useful when applied by competent practitioners.

5. Documentation, Records, and Traceability

Quality evidence must be reliable, retrievable, protected, and proportionate. Typical records include approved requirements, design calculations, review minutes, inspection results, test data, calibration certificates, supplier certificates, training records, nonconformance reports, corrective-action evidence, configuration histories, and acceptance certificates.

A document is an instruction or reference; a record is evidence that an activity or result occurred. Both require control, but records generally should not be altered after the fact. Corrections should preserve the original entry, identify the correction, and record who and when made it, according to applicable policy.

Traceability links a requirement to its source, design element, work activity, test or inspection, defect record, change history, and acceptance decision. A requirements traceability matrix can reveal orphan requirements, unverified deliverables, and tests that do not address actual requirements. Traceability is particularly important in regulated, safety-critical, software, pharmaceutical, aerospace, and complex systems projects.

Digital tools can improve retrieval and version control, but a repository alone does not create governance. Access rights, naming conventions, metadata, retention periods, backup, cybersecurity, privacy, and disposition rules must be defined. Personal data in quality records should be minimized and handled lawfully.

6. Resources, Measurement, and Reporting

Quality resources include competent people, time for reviews and rework, calibrated instruments, test environments, laboratories, inspection software, independent assessors, training, and budget. A quality plan that schedules testing without providing test environments or qualified personnel is incomplete.

Measurement equipment should be suitable for the required accuracy and maintained or calibrated according to applicable requirements. Results should include units, method, instrument identity where relevant, date, operator, environmental conditions when material, and any limitations. Measurement uncertainty may matter when a result is close to a specification limit; teams should not present a borderline result as exact without considering the measurement system.

Quality reporting should support decisions rather than create dashboards for their own sake. A useful report may include:

• current performance against quality objectives;
• completed and upcoming inspections or reviews;
• open nonconformities by severity and age;
• rework, defect, and failure trends;
• supplier performance and overdue corrective actions;
• audit findings and closure status;
• emerging risks and required decisions;
• changes affecting the quality baseline.

Metrics should be segmented where aggregation hides risk. For example, an overall defect rate may conceal a critical defect in a small but safety-significant subsystem. Data definitions, calculation basis, reporting frequency, thresholds, and escalation rules should be documented.

7. Change Control and Configuration Management

Quality requirements and baselines inevitably evolve, but uncontrolled change destroys the meaning of inspection and acceptance. Integrated change control evaluates proposed changes for impact on scope, requirements, design, interfaces, risk, schedule, cost, resources, testing, regulatory approvals, and operational performance.

Configuration management establishes and maintains the identity, status, history, and integrity of project items. A configuration item may be a requirement set, software release, engineering drawing, equipment model, test procedure, or approved process. Core practices include:

1. configuration identification: define items and version identifiers;
2. baseline establishment: approve a reference version;
3. change control: evaluate and authorize modifications;
4. status accounting: record current and historical status;
5. configuration verification and audit: confirm that the item and records agree.

A change is not fully implemented merely because a new file exists. Related specifications, interfaces, test cases, training, procurement documents, work instructions, and acceptance evidence may also require revision. After change, regression testing or re-inspection may be required to ensure that previously conforming functions remain conforming.

8. Worked Example: Planning Quality for a Digital Permit System

A municipality is developing a digital building-permit service. The system must accept applications, validate required information, route cases to reviewers, protect personal data, and provide status information to applicants.

Background and problem

A previous system was technically delivered on time but generated complaints because applicants could not understand rejection messages, reviewers used inconsistent rules, and performance deteriorated during peak periods. The new project has a fixed regulatory launch date and must integrate with an identity service and document repository.

Quality objectives and criteria

The project team identifies these objectives:

• every mandatory application field shall be validated before submission;
• 95% of standard application pages shall load within two seconds under the agreed test workload;
• all approved security test cases shall pass before production release, with no unresolved critical vulnerability;
• rejection messages shall be understandable to representative users, measured through a defined usability test;
• each application decision shall be traceable to the applicable rule, reviewer, version, and timestamp;
• the service shall meet the availability target specified in the service agreement, excluding approved maintenance.

The team defines the population and method for each metric. “Page load” is specified as a percentile-based response-time measure under a stated workload rather than an informal impression. Security acceptance is linked to a controlled test scope and severity classification. Usability is assessed with representative users and task success criteria, not only with developer opinion.

Inspection and review strategy

The plan establishes requirements and interface reviews before development, peer review for critical rules, automated tests for validation logic, integration tests with external services, security testing before release, accessibility assessment, performance testing under representative load, and operational readiness review. A hold point prevents production deployment until critical defects are closed or formally accepted by authorized governance.

A traceability matrix links each regulatory rule to a requirement, implementation component, test case, result, and release configuration. The configuration baseline identifies the approved code version, database migration scripts, rule catalogue, infrastructure settings, test evidence, and user guidance.

Reporting and change control

Weekly reporting includes escaped defects, open critical and high findings, test completion, rule changes, response-time trends, and overdue corrective actions. A proposed change to a permit rule is assessed for legal authority, affected workflows, user communications, regression tests, data migration, and release timing. The change board cannot approve the rule modification without identifying the revised acceptance evidence.

Outcome and learning points

The project avoids treating quality as a final technical test. It combines prevention through clear rules and reviews, appraisal through testing and audits, and controlled acceptance through traceability and configuration management. The principal lesson is that quality objectives must describe not only system attributes but also evidence, ownership, timing, and consequences of failure. Another lesson is that usability, security, legality, and performance are interconnected; optimizing one in isolation can damage the service as a whole.

9. Challenges, Limitations, and Ethical Governance

Ambiguous or conflicting requirements

Stakeholders may use the same term differently, or regulators and users may impose incompatible expectations. The project should record assumptions, seek authoritative interpretation, and escalate unresolved conflicts rather than conceal them in test execution.

Metric gaming and perverse incentives

If teams are rewarded only for low defect counts, they may avoid recording defects, narrow the inspection population, or defer disclosure. Metrics should be interpreted with context, independently sampled where appropriate, and balanced with learning and transparency indicators.

False precision

A metric with several decimal places is not necessarily accurate. Measurement-system limitations, sampling error, changing populations, and data-quality problems should be reported. Managers must distinguish absence of evidence from evidence of absence.

Supplier and subcontractor dependence

The project remains accountable for integrated outcomes even when work is outsourced. Contracts should define requirements, evidence, access for inspection or audit, notification of changes, nonconformance handling, record retention, and flow-down obligations. Certification by a supplier is useful evidence but does not automatically prove project-specific conformity.

Ethical and regulatory responsibilities

Quality decisions can affect safety, privacy, accessibility, public funds, and equitable service access. Concealing defects, falsifying records, suppressing adverse test results, or accepting known nonconformance without authorized risk evaluation is unethical and potentially unlawful. Quality professionals should maintain evidence integrity, protect whistleblowers, respect confidentiality, and escalate conditions that create unacceptable harm.

10. Technology, AI, and Contemporary Practice

Digital engineering, automated testing, continuous integration, model-based systems engineering, sensor data, and electronic quality records can increase traceability and shorten feedback cycles. They also introduce risks: automation may reproduce biased or incomplete test data, dashboards may confuse activity with quality, and changing software dependencies may invalidate previous evidence.

AI can assist with classifying defects, identifying patterns in nonconformance records, generating test cases, and summarizing audit evidence. It should not be treated as an autonomous acceptance authority. Human experts must validate outputs, protect confidential data, assess bias, preserve audit trails, and ensure that generated evidence is reproducible. For safety-, legal-, or rights-critical decisions, governance should specify approved models, data provenance, review thresholds, override authority, and retention of prompts or outputs where relevant.

Contemporary quality planning increasingly emphasizes resilience, sustainability, cybersecurity, accessibility, supply-chain transparency, and operational outcomes. These concerns broaden quality beyond conformance at handover. The project team should ask whether the deliverable remains safe, secure, maintainable, inclusive, and fit for purpose throughout its intended life.

Best-Practice Checklist

Before approving a project quality management plan, confirm that:

• quality objectives are linked to stakeholder value, risk, and acceptance;
• requirements are measurable or have an explicit evaluation method;
• standards and precedence rules are identified;
• metrics include definitions, units, populations, owners, and thresholds;
• tolerances are distinguished from process-control limits;
• inspections, tests, reviews, and audits have entry and exit criteria;
• hold and witness points are unambiguous;
• competence, independence, equipment, and test environments are available;
• records are traceable, secure, retrievable, and retained appropriately;
• nonconformities receive containment, root-cause analysis, corrective action, and effectiveness review;
• changes trigger impact analysis and regression or re-verification where necessary;
• configuration baselines include all relevant components and interfaces;
• reporting supports decisions and does not encourage metric manipulation;
• acceptance authority and residual-risk ownership are explicit.

Chapter Summary

Project quality planning converts expectations, requirements, standards, and risks into measurable objectives and controlled evidence. A robust plan defines quality characteristics, metrics, tolerances, acceptance criteria, responsibilities, inspection and test activities, reviews, audits, resources, records, reporting, nonconformance treatment, change control, and configuration management.

Quality is broader than final inspection. Prevention and sound process design reduce the probability of defects, while appraisal and control provide evidence and detect variation. Quality objectives must be measurable, but metrics require clear definitions, appropriate sampling, reliable measurement, and contextual interpretation. Specification limits describe acceptable outputs; control limits describe process behavior and must not be confused.

Inspection and test plans identify what is checked, when, by whom, using which method, and with what evidence. Reviews and audits should be planned decision mechanisms rather than ceremonial meetings. Traceability connects requirements to design, implementation, verification, change history, and acceptance. Configuration management protects the integrity of the approved baseline and ensures that changes trigger appropriate re-verification.

At postgraduate level, quality planning should be understood as a governance and systems problem. It involves trade-offs among value, risk, cost, schedule, compliance, ethics, and operational performance. Effective plans are proportionate, evidence-based, transparent, and designed to support learning rather than concealment.

Key Terms

Quality: Degree to which characteristics fulfil requirements and intended purpose.

Quality planning: Process of identifying quality requirements and determining how they will be achieved and demonstrated.

Quality assurance: Process-oriented evaluation of whether quality arrangements are suitable, followed, and effective.

Quality control: Monitoring and assessing results to identify nonconformity and support corrective action.

Conformance: Fulfilment of specified requirements.

Fitness for purpose: Suitability of a deliverable for its intended use.

Quality objective: Defined quality result with a target, measurement basis, and owner.

Metric: Defined measure with a unit, method, population, and interpretation.

Acceptance criterion: Condition that must be met for authorized acceptance.

Tolerance: Permitted range for a specified characteristic.

Control limit: Statistical boundary used to assess process stability.

Inspection and test plan: Schedule defining checks, methods, responsibilities, evidence, and control points.

Hold point: Mandatory authorization point before work may proceed.

Witness point: Point at which an authorized party may observe an activity.

Nonconformity: Failure to meet a specified requirement.

Corrective action: Action to eliminate the cause of a detected nonconformity.

Traceability: Ability to link requirements, work, evidence, changes, and decisions.

Configuration management: Control of the identity, status, history, and integrity of project items.

Quality baseline: Approved reference set of requirements, specifications, methods, and acceptance criteria.

Cost of quality: Prevention, appraisal, internal-failure, and external-failure costs associated with quality.

Review Questions

Short Answer Questions

1. Distinguish quality assurance from quality control.
2. What information should a measurable quality objective contain?
3. Explain the difference between a tolerance and a control limit.
4. What is the purpose of an inspection and test plan?
5. Why is configuration management important to project quality?

Long Answer Questions

1. Explain how stakeholder expectations can be transformed into measurable quality requirements and acceptance criteria. Use an example.
2. Discuss the relationship among prevention, appraisal, internal failure, and external failure costs.
3. Describe the main contents of a project quality management plan and explain how they interface with other project plans.
4. Critically evaluate the role of reviews, audits, inspections, and tests in a project quality system.
5. Explain how change control and configuration management protect the validity of quality evidence during a project.

Analytical / Application Questions

1. A project reports a low overall defect rate, but two safety-critical components have recurring failures. Analyze why the aggregate metric is insufficient and propose a better reporting and control approach.
2. Design an inspection and test plan outline for a software release that handles personal data. Identify at least five control points, their evidence, and the authority required for release.
3. A supplier claims that its certificate proves conformity, but the supplied component has been modified from the approved design. Determine the quality, configuration, contractual, and governance actions the project should take.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes quality assurance from quality control?

A. Quality assurance focuses on processes, while quality control focuses on results and deliverables.

B. Quality assurance is performed only after delivery, while quality control is performed only before work begins.

C. Quality assurance measures cost, while quality control measures schedule.

D. Quality assurance is the customer’s responsibility, while quality control is the supplier’s responsibility.

Correct Answer: A. Quality assurance focuses on processes, while quality control focuses on results and deliverables.

Question 2

A project inspects 250 units and finds 5 nonconforming units. What is the defect rate?

A. 0.5%

B. 2%

C. 5%

D. 20%

Correct Answer: B. 2%

Question 3

Which item is a specification limit rather than a control limit?

A. A statistically calculated boundary used to assess process stability

B. A range of values defined as acceptable for a deliverable characteristic

C. A trend line calculated from time-ordered observations

D. A warning threshold based on historical process variation

Correct Answer: B. A range of values defined as acceptable for a deliverable characteristic

Question 4

What is the primary purpose of a hold point in an inspection and test plan?

A. To permit work to continue without documentation

B. To require formal authorization before work proceeds

C. To replace all testing with supplier certification

D. To eliminate the need for acceptance criteria

Correct Answer: B. To require formal authorization before work proceeds

Question 5

Which sequence best represents quality traceability?

A. Budget → invoice → payment → closure

B. Requirement → design or work → verification evidence → acceptance decision

C. Meeting → presentation → email → procurement

D. Risk → vacation schedule → audit → invoice

Correct Answer: B. Requirement → design or work → verification evidence → acceptance decision

Question 6

Why must a quality plan identify measurement methods and populations for metrics?

A. To ensure that results are interpretable and comparisons are meaningful

B. To guarantee that every result will meet the specification

C. To eliminate the need for competent inspectors

D. To make all project metrics identical

Correct Answer: A. To ensure that results are interpretable and comparisons are meaningful

Question 7

Which activity is most directly associated with configuration management?

A. Approving a project celebration budget

B. Tracking the identity, version, and change history of an approved design

C. Estimating the number of project stakeholders

D. Selecting a meeting room for a review

Correct Answer: B. Tracking the identity, version, and change history of an approved design

Question 8

A process has an acceptable average output but highly variable results. What is the principal quality concern?

A. Variation may cause individual results to fall outside specification limits.

B. The average proves that every result conforms.

C. Variation is irrelevant when the mean is acceptable.

D. The process automatically has high capability.

Correct Answer: A. Variation may cause individual results to fall outside specification limits.

Question 9

Which is the strongest reason not to rely solely on final inspection?

A. Final inspection always costs more than prevention.

B. Defects may already be embedded in design or process decisions and become costly to correct.

C. Inspection cannot produce records.

D. Final inspection is never required by contracts.

Correct Answer: B. Defects may already be embedded in design or process decisions and become costly to correct.

Question 10

What should happen when a proposed change affects an approved configuration baseline?

A. Implement it immediately and update records at project closure.

B. Ignore testing if the change is requested by a senior manager.

C. Assess impacts, obtain authorized approval, update affected items, and perform required re-verification.

D. Delete the previous baseline to avoid confusion.

Correct Answer: C. Assess impacts, obtain authorized approval, update affected items, and perform required re-verification.