Foundations of Project Quality Management

Introduction

Project quality management is the disciplined practice of ensuring that project outputs and project processes satisfy agreed requirements and create value for stakeholders. It is not limited to inspecting a finished deliverable. It begins when needs are identified, continues through design and execution, and extends into use, support, learning, and organizational improvement.

Quality is especially important in projects because projects are temporary, often unique, and subject to uncertainty. A project may have a fixed budget and schedule, but an output that is unsafe, unreliable, unusable, or non-compliant cannot be considered successful. Conversely, excessive or unnecessary quality can consume resources without creating proportional value. Effective quality management therefore requires managerial judgement: the project must achieve the level of performance that is required and appropriate for its intended use.

This chapter establishes the conceptual foundation for later study of quality planning, assurance, control, measurement, auditing, statistical tools, continuous improvement, and quality governance.

Learning Objectives

After studying this chapter, you should be able to:

1. Explain quality, grade, fitness for use, conformance, and value in a project context.
2. Distinguish verification from validation and explain their relationship.
3. Explain defects, prevention, appraisal, quality assurance, and quality control.
4. Describe the historical evolution of quality management and its major schools of thought.
5. Analyse how quality influences project success, risk, cost, schedule, benefits, and stakeholder trust.
6. Apply foundational quality concepts to a realistic project situation.

1. The Meaning of Quality in Projects

1.1 Quality as fulfilment of requirements and intended use

Quality has several complementary interpretations. In a project, quality generally refers to the degree to which characteristics of a deliverable, service, process, or result fulfil requirements. Requirements may be explicit, such as contractual specifications, or implicit, such as safety, accessibility, reliability, professional ethics, and applicable law.

A useful distinction is between conformance quality and performance quality. Conformance quality asks whether the output was produced according to specified requirements. Performance quality asks whether the output performs effectively in its real context. A software application may conform to its written functional specification yet be too slow for users. A bridge may conform to drawings yet be difficult to maintain. A training programme may deliver all scheduled sessions yet fail to improve capability. Quality therefore involves both compliance and fitness for purpose.

Quality is not synonymous with luxury, excellence, or the highest possible specification. A basic, reliable product can be high quality if it meets its intended purpose. A premium product can be poor quality if it fails essential requirements. Quality decisions should be based on stakeholder needs, risk, life-cycle consequences, and value—not on prestige alone.

1.2 Quality and grade

Grade is a category or rank assigned to products or services having the same functional use but different technical characteristics. Quality and grade are related but not identical. A low-grade product may be high quality when it consistently meets the requirements of its grade. A high-grade product may be poor quality when it contains defects or fails to perform.

For example, an economy hotel and a luxury hotel have different grades. If the economy hotel provides a clean, safe room as promised, it may deliver high quality even though its grade is lower. Confusing grade with quality often causes unnecessary over-specification, cost growth, and scope disputes.

1.3 Fitness for use

Fitness for use means that a product or service is suitable for the purpose for which users need it. This concept emphasizes the user's context rather than the producer's internal process alone. Fitness may include performance, reliability, safety, accessibility, maintainability, compatibility, and ease of use.

Fitness for use is evaluated against actual or reasonably foreseeable operating conditions. A medical device designed for a sophisticated hospital may not be fit for use in a remote clinic without stable electricity. A data dashboard may be technically accurate but unfit for use if decision-makers cannot interpret it in time.

1.4 Quality, value, and stakeholder expectations

Quality is a value judgement as well as a technical judgement. Stakeholders may value different characteristics: customers may value usability, regulators may value compliance, operators may value maintainability, and sponsors may value benefits and affordability. Requirements engineering and stakeholder engagement are therefore essential quality activities.

A project should distinguish:

• Mandatory requirements, whose failure creates unacceptable risk or non-compliance.
• Performance requirements, which define measurable levels of capability.
• Preference requirements, which improve desirability but may be negotiable.
• Emergent expectations, which may not have been documented but become important during use.

The project manager must make these distinctions visible and obtain decisions when trade-offs arise.

2. Core Quality Concepts

2.1 Requirements, characteristics, and acceptance criteria

A requirement states a need, expectation, condition, or capability that must be satisfied. A quality characteristic is an attribute that can be evaluated, such as accuracy, response time, strength, completeness, security, or maintainability. Acceptance criteria specify the conditions under which a deliverable will be accepted.

Good acceptance criteria are observable and testable. “The system shall be user-friendly” is ambiguous. “A trained first-time user shall complete the standard transaction within five minutes with no critical error” is more useful, provided the measurement method and test conditions are defined.

2.2 Defects and nonconformities

A defect is an imperfection or deficiency that causes a product, service, or result not to meet a requirement or intended use. A nonconformity is the failure to fulfil a specified requirement. The terms overlap, but nonconformity is often used in formal quality systems and audits.

Defects may be introduced during requirements analysis, design, procurement, construction, coding, integration, documentation, or operation. The visible defect is frequently a symptom of a deeper process problem. For example, an incorrect invoice may result from poor data validation, ambiguous requirements, inadequate training, or an uncontrolled interface between systems.

Defects can be classified by severity, occurrence, detectability, location, or cause. Severity concerns the consequence if the defect reaches the user. Occurrence concerns how often it arises. Detectability concerns the likelihood that existing controls will discover it before harm occurs. These dimensions support risk-based prioritisation.

2.3 Verification and validation

Verification asks: “Are we building the product right?” It evaluates whether a work product conforms to specified requirements, designs, standards, or procedures. Reviews, inspections, calculations, code analysis, document checks, and tests can support verification.

Validation asks: “Are we building the right product?” It evaluates whether the completed or emerging result satisfies the needs of its intended users and other stakeholders in its operational context. User acceptance testing, field trials, simulations, demonstrations, and operational pilots support validation.

Verification and validation are complementary. A deliverable may pass verification but fail validation if the original requirements were incomplete or misunderstood. For example, a system can meet every documented interface requirement but fail to support the actual workflow of emergency staff.

2.4 Prevention, appraisal, and failure

Quality-related work is often grouped into three categories:

• Prevention costs arise from activities intended to avoid defects, such as requirements clarification, training, process design, supplier qualification, and error-proofing.
• Appraisal costs arise from evaluating conformance, such as inspection, testing, audits, reviews, and measurement.
• Failure costs arise when requirements are not met. Internal failure occurs before delivery, such as rework, scrap, retesting, or schedule disruption. External failure occurs after delivery, such as warranty claims, recalls, penalties, lost reputation, or harm to users.

The categories are useful for decision-making, but they should not be interpreted mechanically. A prevention activity is worthwhile when its expected benefit exceeds its cost and when it addresses meaningful risk. Testing remains necessary even in a mature process because prevention cannot eliminate all uncertainty.

2.5 Quality assurance and quality control

Quality assurance (QA) is the planned and systematic set of activities that provides confidence that the project will use appropriate processes and that outputs will meet requirements. QA is process-oriented and includes process assessment, audits, methods, standards, training, lessons learned, and improvement actions.

Quality control (QC) is the monitoring and measurement of specific project results to determine whether they conform to requirements and to identify ways to eliminate causes of unsatisfactory performance. QC is more output-oriented and includes inspection, testing, measurement, defect logging, data analysis, and corrective action.

QA and QC should not be treated as completely separate departments. QA establishes and improves the capability of the system; QC generates evidence about actual results. QC findings may reveal weaknesses requiring QA improvement, while QA methods determine how QC should be performed.

3. The Evolution of Quality Management

3.1 Inspection and quality control

Early industrial approaches relied heavily on inspection after production. Inspectors separated acceptable items from defective items. This approach was valuable where outputs were repetitive and measurable, but it had serious limitations: defects had already consumed resources, inspection could miss hidden failures, and responsibility for quality was often assigned to a specialist department rather than to the whole organisation.

Statistical quality control later introduced sampling, variation analysis, and process monitoring. Instead of examining every item, organisations could study whether a process was stable and capable of producing conforming outputs. This was an important shift from finding bad products to understanding the process that produced them.

3.2 Quality assurance and systems thinking

Quality assurance broadened attention from individual outputs to the management system. Documented procedures, competence requirements, configuration control, supplier management, design reviews, and corrective-action systems became central. The underlying insight was that consistent results require controlled and repeatable processes, even when the final outputs are unique.

Project environments complicate this principle because projects are temporary and often involve novel work. A project cannot simply copy a factory process. It must select, tailor, and integrate processes that are proportionate to its risks and context.

3.3 Total quality management and continuous improvement

Total quality management (TQM) treats quality as an organisation-wide responsibility linked to customers, processes, leadership, people, suppliers, and continuous improvement. It emphasises prevention, factual decision-making, systems thinking, and learning.

Important contributors include:

• W. Edwards Deming, who emphasised variation, systems, leadership responsibility, and continual improvement.
• Joseph Juran, who developed the quality trilogy of quality planning, quality control, and quality improvement and highlighted fitness for use.
• Philip Crosby, who stressed conformance to requirements and the principle that prevention is preferable to accepting defects as inevitable.
• Kaoru Ishikawa, who promoted quality circles, cause-and-effect analysis, and organisation-wide participation.
• Armand Feigenbaum, who developed the concept of total quality control across the full organisational system.

These contributions should not be treated as competing slogans. They provide different emphases: statistical understanding, managerial planning, prevention, participation, and system-wide integration.

3.4 Contemporary quality management

Modern quality management combines process discipline with agility, risk management, user-centred design, data analytics, sustainability, cybersecurity, and regulatory governance. Standards such as ISO 9001 provide a framework for a quality management system, while sector-specific standards may define additional requirements. Standards do not guarantee quality automatically; they provide structures for consistent management, evidence, and improvement.

Agile methods have also influenced project quality. Frequent feedback, automated testing, integration, demonstrations, and retrospectives can reduce the time between defect introduction and discovery. However, agility does not remove the need for clear acceptance criteria, traceability, independent assurance where risk warrants it, or compliance evidence.

4. Quality and Project Success

Project success is multidimensional. Traditional measures include scope, schedule, cost, and quality, but contemporary evaluation also considers benefits, stakeholder satisfaction, safety, sustainability, strategic alignment, organisational learning, and long-term operational performance.

Quality contributes to success through several pathways:

1. Benefits realization: A usable and reliable deliverable is more likely to produce the intended benefits.
2. Risk reduction: Effective prevention and control reduce failures, hazards, claims, and regulatory exposure.
3. Schedule performance: Early defect detection reduces late rework and integration surprises.
4. Cost performance: Prevention may increase early expenditure but reduce total life-cycle cost.
5. Stakeholder confidence: Transparent evidence of quality improves trust and acceptance.
6. Operational sustainability: Maintainable, secure, and adaptable outputs continue to create value after project closure.

Quality should not be viewed as an isolated constraint that competes equally with time and cost in every situation. Some quality requirements are non-negotiable because they concern safety, law, ethics, or essential function. In other areas, scope, time, cost, and quality can be optimised together through design choices, sequencing, modularity, and risk-based testing.

4.1 Cost of quality and the cost of poor quality

The cost of quality includes the investment required to prevent and appraise quality problems as well as the costs resulting from failures. The cost of poor quality is commonly used to describe internal and external failure costs, although organisations define the boundary differently.

A project should consider life-cycle cost rather than only project expenditure. A cheaper design may impose high maintenance, energy, downtime, support, or disposal costs. Quality decisions should therefore account for total cost of ownership, expected failure consequences, and the distribution of costs among stakeholders.

4.2 Quality indicators and evidence

Quality performance should be assessed using meaningful measures, not an excessive number of metrics. Possible indicators include defect density, first-pass yield, test pass rate, rework hours, escaped defects, response time, reliability, customer complaints, audit findings, corrective-action closure time, and acceptance rate.

A metric is useful only when its definition, data source, sampling method, timing, owner, and decision consequence are understood. For example, a high test pass rate can be misleading if tests cover only easy scenarios. Metrics should be interpreted with context and should not encourage gaming or concealment.

5. A Practical Quality Management Framework

A project quality management approach can be structured as an integrated cycle:

1. Understand stakeholders and context. Identify users, regulators, sponsors, operators, suppliers, and affected communities.
2. Translate needs into requirements. Define measurable characteristics, constraints, assumptions, and acceptance criteria.
3. Plan quality. Select standards, methods, roles, measures, review points, testing strategies, records, and escalation rules.
4. Design quality into the solution. Use robust design, clear interfaces, error prevention, accessibility, security, maintainability, and risk controls.
5. Assure the process. Review whether approved methods are being followed and whether they remain suitable.
6. Control deliverables. Inspect, test, measure, analyse defects, and document evidence of conformity.
7. Validate with users. Demonstrate fitness for use under realistic conditions.
8. Manage nonconformities. Contain the immediate problem, determine root causes, correct the condition, and verify effectiveness.
9. Learn and improve. Capture lessons, update processes, and transfer knowledge to future projects and operations.

This cycle is iterative rather than strictly linear. Discoveries during validation may require changes to requirements or design. A change should be evaluated for its effects on scope, schedule, cost, risk, compliance, interfaces, and benefits.

5.1 Root-cause thinking

Correcting a symptom is not the same as eliminating its cause. Root-cause analysis may use the five-whys technique, cause-and-effect diagrams, fault-tree analysis, Pareto analysis, process mapping, or structured problem-solving. The selected method should match the complexity and risk of the problem.

Root-cause analysis must avoid blame-based explanations such as “operator error” when the process made the error likely. Questions should examine unclear instructions, workload, training, interfaces, tools, incentives, environmental conditions, supervision, and organisational decisions.

5.2 Governance and ethical responsibilities

Quality governance defines authority, independence, escalation, evidence, and accountability. A project should establish who can approve requirements, accept deliverables, waive a nonconformity, stop unsafe work, and authorise release.

Ethical quality management requires accurate reporting, protection of users, respect for affected communities, and refusal to conceal defects or manipulate evidence. A project manager may face pressure to meet a launch date despite unresolved risks. Professional responsibility requires transparent communication and proportionate escalation, especially where safety, privacy, security, or legal compliance is involved.

Quality records may also contain personal, commercially sensitive, or security-critical information. Access, retention, version control, and auditability should be managed consistently with applicable law and organisational policy.

6. Technology and AI in Project Quality

Digital tools can improve traceability, automated testing, configuration management, sensor-based inspection, and real-time reporting. Artificial intelligence may support anomaly detection, document comparison, defect classification, predictive maintenance, and analysis of historical project data.

These technologies do not replace professional judgement. AI outputs can reflect biased training data, hidden assumptions, poor data quality, or model drift. A project must define human review, validation datasets, decision authority, audit trails, cybersecurity controls, and conditions under which automated recommendations may be overridden. Automation should strengthen prevention and evidence, not create false confidence.

7. Illustrative Case: Riverside Health Information System

Background

A regional health authority initiated a project to replace fragmented patient-record systems with an integrated electronic health information system. The project involved hospitals, clinics, laboratories, pharmacies, patients, suppliers, and regulators. The sponsor initially defined success as delivering the system within eighteen months and within the approved budget.

Problem

During a pilot, the system passed most functional tests but clinicians reported that medication alerts appeared too late in the workflow. Several laboratory results were also displayed with unclear units. The supplier argued that the software met the signed specification. Clinical users argued that the system was unsafe and not fit for use.

Analysis

The project had performed substantial verification against documented requirements but insufficient validation in realistic clinical conditions. Requirements had been written mainly by technical analysts and did not adequately represent emergency workflows. The quality plan also treated usability as a preference rather than as a safety-related characteristic.

A cross-functional review identified four causes:

• incomplete stakeholder participation during requirements definition;
• testing with scripted data rather than realistic cases;
• lack of an explicit clinical usability and safety acceptance criterion;
• unclear ownership of interface decisions between the supplier and health authority.

The visible defects were therefore symptoms of weaknesses in requirements, governance, and validation—not merely coding errors.

Approach and solution

The project paused the affected release and established a clinical quality board with authority to reject unsafe functionality. It revised requirements using workflow observations and structured interviews. New acceptance criteria specified alert timing, unit display, accessibility, and behaviour under network interruption. Clinicians participated in scenario-based validation, while technical teams continued verification through automated and integration tests.

The project also introduced traceability from clinical risk to requirement, design control, test evidence, and acceptance decision. A controlled pilot was conducted in two clinics before wider deployment. Defects were prioritised by potential patient harm rather than by convenience of correction.

Outcome

The revised system was delivered later than the original target but with improved clinical acceptance and reduced operational risk. Some non-critical features were deferred to protect safety-critical validation. The sponsor concluded that the original schedule measure had been too narrow: a faster deployment of an unsafe system would not have constituted project success.

Learning points

The case demonstrates that:

1. Verification cannot substitute for validation.
2. Quality requirements must reflect real use and risk.
3. Stakeholder participation is a quality-control and quality-assurance concern.
4. Early prevention and realistic validation can be less costly than post-release failure.
5. Governance must allow qualified stakeholders to stop or modify an unsafe release.
6. Quality, schedule, cost, and scope decisions should be evaluated against benefits and consequences, not treated as isolated numbers.

8. Challenges and Limitations

Quality management is difficult when requirements are ambiguous, stakeholders disagree, data are incomplete, suppliers control critical knowledge, or outcomes emerge only after project closure. Some qualities—such as trust, dignity, resilience, or user confidence—are difficult to measure precisely. Excessive documentation can also create bureaucracy without improving performance.

There is no universal quality method. A safety-critical engineering project may require formal verification, independent assurance, configuration control, and extensive evidence. A small innovation project may need lightweight experiments, rapid feedback, and adaptable criteria. Tailoring should preserve essential controls while avoiding activities that add little value.

Managers should also recognise the danger of local optimisation. A team may improve its own defect rate by passing difficult work to another team, or reduce testing to meet a milestone while increasing operational risk. Quality must be managed across the whole value stream and life cycle.

Best-Practice Principles

• Define quality in terms of stakeholder needs, intended use, and measurable requirements.
• Separate grade from quality; do not confuse premium specification with fitness for purpose.
• Prevent defects through sound requirements, design, competence, and process control.
• Use verification and validation as complementary forms of evidence.
• Apply risk-based and life-cycle thinking to quality decisions.
• Make acceptance criteria observable, testable, and agreed before delivery.
• Treat defects as opportunities to improve systems, not merely occasions to assign blame.
• Maintain traceability for critical requirements, decisions, tests, and changes.
• Report quality information honestly and protect users from unacceptable harm.
• Tailor quality activities to project complexity, uncertainty, regulation, and consequence of failure.

Chapter Summary

Project quality management ensures that project processes and deliverables meet agreed requirements and are fit for intended use. Quality is distinct from grade: grade describes category or level of specification, whereas quality concerns conformity and suitability. Requirements, characteristics, acceptance criteria, defects, and nonconformities provide the vocabulary for defining and evaluating quality.

Verification determines whether a product is being built according to specified requirements; validation determines whether the right product is being built for real users and contexts. Prevention seeks to avoid defects, appraisal evaluates conformance, and failure costs arise when defects escape or disrupt work. Quality assurance focuses primarily on process capability and confidence, while quality control focuses primarily on measuring and correcting deliverables.

The evolution from inspection to statistical control, quality assurance, total quality management, and contemporary risk-based systems reflects a movement from detecting defects to preventing them and learning from variation. Quality contributes to project success through benefits realization, risk reduction, stakeholder confidence, cost and schedule stability, compliance, safety, and long-term operational performance. Effective project quality management integrates requirements, planning, design, assurance, control, validation, governance, ethical conduct, and continuous improvement.

Key Terms

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

Grade: Category or rank assigned to products or services with similar functional use but different characteristics.

Fitness for use: Suitability of a product or service for its intended purpose and operating context.

Conformance: Fulfilment of specified requirements.

Requirement: A need, expectation, condition, or capability that must be satisfied.

Acceptance criteria: Conditions that must be met for a deliverable to be accepted.

Defect: An imperfection or deficiency causing failure to meet a requirement or intended use.

Nonconformity: Failure to fulfil a specified requirement.

Verification: Evaluation of whether a work product conforms to specified requirements.

Validation: Evaluation of whether a product satisfies stakeholder needs in its intended context.

Prevention: Action taken to avoid defects or reduce their likelihood.

Appraisal: Evaluation activities used to assess conformance.

Quality assurance: Planned activities providing confidence in suitable processes and expected results.

Quality control: Monitoring and measurement of results to identify and correct nonconformity.

Cost of quality: Prevention, appraisal, and failure costs associated with achieving quality.

Internal failure: Cost of nonconformance discovered before delivery.

External failure: Cost of nonconformance discovered after delivery.

Traceability: Ability to relate requirements, designs, tests, changes, and acceptance evidence.

Fitness-for-purpose validation: Confirmation that a result works for its intended users and context.

Continuous improvement: Ongoing effort to improve processes, results, and organisational capability.

Review Questions

Short Answer Questions

1. What is the difference between quality and grade?
2. Define fitness for use and provide one project example.
3. How does verification differ from validation?
4. Distinguish quality assurance from quality control.
5. What is an external failure cost?

Long Answer Questions

1. Explain the evolution of quality management from inspection to contemporary project quality systems.
2. Discuss how quality contributes to project success beyond compliance with scope, schedule, and budget.
3. Explain prevention, appraisal, internal failure, and external failure costs and their managerial significance.
4. Describe a practical quality management cycle for a complex project.
5. Analyse the ethical and governance responsibilities of a project manager when a deliverable meets specifications but may harm users.

Analytical / Application Questions

1. A software project passes all documented functional tests, but users cannot complete critical tasks efficiently. Analyse whether the issue is one of verification, validation, requirements, or quality control, and recommend actions.
2. A construction project is behind schedule because repeated defects require rework. Develop a root-cause-oriented quality response rather than merely increasing final inspection.
3. A sponsor proposes reducing safety testing to meet a public launch date. Evaluate the proposal using quality, risk, governance, life-cycle cost, and stakeholder perspectives.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes quality from grade?

A. Quality is always associated with premium specifications, whereas grade is associated with basic specifications.

B. Quality concerns fulfilment of requirements and intended use, whereas grade indicates a category or level of specification.

C. Grade measures defects, whereas quality measures project duration.

D. Quality applies only to services, whereas grade applies only to products.

Correct Answer: B. Quality concerns fulfilment of requirements and intended use, whereas grade indicates a category or level of specification.

Question 2

Which activity is primarily an example of validation?

A. Checking source code against a coding standard

B. Reviewing a design drawing for completeness

C. Testing a healthcare system in realistic clinical workflows with intended users

D. Comparing a procurement document with an approved template

Correct Answer: C. Testing a healthcare system in realistic clinical workflows with intended users

Question 3

What is the primary focus of quality assurance?

A. Separating defective finished products from acceptable products

B. Providing confidence that suitable processes are being used and improved

C. Reducing the approved project scope

D. Assigning responsibility for every defect to an individual

Correct Answer: B. Providing confidence that suitable processes are being used and improved

Question 4

Which of the following is a prevention cost?

A. Warranty replacement after delivery

B. Retesting failed components

C. Supplier qualification and process training

D. Customer compensation for service failure

Correct Answer: C. Supplier qualification and process training

Question 5

A deliverable meets every written specification but does not support the user's real workflow. What is the most likely fundamental issue?

A. Successful validation

B. Failure of fitness for use and possibly incomplete requirements

C. Excessive appraisal cost only

D. Correct grade selection

Correct Answer: B. Failure of fitness for use and possibly incomplete requirements

Question 6

Which statement about a defect is most accurate?

A. A defect is only a problem discovered after delivery.

B. A defect is any difference between two project schedules.

C. A defect is an imperfection or deficiency that causes failure to meet a requirement or intended use.

D. A defect is always caused by an individual operator.

Correct Answer: C. A defect is an imperfection or deficiency that causes failure to meet a requirement or intended use.

Question 7

Why is root-cause analysis preferable to simply repairing a visible defect?

A. It guarantees that no future defects can occur.

B. It seeks to address the underlying conditions that allow the defect to recur.

C. It eliminates the need for validation.

D. It transfers quality responsibility to the customer.

Correct Answer: B. It seeks to address the underlying conditions that allow the defect to recur.

Question 8

Which project decision best reflects risk-based quality management?

A. Apply exactly the same testing effort to every deliverable regardless of consequence.

B. Eliminate all reviews to maximise speed.

C. Devote stronger independent assurance to a safety-critical interface than to a low-risk document.

D. Accept all defects until final inspection.

Correct Answer: C. Devote stronger independent assurance to a safety-critical interface than to a low-risk document.

Question 9

Which statement best describes quality control?

A. It monitors and measures project results to identify and correct nonconformity.

B. It defines the organisation's strategic mission.

C. It replaces stakeholder engagement with automated testing.

D. It concerns only supplier contracts.

Correct Answer: A. It monitors and measures project results to identify and correct nonconformity.

Question 10

A project delays release to conduct realistic user testing of a safety-critical system. Which principle does this decision most strongly illustrate?

A. Schedule is always more important than quality.

B. Validation and fitness for use are relevant to project success.

C. Grade and quality are identical.

D. Appraisal activities are unnecessary when requirements exist.

Correct Answer: B. Validation and fitness for use are relevant to project success.