A design and development plan has to name interfaces

What the plan has to document, not just schedule

Clause 7.3.2 requires an organization to plan and control the design and development of a product, and to maintain design and development planning documents that are updated as the work progresses. It names what those documents have to establish: the verification, validation, and design transfer activities appropriate at each design and development stage; the responsibilities and authorities for design and development; the methods used to ensure traceability of design and development outputs back to design and development inputs; and the resources needed, including the competence of the personnel involved. A plan built as a calendar of milestones can satisfy a project manager without satisfying the clause, because none of those four items is a date — each one is a decision about how the work will be checked, who answers for it, and how a later reviewer traces an output back to the requirement that produced it.

Interfaces are the item a schedule leaves out entirely

The clause adds one more requirement a scheduling tool has no native place for: the plan has to identify and describe the interfaces between the different groups or activities that provide, or receive, input to the design and development process. A device's design rarely comes from one function working in isolation — manufacturing engineering, clinical, marketing, and risk management each hand something into the process at a specific point, and each handoff is a place a requirement can get lost in translation if nobody owns it. Naming a phase gate on a Gantt chart doesn't say who from manufacturing has to sign off before a material spec locks, or when clinical's input on labeling has to land relative to design freeze. That's the interface the clause is actually asking a plan to describe.

Resources and competence belong in the plan, not a staffing afterthought

The fourth documented item — resources needed, including the competence of the personnel involved — is easy to treat as outside the plan's real scope, something HR or a project sponsor handles separately from the design-controls paperwork. Clause 7.3.2 doesn't leave it that way. If a stage requires a specific competence a project doesn't currently have on staff — a biocompatibility reviewer, a specific software verification skill, a particular test method's operator qualification — the plan is where that gap has to surface, before the stage that depends on it arrives rather than during it. A plan silent on resources hasn't left out a detail; it's left out one of the four things 7.3.2 requires the document to establish.

The plan sets up the reviews, without conducting them

The plan's job is to identify design and development stages and the review points within them — it decides when a review happens, not what has to happen inside one. Clause 7.3.4's own design review requirement runs “in accordance with the planned arrangements” 7.3.2 sets out, which means a review scheduled outside the plan, run because someone remembered a milestone was coming rather than because the plan called for it at that stage, has already drifted from the structure the clause assumes. The plan is upstream of the review the same way it's upstream of every other design-control activity that follows it.

A plan that doesn't get updated stops being the plan

Clause 7.3.2 requires the plans themselves to be reviewed, updated, and approved as design and development evolves — not filed once at kickoff and left to describe a process the project has since outgrown. A scope change, a new intended use, a supplier substitution discovered mid-project: each one can shift which stages still make sense, which interfaces still apply, or which activities a later stage now depends on. A design history file that still shows the original plan next to activities that clearly departed from it has a gap an auditor doesn't need much help finding.

Where this meets the rest of the file

Everything downstream assumes 7.3.2 already ran: design inputs get determined against the responsibilities the plan assigned, verification and validation happen at the stages the plan named, and design transfer and later change control both inherit the traceability method the plan defined at the start rather than invent one after the fact. A design and development plan template built around 7.3.2's four documented items, the interfaces requirement, and a defined path for re-approving the plan itself is previewed in the launch catalog. If your program plans a design differently, the shelf takes that correction directly.