Integrating Portfolio Management Into the Product Development Process


There are probably numerous ways to extend the product development process to encompass portfolio management, but one critical goal that we are trying to achieve is ongoing portfolio management versus the annual portfolio review approach. Generally, this means monitoring and analyzing the situation and events on a regular basis.

One relatively easy way to start toward an integrated solution is to look for ways to tie portfolio management decisions to major project reviews. Most product development processes in the technology space are based on the stage-gate concept, which requires formal reviews at predesignated milestone points before the project team can continue to the next stage (see Figure 12-3). This is a logical point to extend the normal stage-gate criteria to include a review of how the project fits into the portfolio, how recent project decisions may affect other parts of the portfolio, and how other portfolio decisions may affect this project. In theory, this is not quite as continuous a process as you may want, since portfolio reviews only come at stage-gates and then only for the projects in question. However, depending on the number of projects running simultaneously in your portfolio, progressions to stage-gates may happen as often as monthly, which is certainly much better than only addressing the portfolio once a year.

click to expand
Figure 12-3: Portfolio reviews tied to stage-gates.

Agile Strategy

Tie portfolio reviews to stage-gates as a first step toward 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.

Agile Strategy

Develop and maintain a "master dependency" list for the portfolio, then have project teams address how their projects affect and are affected by this list at each stage-gate.




Agile Project Management(c) How to Succeed in the Face of Changing Project Requirements
Agile Project Management: How to Succeed in the Face of Changing Project Requirements
ISBN: 0814471765
EAN: 2147483647
Year: 2006
Pages: 96
Authors: Gary Chin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net