Clause 8.3 of ISO 9001: Design and Development

By now you’ve no doubt realised that I’m a huge Deming fan. The man was incredibly smart, creative and clear-sighted. He was the King of Processes (“if you can’t describe what you’re doing as a process, you don’t know what you’re doing”), as well as a staunch advocate of the notion that “innovation comes from the producer – not the customer”.

Clause 8.3 is a neat intersection of these two observations by Deming. His work may be many decades old by now, but it has lost absolutely none of its power and relevancy. Keep his wisdom in mind as you work through this vital clause.

Clause 8.3.1 - Review with your staff what processes you have to design and develop your products and services

Look at the stages you use as well as the controls you have during and after those stages. Write them down on a whiteboard. Then check to see what controls you have in place to manage those processes – things like decision points, approvals, sign-offs, monitoring, meetings, customer review points etc. Put those on the whiteboard too.

Clause 8.3.2 - Determination of Control Points

The best way to determine this is to consider a list of 10 items, namely:

Complexity of the design.
The process stages including the review stages.
The testing you will do to check the design.
Who will be responsible and what authority will they have?
What resources are needed?
The interfaces between teams in the process.
How will customers get involved?
Who will use the design next?
What control do customers and other parties have over the design?
Determine what records you will keep to prove what you have done.

For example, here at Mango we use a range of processes with multiple stages that include activities like SCRUM and Agile development (these are two fantastic quality tools used by the software industry – if you’re in software and you’re not using them, get with the programme ASAP!). We also have continuous release processes where we update the product monthly.

It took us a few days to break down and describe the development process, but it was time well spent because it made things so much clearer for our whole team. Remember, as Deming pointed out, “it is not enough to do your best; you must know what to do, and then you do your best”.

8.3.3 - Establish the Requirements for Design

Once again, the standard gives you a simple list of what you need to consider:

The functional and performance requirements for the design.
Any information from previous designs.
What are the statutory, regulatory, standards or codes of practise requirements?
List any potential consequences of failure.
Make sure the requirements are clearly defined and any conflicts are resolved.
Again, determine what records you will keep to prove what you have done.

Clause 8.3.4 - Ensure you have processes to control design and development

These include:

reviews
verification
validation
problem solving
capturing records

Once you have created your design (it could be drawings, specifications, coding, plans, models etc.), the standard (8.3.5) then requires you to ensure that:

The design meets the requirements.
The design can be manufactured or the service offered.
The design can be inspected and tested.
That characteristics of the design are specified.

At this point in working through the clause many people feel that the hard yards have been done, and spend little time or energy on the elements of review. Big mistake. Unintended consequences are always a possibility – not just for software, but for every single industry in existence – so to miss this step or to do a rushed job can be very expensive in terms of missed opportunities, and devastating with regard to costly errors.

Deming was very aware that everyone has blind spots – as he said, “the big problems are where people don’t realise they have one in the first place”. So take time to thoroughly review, authorise and check all changes to the design. You need to be sure that they don’t cause other issues (8.3.6). You want to ensure that you don’t have any blind spots.

Design and Development at Mango

Here at Mango, during each monthly release, we have a number of formal reviews to check on progress. In addition each requirement is designed, developed and verified by the Software Developer prior to delivery to a User Tester. The User Tester then validates that the requirement is working both prior, and after, release. Any problems are reported into the software developer for fixing. All changes are recorded, listed and monitored to ensure they are well managed.

Takeaways

Clearly define what processes you use for designing and developing your products and services.
During planning consider the list of 10 items from ISO 9001 when you are determine your processes.
Work out the requirements for what you are designing.
Make sure you have processes to control the design and development.
Make sure any changes to the design and development are controlled.
Make sure you put in some effective reviews to ensure nothing slips through the cracks.