Design Control Gating Process - Seeking work instructions and discussion

[RosieA]

I've now been at my present company for a year...they've been ISO certified for over 10 years, so I figured that that every area had been pretty well reviewed to death in that time. However, yesterday I tried to do an audit of the Engineering area and found a system that is so tangled up that I couldn't audit several processes.

I've agreed to help the Director of Engineering rebuild. He's never heard of the Gating process that many companies use to manage design control. I've done Gating procedures in another company, but that was a very different kind of business than my current one. I wonder if anyone has information or work instructions they could share on Gating Processes that can help me get my thought processes kicked into gear?

[ZeeMan]

We've been doing design-side process quality at my company for several years now, but I am unfamiliar with the term "gating".

Can you describe it for me so I can see if we're doing something similar?

[Govind]

Gating is one of the approach to design and development Process

We use this process with gates:
Opportunity Assessment Gate,
Planning Gate (includes end of Life cycle planning),
Design Gate,
Qualification Gate,
Release to Manufacturing Gate.

These gates have Go/No Go decisions and several criteria need to be met before the Gate Review signoff by the project Team, Program manager.

Design and development process documentation are confidential to organizations. But you may find examples in

http://www.npd-solutions.com/pdforum.html

This is a very useful site you may want to explore.

Govind.

[Wes Bucey]

In Reply to Parent Post by ZeeMan

We've been doing design-side process quality at my company for several years now, but I am unfamiliar with the term "gating".

Can you describe it for me so I can see if we're doing something similar?

An analogy which might help envision the process:
Think of an intricate network of irrigation canals.
Each section of the network has a movable "gate" to allow or deny flow of water.
When the water comes from the main source, it is directed to the areas where it is needed and shunted from the areas where it isn't wanted by opening or closing the gates.
Within a business process (approving/denying projects), an original idea goes through these various gates, depending on the scope and application of the project. The art is in deciding WHICH projects go through WHAT approval processes and WHO (customer, regulator, bean counter, etc.) is involved in the decision.

I have a good idea of WHAT "gating" is. Not a strong response on performing the "art."

[RosieA]

hi Zee,

A gating process is one in which you have pre-set review points (gates) that includes deliverables and require team approvals before moving forward.

Typically they would be something like:
Gate 1: Input requirements outlined
Gate 2: Product Specs defined, regulatory issues addressed, market analysis done,
Gate 3: Prototype completed, test plan developed, FMEA done
Gate 4: Verification and Validation complete, Manufacturing documentation done, manuals completed, regulatory requirements completed

At each step you update the design plan, and gain cross-functional approval on the progress of the design. These can act as the design review minutes with enough definition.

Hope that helps explain the structure.

[The Taz!]

Gee. . . it sounds alot like the Milestone tracking on an AQP in Automotive. A TS Measureable of that process.

[ZeeMan]

Got it. We would refer to that as a "Decision Point" or "Management Authorization" process. Unfortunately, that kind of "gating" is only done for programmatics, not for the specifics of the Design & Development process.

If I understand your approach correctly, you want to implement an engineering process whereby engineering must have met certain criteria before they can proceed to the next design phase. If the point is strictly to create a clean process so that it is auditable, I think that will work fine. It will tell you if they've completed certain steps necessary to continue.

The approach our quality group has taken in design is that the design process has work product outputs that can be assessed for 'goodness'. For example, every design project has requirements, and these are documented. We (quality) review these outputs for fundamental characteristics that are critical to the documents goodness. For requirements, these are that the requirements are clear, traceable (to higher/lower level requirements), and verifiable.

Our engineering process also has a certain time-phasing to it so that there should be certain outputs at certain times, but quality is less concerned with that than with the quality of each output. Once we get to the end of design & development, there is a programmatic gate that quality has input on as to whether the design can be transitioned to the factory. This gate ensures that certain things are done. Quality can also say that the things that have been done are good.

We found that there are only a few 'categories' of design work products, and have established fundamental characteristics of goodness for each of these work product categories and are keeping these as metrics. The long-term approach is to develop a kind of profile that matches the amounts of these metrics over the design timeline with the result of that design in the factory and field. Doing this should allow us to determine the 'ideal' profile. We can then track current projects against the ideal and be able to predict whether a design project needs immediate help to prevent it from having problems in the factory and field. This comparison should also allow us to determine if there are some local practices (we have a lot of design groups) that are better/worse than the process norm and enable process improvement.

That's the dream. It's just getting started. I don't know if any of that helps you, Rosie, but I hope so.

[45fan]

In Reply to Parent Post by Govind

Gating is one of the approach to design and development Process

We use this process with gates:
Opportunity Assessment Gate,
Planning Gate (includes end of Life cycle planning),
Design Gate,
Qualification Gate,
Release to Manufacturing Gate.

These gates have Go/No Go decisions and several criteria need to be met before the Gate Review signoff by the project Team, Program manager.

Design and development process documentation are confidential to organizations. But you may find examples in

http://www.npd-solutions.com/pdforum.html

This is a very useful site you may want to explore.

Govind.

Your gating process is very similar to the one I am writing up. Also a very standard sequence, with slightly different terms. My company is strictly involved in medical product development, no sales or manufacturing except for prototyping (that will hopefully change). So as far as ISO, and FDA regs, are concerned, our company is governed by design control, with all others supporting the design and development activities. My concerns are mainly on how to implement a "product development process" vs. design controls.

I've researched the forums but still have some questions that I am hoping will help me streamline my documentation:
1. Do you have a procedure that covers the design controls requirements explicitly and another for the development process, or just one that integrates both? I am interpreting 7.1 and 7.3.1 to occur at the same time for our organization, so it seems that one procedure can address all requirements. I also lump 7.2.1 and 7.2.2 with 7.3.2.

2. Does your gate 1, Opportunity assessment, include "research" activities such as concept development and feasibility studies or is that done at some other time? For the projects that we have, it seems next to impossible to correctly and efficiently conduct "research" like concept development and feasibility studies without implementing some design controls, at least to the point that design input requirements are specified. Since researchers don't like to be encumbered by extensive procedures and documentation requirements, which I agree does tend to stifle creativity, they tend to resist using design controls. To be fair, design controls are really intended to apply only to the design of the finished device, but when solutions are not readily apparent and research has hit several brick walls, it seems that it is time for some level of design controls, or at least more intelligent project management, which can be realized by the use of some level of design controls. This is why I asked the question as I did.