1. Define products based on market needs analysis. Value creation is critically dependent on addressing key unmet market needs. Product definition driven by market needs is safer than one driven by technical ideas. In addition to surveys and interviews, end-user observation in their work environment can produce insights that become essential to successful product definition.

2. Engage cross-functional teams. A successful product development requires input from many perspectives. Modulated inputs from sales, service, support, manufacturing early in the process keep the project team from being blindsided. The process is one of the natural tension involved in trade-offs. Here, an environment of authentic dialogue among team members leads to creative problem solving that adds value.

3. Operate a funnel, not tunnel. Projects are hard to kill but easy to wound. We tend to be hopeful of a good outcome by prolonging a troubled project. We also worry about hurting people’s feelings by killing “their” project. Bandwidth get’s consumed as a project churns all the way to the bitter end.

4. Approve projects only if resources are available. A “go” decision at a gate is empty if resources are not really available. Overloading the resources results in gridlock – slows everything down and eventually results in lost productivity. Mental switching costs are high when developers are multi-tasking on more than 2 projects.

5. Standardize project review templates. A large volume of information can hide facts that are critical for decision making. Using a template that makes key information clear is vital for good decision making. Product cost, performance, remaining risk factors, functions not yet implemented, user/market feedback should always be clearly presented.

6. Avoid executive pet projects.  On the one hand, the forcefulness of an executive champion can help move mountains. On the other hand, pet projects that run outside of process and develop a life of their own can become difficult to contend with at the end. These are often projects that bypass the gates and cannot be killed.

7. Scheduling and decision making. Plan ahead to schedule dates for gate reviews but not so far ahead that the team cannot hold to the date. Moving the gate review dates around can be cause for much consternation. For the process to be meaningful, always make a go/kill/recycle decision at the gate.

8. Limit gate review participation. Good execution of a project may require input and involvement from a large number of people. This should be done during the project stages. At the gate review itself, the participation can be limited to the project’s core team and gatekeepers (the ones who own the resources). A smaller review team avoids unnecessary and unhealthy confusion.

9. Use transparent criteria for decisions. After the presentation and Q&A at the gate review, decisions can be highly subjective. Using a scorecard that allows multiple gatekeepers to rate a project on multiple criteria can be a good way to achieve some objectivity to justify a decision to the team.

10. Conduct portfolio reviews. That attractiveness of a project can only really be gauged in relation to other projects in the pipeline. Since the problem is one of resource allocation, it helps to periodically consider the portfolio as a whole for optimal allocation.