Who should define and own the Design and Development Plan and how to maintain the updates and revisions.

[v9991]

1. per my understanding, it should be owned by "project / program manager", and shall be defined in consultation with the key stakeholders ( viz., technical lead and regulatory etc); also certain references.,
https://alvintai.com/wp-content/uploads/2015/01/Design-Control-SOP.docx

2. as these documents are alive and evolve with the product development, there are two options
a. to revise and version them through the life cycle. ( with appropriate change management/controls from set stage viz., D.Input can be updated without change control till Design Verification Plan; but any changes later should be put through formal change control)
b. to update through addendums, and integrate the details at a set milestone viz., for D.Input, integrate before Design verification.

per my understanding, 2.a is right choice. as per FDA's guidance.
https://www.fda.gov/media/116573/download

Eventually, the design input must be reviewed for adequacy. After review and approval, the design input becomes a controlled document. All future changes will be subject to the change control procedures, as discussed in Section I (Design Changes)

pl guide with clarification and reference

 

[yodon]

There's nothing prescriptive about who should "own" (or even approve) the Design & Development Plan. Obviously it should be coordinated with applicable stakeholders and generally the project manager is probably in a good position to do so - so the project manager is probably a good choice but not required.

I got a little lost on your second question. The Design & Development Plan is independent from the other documents (e.g., Design Inputs). The Design & Development Plan should, indeed, be updated as the project progresses. The means for update are not specified. Once approved, though, updates should (per basic Document Control requirements) be approved by the same roles that approved the original (there are a few caveats but that's the gist).

The question of when to put things under change control is always a difficult one to answer. To me, design inputs provide the foundation for the rest of the work so I push for the initial baseline (approval) early. Changes to the Design Inputs always have a ripple effect and if those aren't managed well, you can end up in chaos. If you're informally modifying design inputs, you could end up with developers going in the wrong direction.

 

[Ronen E]

The question of when to put things under change control is always a difficult one to answer. To me, design inputs provide the foundation for the rest of the work so I push for the initial baseline (approval) early. Changes to the Design Inputs always have a ripple effect and if those aren't managed well, you can end up in chaos. If you're informally modifying design inputs, you could end up with developers going in the wrong direction.

Maybe straying off topic, however -

I think control over changes (in contrast with "change control") goes without saying on pretty much everything once you go under Design Control, which is normally when "research", "feasibility", "proof of concept", "market probing" and all that jazz ends (there should be a formal, documented cut-off). I couldn't agree more about Design Input changes. The really hard question (and one a lot of orgs are pondering) is when to start applying the regulatory element "Design Change", i.e. when to start applying the Design Change SOP or WI.

The approach I usually follow is: after the successful conclusion of the first Design Verification round (i.e. after its Design Review). If that round is unsuccessful (i.e. some design elements need changing, including possibly some design inputs) the design should still be considered "liquid", and the initial design development controls should suffice. I think this is important, so as to not over-encumber the initial design/engineering work with processes that consume resources, slow down progress and add little value overall.