Design Development Procedure ISO 9001 2015 | QP1100

ISO Design Development Procedure

The ISO Design Development Procedure delineate planning and controls during the design phase to optimize quality, effectiveness, safety, and customer satisfaction prior to manufacturing in conformance with ISO 9001:2015.

This procedure applies to all new product development, as well as to developing significant changes to existing products. (20 pages, 3226 words)

ISO Design Development Responsibilities

All Employees are responsible for ensuring product and process improvement.

The Engineering Manager is responsible for designing, evaluating, testing, and all technical aspects of product and process development.

The Accounting Manager is responsible for evaluating and reporting on the financial aspects of product/process development.

The Marketing Manager is responsible for coordinating product development with the customer base, supervising field trials, finding new markets for the company’s products/processes, and raising awareness of the company’s offerings.

Top Management is responsible for final review and approval of design and development (D&D) projects.

The Product Development Team is responsible for managing the product design-and-development process; may also be known as “the Project Team”.

ISO Design Development Definitions

Design phase – The most important phase of the product life cycle, because inherent quality, effectiveness, and customer satisfaction of the product are established here. No matter how carefully a product may be manufactured or how perfect a quality control program, inherent qualities cannot be improved except through design enhancement.

It is crucial that adequate planning and controls be established, implemented, and maintained during the design phase to optimize quality, effectiveness, safety, and customer satisfaction prior to manufacturing.

Failure Mode and Effects Analysis (FMEA) – Technique for testing design of products in which failures are assumed to occur. The probability of each failure occurring and the result of failure are analyzed. If possible, hazards and faulty performance are designed out of the device; if not, hazards/substandard performance are compensated, reduced, or prevented (by interlocks, warning signs, explicit instructions, alarms, etc.). Risk of failure cannot always be removed from products but can be understood and controlled to the extent possible with existing technology.

Fault Tree Analysis – Deductive, top-down approach to failure mode analysis, where:

• System failure or safety hazard is assumed;
• Basic component failure or an event that could cause the assumed system failure or safety hazard is identified; and
• Computational techniques are used to analyze basic defects, determine failure probabilities, and establish the severity of failure effects.

Key characteristic – Feature of a material, part, or process, variation of which will significantly influence a product’s fit, performance, service life, or manufacturability. Key characteristics are essential to meeting product goals.

Quality Function Deployment (QFD) – Structured approach to defining customer needs or requirements and translating needs into specific plans to produce products to meet those needs. The “voice of the customer” (the term used to describe stated and unstated customer needs or requirements) is captured in a variety of ways (e.g., direct discussion or interviews, surveys, focus groups, customer specifications, observation, warranty data, field reports) and then summarized in a product planning matrix – a “house of quality”. Houses of quality are used to translate higher-level “whats” – needs – into lower-level “hows”, product requirements or technical characteristics to satisfy these needs.

Requirement – Condition that must be met in order to do something; something wanted or needed; something essential to the existence or occurrence of something else.

Verification – Evaluating a system or component during or at the end of the development process to determine if it satisfies specified input requirements.

Validation – Evaluating a system or component during or at the end of the development process to determine if it satisfies actual use conditions.

ISO Design Development Activities

• Design Inputs
• Design and Development
• Design and Development Review
• Design Verification
• Design Validation and Testing
• Project Assessment

ISO Design Development References

• ISO 9001:2015, “Quality Management System – Requirements”, International Organization for Standardization (ISO), Sep., 2015.

ISO Design Development Forms

• Design Review Checklist
• Design Completion Checklist for EMD
• Design Completion Checklist for Non-EMD
• Sample Verification Checklist
• Product Test Form

Difference Between Verification and Validation

If you’re tasked with preparing a project management plan, one of the elements of that plan is a test plan. Your test plan should include three distinct tests that you’ll need to perform: verification, validation, and acceptance. Do you know the difference between verification and validation, and how they’re related to design development?

VERIFICATION TESTING

This is testing that ensures the expressed user requirements, gathered in the Project Initiation phase, have been met in the Project Execution phase. One way to do this is to produce a user requirements matrix or checklist and indicate how you would test for each requirement. For example, if the product is required to weigh no more than 15 kg. (about 33 lbs.), the test could be, ”Weigh the object ” does it weigh 15 kg. or less?”, and note “yes” or “no” on the matrix or checklist.

VALIDATION TESTING

This ensures that any implied requirement has been met. It usually occurs in the Project Monitoring and Control phase of project management. Using the above product as an example, you ask the customer, “Why must it be ‘no more than 15 kg.’?” One answer is, “It must be easy to lift by hand.” You could validate that requirement by having twenty different people lift the object and asking each one, “Was the object easily to lift?”If 90% of them said it was easy, you couldconclude that the object meets the requirement.

We call this an implied requirement because the answer to “Why?” was not stated: the ”easy to lift” requirement was not clearly specified or defined. Another way to validate an implied requirement is to produce some test objects, or prototypes, and have the customer evaluate them in the field.

ACCEPTANCE TESTING

Next comes Acceptance Testing, the official approval of your deliverables by the customer. Your customer may accept your verification and validation test results and accept the object. The customer may also have their own “easy lifting expert” on hand and use them for the acceptance test. Acceptance testing often occurs at the end of the Project Monitoring and Control phase, but it can also take place at the beginning of the Project Review and Close phase.