8.3.2 Design and development planning
When tackling this clause, it is important to clearly identify how and where it is applicable within your organization to avoid confusion. For example, last week we discussed how many organizations do not actually do any type of design or development of their product/service, but may defer to their customer’s design. But, we also discussed that while we may not do product design, we do design our processes for our QMS and “product realization” or order fulfillment, and therefore, we do, in fact, have a design process of sorts.
The design process may be the same for both types of design, or they may be quite different. Designing a process may be (or may have been) a one time thing when the organization was established. There may be periodic reviews of the process to look for opportunities for improvement. And the organization may choose to employ the same process should additional products/services be added to their offerings. However, design of a process may differ significantly from design of a product/service, and these two ideas should therefore be addressed separately, depending on the complexity of both processes.
In any case, the requirements are these:
“In determining the stages and controls for design and development, the organization shall consider:
a) the nature, duration and complexity of the design and development activities;”
Again, there is no longer an option to “exclude” this requirement, even if the organization does not design its products/services, there is an expectation that some type of design process be defined for design of processes.
“b) requirements that specify particular process stages, including applicable design and development reviews;”
This may be very simple or complex depending on its applicability (what is being designed)
“c) the required design and development verification and validation;”
This is obviously a very important requirement in design, because every design should be verified and validated.
“d) the responsibilities and authorities involved in the design and development process;”
e) the need to control interfaces between individuals and parties involved in the design and development process;
f) the need for involvement of customer and user groups in the design and development process; ”
As in any process, responsibilities and interactions should always be clearly defined to ensure the integrity of the process. And finally,
“g) the necessary documented information to confirm that design and development requirements have been met.”
This is a reference to what type of records will be kept, and it is at the discretion of the organization to define this for themselves (in the absence of regulatory, statutory or customer requirements).
THIS WEEK’S HOMEWORK
First, take a look at your current QMS structure. Did your organization previously “exclude” the design clauses? If so, it’s time to get to work defining a design process that would be applicable to the design of processes within your organization. It needn’t be complicated, wordy, over-documented or cumbersome. But it should clearly lay out the steps that you and your organization would determine to be appropriate to your needs. Be sure to address each of the bulleted items above and you’ll have what you need to ensure your compliance.
If your organization did historically have a formal design process, be sure these requirements are all included. And also have a look to see whether that design process would apply to the design of processes as well. Make modifications where necessary.
And finally, do a quick check of your “documented information” to ensure you’re following your system and everything is in order. Good luck!
