Benefits of ISO 9001, Part 7: Clause 8.

3 on
Design & Development
Posted by Christopher Paris | Jan 7, 2020 | Guidance Document
[This series of articles tries to emphasize the benefits of ISO 9001, and how to yield results from each major
clause of the standard.]
Overview
The “Design and Development” clause was previously understood to refer only to design of products. This
was true from the 1987 edition through until 2015, and decades of official accreditation rules were created and
upheld, allowing companies that don’t design product to exclude the clause as not applicable. Those rules still
exist, but ISO 9001:2015 confused matters by adding the words “… and Service” to the title of the clause,
without then adding any specifics on the design of services in the text itself. ISO 9001 authors admitted they
simply edited the title, thinking that was sufficient. (Sigh.) This has led folks to get confused: can you exclude
it at all, now? If you don’t design product, and merely build to the customer’s print, isn’t doing so technically a
“service” that needs to be designed?
The answer is complicated, and ISO hasn’t resolved the conundrum yet. See what I wrote about that
problem here.
For the context of this article, however, let’s assume that you — at the very least — design product. Perhaps
you may want to opt to apply this to the design of services, as well, and that’s entirely up to you.
Clause 8.3.1
The first sub-sub-clause is simply an introductory paragraph that requires you to implement a “design process”
as you see fit. Keep in mind, regardless of ISO 9001 suggesting this be a “process” (singular), you can opt to
split design activities into multiple processes (plural) if you choose to. Ignore their prescriptive wording here.
Otherwise, there’s not much to worry about in this introductory clause, so we can move on.

Clause 8.3.2
The standard then goes on to give a fairly detailed list of things to consider when starting any design activity,
through an initial planning stage. Full implementation of this goes beyond the scope of this article
(read Surviving ISO 9001 instead), but you should first decide if you will have a single “design plan” for all
your products and services, unique design plans for each separately, or a combination thereof. Whatever path
you choose, the bulleted list provides critical things to consider when developing this plan.
The standard does not require the design plan(s) to be documented, but this is obviously a good idea. Failing to
do so ensures the design plans will be ignored a few minutes after you finish them.

One point: the bulleted list appears like a list of requirements, but the leading sentence says that these are
things to “consider.” That work makes the entire list optional, so use whatever suggestions here you like, and
throw out the ones you don’t. I don’t think any are unnecessary, but some are redundant with other QMS
aspects (such as the callout for resources), so you may not have to consider them a second time during design
activities.

Clause 8.3.3
Design and development “inputs” are merely the intended requirements for the final product or services: what
is it supposed to do? Look like? Be made of? Those things.

Any design engineer will tell you that getting the requirements (inputs”) right is critical, and failing to so will
doom your product before you ever start building it. Take your time here. Don’t only rely on what you think
the product should do, but find out what the customer’s expectations are; analyze the “use case” of the product,
meaning the usage of the product from the user’s perspective.

Then go back and check your prior designs, to see if you can learn anything from those that would inform the
new design. Check statutes and regulations, industry standards, specifications, etc. Get data on competitors’
similar products, to make sure yours is better. All of this information is critical before you put pen to paper on
the actual design work.

The process is similar when designing services; gather as much information as you can on what  you want the
service to accomplish, the customer’s expectations, etc.

Clause 8.3.4
With the design plan and requirements in hand, it’s time to start designing. Here older versions of the standard
were clearer to understand, even if they adopted a “waterfall” design model that some have evolved past. The
new standard just throws a bunch of design ideas in a list, and hopes they stick. They no longer explain, for
example, what they mean by design verification vs. validation.
 The upside to this chaos is that you have additional freedom to plot your design process how you like. Whether
it’s Agile, Waterfall, Hybrid or something else, no matter what you do it will likely comply with ISO 9001
now.  The downside is that if you aren’t a design engineer, you might not know where to start, and the standard
isn’t going to help you in that. (Again, the details are way beyond the scope of this article, so you’ll have to
read my book … or someone else’s, if you’re not fussy.)
Just be sure that whatever design protocol or method you adopt, you are touching on the concepts raised by the
bulleted list in 8.3.4.

Clause 8.3.5
The standard then moves onto what it calls the design “outputs,” meaning the actual thing that is created which
defines the design. This could be a drawing, print, 3D model, schematic, specifications, bills of material … you
name it. Under “Industry 4.0,” the idea of a blueprint being the final design output is no longer true, and much
of the outputs are purely digital, existing in 3D and sometimes even 4D (considering time as the fourth
dimension.) It’s heady stuff these days, but also incredibly fun and exciting.

At the very least, your design outputs must present the design in a way that it can be built (for products) or
delivered (for services), and that the resulting product or service can be inspected or tested afterward. That
means defining inspection or testing criteria, for example.

Clause 8.3.6
The final section of the Design and Development clause goes into ensuring that changes  to the design are
made in a controlled manner. Essentially what you want to do is prevent the design from being altered without
a formal review and approval process. The standard doesn’t say this, but clearly having revision control over
design outputs key here, whether that’s assigning revision numbers (or letters) to the drawings or models, or
using a full-blown design control database that has version controls baked into it.
Benefits
When implemented properly, Clause 8.3 should result in the following tangible benefits for your company:

1. Despite the chaotic writing of the clause as it now appears, this is itself a benefit: you
can now design any type of design model you want, whether waterfall, agile, iterative or some
hybrid. This is a great benefit, but only for those who know the difference between these
models.
2. This new vagueness in the standard also helps companies who are on the forefront of
Industry 4.0 implement design and remain compliant to ISO 9001. For example, you can now
send draft designs directly to 3D printers or additive manufacturing stations and generate
prototypes without breaking ISO’s expectations. (This would have been harder to claim under
older, stricter writings of the clause.)

3. Yes the new vague writing can be applied to the design of services, if you’re into that
sort of thing.

4. Creating a master design plan, typically as an overall design “procedure,” helps ensure
everyone in the design organization works to a similar structure or model. This is beneficial
because too many manufacturing organisations give their design teams too much free rein
when designing product, resulting in ad hoc or chaotic design processes that often don’t result
in meaningful designs or, worse, lead to product nonconformities. A bit of structure is good,
even if your designers will resist it at the beginning.

5. Developing unique design plans for different products or customers is also beneficial, as
it will allow for flexibility while still maintaining a culture of organization within the design
teams.

6. Ensuring requirements (design inputs) are thoroughly collected, reviewed and analyzed
before design work begins helps ensure the design result is meaningful, and reduces revisions
or re-design work later.

7. Requirements analysis also keeps your product in compliance with laws, and thus keeps
you from getting sued later. That’s good!
8. Thoughtful and careful design reviews ensure the design doesn’t proceed — whether
further into the design process or, worse, into production — unless the design is good.

9. Verification and validation, while poorly discussed in the standard, will help ensure
designs are capable of being made before they ever get released. V&V is a critical design
activity.

10. Careful review and approval of design changes is never a bad thing, as it prevents folks
from “breaking” what may have been a good design by changing it in a chaotic manner