ISO 9001 clause 8.3.2: plan design around its complexity and interfaces

What clause 8.3.2 requires in practice

This clause requires you to decide how a design activity will be run before the work gathers pace. When setting the stages and controls, the organisation weighs ten matters. They include how complex and long-running the work is, which review points and which verification and validation activities are needed, and who holds responsibility and authority. They also include the internal and external resources required, how hand-offs between the people involved will be controlled, and whether customers or other interested parties should take part.

Planning must also look ahead to how the product or service will later be provided, how much control customers and others expect over the design process, and what documented information will show that the design requirements were met. The clause does not dictate a sequence of stages. It expects a plan proportionate to the work, and the output is a considered set of stages, controls, roles and evidence expectations that the team actually uses.

Choose stages and controls for the work

Consider the design's complexity and the information likely to become available as it progresses. Identify appropriate review, verification and validation activities. These have distinct purposes, even when combined within one practical activity. Planning should ensure that necessary decisions occur when they can still influence the result.

The standard does not require one development methodology. Iterative cycles can be suitable, provided the organisation understands how requirements, evidence and decisions remain connected. A planning approach should describe actual working arrangements rather than a formal sequence that teams routinely ignore.

Why design planning matters to the business

Design problems are cheapest to fix when they are still ideas. A design effort with no agreed reviews, owners or customer touchpoints tends to surface its misunderstandings late, when rework is costly and delivery dates are already promised. Sound planning protects margins, keeps external partners and internal teams aligned, and gives customers confidence that their involvement will be sought at the right moments. It also shapes audit outcomes: an auditor who sees a plan matched to the real complexity of the work, and records showing it was followed, will usually find little to challenge. A plan that exists only on paper invites questions about whether control is real.

How to implement clause 8.3.2

The aim is a plan that fits each design project, rather than one template applied to every job. One practical route follows.

1. Classify the design work by novelty, risk and number of parties, so that simple changes and complex developments receive different levels of planning.
2. Break the work into stages and decide where reviews, verification and validation naturally belong, noting what question each will answer.
3. Name the person accountable for each stage and the authority to approve moving on.
4. List the internal skills and outside inputs needed, including any supplier, laboratory or specialist, and confirm they will be available when required.
5. Identify the points where teams or organisations hand work to one another, and agree who owns each interface and how issues are raised.
6. Decide where the customer or another interested party should be consulted, and what level of oversight they expect.
7. Record what evidence will show requirements were met, and revisit the plan when scope or risk changes.

Illustrative software example: a customer integration

Illustrative construction-service example: coordinated design information

A hypothetical consultancy designs an interior layout with several specialist contributors. Each discipline has its own programme, but the combined plan does not identify when conflicting requirements will be reviewed or how the client will confirm relevant use needs.

The consultancy establishes suitable coordination points, assigns authority for resolving interfaces and plans reviews before downstream information is issued. It also considers what the subsequent delivery team needs from the design outputs. Technical and statutory design decisions remain with suitably qualified people; the QMS example concerns planning the responsibilities, information and evidence around those decisions.

Provide resources and clarify authority

Design may require internal and external resources, including specialist knowledge, tools, test capability and time for review. Consider their availability in the plan. An activity scheduled without the necessary people or information may create an apparent milestone that cannot be achieved meaningfully.

Assign responsibilities and authorities for relevant design decisions. People need to understand who produces information, who evaluates it and who resolves a disagreement. Where several organisations contribute, clarify the interfaces rather than assuming each party understands the other's process.

Plan customer involvement and downstream use

Customers and other relevant interested parties may need to contribute information, review proposed results or participate in validation. Determine the involvement appropriate to the design and relevant requirements. Their participation should be planned sufficiently early to avoid treating an unresolved need as a late surprise.

Consider subsequent provision of the product or service. Production, implementation, support or other downstream processes need usable outputs. The level of control expected by customers and other relevant parties can also influence planning. Do not assume the development team's preferred method is automatically sufficient for every commitment.

Plan evidence without creating unnecessary paperwork

Common nonconformities with clause 8.3.2

Auditors usually find weaknesses where planning is thin or ignored.

• Design projects run with no defined stages, reviews or responsibilities, and staff cannot say who approves progression.
• The plan lists tasks and dates but says nothing about verification or validation, so the intended-use question is never planned for.
• Interfaces with outside designers or customer teams are left uncontrolled, so that conflicting versions arise of information.
• Plans are written once and never updated, although the project scope has visibly changed.
• No evidence exists that customer involvement expectations were considered.