twitter2  fb2  in2

Tenet #8 - Ten Tenets of Portfolio Management

Rate this item
(0 votes)
by Larry Pendergrass, Principal

Tenet #8: Improve flow.

In my last blog, I spoke of the need create a tiered set of portfolios and associated roadmaps, to pay careful attention to supporting frameworks such as technology, process and competency roadmaps. The PPM team must insist on, and have personal involvement in the creation of these ancillary portfolios and roadmaps. They are feeders into your PPM process, and directly into your project roadmaps.

In this blog I would like to discuss the need to act to continuously improve the flow of projects through the pipeline. The PPM team has the capability through its decisions to improve or completely shut down the flow of projects through the new product development process. At first, many may not see the direct contribution of the PPM process to project flow; however, the PPM team has perhaps the largest lever available to radically change the flow, that of choosing the number and type of projects in the pipeline at any one time. Thus, the balance chosen between “trying doing too much” and “doing too little” is an essential decision-point for the firm.

Flow has been studied theoretically and experimentally in a diverse set of fields, from communication to traffic flow. With the goal of maximizing the flow of objects through a system, we must keep the findings of these various fields in mind and apply them to our new product development system. Specifically, the throughput time (or time in the system) increases as T=s/(1-) with the utilization of the system [1] (where T is the time in the system, s is the service time and  is the utilization level. See the figure below.) Note the rapid increase in throughput time as the utilization exceeds 80%. You can see this at work on or freeway systems as the impact of cars breaking, acceleration, human reaction times, and bottlenecks in the system reduce the flow significantly when too many cars are on the freeway. This is why many freeway on-ramps near large cities use metering lights to regulate the cars let on the freeway. Overloading a system (or even just overloading critical and often bottlenecked resources in the system) reduces the speed in a non-linear way. This is just as true in a product development system as it is on the freeway.

 

figure-4

 

Having a project in the pipeline for a very long time is bad for business in so many ways. The issue is not just that of having few products coming out of the pipeline. Long throughput times also cause issues in meeting the market needs, often assessed at the beginning of the project and dangerously stale by the time the product hits the market. Additionally, having high utilization of resources and too many projects in the pipeline necessarily drives frequent switching of attention from one project to another, risking more frequent and serious mistakes in the product development process. Finally, people are often demoralized if they see projects languishing and not solving the customer problems for which their hard work was targeted.

Of course, if you reduce the utilization of a system to near zero, the flow of products through that system also goes to zero. And if the utilization is high, the flow also goes to zero. So there is an optimal utilization point for any system to create the maximum cadence of high quality products coming out of the system. Since the number and type of project at any time in the pipeline is in the hands of a decision team like the PPM team, this team’s choices will directly impact the speed of the system and the flow of projects through that system.

With this in mind, how should a PPM team behave? To begin with, it is essential that the team has a full understanding of the system utilization levels, and the levers which may be pulled to change that utilization level. Some writers advocate the measurement of the queue levels at key areas in the product development organization with triggers in place to address high queue levels as they occur. But one thing is for sure: your optimum utilization is almost always at a lower point that everyone thinks it should be! This is because all of the pressures in the organization will be to push toward adding one more project, but in the process increasing the utilization in the system. The natural tendency is to be on the high utilization side of the optimization curve. The PPM team will have to fight to reduce the number of projects in the active pipeline to move low enough in utilization to be near the optimum utilization point.

A number of years ago I became the head of an organization that had shown significant trouble in delivering products out of its new product development organization. Although there were many ways we could and did ultimately improve the organization, one of the first and most important decisions was to reduce the number of projects in the active pipeline… by about a factor of four. Far more projects were in the active pipeline than the system could handle. Interestingly, but not surprisingly now to readers of this article, by reducing the number of projects, over the next couple of years we showed the number of products out of the NPD organization increased by a factor of between 5 and 10 times, while at the same time improving the schedule accuracy about a factor of 3. Of course, there were many improvements that added to this kind of result. Not all of the improvement was through reducing the number of projects on which we worked. So your results may vary. But the chances are very high that unless you keep this concept and the graph above firmly in mind at all times, your organization today has more projects in the pipeline that it should for optimal results.

It is incumbent on the PPM team to continuously keep a focus on improving the product development flow. The PPM team has perhaps the largest lever in its hands, that of the quantity and type of projects in the pipeline. Keep a close eye on utilization and queue levels. Your optimum utilization is almost always lower than you think it should be.

 

[1]See for example this slide set on queuing theory: http://williams.comp.ncat.edu/comp755/Q.pdf

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.

Corporate Headquarters:

TechZecs, LLC
1730 Kearny Street,
Suite F-3
San Francisco,  California
94133 USA

Principal and Founder

Dr. Scott S. Elliott
Telephone: +1.415.830.5520
Email: scott.elliott@techzecs.com
           info@techzecs.com

Grab our contact information

qr-linkUsing your smart phones, open your QR Code reader and quickly scan this image to save our contact information automatically .