Most product development organizations have deployed some form of Stage/Phase-Gate and Gate Review process to provide structure to their projects, yet many struggle to achieve the full benefits that such a process can offer. Effective product development results from effective risk management. This paper presents the Gate Review process as a systematic tool for managing project risk and provides practical guidelines for holding effective gate review meetings.
One of the fundamental objectives of an effective Gate Review process is to reduce project risk as rapidly as possible as a basis for deciding whether to continue investing in the development project or not. This should be done with the minimum possible expense and with the lowest possible administrative effort.
The process of managing risk is shared between the project team and the management team. The project team manages risk factors that are internal to the project, e.g., will the product satisfy customer needs, will we be able to achieve the critical functions and performance with available technology, we will achieve target cost, etc. The management team should provide a check and balance on the project team’s efforts to manage internal risk, and, more importantly, their role is to manage external or higher level risks, e.g., the risk that the project deviates from the strategic business objectives, the risk that this project takes resources away from higher priority projects, etc. If the management team gets too involved in managing project specific risk, the rate of progress will be slower (micro-management). On the other hand, if the management team is not sufficiently involved, the project may deviate from the organization’s strategic objectives, suffer from poor execution by an inexperienced team that needs timely correction, and/or interfere with other project resources.
It is therefore necessary to define points in the project timeline where the management team engages with the project team to assess risk against both internal and external criteria and make a decision to a) proceed, b) cancel the project, c) place the project on hold, or d) request additional work in the current phase. These points occur where there are decision points about major commitment of resources: proceeding with detailed development, investing in tooling, investing in launching a new product, etc.
There are some logical, high level risk reduction tasks/activities that can be used as the basis for defining the phases of the product development process. The names that are given to the phases are somewhat arbitrary but the defining tasks must be performed in the correct sequence in order to consistently achieve the minimum development time (there are many more tasks than listed – these are the defining tasks).
|Idea||Capture and rank the idea against strategic priorities|
|Investigation||Assess readily available data to better quantify the opportunity. Recheck for alignment with strategic objectives and relative priority against other projects.|
|Feasibility||Select the product concept based on customer needs, competitive solutions, product cost, product quality, and technical risk tradeoffs|
|Development||Develop the product and manufacturing or service process (detailed design)|
|Pilot/Launch||Verify the manufacturing or service process. Introduce the product|
|Production/Deployment||Ramp up production volumes and refine manufacturing process to achieve cost and quality goals or deploy and refine the service|
Between each of the phases is a management assessment event where the project is evaluated against specific criteria to determine if the project should proceed. This gives us a framework for managing our projects and sets up the timing for the gates.
Note that the transition from Idea to Investigation is not defined as a gate. The screening and approval to move into the Investigation phase is generally managed by a subset of the gate review team and is therefore defined as a separate event. The rest of the discussion will focus on the gate review points as defined here. (Note: for high risk projects with long phases, the management team may require that the team hold one or more Update Reviews between gates. Care must be taken not to impose unnecessary reviews since they take time and will slow down other project activity).
As the teams prepare for and execute gate reviews, there is a specific set of information or criteria that the management team must be able to assess as the basis for the gate decision. Getting the right information into the gate review process is critical to achieving the ideal risk/expense profile.
The fundamental criteria for assessing a project at a gate review are the same at every gate (listed below). However, the degree of scrutiny and rigor that is applied to those criteria must be consistent with the information that can be reasonably captured in the phase preceding the current gate.
|Market Attractiveness||Is the market well defined? Substantial? Growing? Can competitive advantage can be achieved|
|Customer Value||Are customer needs understood and addressed by the product? Does the product provide unique benefits and a compelling value proposition?|
|Technical Risks||Is the product technically feasible? Do we have, or can we acquire the needed knowledge & expertise? Is it reasonable to close the technical gap within a product development effort? Is the complexity and technical risk can manageable?|
|Market Risks||Can the product advantages can be effectively communicated? Is the product consistent with sales channel desires and expectations? Can the projected market share be achieved through the defined sales channels? What is the risk of our competitive advantage being undermined by the time the product is launched?|
|Financial Return||Is the projected financial return adequate? How likely are we to achieve the needed financial return?|
|Regulatory Risks||How challenging is the regulatory environment? What is the likelihood of new regulatory requirements that negatively impact the product?|
|Strategic Alignment||Does the project fit with the product line and business strategy? Do we have the necessary core competencies? Does the project support a balanced project portfolio? Is the project priority high enough to justify resource assignment?|
Table 3 suggests the level of information that would be expected at each gate, reflecting an evolving focus as project data is collected, analyzed and interpreted.
|Criteria||Gate 1||Gate 2||Gate 3||Gate 4|
|Market Attractiveness||Preliminary market definition, market size and market growth estimates based on data that could be acquired without funded market research; preliminary assessment of competitive landscape and trends based on available literature, web sites etc.||Full market definition with credible data to support market size/growth estimates and the baseline forecast; thorough assessment of competitive landscape and trends and implications to the project.||Update to market definition, size/growth estimates and forecast based on any new information collected; updates to competitive landscape and trends as applicable|
|Customer Value||Preliminary assessment of customer needs based on data that could be acquired without funded market research; preliminary assessment of competitive solutions and opportunity for differentiation; preliminary identification of product concepts; preliminary product requirements.||Firm product requirements based on credible set of data based on VOC investigation, competitive benchmarking and technical tradeoff analysis including DFM/A assessments. Compelling value proposition established.||Update to product requirements based on new information. Assessment of ability to meet requirements based on development activities.|
|Technical Risks||High risk areas of preliminary product concepts identified.||Technical data indicates that the selected concepts for both the product and manufacturing/service process designs are feasible.||Prototype test data indicates conformance to key specs with adequate manufacturing margins. All significant technical risks have been addressed. Manufacturing risks are identified. The manufacturing/service process appears to be viable.||Data from early production runs indicates that the product can be built at the projected volume, cost and quality levels. The product is fully validated. All manufacturing/service process/infrastructure issues resolved.|
|Market Risks||Preliminary sales channel strategy identified. Likelihood of achieving projected sales volumes assessed for this channel strategy. Preliminary projection of competitive situation at time of introduction.||Sales channel strategy is firm. Likelihood of achieving projected sales volumes re-assessed for this channel strategy, based on channel input. Projection of competitive situation at time of introduction.||Customer feedback on prototype units supports product strategy. Update to channel strategy and forecast based on latest data. Strategy for communicating product advantage to both channel and end users defined. Product launch preparation is complete.||Launch plan update. Early feedback from customers indicates product acceptance and launch plan effectiveness. Product support infrastructure is in place.|
|Financial Return||Preliminary estimate of the financial return (return factor, NPV and breakeven time, etc).||Firm target cost established. Likelihood of achieving target cost assessed. Financial return updated based on sales forecast.||Bottoms-up estimate of product cost is consistent with targets. Financial return (return factor, NPV and breakeven time, etc) updated based on bottoms-up cost estimate and latest sales forecast.|
|Regulatory Risks||Preliminary assessment of applicable regulatory standards.||Full assessment of applicable regulatory standards.||Update based on new data or regulations.|
|Strategic Alignment||Fit with the business strategy and core competencies; supports a balanced project portfolio; high enough priority to justify resource assignment.||Fit with the business strategy; fit with core competencies; supports a balanced project portfolio; high enough priority to justify resource assignment.||Fit with the business strategy is high enough priority to justify resource assignment.|
The gate review criteria shown in Table 3 imply a set of tasks that the team must execute in the preceding phase of the project. It is helpful to define the development process to include the tasks that should be performed in each phase of the project as shown in the task plans. This process definition will provide consistent guidance to the teams on these key in each phase that are the foundation to fulfilling the gate criteria.
As the team works their way through a project phase they may uncover some information that seriously threatens the project’s viability. If so, they should immediately call a management update meeting where they would make recommendations to either change the project charter or cancel the project. This action is more likely to occur in the early stages of the project, but could occur later under some circumstances. The key here is to kill unattractive projects as quickly as possible. Assuming this is not the case, when the team approaches the end of a given phase, they will need to assess the project against the gate criteria. As part of the gate review, the team should provide their recommendations on the outcome of the gate review. The team’s assessment will be much more detailed than the gate review with the senior managers – put another way, the information presented in the gate review will be a summary of the team’s assessment.
Much of the value of the Gate Review process occurs during the preparation for a gate review – this is not project overhead – a periodic, objective assessment by the team members of the status of the project is a critical element of effective project management.
A project scoring methodology can be used to help the gatekeepers to assess projects against these criteria. An example of project scoring is shown below.
There are different approaches that can be used to organize around gate reviews. One approach is to consolidate gate reviews for several projects and hold them periodically, say once per month. The advantage of this approach is that the managers only have to plan to be available on one day per month to support the gate review process. However, this approach has some significant disadvantages. First, in a large organization, these meetings will become very long and difficult to manage as team after team present their gate review content and/or project updates, some of which will run late even in the most disciplined organizations. Second, this approach causes delays by forcing a gate review to occur at the next available gate review date. With monthly reviews, this delay could be up to 4 weeks and can add up over several gates through the project lifecycle. It is likely that project work will continue through this delay period, but in the event that the project is cancelled or redirected, the work may be wasted.
Another approach is to hold gate reviews on a project by project basis as needed. This has the advantage of minimizing project delays but can make scheduling managers more challenging.
A compromise is to use a weekly or bi-weekly format – to block off time on the gatekeeper’s schedules for the same time every week for gate reviews. If there are no projects to review then there is no meeting. If there are multiple projects to review then an appropriate agenda is established, but ideally no more than 3 reviews per meeting.
The first part of the gate review process is to assess whether the project should continue based on it’s own merits. The second step is to assess whether the project has high enough priority relative to other projects to justify continuing. The second step is a key component of effective portfolio management i.e. managing the overall project stack the business objectives.
The gatekeepers/approvers may cover both decisions in the gate review meeting or may make the second step decision subsequent to the gate review meeting. In the case of the latter, the decision should be made within one business day to avoid potential waste.
The review and approval team is comprised of the senior managers that have profit and loss responsibility for the affected product lines, have responsibility for defining the business plan and overall product development strategy and have the authority to commit resources to the projects. The titles of the gatekeepers will vary from organization to organization but could be vice president level in a smaller company or director level in business units of a larger company. The team should include members with strong backgrounds in product development strategy, product marketing, product technology/capability, manufacturing process technology/capability and finance.
To be effective, the review and approval team members must understand and accept the basic premise of the gate review process as presented here i.e., the process is designed to provide an optimum combination of risk reduction, project expense, time to market and administrative overhead. Risk is inherent in the process and must be systematically reduced across all risk areas (business/marketing risk, technical risk, financial risk).
Excessive, selective focus on risk reduction in one of these areas relative to the others can undermine the gate review process and might actually increase overall project risk. A common example is an excessive focus on financial risk management. If a high level of financial detail is demanded at the Feasibility Start gate in an effort to reduce financial risk, the team will respond by pushing detailed design upstream from the Development Phase to the Feasibility Phase so that they can provide a detailed bottoms-up estimate of product cost. This results in a longer Feasibility Phase which delays the subsequent gate – this gate may have resulted in the project being cancelled or redirected if held earlier, but with the delay and additional resources necessary to perform the detailed design, the project expense is now substantially higher making the decision to redirect or cancel much more difficult and less likely. In such cases, the risk reduction that could have been achieved by holding an earlier gate review could vastly outweigh the benefits of a more detailed financial justification which is dependant on many areas of inherent uncertainty (market size, market growth, market share, cost of goods, etc). Avoiding these pitfalls can be difficult for many management teams since this approach may require them to think differently. For this reason, it is recommended that a process expert play the role of facilitator to help guide the managers to manage risk effectively under the structure of the process, until the organization has mastered the process.
Here are some recommended ground rules for the Gate Review process.
The following is a suggested agenda for a gate review.