twitter2  fb2  in2

Ten Tenets of Fast Projects - Tenet #5: Sharpen your prioritization

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

Tenet #5: Sharpen your prioritization

I have worked with new product development leaders in the past who have said “We don’t prioritize projects in our active portfolio. All projects in the active funnel must be completed according to our agreements. That’s why they are approved to be in the active funnel; and it’s how we drive our teams to get the best performance.” This reasoning may appear to be sound, and perhaps in some industries and for some types of projects this mandate will work well [1]; but in many industries and for many types of projects, the uncertainties in a project are just too high. Unless you have already driven your organization to a high level of conservatism in schedules (read “long schedules”) and have pushed risk-taking out of your process (read “little innovation in your products”), this type of directive will probably fail since few projects can account for the significant surprises that will impact scope, schedule or cost. In short, if you want fast projects and wish to maintain an innovative environment, this idea of no prioritization is a bad one.

Prioritization of projects is almost always necessary for the well-run product development organization wishing to emphasize fast throughput time and at the same time encourage high levels of innovation. This prioritization is essential to allow for well-reasoned decision making, agreed upon at the highest levels when leaders are faced with surprises.

Prioritizing projects can be managed at two different levels: centralized and distributed.

  • Centralized prioritization: In centralized prioritization, a leader or a group of managers at the top of the organization make decisions (which may be revisited often) that result in an ordered, prioritized list of projects. Their reasoning, while probably well informed and carefully considered, may or may not be apparent to those who must execute to this directive.
    • Advantage: The needs and desires of top management are completely accounted for since they are personally performing the prioritization.
    • Disadvantage: Leadership may be too slow to re-priotize due to bust schedules. The development teams may feel victimized due to the seemingly arbitrary changes that impact resource plans.
  • Distributed prioritization: In distributed prioritization, no centrally controlled list is used. Rather at each local major work-center (such as PC Design) prioritization decisions are made based on an agreed-upon algorithm. This local prioritization may be done, for instance, using “cost of delay”, or “scope, schedule, cost” prioritization for each project (see below).

    • Advantage: The work center team can quickly take into account current information; therefore, communication of the priorities will be faster, eliminating the need to question top management about the impact of changed conditions on priorities. This method will drive local understanding and ownership for the decisions.
    • Disadvantage: The prioritization algorithms require careful training. It may not be possible to create an algorithm that accurately represents decisions that people at the top of the organization would make.

Either centralized or distributed prioritization can be made to work, but which will make your team faster will depend on training and sense of urgency. In general, distributed decision making will be faster (see “Tenet #7: Decentralize the decision-making”) but it requires clear understanding of algorithms and training in how to accomplish this prioritization.

For distributed prioritization, there are several ways to create algorithms that will probably represent well the expectations of your sponsors. Two primary methods are Cost of Delay (COD) and Scope, Schedule, Cost (SSC) prioritization.

Cost of Delay (COD)

The COD is a measure of the cost to the company of any delay in the product release time. For instance, it may be expressed in $K/month. COD should take into account the total loss of gross profit over the lifetime of the product due to a late release.

The Cost of Delay for a project can be an excellent way to tie economic benefit (or liability) directly to the prioritization of projects. With this algorithm, projects entering a certain work area would be chosen based on the COD assigned (and hopefully revisited often) to a given project. Alternatively, if projects are expected to spend different amounts of time in the work area, prioritization should be managed using COD*TT (TT=Throughput Time) for that work area. Those projects with a high cost of delay expecting to have long and complex processes applied in a given work area would be prioritized higher.

Estimating the COD is easier than it first seems. An excellent discussion of the cost of delay can be found in Donald Reinertsen’s book The Principles of Product Development Flow: Second Generation Lean Product Development.

An exact calculation would require a perfect understanding of all variables and of the future, but good approximations can be made from rules of thumb and special understanding of critical events (such as market windows closing). For example Reinertsen suggests that a reasonable approximation can be made by estimating the COD in $K/month to be the gross profit expected in one month of mature volume. In other words, the difference in the integrated values of the reference graph of gross profit over time and the delayed gross profit over time is about the same as the gross profit achieved at mature volumes over the delay time. (This rule of thumb assumes that the curves of interest are well behaved. It also assumes the end of life for a product occurs at the same time regardless of the new product launch time, usually a pretty good assumption.) See Figure 5-1. Note that for these graphs, Reinertsen’s COD rule of thumb estimate is a little high for the red line and a little low for the green line. But as a rule of thumb it is very useful.

I have personally tried this rule of thumb using real data from several real projects, and I found that the rule of thumb value is either pretty close to the actual value, or underestimates it and therefore represents a minimum value. For real projects, the result of a late project is likely to be lower mature volumes as well as a loss of early revenue. In fact, missing certain market windows may damage the lifetime gross profits so as to make the project no longer worthwhile.


Figure 5-1: Example Gross Profit graphs illustrating the impact of late projects, and the calculation of Cost of Delay.


Calculating the COD in this way, as a loss in gross profit equivalent to mature volumes for the length of time equivalent to the delay, is an easy and useful estimate. If necessary, adjustments can be made for known impacts due to market windows or other major loss of revenue. The COD calculated in this way should be thought of as a minimum loss. The actual COD is likely to be higher.

Scope, Schedule, Cost (SSC)

Leaders of the NPD department need to optimize the use of resources to generate the greatest increase in shareholder value. Since not all projects have the same value to an organization, trade-offs between projects may be necessary, robbing from one project to help another. Additionally, a project portfolio should include a balance of different types of projects, some projects where schedule speed is essential and others where keeping project cost low is very important. I am sure you already understand this balance and these traded-offs and have experienced them with your own portfolio. In fact, if you were to look at your entire active portfolio, you should be able to place a priority (1, 2 or 3) on the major three dimensions of each project: Scope, Schedule and Cost [2]. It shouldn’t surprise you that there is a mix of project types, for example:

  • Scope=1, Schedule=2, Cost=3
  • Scope=3, Schedule=1, Cost=2
  • Scope=2, Schedule=1, Cost=1

Additionally, in some cases, project speed may be more important than schedule accuracy. So “schedule” being number 1 priority will usually need some clarification. As a result of acknowledging this necessary mix of Scope, Schedule, Cost prioritization, it should also be expected that the head of product development may have to make significant trade-off decisions. This is, in fact, prioritization. And an algorithm could be created around this, aligned with your company strategy.

For instance, marching orders could be given to the project teams and work area supervisors that any project with schedule=1 have the highest priority, andyour algorithm may be something like this:

  • If Schedule=1 and Scope=2Project Priority=1
  • If Schedule=1 and Cost=2 Project Priority=2
  • If Scope=1 and Schedule=2Project Priority=3
  • If Cost=1 and Schedule=2 Project Priority=4
  • If Scope=1 and Cost=2 Project Priority=5
  • If Cost=1 and Scope=2 Project Priority=6

In the above, I have assumed that the corporate strategies are consistent with schedule being most important, followed by scope (and perhaps implied “innovation”).

It is essential for speed to have some type of prioritization process to allow for rapid and well-judged decisions. Distributed decision making is the best, if it can be managed well. Two types of prioritization algorithms are the cost of delay, and building on the priorities for scope, schedule and cost for each project.

In the next blog, “Tenet #6: Standardize the routine”, I will describe the value to speed of standardizing on the routine elements of NPD. Clearly greater variation and freedom during invention (earlier stages of the process) is expected in NPD. But there are also many tasks, especially in the backend of the development processes, that are common to nearly all projects and standardization can help speed-up delivery of new products.


[1] I have had conversations with some manufacturing leaders (typically a well-controlled, less variable system than new product development) that have shown excellent success by eliminating high priority “lots” or “jobs” from the manufacturing process. It seems that prioritization is not always the best approach, but in product development where the variability is quite high and real-time trade-offs become critical to maximize the value to the company, I have found prioritization of some sort to be essential. Now if a product development organization ever truly reached the low level of utilization of resources as described in “Tenet #4: Reduce the Portfolio”, estimated to be about 75%, then perhaps prioritization would become less necessary. Until that time and due to the uncertainty in new product development, prioritization remains indispensable.

[2] Definitions: Scope of a project includes all dimensions in which project is expected to perform from specifications to product cost to quality; Schedule may have aspects of accuracy or speed; Cost in this sense refers to the project and not the product cost.

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

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 .