In this video, I’m going to cover ISO 9001 Clause 8.3 Design and Development. I’m going to break this clause down and turn it into something you can all understand. You’ll then be able to apply this to your own organization's system and understand what the requirements will look like for you. No more guessing! Keep on watching as I can show you just how easy this is.
There are 6 subclauses in 8.3 and it’s important to cover all of them together as they really do form their own continual improvement cycle.
The 6 subclauses are:
- - 8.3.1 General
- - 8.3.2 Design and development planning
- - 8.3.3 Design and development inputs
- - 8.3.4 Design and development controls
- - 8.3.5 Design and development outputs AND finally
- - 8.3.6 Design and development changes
The first subclause 8.3.1 General just simply states The organization shall establish, implement and maintain a design and development process that is appropriate to ensure the subsequent provision of products and services.
Easy! If you follow a process for all of the next subclauses, then you will achieve this! Let me explain what I mean. We are now left with Planning, Inputs, Controls, Outputs, and Changes.
If we look at these 5 activities as an ongoing cycle it will look something like this.
Now you can see that these 5 subclauses form a partnership for ongoing output for the provision of products and services (just like the clause statement from 8.3.1 General).
Now, I’m not going to start off with Planning (Clause 8.3.2) because if you understand and implement the requirements of clauses 8.3.3 through to 8.3.6 then most of the Planning clause will already be addressed. So, let’s revisit clause 8.3.2 Planning once we’re done and you’ll see where it all links together.
Starting with clause 8.3.3 Design and development inputs which states The organization shall determine the requirements essential for the specific types of products and services to be designed and developed. The organization shall consider:
- a)functional and performance requirements
- b)information derived from previous similar design and development activities
- c)statutory and regulatory requirements
- d)standards or codes of practice that the organization has committed to implement
- e)potential consequences of failure due to the nature of the products and services
If I look at these requirements from the perspective of us here at ATOL, when we consider our inputs for designing and developing our training, I can see that our functional and performance requirements might include how we want our content, practice activities, and assessments to work.
It will also extend to how we provide downloadable documents and even embedded videos in our course. We would understand these requirements from previous similar design and development projects for training. which ticks off point b). In fact, we have a standard Project template that we use for course development, so when we learn something new or how to improve, or we identify something that needs to be included that we may have missed, this template is updated so we don’t forget the next time!
We also then need to understand what statutory, regulatory, standards, or codes of practice apply to what we plan to deliver. For us, we would also need to consider the performance criteria of the competency we plan to deliver so that our content and assessments meet these requirements. From a broad sense, we also need to be aware of providing different methods of learning to account for our student’s needs, so we have to plan how we mix our written, audio and visual content throughout. Another great input is from an obvious source – the customer! It is important to obtain their feedback - which is considered to be an input.
We also consider the potential consequences of failure – which specifically for ATOL would be a failure to launch our training on time as well as our course does not function as expected when we go live. To allow for this we map out timeframes and allow sufficient time for contingencies and testing prior to go live.
Clause 8.3.3 then goes on to say Inputs shall be adequate for design and development purposes, complete and unambiguous. Conflicting design and development inputs shall be resolved. The organization shall retain documented information on design and development inputs.
This explains to me that when we map out our plan, we have to be specific right down to every single task. This is why we use a project management program to manage our course planning so we can get right down to the smallest task with clear direction for the person responsible. And by managing our planning by using an online program we automatically tick the requirement for retaining documented information on our inputs. It’s all there in black and white – what we stated our inputs were and how we achieved them.
Now we can move on to clause 8.3.4 Design and development controls which states The organization shall apply controls to the design and development process to ensure that:
- a) the results to be achieved are defined
- b) reviews are conducted to evaluate the ability of the results of design and development to meet requirements
- c) verification activities are conducted to ensure that the design and development outputs meet the input requirements
- d) validation activities are conducted to ensure that the resulting products and services meet the requirements for the specified application or intended use
- e) any necessary actions are taken on problems determined during the reviews, or verification and validation activities
- f) documented information of these activities is retained
This can be achieved so easily for us here at ATOL. Again, because we use Asana, a task and project management program. This is going to sound like a plug for Asana, but it’s not. I do love Asana however there are a lot of other project and task management programs out there that businesses use. Because we use Asana for our design and development management of our courses, all of the elements of this clause are met which include:
- - Our results we want to achieve are defined as a separate section or task – for example, SME content complete, content updated to the platform, content reviewed, content updated with feedback – and the ultimate end result is Go Live!
- - Reviews of content are included as a task.
- - Verification (checks along the way) is included as a task for both the SME and testers – does it all make sense? Do the functionalities do what they are supposed to?
- - Validation is completed with the end product – does the course perform and function as it was intended? This is discovered in our final test on the LMS platform.
- - And of course, if there are any actions that need to be taken from all of these reviews, verifications, validations, and testing, the actions are recorded in Asana or in the course reviewer program.
- - Leading to the retention of documented information to provide evidence that we’ve done all of this!
See, while there are lots of words in this subclause it is really easy to tick the requirements if you use the right tools!
Then we can move to Clause 8.3.5 Design and development outputs. This clause states The organization shall ensure that design and development outputs:
- a) meet the input requirements
- b) are adequate for the subsequent processes for the provision of products and services
- c) include or reference monitoring and measuring requirements, as appropriate, and acceptance criteria
- d) specify the characteristics of the products and services that are essential for their intended purpose and their safe and proper provision
These outputs might be draft course content for review, draft videos for review, assessments, workbooks, and of course the final course content. It could also include website updates and marketing collateral.
You can see when they talk about outputs in design and development, you just have to determine what ‘product’ or ‘service’ are we delivering along the way. What needs to be completed along the way and of course in the final stage?
Determine what these are, and you will also then understand what your input requirements are which we discussed in clause 8.3.3. And of course, ensure that you have evidence of these outputs being planned and achieved, which is easy for us here at ATOL as it’s all transparent in Asana.
You can then move on to clause 8.3.6 Design and development changes which states The organization shall identify, review and control changes made during, or subsequent to, the design and development of products and services, to the extent necessary to ensure that there is no adverse impact on conformity to requirements.
The organization shall retain documented information on:
- a) design and development changes
- b) the results of reviews
- c) the authorization of the changes
- d) the actions taken to prevent adverse impacts
This is easy! So if anything changes along the way just use the same system you have in place to start with. For example, if performance criteria changes for a course assessment while we are in the middle of building a course, we would simply update that criteria requirement in our Plan, which would then prompt us to review the Inputs – which of course does include performance criteria already, then we’d look at Controls – and ask ourselves does this input change mean we need to put in place different controls, like reviews, verification or validation.
Do we need a different SME for this? And then finally with this performance criteria change will it mean a different output? I would say yes – because with different performance criteria comes a different assessment (possibly). So, we’d have to review our current output assessments to see if any meet the new requirements, otherwise, we will have a new output (meaning a new assessment).
Now we can skip back to the beginning of clause 8.3.2 Design and development planning.
Stick with me – we’re nearly finished!
This clause states …. A lot of things. To be honest I’m not going to go through them all straight from the Standard! Why? Because they are all covered by simply meeting the clause requirements from 8.3.3 through to 8.3.6. I’ll summarise instead. So, because we have mapped out our inputs, controls, and outputs as well as understanding how to use that same process if any changes occur, we have achieved all of the following Planning requirements:
1 - because you know what you need to produce at different stages you will have an idea of the duration of the project. What the planned dates are along the way right through to completion. You know this because you have mapped out the outputs (remember that was clause 8.3.5)
2 - You will know what the process stages are - including reviews, verifications, and validation (remember this was in clause 8.3.4 Controls)
3 - You will know who is responsible as you should identify those competent people that can achieve the milestones at different stages of the project as well as who is responsible for the review, verification, and validation of course. While planning this you may have also picked up that you might require someone with certain skills and experience that are external to the business. A great example of this for us here at ATOL is that we have a gap in knowledge for ISO 27001, so we have found ourselves an external resource.
4 - As part of your inputs (clause 8.3.3) you have recognized that it’s important to include the customer, so you’ve already got that covered as well.
And finally 5 - the documented information needed to demonstrate this planning is all picked up in the documented information you are retaining for inputs, controls, outputs, and changes. No need to do even more!!
Phew! That is it! I know this is a big one, but it was really important to keep all of the subclauses together because they all work together.
Now that I’ve explained all of these requirements, can you see more clearly how you could action and demonstrate these requirements in your organization and management system?
Learn even more by completing a qualification in one of our ISO 9001 courses.
