Control the NPD Process with Gate Reviews and Design Reviews


Efficient and effective product development is characterized by empowered teams with well-defined objectives and necessary resources. However, product development is not done in a management vacuum. Two important mechanisms provide management oversight and control.


The first mechanism is a management-oriented review occurring at the end of a logical project phase. This type of review is referred to as a gate review, phase-gate review, phase review or phase approval. This review assesses that the project is worthy of continuation and that risks are manageable. It approves the expenditure of resources to continue with the project. The term “gate” implies that the project must go through this step in order to continue on. The typical timing of phase-gate reviews is shown in the project phase diagram.

The management team that conducts these reviews usually stays constant across all projects to bring consistency to the review process and to maintain a comparative perspective among projects so that they better recognize the good projects and the projects that are in trouble. This multi-functional management team often consists of vice-president or director level personnel. This team might be one and the same as a products committee or a product development steering team that manages the development pipeline, screens projects, and establishes project priorities.

The phase-gate reviews should have well-defined entry criteria, review objective and agenda for each review (see example of the definition for phase-gate reviews).

When companies start with an ill-defined process or lack any type of phase-gate reviews, “hard” gates are usually established. This means that the review must be successfully conducted before the program proceeds. When a well-disciplined development process is in place and development personnel are used to gate reviews, the organization is positioned to move to “soft” gates. Soft phase-gate reviews allow the project to proceed in parallel with conducting the review, thereby reducing time-to-market. In other words, there are no “hard” stops while the team prepares for and conducts the review.


The second mechanism is a technically-oriented design review. There are typically several types of design reviews that occur at different points in the new product development process. These design reviews are placed at a point in the process where there has been development of some aspect of the product or process design that should be assessed before the project continues based on those technical decisions. These reviews are intended to provide an independent assessment of either the documented requirements for the new product, the concept of the new product, the design of the new product, the process design to manufacture and support the new product, or the readiness to put the new product into production. These design reviews are not only a method to help verify the design of the product, but also a means to reduce the risk associated with the new product. The typical timing of design reviews is shown in the project stage diagram.

Design reviews are not witch hunts. Development personnel should learn to value design reviews as a means to reduce program risks and increase program success. They should be conducted in with a spirit of cooperation.

Design reviews are conducted with a design review team composed of experienced, senior-level personnel who understand the technology involved in the product or system and its associated technical risks. These personnel should not be directly involved in the program in order to provide an objective perspective on the design. Design review team members are chosen to match their skills and expertise to the requirements of the project. The team is multi-functional to address all the subject matter and issues covered during the review. The team may stay in place for the project or new personnel may be added and existing design review team members dropped as the project evolves in its development cycle.

Design reviews, while technically focused, are not limited to just the design of the product. They must address all the life cycle requirements of the product as well as the program requirements such as cost, schedule and risk. An design review agenda (see the example of a design review agenda) should be established to cover all of these topics and to guide the review. In addition to an agenda, it is useful to define which process outputs are needed to support the design review or should be inspected in preparation for the design review.