8.3.4 Design and development controls
Hello Readers! It’s been a very busy summer and last week, an on site client project consumed the week before I knew it had gotten away from me! So, this week, we have a double edition, talking about 2 sections, “8.3.4 Design and development controls” and “8.3.5 Design and development outputs”. Please enjoy this week’s topics.
Well, this is more like it! Straightforward and nothing much to debate about. The entire section on design and development is very easy to understand and structured in a sensible way for the organization to understand and implement processes for compliance, and for the criteria to be clearly understood in terms of evaluation criteria. Let’s get right to it. The section reads:
“8.3.4 Design and development controls
The controls applied to the design and development process shall ensure that:
a) the results to be achieved by the design and development activities are clearly defined”
This points right back to “inputs” in that the results should clearly be understood before an effective design can take place.
“b) design and development reviews are conducted as planned;”
This was defined in the “inputs” phase, but it is listed here again to ensure the proper controls are actually implemented in the design process.
“c) verification is conducted to ensure that the design and development outputs have met the design and development input requirements;”
Again, I really like the point by point connection between defining the requirements and then following up and meeting them, and being sure to have controls in place to monitor it along the way.
“d) validation is conducted to ensure that the resulting products and services are capable of meeting the requirements for the specified application or intended use (when known).”
This can be a sticky issue and requires a well defined and well disciplined relationship with the customer. Not only must the specifications be met, but the intent of the product/service as well. I know I’m not the only one who has experienced a successful launch of a product which completely met specification, but did not perform as intended, meet up with a mating part, match an adjacent component in color/texture, etc until the validation phase.
And now we’re onto “8.3.5 Design and development outputs
The organization shall ensure that design and development outputs:
a) meet the input requirements for design and development;”
It’s important to note the cascade effect this section creates as it lists its criteria. Inputs are defined. Controls for the inputs are created. And outputs are evaluated to ensure they meet the original inputs. A closed loop system including inputs-controls-outputs will ensure this is compliant.
“b) are adequate for the subsequent processes for the provision of products and services;”
This begins to shed light on a very important part of design and development, and that is feasibility in “real life”. Many products have been successfully designed and validated, but after a team of engineers completes the process, there is sometimes an awkward handoff of the project to operations and quality personnel who, without intimate involvement in the design process, may have to fumble through setting up a production and control plan. Having one of the required outputs from design be that the outputs are helpful in the provision of those products/services is a great way to bridge that gap and provide a smooth transition.
“c) include or reference monitoring and measuring requirements, and acceptance criteria, as applicable;”
This too is important that the intent of the design be carried through the lifetime of a product/service to ensure the monitoring and measuring requirements support the ongoing suitability of the product/service.
“d) ensure products to be produced, or services to be provided, are fit for intended purposes, and their safe and proper use. ”
This is more of the same language to ensure that the product or service not only meet the specifications, but that it meet its intended use (and is of course, safe).
“The organization shall retain the documented information resulting from the design and development process.”
This is a clear call for records of all phases of the design process.
We noted a couple of weeks ago, the importance of a design process overall. Whether the design process apply to a specific product/service, or a provision or realization process, it is important to ensure we tick all the boxes and people work together to not only accomplish their part of the process, but to ensure that as responsibilities are transferred from one area to the next, that the original inputs and intents stay consistent from beginning to end. I think the language here is clearly written and easily understood and implemented.
THIS WEEK’S HOMEWORK
Take a final look at your design process (being sure to once again consider whether there is more than one process applicable to product/service v process). Are all inputs-controls-outputs in place and compliant? Now, look at your records or “documented information” and ensure there is evidence to support the requirements defined here. Good luck!
