Design & Development, Made Simple

There seems to be a lot of confusion around recognising when design and development is, or is not a part of the management system and with regards to the latter - if the non-applicability of the requirement can be justified. I can say that from personal experience a lot of Auditors either shy away from this clause or simply don’t do it properly, historically myself included! But when broken down into smaller steps, is it really as daunting as it seems?

First let’s begin by looking at the terms and applying their meaning into context of the standard:

Design

The definition of design is “a plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is made.” Simply put into context; if the organization are creating something; be it tangible (product) or intangible (service), there will almost certainly be an element of Design.

In such cases, the application of clause 8.3 shall be implemented. Even if the client “does not design” anything physically themselves and they outsource the process - the responsibilities cannot also be outsourced, the organization have to apply the necessary controls (see clause 8.4.1-a). The point to remember is - who’s paying for it?

Development

The definition of development is “the process of developing or being developed”. Not a particularly useful definition when applied to the standard! However, here are a few ‘real-life’ examples that you may have come across whilst auditing... An organization provides an existing product or service but need to make changes to enhance the performance or to meet a customer’s specific requirements; this is development.

Another organization may be defining acceptance criteria through trial and error; again, this is development. You may visit an organization that has an established process but they have needed to tweak it to achieve a different, or better result... You guessed it - development.

Non-applicability and justification

It goes without saying, but if the organization are conducting any of the activities mentioned above; then they cannot justify the non-applicability of “Design and development of products and services” in their management system. An example of when this might be possible would be if the organization are providing a product or service that is well-established or its design is fixed and requires no further amendments or development.
 
I was at an audit not long ago where the client had excluded clause 8.3 from their management system. Their justification was that they were “making the product fit the customer’s requirements”; they were modifying the characteristics of the product to meet the customer’s requirements for their intended application. Whilst the product itself never actually changed, they were taking an existing formula and changing the specification in order to meet the client’s requirement - sound familiar?

This is development. It is important to remember that all design and development starts with an ‘input’ (more on this below) and just because that input comes from an external source, it doesn’t mean that the organization are not responsible for the control of the design and development of products and services process.
 
The long and short of it is that if the organization “uses resources to transform general input requirements for an object (tangible/intangible) into more detailed output requirements for the object”, then they’re either designing or developing. (Ref: ISO 9000:2015)
 
The process for auditing is simple, there are five steps which must be considered:

Planning - simply put, the organization will have a plan on how they will do the design and development. Good examples of this would be - A design/development plan which demonstrates: the project timescales, deliverables, responsibilities of team/individuals, persons of authority for sign-off (internal, or external customer), design reviews at relevant points in the project (e.g. start, confirmation of inputs, post verification, post validation, finish, etc.), resources required throughout the project, communication with subsequent process owners, and required controls throughout the project and intended use of the output. Remember the 6 P’s...

Inputs - there are a multitude of potential inputs to the process: have the organization confirmed the requirements from the customer (what do they want to achieve and what are their needs & expectations) and considered parameters & constraints (e.g. materials, dimensions, functionality, life cycle, sustainability, etc.), have statutory and regulatory requirements or codes of practice been considered (product and safety directives, building regulations, CDM, ACoPs, etc), availability of information from previous designs (review of learnings - good/bad/potential improvements, etc.) which provide priceless data and knowledge to mitigate the risk and consequence of failure.
 
Controls - A critical step in the process: have the organization determined how results to be achieved are defined - what are the project deliverables, how will they be achieved and how will they be measured (acceptance criteria). Have reviews been conducted throughout the project as mentioned above at relevant points in order to to meet the input requirements?

Verification - has the product/service as designed/developed as intended in relation to the input requirements, this can be reviewed through different types of testing (e.g. prototype, proof, demonstration, inspection, analysis or acceptance).

Validation - has the product/service been designed/developed that it fulfils the requirements of its intended use, most likely reviewed once the deliverables have been achieved. For example: testing under operating conditions, in order validate that the product/service meets the customer’s requirements and covers all outputs, including potential risks of use. Conducting reviews post verification and validation in order to iron out any potential issues - these are all critical requirements of design and development controls and must be documented in some form.
 
Outputs - have the organization met the input requirements (achieved the intended results), can they move forward in the project using the outputs, have they confirmed any necessary equipment for measuring and/or testing and the acceptance criteria. Typical examples of such outputs include: conceptual designs, technical/engineering drawings, product specifications, manufacturing instructions, bill of materials, information for purchasing and other subsequent processes.
 
Changes - have the organization established a formal process for controlling design and development changes; throughout the project and during reviews, how have changes been documented, the results of design and development reviews communicated. How are changes authorized (think about the persons of authority, as above), how can most up-to date revisions be identified and mitigate the risk of using superseded versions? Examples of this include: version/revision/authorization control on drawings, a design/drawing register, engineering change notes, etc.
 
Specific documented information is required by the standard at relevant stages of the design and development process in order to demonstrate conformity.
 
In summary, we don’t all have to be experts in conceptual/engineering design and development to understand the requirements and how to effectively audit them. As long as we follow our own process - as above, and apply a competent interpretation of the standard, yet flexible in relation to the context of the organization, then this clause is actually a lot more straightforward than what it seems.
 
Authored by Alan Michael Gould - NQA UK Regional Assessor