ISO 9001:2015 - Clause 8.

3 - “Design and
development of products and services”; the most
dreaded auditable clause in the standard, but
does it have to be?

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?

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.

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.
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.
 
ISO 9001:2015 CLAUSE 10 IMPROVEMENT

Occasionally undesired things occur; now it’s time to address nonconformity and
corrective action. And to make things better there’s a continual improvement. The
requirements here are familiar and well understood. But what about preventive action? It
does not appear. As some have argued for many years, one of the objectives of a
management system is preventive action. The requirements in clause 4.1 to “…determine
external and internal issues that are relevant to its purpose and that affect its ability to
achieve the intended outcome(s) of its Quality management system” and in clause 6.1 to
“determine the risks and opportunities that need to be addressed to assure the Quality
management system can achieve its intended outcome(s); prevent, or reduce, undesired
effects; achieve continual improvement.” not only address preventive action but go beyond.
And in the end, auditors will look back at the management system established in clause 4.4,
reviewed in clause 9.3 and now continually improved. Finally, although there remains a
requirement for processes, there is no mention anywhere of procedures, documented or
otherwise. If a discipline considers that they are required then they will appear in clause 8
– Operations. However, if they are not a requirement but the organization themselves
consider they need them then that will be their decision