QMS Guidance Pt. 5 – ISO 9001 Clause 8.3
Yes you read the header right, I’m going out of line with the standard again. Clause 8.3 is called ‘Design and Development of Products and Services’ and is a bit of an enigma.
Right from the 1987 version to the 2015 version the standard referred to products, and then in 2015 decided to add services into the mix. The effect being – well, confusion. Previously those companies that didn’t design products could opt out of this clause but the adding of ‘services’ muddied the waters some. ISO has provided no guidance on what they were seeking to achieve and so still to this day this clause is mostly opted out if a company doesn’t design products, the services part being overlooked.
So for the purposes of this guidance note you can assume that Clause 8.3 applies if your company designs products and I’ll overlook the conundrum of services until we all get some clear guidance. (Although inside my head, as a purist I think most if not all organisations are involved in designing services.)
The other reason I’m going out of order is I just think design comes before operational delivery in the normal course of events, you just don’t really know if you can deliver a product or service till you’ve designed it in part at least, but I do accept the notion of redesign as things go to meet changing needs and expectations.
A simple explanation of what Clause 8.3 is going to cover.
This is a detailed bullet list of things and actions for your ‘design plan’ to cover-off. From an implementation perspective you’re going to have to decide if you’re going to have a universal design plan, a unique design plan for each product and service or a mix of the two. I can say here and now I would mostly recommend a mixed approach as the best way of achieving well managed design processes. But of course it all depends on the what the organisation designs that’ll determine the process.
The standard has no requirement to document the design plan instead the list is for consideration, but it would seem an obviously good idea if it were documented (remember clause 7.5 – documented information necessary for effectiveness, well this probably would be one of those documents). Not to document a plan will inevitably mean it just wont be followed. What the standard does require however, is that you document that the design requirements have been met, (so no documented design plan required, but a documented statement to the effect that the design requirements have been met – seems a bit lite on the requirement to me).
Because the list is a list of considerations, provided you’ve considered them you can then decide to ignore those points on the list that don’t apply. So for example you might decide the point about looking at resource planning is overstating things, that actually you’ve already covered this off, so it would seem legitimate to ignore this point.
This is about the requirements for design ‘inputs’ and any designer will gladly tell you that getting the inputs right is fundamental to good design. I strongly recommend taking time over getting the design inputs correct, not just correct from a ‘what you think the product will do point of view’ but going back to the customer and checking it’ll meet their requirements and expectations. How will what you are designing be used and will it stand-up to this use?
The standard requires that you retain documented information on design inputs.
Another clause that ISO have thrown together leaving you plenty of room to move around in, and this one calls itself ‘controls’.
So the clause mentions things like ‘verification activities’ and ‘validation activities’ but offers no detail on what these might look like. The good news then is you have the freedom to decide for yourself how you want to exercise control over the process. You might choose the traditional ‘waterfall’ style, or go for something more ‘agile’ like scrum or a combination, but whatever you choose, provided you document what you do, then you’re very likely to meet the requirements of the standard.
Okay we’ve got a plan, made sure the inputs are correct and exercised some control over the process, now we’re onto ‘outputs’, the fruits of your design labours. Formerly this would have been a ‘blue-print’ and if you go and do a search for what these are you’ll probably be equally glad about how things have moved-on and dismayed at what a ‘blue-print’ actually was.
Design outputs can take any number of forms; digital models, 3D models, 4D models (where time is a design factor), specifications, bill of materials… the list could go on, but you get the idea.
Whatever form the outputs take they must represent what you are going to make in some understandable form. Because the standard requires specifics about the product characteristics to be known (not unreasonable) you are now at the point where you can define testing and measuring activities when the design goes into production.
And once again you’re required to keep documented information on the design outputs.
This the final stage in Clause 8.3 and deals with ‘changes’. Essentially the standard is looking for the design to be reviewed and any changes made to be controlled. Interestingly what the standard doesn’t ask for is documentation but I offer that you would be well advised to have a formal review and pass-off process for changes and that this is documented with authority sign-off on the changes. The simple way is revision numbers, but for detailed specifications (I’ve been involved with some specifications that are 100’s of pages long) you’d be better off with formal sign-off by all process owners.
Take-Away # 1 – this clause is very lite on the detail but this means you can fairly well decide what your own design processes should and can be. This is broadly speaking a benefit but only if you fully understand the design process you choose to employ.
Take-Away # 2 – the vagueness of the clause allows businesses to cut through previous stricter requirements at speed (think industry 4.0).
Take-Away # 3 – by creating an overview master design plan as a ‘procedure’ you will ensure that the design process is the same throughout the organisation. You might experience some push-back from your designers but structure will result in meaningful designs and a lot less non-conformity.
Take-Away # 4 – adopting a mixed approach to design plans to include product specific unique design plans allows you to remain organisationally flexible and has the added benefit of keeping things as creative as possible.
Take-Away # 5 – ensuring the inputs are as complete as possible will mean more right-first-time designs, less revisions and lower cost of design.
Take-Away # 6 – verification and validation is only touched on but v & v activities are a central part of ensuring good design outputs for both the design process and following production processes.
Take-Away # 7 – review and approval is never going to be a bad thing, it prevents people from engaging in chaotic behaviours, meaningless design processes and products that don’t actually meet customers requirements or statutory or regulatory requirements.
Philip Dawson MBA | Lead Auditor | ISO 9001 | ISO 14001 | ISO 45001 | ISO 27001 | Lean 6-Sigma Practitioner
Enjoyed this post or found it informative: