ISO 9001:2000 7.5.1 Control of Production and Service Provision

Change: Re-wording
Procedure Required: NO
Record(s) Required: Multiple (5)

Comments:
The following records are required:

• Records relating to design and development inputs (sec. 7.3.2)
• Records of the results of design and development reviews and any necessary actions (sec. 7.3.4)
• Records of the results of design and development verification and any necessary actions (sec. 7.3.5)
• Records of the results of design and development validation and any necessary actions (sec. 7.3.6)
• Records of results of the review of design and development changes and any necessary actions (7.3.7)

Guidance:
If the organization does not perform design and development activities, then the quality manual should address section 7.3 as an exclusion.

7.3.1 Design and Development Planning

Comments:
This section requires the organization to plan and control the design and development of product.

During the design and development planning, the organization must determine:

a) the design and development stages, 
b) the review, verification and validation that are appropriate to each design and development stage, and 
c) the responsibilities and authorities for design and development.

The organization must manage the interfaces between different groups involved in design and development to ensure effective communication and clear assignment of responsibility. Planning output shall be updated, as appropriate, as the design and development progresses.

Guidance:
I suggest paraphrasing the wording of the standard in your Quality Manual. Because there is no requirement for a procedure or record(s), planning output can take any form.

If each design is unique, then I suggest developing a design and development plan for each design.

If design and development has been standardized, then I suggest developing a generic (general) design and development procedure or flowchart addressing the requirements of 7.3.1.

7.3.2 Design and Development Inputs

Comments:
This section requires the organization to determine and maintain records of inputs relating to product requirements. Design and development inputs must include:

a) functional and performance requirements, 
b) applicable statutory and regulatory requirements, 
c) where applicable, information derived from previous similar designs, and 
d) other requirements essential for design and development.

Design and development inputs must be reviewed for adequacy. Requirements must be complete, unambiguous and not in conflict with each other.

Guidance:
I suggest paraphrasing the wording of the standard in your Quality Manual.

If the design input is provided from the customer, then the review of design input may be incorporated as a part of the review of customer requirements (7.2).

If the design input is provided from internally (e.g., from the sales or marketing function), then the review of design input would ordinarily be undertaken by the design and development (e.g., engineering) function.

7.3.3 Design and Development Outputs

Comments:
This section requires the organization to provide the outputs of design and development in a form that enables verification against the design and development input. Design and development outputs must:

a) meet the input requirements for design and development,
b) provide appropriate information for purchasing, production and for service provision,
c) contain or reference product acceptance criteria,
d) specify the characteristics of the product that are essential for its safe and proper use, and
e) be approved prior to release.

Design and development outputs are typically drawings or schematics, but may take other forms (e.g., software).

Guidance:
I suggest paraphrasing the wording of the standard in your Quality Manual.

CAUTION - Phantom Requirement:
Although not specifically required in the standard, some ISO 9000 auditors expect the approval releasing design and development output to positively identify the individual who authorized release of the design. The basis for this interpretation relates to the auditor being able to verify that the individuals approving the design are both authorized (as per section 5.5.1) properly trained and qualified (as per section 6.2). I suggest defining in your Quality Manual (or procedure) "which" positions (job titles) are authorized to approve design and development output.

7.3.4 Design and Development Review

Comments:
This section requires the organization to perform systematic reviews of design and development, at suitable stages, in accordance with planned arrangements (ref 7.3.1) to:

a) evaluate the ability of the results of design and development to meet requirements, and 
b) identify any problems and propose necessary actions.

Participants in such reviews must include representatives of functions concerned with the design and development stage(s) being reviewed. Records of the results of the reviews and any necessary actions must be maintained.

Guidance:
I suggest paraphrasing the wording of the standard in your Quality Manual.

Include design and development reviews in the design and development plans (ref. 7.3.1) and create records from such reviews.

7.3.5 Design and Development Verification

Comments:
This section requires the organization to perform design "verification" in accordance with planned arrangements (ref. 7.3.1) to ensure that the design and development outputs have met the design and development input requirements. Records of the results of the verification and any necessary actions must be maintained.

Previous versions of ISO 9001 had included a note explaining design verification. While a definition for verification has been provided in ISO 9000:2000, "Quality management systems—Fundamentals and vocabulary", section 3.8.4, it offers little in the way of guidance.

The note explaining design verification in ISO 9001:1994 listed the following examples:

• performing alternative calculations,
• comparing the new design with a similar proven design, if available
• undertaking tests and demonstrations, and
• reviewing the design-stage documents before release.

Guidance:
I suggest paraphrasing the wording of the standard in your Quality Manual and create records of design verification (which may be included in a design review).

7.3.6 Design and Development Validation

Comments:
This section requires the organization to perform design "validation" in accordance with planned arrangements (ref. 7.3.1) to ensure that the resulting product is capable of meeting the requirements for the specified application or intended use, where known. Wherever practicable, validation must be completed prior to the delivery or implementation of the product. Records of the results of validation and any necessary actions must be maintained.

Previous versions of ISO 9001 had included a note explaining design validation. While a definition for validation has been provided in ISO 9000:2000, "Quality management systems—Fundamentals and vocabulary", section 3.8.5, it offers little in the way of guidance.

The note explaining design validation in ISO 9001:1994 offered the following points:

• Design validation follows successful design validation.
• Validation is normally performed under defined operating conditions.
• Validation is normally performed on the final product, but may be necessary in earlier stages prior to product completion.
• Multiple validations may be performed if there are different intended uses.
  

Real world examples of design validation include the use of prototypes (hardware), Alpha tests and Beta tests (software).

Guidance:
I suggest paraphrasing the wording of the standard in your Quality Manual and create records of design validation (which may be included in a design review).

7.3.7 Control of Design and Development Changes

Comments:
This section requires the organization to identify and maintain records of design and development changes.

Design and development changes must be:

1. reviewed,
• including evaluation of the effect of the changes on constituent parts and
• product already delivered
2. verified,
3. validated, as appropriate, and
4. approved before implementation.

Records of the results of the review of changes and any necessary actions must be maintained.

Control of design changes is sometimes referred to as "configuration management".

Guidance:
I suggest paraphrasing the wording of the standard in your Quality Manual and create records of design changes.

The requirement to "identify" design changes can be met through simple revision control along with a brief description of the change (usually included on the drawing, schematic, or as a note / comment written in the software code).

The reason for the review to take into consideration product already delivered typically involves replacement equivalancy issues.