A common root cause of a failed portfolio system is that the fuzzy-front-end is an unmanaged process in most companies. It just happens in an ad-hoc way, with multiple stakeholders trying to influence it in their direction (i.e. the classic engineering versus marketing conflict). With no single point of leadership.

We've been working with a large European venture fund to determine their optimal portfolio of investment opportunities. The modeling concept is based on the work we have been doing prioritizing strategy, markets, customers, product requirements, and new product project portfolios. It is based on the idea that these decisions are influenced by objectives or decision criteria.

At the highest level it seems there are four broad areas that impact the $ success of a company's product portfolio: Whether or not products accurately target the "right" customers and/or market segment(s), Whether or not the "right" product is being developed for and delivered to the "right" customer, Whether or not the product is being delivered to the customer at the "right" time, Whether or not the product is delivered at or under budget

Focus, focus, optimize...

We've documented a series of key success factors (KSFs) concerning the deployment of Strategy Planning and Portfolio Modeling Systems.

We've developed a deployment template that follows the 4-step flow from Strategy Prioritization to Success/Failure Analysis.

We've developed a deployment process flow for engaging management teams in effective new product portfolio prioritization using a 4-stage metric. Each stage increases in degrees of sophistication. These levels permit groups to deploy the process at their level of readiness. Typical implementations see different groups in the organization at different stages. Our clients set a target date for all groups to reach Stage 4, they progress at their own speed gaining value at each stage. The framework provides a metric to measure progress.

This is a recommendation sent to a client concerning a project that lacked a target customer and was late. It discusses a change in behavior that is difficult to make happen; "before-the-fact action" versus "after-the-fact reaction."

Viewing project portfolios against constraints....to determine what can be accomplished with available resources. Traditional "project scoring" systems we see are a list of projects in a spreadsheet scored against some sort of measurement criteria.

20% of the projects generate 80% of the benefit. We see the Pareto Principle at play over and over again as we model NPD project portfolios with clients. Many times, 20% of the projects (i.e. the $'s) generate 80% of the benefit towards reaching an organization's objectives. This means that 80% of the projects fall on the “diminishing returns” part of the cost-benefit curve. Why still do them?

Project Portfolio is a discussion of how to prioritize projects, when resources are finite and you need to select the best portfolio of projects to maximize benefit, or in other words, “Those projects that give you the biggest bang for the buck.” How do you prioritize projects when resources are finite?

In this screencast called “Part B” I will show you the third constraint type using Resources. We’ll deal with the same problem statement, “How to prioritize projects based on a limitation of resources.” We need to select the best project mix to maximize benefit in order to meet our objectives.

In this screencast called “Part C” I’ll introduce the time dimension to the modeling process.

A consistent and fundamental problem we see in our practice is too many projects and not enough resources (people, materials, equipment, and money). Why?

What is the cost of delay? It grew out of our best-practice research, where we observed successful new product development teams using various methods to quantify the cost of schedule delay.

It seems odd to ask this question, Why accelerate?, since it’s obvious in the technology business that you die if you don’t release new products faster than your competition. Fast teams know this reality and communicate the “need for speed” to the engineering teams. In slow environments, this critical information is insulated from the technical teams and only reserved for marketing, finance, and leadership forums.

When implementing improvement systems that impact business processes and require methodology and tools; you must first define the problem you are trying to solve. Often we see organizations start with possible solutions without first define the business problem they are trying to solve.