Integrating Portfolio Management Into the Product Development Process

Stage-gate review meetings should be scheduled at regular periodic intervals (i.e., on the first Thursday of each month), so key managers can get them on their calendars; however, only projects that are at a stage-gate need to be discussed. In fact, at any particular stage-gate review meeting, only one or a few projects may be specifically reviewed, though you can focus part of that review on how the specific project affects and is affected by the rest of the business project portfolio. Even when a minority of the total projects is reviewed, the discussion on interactions with the rest of the portfolio may extend to the majority, if not all, of the portfolio projects.

The first few times that you use this integrated process, you may find that most of the discussion is off-the-cuff or consists of brainstorming. Once project teams realize how interdependent they are and how much they can learn from each other, you can better facilitate a learning process. Project teams will become better able to communicate specific dependencies on other projects or areas of interest to the other project teams in the portfolio, as well as to the stage-gate review committee. By reviewing any particular project's status against a "master dependency" list from the larger project portfolio, project managers can quickly identify issues and synergies that may not otherwise have been specifically identified or discussed.

The idea here is for the project team and stage-gate committee to identify issues (based on the master dependency list), follow them up with a discussion to qualify the discovery, and then scheduling time offline from the stage-gate meeting for further investigation with the appropriate parties. This process tends to help individual projects come together as a single portfolio with common objectives. The result not only adds value to the project, it is partially a criterion for progressing to the next phase.

For example, let's say that the project under review is one of five projects that together comprise a program to develop an ultra -light notebook computer. The team responsible for the video display subsystem comes to the stage-gate review meeting having met all of its objectives for the previous stage. Additionally, it has created a project plan (i.e., a Project Data Sheet) for the next stage and is ready to begin executing on it upon receiving approval from the stage-gate committee, which it fully expects to receive. The video display design is right on target for all specifications except one, steady-state power, which is on the high end of the tolerance but still within spec. The video team considers this a low priority since it is still within spec. This issue, however, comes up at the stage-gate review meeting during a review of the "potential impacts to other portfolio projects". The technical leader from the power-supply team realizes that this could be a critical issue because his team has been considering lowering the steady-state power specification to a point that would put the video display out of spec. A discussion ensues and it is determined that the video team, while meeting its own objectives, should not continue further development until the steady-state power question is resolved.

This example demonstrates how being cognizant of the potential impacts your project may have on other projects in the portfolio, and actively communicating those impacts to others, can help optimize the overall portfolio. This situation may have had a different outcome had the power-supply team identified steady-state power as a potential problem on the master dependency list, with a comment such as "Review all steady-state power requirements with power-supply team before finalizing designs". In this way, the issue could be identified prior to the stage-gate review meeting. Subsequently, it may have been resolved before the meeting as well.