Project Product, Quality and Acceptance Control

Control guidance

Quality begins with the product baseline

Quality is the degree to which a product's inherent characteristics fulfil requirements. In project control, the first task is not inspection; it is agreement about the product and its intended use. The project product description defines the final output from the customer's or commissioning authority's perspective. It normally covers purpose, composition, derivation, development skills, customer quality expectations, acceptance criteria, acceptable tolerances, acceptance method and acceptance responsibilities.

Component product descriptions then define each major product needed to create the final output. They state purpose, composition, derivation, format or presentation, quality criteria, quality tolerance, quality method, reviewer and approver. This structure converts scope from an activity list into testable products. The product breakdown and descriptions collectively define the scope baseline at the relevant planning level.

Customer quality expectations are broad statements discussed early, such as reliability, usability, maintainability or compliance. Acceptance criteria translate those expectations into a prioritised list of measurable conditions for the final product. Component quality criteria are more detailed specifications used to review individual products. Mixing these levels can leave teams testing components without knowing whether the integrated product is acceptable.

Control guidance

Scope, criteria and tolerance

Scope is the total set of products and the extent of their requirements. A product breakdown structure shows the product set; the associated descriptions show depth and acceptance. Scope tolerance defines a permitted deviation from that baseline before escalation is required. It must not be used to avoid necessary change control or to accept a product that violates law, safety, contract or mandatory criteria.

A good quality criterion is specific enough to verify, linked to the need it protects and paired with a method. 'Easy to use' is an expectation; 'a trained operator completes the defined transaction without assistance in the agreed test environment' is closer to a criterion, but the actual threshold and population must be agreed for the project. Criteria may be qualitative when expert judgement is appropriate, provided the reviewer, method and decision rule are still defined.

Quality tolerance states the permissible range around a criterion. It differs from an undefined concession. A tolerance is approved in advance as part of delegated authority; a concession is a decision to accept an off-specification after impact assessment. Tolerance should never be invented from an illustrative source value.

Control guidance

Quality planning

Quality planning establishes the quality management approach and schedules the activities needed to produce evidence. It identifies applicable organisational systems, external obligations, standards, customer expectations, responsibilities, review methods, test environments, sampling, tools, records, nonconformance handling and assurance. It also explains how quality information will enter progress, risk, issue and change control.

Plan quality early enough to affect design. Inspection at the end cannot compensate for missing criteria, unsuitable interfaces or an untestable product. Product-based planning helps by creating descriptions before estimating and scheduling work. The team can then include review preparation, independent checks, test data, rework allowance and approval lead time in the stage and work-package plans.

Lessons should inform criteria and methods. Earlier defects may reveal a weak interface, ambiguous wording, inadequate test environment or late user involvement. The lesson should change the current product description or quality approach, not merely be cited in a log. Quality responsibilities also need capacity: a named reviewer who is unavailable at the required time becomes a schedule risk.

Control guidance

Quality control and product approval

Quality control checks whether products meet their criteria through review, inspection, test, demonstration, analysis or another approved method. It identifies defects, confirms completion and produces records that support approval. The producer should not be the only reviewer where independence is needed. The approver decides whether the evidence is sufficient and the product satisfies the authorised description.

Quality status must be linked to a specific product version. A passed test on an earlier configuration does not automatically approve a modified product. Configuration control identifies the version, status and relationships between products. When a baselined product changes, the impact assessment must determine which reviews or tests need to be repeated and which downstream approvals may be invalidated.

A quality register records planned and completed quality activities, dates, results, responsible people and references to evidence. It should not duplicate detailed laboratory or technical records; it provides the project-control view and traceability. Progress reporting should distinguish products not started, in production, under review, approved, accepted with concession and rejected.

Control guidance

Approval, acceptance and assurance are different

Approval confirms that a component product meets its description and can be used as intended in the project. Acceptance confirms that the final integrated project product meets the agreed acceptance criteria and can be handed to the customer or operational owner. Approval may be performed many times by technical or user authorities; final acceptance is a defined project decision and is required before normal closure unless premature closure follows a different disposition.

Project assurance assesses whether the project's quality planning and control are appropriate from business, user and supplier perspectives. Quality assurance provides confidence to the wider organisation that relevant quality systems, policies and standards are being followed. Neither replaces product verification. A process audit can show that a test procedure was followed; it does not by itself prove that a particular product passed its acceptance criteria.

Acceptance must include operational readiness where the product cannot deliver value in isolation. Handover information, training, maintenance, support, permits, spares, data, security or transition actions may be separate products or acceptance conditions. Define them early so technical completion is not mistaken for readiness to use.

Control guidance

Control defects, off-specifications and concessions

A defect is a quality finding that may be corrected within authorised work. An off-specification is a product that is forecast or known not to meet its approved description. It is a formal issue because it can affect scope, quality, benefit, risk, cost or schedule. The project manager captures it, verifies configuration, assesses impact and proposes options. The authorised decision-maker may require correction, grant a concession, modify the product description through controlled change, defer a decision or escalate if tolerance will be exceeded.

A concession records acceptance of the specific deviation and any conditions. It should identify the product and version, unmet criterion, rationale, impact, residual risk, affected interfaces, owner, validity period and follow-on action. It is not permission to ignore similar defects on other products. Repeated concessions may indicate weak requirements, inadequate capability or a deteriorating business case and should be analysed as a trend.

Corrective action should address both product and cause when useful. Immediate rework may restore compliance; a process change may prevent recurrence. The team should update the quality register, issue record, configuration status, forecast and lessons. Changes to acceptance criteria need the correct user and business authority, not only technical agreement.

Control guidance

Worked example and readiness review