[This series of articles tries to emphasize the benefits of ISO 9001, and how to yield results from each major clause of the standard.]


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.


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.

Click here for the full series of articles on The Benefits of ISO 9001:2015.


About Christopher Paris

Christopher Paris is the founder and VP Operations of Oxebridge. He has over 30 years' experience implementing ISO 9001 and AS9100 systems, and is a vocal advocate for the development and use of standards from the point of view of actual users. He is the author of Surviving ISO 9001 and Surviving AS9100. He reviews wines for the irreverent wine blog, Winepisser.


Aerospace Exports Inc