1Management system guidance

8.3 Design and development of products and services

8.3.1 Design and development - General

This is a new requirement that mandates the introduction of a design and development
process where this activity is required. You should seek and record evidence that, where
applicable, your organization has implemented a design and development process to allow
effective product or service provision, where the requirements for products and services are
not defined by your customers or interested parties.

Many companies perform some enhancements or minor reconfiguration of mature designs,

such organizations may have to introduce a comprehensive design system and related or
processes. If your organization is ‘design responsible’ but outsourcers all of its design, all
records from Section 8.3 must be maintained by your organization, as they are responsible for
design.

Determine your organization's arrangements for establishing, implementing and maintaining

the design and development process that includes design and development planning, inputs,
controls, outputs and changes.

8.3.2 Design and development planning

This requirement expands upon ISO 9001:2008 Clause 7.3.1 – Design and Development
Planning. It is likely that if your organization already complies with this clause, you will
already be undertaking the activities required by ISO 9001:2015 Clause 8.3.1.

You should seek and record evidence that your organization has considered the explicitly
referenced considerations relating to the design and development process set out above.

You should also ensure that your organization has retained documented information to
confirm the identified design and development requirements were met and that design
reviews were undertaken. You should have an overall plan for how you undertake your
designs.

Your plan must specify the design and development stages, activities and tasks;
responsibilities; timeline and resources; specific tests, validations and reviews; and outcomes.
There are many tools available for planning ranging from a simple checklist to complex
software. Control product design and development planning activities including:

1. Scope of the design e.g. customer requirements (see 8.2.2) design rationale, design
assumptions, objectives, complexity, size, detail, timescales, criticality, constraints, risks,
producibility, accessibility, maintainability;
2. Stages of the design process, distinct activities and review e.g. work breakdown structure,
work packages (tasks, resources, responsibilities, content, inputs/outputs), concept design,
preliminary design, detail design, design review gates preliminary design review, detail
design review, critical design review);
 3. Verification and validation activities comprising checks, trials, tests, simulations,
demonstrations required to ensure requirements are met;
4. Assignment of responsibilities and authorities e.g. job profiles, CVs, accountability
statements, delegation of authority, levels of approval, register of authority and approvals,
authorized signatories;
5. Internal and external resources such as knowledge acquisition, people, competency,
investment, funding, facilities, equipment, innovation, technology, interested parties
(customers, external providers, research establishments), information (principles, standards,
rules, codes of practice);
6. Organizational interfaces such as personnel and functions e.g. sales, project management,
production, procurement, quality, finance, customers, end users;
7. Levels of control required or implied by interested parties (customers, regulators, end users
etc.) e.g. customer acceptance, safety checks, risk management, verification/validation
activity, product certification;
8. Required documented information e.g. design plan, design reviews, design outputs
(specifications, schemes, drawings, models, data, reports), control plans, certificates.

Although the standard does not require a documented procedure, the design process needs to
demonstrate how the process is controlled and planned. The organization, however, will need
to provide some type of objective evidence as to what the planning activities include. This
can be accomplished with the use of time-lines, Gantt charts or any other planning method
such as Microsoft project manager.

In addition, auditors would likely want to see objective evidence of how the interfaces
between other processes are managed, either through statements, or in associated procedures,
process mapping, and matrix approach or in the time line planning.

8.3.3 Design and development inputs

This requirement expands upon the requirements from ISO 9001:2008 Clause 7.3.2 - Design
and Development Inputs 7.3.1. You should seek and record evidence that your organization
has documented and retained information concerning the need for internal and external
resources and the potential consequences of design or development failure.

Define which deign and development inputs are required to carry out the design and
development process. The inputs should be determined according to the design and
development activities. For example, which employees are required or what information is
required for every step of the development. When determining design input requirements,
ensure the retention of documented information such as:

1. Statutory and regulatory requirements e.g. legislation, regulation, directives;

2. Standards or codes of practice e.g. policies, standards, specifications, rules and aids,
protocols, guidance, industry codes
3. Functional and performance requirements informed by customer requirements,
operational and performance charateristics, usability, reliability, availability,
maintainability, and safety (e.g. Human factors and RAMS);
4. Knowledge exchange from other, similar proven designs, lessons-learned,
performance data, in-service data, customer feedback, external feeback, best practice,
benchmarking;
5. Design assumptions and associated risks;
 6. Methods of validation and verification;
7. Adequacy of inputs e.g. clear, complete, unambiguous, and authorized;
8. Conflicting inputs are resolved by communicating with interested parties/contract
amendments.

The auditor will need to review evidence that the inputs have been addressed based on the
nature of the product being produced, that they have been reviewed for adequacy and that
records are maintained of the activity. An organization may include design personnel in the
contract review stage; these records may suffice the review of design input requirement.

8.3.4 Design and development controls

This requirement is comparable to the requirements from ISO 9001:2008 Clauses 7.3.3,
7.3.4, 7.3.5 and 7.3.6. You should seek and record evidence that your organization has
applied the necessary controls to its design and development process and has retained the
following documented information:

1. Defined outcomes including such as specifications, design intent, functional and

performance requirements, customer/end user expectations;
2. Design review process with functional representation from the customer, engineering,
production, quality, project management etc.), design review gates (e.g. preliminary
design review, detail design review, critical design review), commercial/technical
considerations, authorized progression to next stage;
3. Verification activities such as modelling, simulations, alternative calculations,
comparison with other proven designs, experiments, tests, and specialist technical
reviews;
4. Validation activities such as functional testing, performance testing, trials, prototypes,
demonstrations, and simulations;
5. Management of actions arising from design reviews, verification or validation
activities e.g. action registers, ownership, timescales, escalation, changes to risk
profile.

Design verification is a comparison between the outputs the inputs. Does the available
evidence indicate that the design will meet the requirements? The verification could consist
of calculations, simulations, prototype evaluation, tests or comparison against samples.

You must maintain documented information of design verification activities; as these records
will indicate the results of verifications and determine any necessary corrective actions.
Perform design and development verification by determining whether the outputs meet the
input requirements for the design. Maintain records of verification activities and approvals.

Design verification should be carried out to check that the outputs from each phase meet the
stated requirements for the phase. Requirement verification should be undertaken to ensure
that the design fulfils the the input requirements, as applicable, while expressing the
necessary functional and technical requirements.

Design validation is similar to verification, except this time you should check the designed
product under conditions of actual use. If you are designing dune buggies, you might take our
creation for a spin on the beach. If you are making beverages, you might conduct a consumer
taste test. Verification is a documentary review; while validation is a real-world test. Perform
design and development validation by ensuring the product meets the specified requirements.
Maintain records of validation activities and approvals.

The organization shall have records that the product designed will meet defined user needs
prior to delivery of the product to the customer, as appropriate. Methods of validation could
include simulation techniques, proto-type build and evaluation, comparison to similar proven
designs, beta testing, field evaluations, etc. Irrespective of the methods used, the validation
activity should be planned, executed with records maintained as defined in the planning
activity.

Retain documented information to demonstrate that the any test plans and test procedures
have been observed, and that their criteria have been met, and that the design meets the
specified requirements for all identified operational conditions e.g. reports, calculations, test
results, data, and reviews.

8.3.5 Design and development outputs

This requirement is comparable to the requirement from ISO 9001:2008 Clauses 7.3.3 –
Design Development Outputs. You should seek and record evidence that the additional
requirement to retain documented information concerning design outputs. You should also
check the need for design outputs to reference monitoring and measuring requirements.

The design and development output is the result of design and development process. The
output is a clear description of the product, containing detailed information for production.
Ensure that your organization's design and development outputs reconcile with its design and
development inputs by:

1. Ensuring outputs meet input requirements e.g. checklists, design review records,
authorization to proceed, customer acceptance, and product certification;
2. Ensuring outputs are adequate for product and service provision e.g. standards,
specifications, schemes, drawings, models, part lists, materials, methods,
manufacturing instructions, technical packages, tooling, machine programs,
preservation, handling, packaging, specialist training, user instructions, service
manuals, repair schemes, and external provision;
3. Reference to monitoring and measuring equipment e.g. inspection equipment, gages,
instruments, environment;
4. Acceptance criteria e.g. product/service specification, limits, tolerances, and quality
acceptance standards;
5. Product/service characteristics e.g. key characteristics, customer critical features,
interface features, inspections, service intervals, and operating characteristics;
6. Critical items such as identification, key characteristics, special handling, service
intervals, component lifing, cyclic life, life management plans, source and method
change, and traceability;
7. Outputs are approved prior to release e.g. scope of authorization, authorized persons,
levels of authorization, method of authorization and documented information is
retained.

A Certifcation Auditor would expect to see objective evidence that the outputs have been
verified against the design inputs. This can be accomplished by reviewing documents, plans,
etc. interfacing with the customer or internal processes and by comparison with past proven
designs. Outputs may also include product preservation methods, identification, packaging,
service requirements, etc. as appropriate.

8.3.6 Design and development changes

This requirement is directly comparable to ISO 9001:2008 Clause 7.3.7 - Control of Design
and Development Changes. It is important to control design changes throughout the design
and development process and it should be clear how these changes are handled and what
affects they have on the product. You should seek and record evidence that your organization
has retained documented information concerning:

1. Design and development changes;

2. The results of reviews;
3. The authorization of changes;
4. Actions taken to prevent adverse impacts.

Your organization should begin identifiying, reviewing and controlling of design changes
including the implementation of a process to notify the customer when changes affect the
customer requirement e.g. customer communication, notifications of change, requests for
deviation, and contract amendments.

It is as important to control design changes throughout the design and development process
and it should be clear how these changes are handled and what effects they have on the
product. Ensure control over design and development changes, design changes must be:

1. Identified;
2. Recorded;
3. Reviewed;
4. Verified;
5. Validated;
6. Approved.

Configuration control can be managed via alteration requests, notice of change, amendments,
deviations, waivers, concessions, part revision changes, part number changes, change
categories, service bulletins, modification bulletins, airworthiness directives, engineering
communication notice, product change boards.

Design and development changes (after the original verification and validation) have to be
'verified and validated as appropriate' (as well as reviewed) and to 'include evaluation of the
effect of changes on constituent parts and products already delivered'.

If the organization chooses not to perform re-verification and re-validation on every design
change, then the auditor should expect to see some very well-defined criteria as to when the
activity needs to occur.

Retain documented information that includes design change history, evaluation of change
results, authorization of change and actions taken in relation to subsequent activities that are
impacted by the change.