Design/Change Control Procedure - How to cope with Changes during Development?

Aphel

Involved In Discussions
hello everybody,

Meanwhile i have read a lot about the requirements regarding change control, but it is difficult to find a practical way for realising them.
According to QSIT the change control procedure or procedures must meet "pre-production design changes" and "post-production design changes".
So the first requirement means design changes during the development of a medical device, the second requirement means design changes after the development has finished and the product is launched to the market.

We established a change control procedure for post-production changes, but not for changes during the development. Management is of the opinion, during the development of a product we have to stay "flexible" without strong rules for changes... At the moment i have no idea, how i can create a simple and effective, but also correct procedure for that issue.

What are your experiences with changes during development, how do you cope with the daily problems? How do you meet this requirement of §820.20?

Thank you very much for your help and your answeres!

best regards,
Aphel
 

harry

Trusted Information Resource
Re: design change control procedure

Welcome to the Cove.

Pending replies, please scroll down the page to see discussions on the same in the 'similar discussions' box.
 
T

The Specialist

A method of control which provides ‘flexibility’ is:

During product development phase, simply provide a ‘change history’ that can be noted on (e.g.) drawings/documents etc. as an interim to full revision e.g.:

(THIS IS ONLY AN EXAMPLE!)

‘Draft’ product drawing is hand-marked and notes added to reference each change

Revision A of the drawing is produced at a time that major product design decisions have been made (milestone). This drawing can continue to be ‘marked-up’ in the same manner as the draft, using a 'change history' table/section on the drawing

Revision B (c, d etc…) can be produced to incorporate marked-up changes as they are agreed and determined (successful through review etc)

Revision 1 is produced at a point in time when you initiate a ‘Design Freeze’

At this point… start to control the drawing (or document) using change control process (where minimal/less frequent changes are likely to occur) and up-rev to ‘Revision 2’ when changes have been made.

Alternatively, if major reviews and re-design is required (for whatever reason as detailed in the change control) you can revert to ‘draft/history control’ method introducing:

Revision 1a, 1b, 1c… etc until you are ready to re-freeze design at Rev 2, where you would again make changes through the change control process.
 

Pads38

Moderator
Thanks Specialist, that re-confirms our approach as well.

As Aphel suggests trying to control designers is like trying to herd cats!

I think that the key thing in all controlled development is that of traceability. That is being able to show how a requirement that is shown in the original specification is tracked through development to the eventual verification.

We have key documents, such as the product specification, device hazard analysis, software requirements spec etc that each have a "Document History" box at the end which is used to show the difference between each revision and eventual issue. It is relatively painless.
 

somashekar

Leader
Admin
Thanks Specialist, that re-confirms our approach as well.

As Aphel suggests trying to control designers is like trying to herd cats!

I think that the key thing in all controlled development is that of traceability. That is being able to show how a requirement that is shown in the original specification is tracked through development to the eventual verification.

We have key documents, such as the product specification, device hazard analysis, software requirements spec etc that each have a "Document History" box at the end which is used to show the difference between each revision and eventual issue. It is relatively painless.
Without stopping the innovative and the curious research kid from his applications, you have to look at the design review stages and put a freeze level in your (draft) provisional documentation say P1 and continue with this steps from P1 to P2 >> P3 >> Px until release and get that to say level 00. From then on it becomes your ECN process that takes it to levels 01 >> 02 >> xx
Each freeze level can have a minutes of meeting of design and development review.
All the Px's will constitute your design history.
 

yodon

Leader
Super Moderator
I like to look at the problem from the perspective of impact. If you have a downstream stakeholder (e.g., internal 'customer') that is making decisions and taking direction based on what you provide them, then if you don't control those changes, you're going to pull the rug out from under them. If you have no downstream stakeholders or if they aren't making decisions based on your material, then you can defer the change control process.

I like to take a software example to illustrate the point. Say you have 2 groups working on independent portions of the software and they have a communication interface. They're free to change all they want within their independent code areas but if they need to change the interface, they need to do so in a controlled manner to ensure the other group can continue to communicate with them. The interface has to be controlled at an earlier stage than the independent software portions.
 

sagai

Quite Involved in Discussions
Very much agree with somashekar.
In a very very extreme case, you can have only one revision at the time of the one and only design review just prior design transfer to manufacturing.
So, it is depends on you, how to specify milestones and design review points.
br
Sz.
 

Aphel

Involved In Discussions
Hello everybody,

Thank you for all the answeres and guesses...

The problem i have, is not to control changes in single documents (e.g. drawings), therefor we have a nice procedure (document controls).

But what are your solutions (procedures) if you have for example the following change during development:

Imagine, you just went through the milestone design freeze, you have already startet design verification. And now - during design verification you realise, that you are not able to pass a certain requirement and you are forced to make a change to a functional design input requirement.

What are your design change procedures saying in such cases?
How do you organise, manage and document such necessary changes?


Best regards,
Aphel
 

sagai

Quite Involved in Discussions
Imagine, you just went through the milestone design freeze, you have already startet design verification.
Fine.

And now - during design verification you realise, that you are not able to pass a certain requirement and you are forced to make a change to a functional design input requirement.

When "you are not able to pass a certain requirement" means there is a missing implementation of the already existing requirement. It is a "normal case", there is no problem with that, this deviation logged and as part of the resolution of this problem it will we implemented, than re verified.


I have an interpretation problem with this:
"not able to pass a certain requirement and you are forced to make a change to a functional design input requirement"

Is it means, instead of implement the requirement, you are about to remove the corresponding functional design requirement?

Actually, for me would be good to understand to relation between "requirement" and "functional design input requirement".

br
Sz.
 

Aphel

Involved In Discussions
Hello,

o.k., i will try to explain it another way.

During design verification you are doing a lot of tests.
Sometimes you have situations, when a test fails for example due to
incorrrect product design. Then you must change the product design to
pass the test.
Or during design validation you have a problem that shows, you are not able meet certain customer requirements. This problem also may lead to a design change, so that you are conform to customer requirements.
I was talking about these kind of design changes.

Are my guesses too theoratically - then i will try bring up an example...

Again, thank you very much for your help...

Best regards,
Aphel
 
Top Bottom