Handling open points in design reviews

[v9991]

1. for performing a design review, should we have the document in signed off form?
or can we perform design review on 'draft' version of document

2. how do you handle the open / review points from design review., i.e., how and where do you justify for having them open for a given stage.
viz., certain closure/response to "MAUDE database related points" in design inputs is dependent on update from supplier of device component.
hence it could be parked for closure before design validation or commercialization. ( where should i document the justification that it does not affect other aspects of design control activities. viz., design verification, design output, etc)

 

[somashekar]

As there can be several design review stages as may be determined, the document in any form could highlight the closed and open points, and these are going to be addressed in subsequent reviews. Any justification could also get into the design stage review records.
What actually do you mean by 'draft' version of the document...

 

[v9991]

Thank you Somashekar for quick response,
so, we need to add justification/rationale of target timeline of open points , right in the design review.

What actually do you mean by 'draft' version of the document...

viz., when we have to do design review for 'design input' stage,
should the design input document be at draft stage or should it be signed off.

 

[somashekar]

Since records of review will be looked up as design progresses, any specific authentic information in it will be of use.
About design inputs, I believe it should be signed off at some point of time after which the reviews can happen.
However since design projects could be over months to year or even more, at times there would be a need to update the design input document. This would be the next revision.
It does not auger well to say that the design inputs are not freezed (draft) and the design stages are in progress.

 

[yodon]

I don't think it's uncommon to include a draft document in a design review. The catch is that you need to be sure that no changes are made other than those driven by the review; otherwise, you would invalidate the review.

Not sure I completely understand the 2nd question. It sounds like you identified some design issues but agree that it's ok to not address them until some later point (if at all). I would definitely capture (document) the issue and document when it will be addressed and why it's ok to defer. If you have to release with the known issue, it would have to be justified based on a risk assessment.