twitter2  fb2  in2

Ten Tenets of Fast Projects - Tenet #4: Reduce the portfolio

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

Tenet #4: Reduce the portfolio

In most cases, the best way to improve the speed of product development is to reduce the number of projects in the active portfolio or project pipeline. Your choices of the number and type projects in the pipeline at any one time have significant consequences when it comes to the speed of your development systems. The balance chosen between “trying doing too much” and “doing too little” is an essential decision-point for the firm.

Throughput has been studied theoretically and experimentally in a diverse set of fields, from communication to traffic flow. Product development can be thought of as a chain of processes through which specific solution ideas, prototypes and documents, encompassing “products under development (PUDs)”, flow until they are deemed ready for production. Each PUD takes some capacity for its development, including engineering time, modeling and prototyping tool time, testing time and equipment, etc. It is self-evident that trying to develop too many products at the same time will slow everything down, but how can we find the optimum for a given capacity of development resources?

Referring to Figure 4-1 below, queuing theorists have shown that the throughput time (or time in the system) increases as T=V*s/(1-) with the utilization of the system [1], where T is the time in the system, s is the service time,  is the utilization level and V is a single variable representing the variation in the system. Note the rapid increase in throughput time as the utilization exceeds 80%, in fact going to infinity as the utilization approaches 100%. You can see this at work on or freeway systems as the impact of car brakes, 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.

 

blog-4-fig-4-1

Figure 4-1: Impact on Throughput time (Time in a system) from Utilization Levels and from System Variation. Note the knee of the curve moving toward lower utilization levels as the variation is increased.

 

Having a project in the pipeline for a very long time is bad for business in many ways. The issue is not just that fewer 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. For fast-moving technologies like consumer electronics, components can be obsoleted before the development is complete, causing expensive and further time-consuming re-design. 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 your management 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 management 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 [2]. But one thing is for sure: your optimum utilization is almost always at a lower point than everyone thinks it should be! This over-utilization is partially due to the pressures in the organization to push toward adding one more project, and partially because of the natural tendency of management to want to fully utilize every resource. Many pundits say that most organizations will find the best results at about 75% utilization of its product development resources (or even lower) [3]. The management 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.

By the way, we have talked a lot about utilization and making sure your resources are not loaded too heavily. This implies that you should have an excellent resource management tool, and one that it is properly maintained and applied. Resource management is a critical part of your NPD business management processes and in my mind, almost rises to the level of another tenet.

A number of years ago I became the head of an organization that had shown significant trouble in delivering products out of its NPD 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 in Figure 4-1 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 management team to continuously keep a focus on improving the product development flow. Keep a close eye on utilization and queue levels (see “Tenet #8: Watch the Buffers and Queues”, for more information). Your optimum utilization is almost always lower than you think it should be.

In next week’s blog, “Tenet #5: Sharpen your prioritization”, I would like to talk about prioritization: it’s value and dangers, and how to accomplish effective prioritization.

 

 


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

[2] See for example The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen

[3] See for example “3 Secrets of Highly Successful New Product Development Executives” by David Paulson, http://playbookhq.co/blog/3-success-secrets-profit-making-rd-executives-wont-tell/

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 .