By:

Too many projects in the development pipeline is a common but serious complaint in new-product development departments. Pipeline gridlock leads to under-resourced development projects, which end up taking too long to get to market, and then often under-perform. Solutions are offered—Gates with Teeth, Red Flags, and the Productivity Index—to achieve a more balanced development pipeline with fewer projects but better projects.

Too Many Projects in the Pipeline

Portfolio management is about translating your business’s innovation strategy into investment decisions on specific new-product projects. Since its popularization in the mid-1990s, new-product portfolio management has faced a number of challenges, as industry struggled to get it right. The most frequently cited challenge is pipeline gridlock—that is, simply too many development projects in the pipeline for the available resources.1,2,3,4 Portfolio managers are “normally concerned and overwhelmed with issues like the prioritization of projects and the continuous distribution of personnel from the different projects to overcome the urgent crises.”5 The result is that people resources are spread too thinly across too many projects, so that every project, even the important ones, are under-resourced.6 The lack of needed resources is one of the fundamental reasons why projects take so long to get to market, and is also blamed for shortcuts taken to save time and effort, that later come back to haunt the project team.7

The Role of New-Product Portfolio Management

The accepted definition in prior research states that “new-product portfolio management is a dynamic decision process, whereby a business’s list of active new-product (R&D) projects is constantly updated and revised. In this process, new projects are evaluated, selected, and prioritized; existing projects may be accelerated, killed or deprioritized; and resources are allocated and reallocated to the active projects.”8,9 The PDMA Handbook definition is much the same.10

A Failure to Kill Bad Projects

One of the reasons for too many development projects is the failure to kill bad projects in a timely fashion. Projects often look good at their beginning, and thus many are initially approved.11 Over time and once into development or beyond and as new information becomes available, some of these “approved projects” lose their luster. By now, however, the project has momentum: They get “a life of their own” and proceed though development regardless, the result of company politics; executive pressure; sunk cost reasoning; financial reasons (it’s in the budget!); emotion and enthusiasm by the project team or management; or simply the lack of a kill mechanism in the process.12 Thus, stopping such projects halfway through development or beyond is like trying to halt an express train at full speed.

Fewer Projects, Better Projects!

To maximize R&D productivity, the answer is to focus your resources: Undertake fewer projects but better projects, resource them properly, and get them done proficiently and in a timely fashion. (Here “productivity” is “output for a given input,” for example “profitability per R&D dollars spent”). An admirable goal, but tough to achieve. Three proven solutions that help eliminate weaker projects and yield focus include:

  1. Real time monitoring and tracking of projects – to spot projects in trouble and to take the needed action early. Sometimes the decision will be Kill, and to re-allocate the resources to higher value, more meritorious projects, the net result being a more productive portfolio. But what metrics should one use to track these projects?
  2. Tougher gates – designed to weed out the weaker, lower value projects before spending more money on them in the next stage. But how does one operationalize “gates with teeth?”
  3. Regular portfolio reviews, with a rigorous ranking and prioritization of projects based on value. The result is a shorter list of better projects and a more productive portfolio. But how does one force rank a set of varied projects against each other?

Let’s see how each solution works in practice.

Monitoring Projects in Real Time

One solution is to monitor new-product projects on an on-going basis and to kill the bad projects in real time.13 This is one of the keys to avoiding overloading the development pipeline. But what metrics does one use to monitor projects over time? Too many firms gauge the continued merit of a project on the basis of traditional project management metrics: meeting milestones (on schedule) and staying within budget. The familiar traffic light used in project management—red, yellow and green lights to signal behind or on schedule—is an example. If the project is “on schedule and on budget,” then all is fine and the default decision is “continue.”

Merely staying on schedule and within budget is a poor reason to continue spending on the project, however: A project may be on schedule and within budget, but because the business case has changed may have become a bad investment and should be killed. Rather, the need here is to determine and monitor the economic health or value of the project as it moves forward.

Track the Productivity Index

The Productivity Index (PI) is a useful metric to gauge the economic health of a project in a dynamic, real time way. The PI is simply the value of the project divided by the constraining resource, usually person-days or dollars. It gauges what value is added for every additional unit of scarce resource—person-days or dollars—that is spent on the project. In effect, the PI gauges the “bang for buck:”

Productivity Index

In practice, one simply takes the estimated NPV from the project’s Business Case, updated as the project moves forward, and divides by the person-days or dollars that must be spent in order to complete the project. Note that sunk costs are not relevant to the determination of the PI, only the “go forward” costs and person-days are counted.

Example: Project Delta is tracked over time for its one-year development, using its Productivity Index (PI) shown in red in Figure 1. The PI starts out at $16.7K per per-day at the point of project approval (at month zero), and ideally should follow the blue line, steadily upwards (the blue line is the original forecast). Note that as one approaches the end of the development (month 12), there remain fewer and fewer person days of work remain to be done, so the blue line forecast starts to rise quickly as the PI’s denominator approaches zero.

Around month 7, however, Project Delta gets into trouble: The Business Case is revised downwards due to less-than-enthusiastic customer feedback on early prototypes, and also the number of days to complete the project increases because some tasks are taking longer than forecasted. So, around month 7, the red line in Figure 1 starts to dip—the additional person days spent yield negative incremental value—and thus signals that it is time for a tough rethink of this project. The revised PI forecast for the rest of the project (the red dashed line) is also disappointing. An immediate Go/Kill gate meeting is scheduled.

Productivity Index chart

Use Red Flags to Spot Projects in Trouble

Tracking the project’s economic health with the PI is a very useful way to signal a potential kill decision, but other negative situations can also occur. What happens when a project misses milestones, or its technical feasibility drops within a stage? Do you wait until the next gate to address the problem and kill or redirect the project? Definitely not! An effective solution is to employ a system of red flags so that action can be taken, and there are no surprises when the project reaches the next gate review. A red flag here is much like a red flag at an auto racetrack. When the red flag is dropped, every driver takes action: There is an emergency on the racetrack, and all the race cars must stop.

Red flags work much the same way for new-product projects.14 Whenever a project gets into trouble, the project leader is required to “throw out a red flag.” The flag is picked up immediately by the PMO Manager (Project Management Office) or Process Manager, who meets with the team leader to discuss the seriousness of the situation; they alert the gatekeepers (senior management), and an emergency gate meeting may be scheduled. The notion here is not to wait out the situation, but to take immediate action to correct the problem or to kill or redirect the project.

A red flag is triggered by a number of negative conditions, for example a significant decrease in expected sales or profitability, falling behind schedule, going over budget, hitting technical roadblocks, or having to omit key product features. Whenever any of these red flag conditions occur, the project leader throws out a red flag.

Build In “Gates with Teeth”

Although your company might have installed a Stage-Gate system to drive new product projects to market, the gates are often either non-existent or lack teeth.15 The reason: Management does not know how to say “no!” Thus, even though gate meetings are held with the best of intentions—to provide a critical evaluation of the project and make a Go/Kill decision—the Kill option is rarely exercised. And like the addictive poker player who does not know when to fold his hand and walk away from the table, there are many good (and not so good) excuses for continuing to push the project onward. Even worse, in many firms we have investigated, there was never an intention to kill a project once underway. After the initial Go decision, the gates amount to little more than a project review meeting, an update for management, or a milestone checkpoint, but not a serious Go/Kill and investment decision meeting.

Commit the People Resources at Gates… Really!

Gates are not simply project reviews nor project milestones. A milestone, as the term suggests, is a check that the project is on time (and on budget); but it is not a Go/Kill decision point. Rather, that’s the role of a gate: A gate is an investment decision, a decision to commit people and funds: a firm commitment of resources to a project leader and team to execute the next stage of the project.

So make it a rule: If the gate decision is Go, then the resources must be committed. If the people resources are not available (now or in the immediate future), the project cannot be given a Go decision. A Go decision without a resource commitment is a “hollow Go decision.” The result of such hollow Go decisions—Go without resources committed—is that there is no limit to the availability of people, and thus too many projects get approved. But by knowing the limit on total people resources available, and deliberately allocating some of these people to specific projects at each gate meeting, an automatic limit exists to the number of projects that management can approve.

Monitor the Resources Committed

An important task of the PMO or Process Manager is to keep track of resource allocations by project and by person. Someone from the PMO usually attends each gate meeting, often as the gate facilitator. If resources really are committed at the gate, then they can record those resource commitments—people, person-days and funds. Then it’s a matter of keeping track of these numbers. While resource management software exits, a simple spreadsheet, one page per month, can also do the job (see Figure 2). Here, people are noted across the top of the sheet, and projects are down the left side. The number of person-days in noted for each row and column, based on the decisions made at the gate meeting.

The PMO manager can now check to see that individuals are not overloaded, and she can also see how many resources are going to each project (versus what was requested by the project leader at the gate meeting). This information is useful when assigning people to projects at gate meetings. For example, three people in Figure 2 are heavily overloaded—their total assigned days add to more than 100% each for the month (noted in red) and thus these three people cannot be assigned to any more projects.

In addition, it often becomes very clear that a project is heavily under-resourced. For example, in Figure 2, three new-product projects have less than one FTE (full-time equivalent people) each, which likely means they are resource deficient (noted in orange).

Resource allocation chart

By keeping track of people and commitments in such a chart, the PMO manager is in a much better position to advise on assignment of people at gate meetings, and also which projects may need more resources at gate and portfolio review meetings. In this Figure 2 example, the three heavily under-resourced new-products were put on hold, and another low value project was terminated, cutting the number of new-product projects from 8 down to 4. The freed-up resources were then re-allocated to better projects, thereby somewhat alleviating their resource deficiencies.

Apply Visible Go/Kill Criteria at Gates

Decisions made at gates are very often wrong. For example, the PDMA estimates that for every four projects that enter the heavy-spending Development stage, only one becomes a commercial success (the other three either are later cancelled, often after considerable resources have been spent, or fail in the market).16 This success rate of “one right decision out of four” needs improvement.

One way to sharpen the gate decision is the use of visible criteria for go. Criteria for go are not just “readiness check” questions to check that certain deliverables are in place or tasks completed, but are tough criteria that look at the attractiveness of the project from an investment perspective.

Financial Criteria: Most firms use NPV or a similar metric to help make the investment decisions on new-product projects. The problem with such financial certain is not the method, but the data. Indeed the limited research done here shows that when financial models are applied to new-product projects, the results are traditionally unreliable, especially pre-development when the key investment decisions must be made.17 Thus, financial models are useful in that they provide an indication of the project’s commercial prospects, and often reveal how much is unknown about the project; but if Go/Kill decisions are made based solely on financial criteria, expect many wrong gate decisions!

Qualitative Scoring Models: A scoring model, comprised of a short list of qualitative screening criteria, can be used in conjunction with financial criteria to improve the quality of the gate decision. Numerous factors have been shown to correlate strongly with new product success and profitability, and should be used as criteria.18,19 As a result, research-based scoring models have been developed that predict new-product outcomes reasonably well, as high as 83 percent accurately, pre-Development.20 Many of the models were initially developed privately within corporations, but in recent years, more are found in the public domain.21 Seven proven criteria for such a scoring model are in Figure 3.

Projects rated by gatekeeper

In practice at gate meetings, following an update presentation of the project by the project team, each gatekeeper scores the project on these criteria using a scorecard (usually on 0-10 or 1-5 scales). These gatekeeper scores are collected and displayed on the meeting room screen (Figure 4); differences between gatekeepers are usually evident, and promote a solid discussion and debate. Then the Go or Kill decision is made, and if Go, the resources are committed (In the example in Figure 4, a score of 65/100 is a “pass”). This approach is loosely based on the Delphi method, which has proven useful when evidence is lacking or limited (Delphi relies on “collective intelligence” of group members to jointly produce better results than anyone in the group could produce on their own, resulting in a better decision). This transparent decision process yields a fruitful discussion, and usually results in more thoughtful and better Go/Kill decisions.

Results of gatekeeper scoring

Portfolio Reviews to Rank and Prioritize the Projects

Portfolio reviews are not just a chance for management to get a quick update on existing projects, but a meeting of senior people to address three vital questions:

  1. Do we have the right prioritization of projects: Are the best projects really at the top of the list and getting the resources they merit?
  2. Do we have sufficient resources: Have we applied enough resources to adequately resource all the active projects in our portfolio and get them done on time?
  3. Do we have the right balance and mix of projects: Or do we have too many “tweaks and modifications” that consume far too many resources, and starve the more valuable projects?

The Productivity Index to Rank Projects

Ranking projects by their NPVs or some similar profit metric is not the way to prioritize development projects. The result is a sub-optimal list of projects. Instead, the Productivity Index, introduced above, is an effective way to prioritize projects when there are constrained resources, which is usually the case.22 Recall from above: The Productivity Index is simply the value of the project divided by the constraining resource, usually person-days or dollars.

In practice at a portfolio review, projects are force ranked 1 to N down the list. Resources per project are added up, and when the resource limit is reached, a line is drawn: Those projects below the line are killed or put on-hold, and their resources are re-allocated to the better projects above the line. Ranking projects by this Productivity Index is one way to cull out the lower “bang for buck” projects—they fall to the bottom of the ranking list. Done correctly, this method maximizes the value of the development portfolio for a given resource spend.

Example: Acme Company has too many active projects in their portfolio, and so projects are taking too long.23 The portfolio manager produced a list of the 16 active major projects—Figure 5—which showed the actual resources going to projects (FTEs) and also what the project leader had reasonably requested. As quickly seen from Figure 5, the “resource demand” greatly exceeds the “resource supply:” 60.7 FTEs versus 26 FTEs. The total resource requirements for all 16 projects is 2.3 times the 26 FTEs available! Little wonder that projects are running behind schedule. Further, almost all projects are under-resourced (actual versus needed resources), with some projects having less than one-half of an FTE assigned; and two exec-sponsored projects (Dental A and Pump, both circled) are consuming 66% of the resources.

List of major projects before ranking

We then force-ranked the projects from best to worst using both the Productivity Index and the Project Attractiveness Score (based on a scorecard method), both shown in Figure 5. The re-ranked result is in Figure 6. After ranking the projects and adding up resources per project (final column), the resource limit is reached after the sixth project. Thus, 10 of the 16 projects were put on hold (shown in red), and their resources re-allocated to the top six projects. As a result, excluding one exec-sponsored project, the other five top priority projects saw their resources increased by a factor of 3.0, and could now be accelerated. A simple procedure, but very effective.

Strategic Buckets to Achieve the Right Mix and Balance of Projects

Strategic Buckets is a best practice designed to move the firm towards the right mix and balance of projects.24 Too often, so many immediate and small projects—fixes, modifications and tweaks—are underway that there are few resources left for the major projects.

In using Strategic Buckets, management makes an annual strategic decision to establish buckets of resources for different types of projects. This strategic approach is based on the simple premise that “strategy becomes real when you start spending money”… so, make the spending (allocation) decisions!

Here’s how it works:25 Various categories or “buckets” of projects are defined, from smaller improvement and modification projects through to product innovations (Figure 7 ). Next, the business’s leadership team makes a strategic decision about what proportion of R&D resources goes to each bucket, setting aside resource buckets for innovations versus improvements versus single customer requests, and so on. The distribution of resources is dictated by the business’s strategy.

Active and proposed development projects are next categorized by bucket and rank-ordered within each bucket until there are no more resources in that bucket. Each bucket has its own ranking criterion. And dimensions other than project types can also be used here, although project types is a popular dimension. For example, resource splits can be by market sector, geography, technology types, and product lines.

How does one determine the appropriate split of resources across project types? No magic answer exists here, any more than there is a single optimal split among stocks, bonds, and bank deposits in an individual’s personal investment portfolio. But the decision must be made. Failure to make a strategic decision here will result in a split based on a series of ad hoc tactical decisions made as the need arises. And this default option is usually wrong!

Strategic buckets

In deciding the optimal split for your company, start with the current breakdown of resources, as determined by your current-state assessment. Merely knowing the current resource split—something that is not always visible in many businesses—will suggest what the split should be, for example, that certain buckets should obviously have increased resources and others should be decreased. Then look at your innovation strategy and its goals and objectives. Consider too your historical track-record with different project types. Another decision input is where best-in-class firms spend their money (a guide, based on higher performing businesses, is shown in Figure 8).26

Example: Senior management in Beta Company meets and reviews their current spending splits by project type. Minor projects seem to be consuming more than they should. A strategic review ensues, including a look at the performance of past projects and the opportunities in each bucket. Then management “votes” and decides on the split shown in Figure 7 above (R&D in dollars per year in each bucket).

Next, active projects are categorized by bucket, and then rank-ordered from best to worst in that bucket, as in Figure 7, much like in the ranking example above. When the resource limit is reached, a line is drawn: those projects below the line are either killed or put “on hold.”

Note that different criteria are used for the ranking in each bucket. In Figure 7, the Productivity Index is used to rank the innovation projects, while cost reduction projects use a simpler ratio (the cost-savings per person-days of work).

When used over time, the method ensures that the projects “in” the portfolio and the spending breakdowns across buckets truly mirror the strategic priorities of the business. And resources are reserved for bolder projects: The method protects higher risk, innovation projects, because they are not compared to predicable, smaller ones; projects are only ranked against similar projects within their own bucket, not across buckets. Additionally, the method limits the number of projects within each bucket: Once the resource limit is hit, projects must be put on hold or killed.

Guide to resource allocation

Making It Work

“Too many projects in our development pipeline” is a common problem in industry, and also is the root cause of much of what ails new-product development. When projects are under-resourced, important tasks are skipped, such as doing the front-end homework, the voice-of customer study, or the extra technical work required to truly delight the customer. And so the project underperforms financially, or it misses its launch date.

Solutions do exist: The goal is to do fewer projects but better projects, and resource them properly. Approaches to achieving this are offered: Some solutions focus on individual projects, such as monitoring projects in real time by tracking the productivity index; the red flag system; monitoring resources going to each project; and finally, tougher gates to kill weaker projects. Other solutions look at the entire portfolio of projects: These include the use of Strategic Buckets to get the right mix and numbers of projects, and portfolio reviews to force-rank projects, thereby eliminating lower value ones. Each of these solutions does take some effort, but then the cost of continuing with too many projects in the pipeline is huge.

About the Author

Dr. Robert G. Cooper is ISBM Distinguished Research Fellow at Penn State University’s Smeal College of Business Administration, USA; and Professor Emeritus, DeGroote School of Business, McMaster University, Canada. He pioneered the original research that led to many groundbreaking discoveries, including the Stage-Gate® Idea-to-Launch process. He has spent more than 30 years studying the practices and pitfalls of 3,000+ new product projects in thousands of companies.

LinkedIn

Email: robertcooper@cogeco.ca

Webpage: www.bobcooper.ca

References

  1. Cooper, R.G. & Sommer, A.F. “New-Product Portfolio Management with Agile: Challenges and Solutions for Manufacturers Using Agile Development,” Research-Technology Management, 63:1, 2020, pp 29-36: http://www.bobcooper.ca
  2. Dalton. M. “Manage Pipeline Bandwidth to Avoid Derailing New Products,” Industry Week, Aug 23, 2016: https://www.industryweek.com/process-improvement/manage-pipeline-bandwidth-avoid-derailing-new-products
  3. Thomke, S. & Reinertsen, D. “Six Myths of Product Development,” Harvard Business Review, 90:5,2012, pp 84-94.
  4. Edgett, S.J. “Portfolio Management for Product Innovation,” PDMA Handbook of New Product Development, 3rd edition, ed. K. B. Kahn, Hoboken, NJ: John Wiley & Sons, Inc., 2013, Ch 9, pp 154-166.
  5. Amaral, A. & Araújo, M. “Project Portfolio Management Phases: A Technique for Strategy Alignment,” World Academy of Science, Engineering and Technology International Journal of Economics and Management Engineering, 3:10, 2009, pp 1919-1927.
  6. Elonen, S. & Artto, K.A. “Problems in Managing Internal Development Projects in Multi-Project Environments,” International Journal of Project Management, 21:6, 2003, pp 395-402.
  7. Cooper, R.G., Edgett, S.J. & Kleinschmidt E.J. “Benchmarking Best NPD Practices-2: Strategy, Resources and Portfolio Management Practices,” Research-Technology Management, 47:3, May-June 2004, pp 50-60.
  8. Meifort, A. “Innovation Portfolio Management: A Synthesis and Research Agenda,” Creativity and Innovation Management, 25:2, 2016, pp 251-269.
  9. Cooper, R.G., Edgett, S.J. & Kleinschmidt, E.J. “New Product Portfolio Management: Practices and Performance,” Journal of Product Innovation Management, 16, 1999, pp 333–350.
  10. PDMA Handbook of New Product Development, 3rd edition, ed. K. B. Kahn, Hoboken, NJ: John Wiley & Sons, Inc., 2013, Glossary, p 461.
  11. Cooper & Sommer, endnote 1.
  12. Aberdeen Group. The Product Portfolio Management Benchmark Report, 2006: https://www.plm.automation.siemens.com/zh_cn/Images/aberdeen_portfolio_mgmt_tcm78-5843.pdf
  13. From Cooper & Sommer, endnote 1.
  14. Cooper, R.G. Winning at New Products: Creating Value Through Innovation, 5th edition, New York, NY: Basic Books, Perseus Books Group, 2017, p 349.
  15. The term “gates with teeth” comes from: Jenner, S. “‘Gates with Teeth’: Implementing a Centre of Excellence for Investment Decisions,” Proceedings, First International Stage-Gate Conference, St. Petersburg Beach, FL, 2007.
  16. PDMA attrition curve: Product Development & Management Association, Chicago IL.
  17. Based on analyses of actual versus forecasted sales or profits of NPD projects. One study in the public domain is from Procter & Gamble; the “50% success rate” is defined as “Actual NPV/Forecasted NPV”: Mills, M. Implementing a Stage-Gate Process at Procter & Gamble. Stage-Gate Leadership Summit, Conference, St. Petersburg Beach, FL, 2007.
  18. Cooper, R. G. “New Products—What Separates the Winners From the Losers and What Drives Success,” PDMA Handbook of New Product Development, 3rd edition, ed. K. B. Kahn, Hoboken, NJ: Wiley. 2013, Ch 1, pp 25-33.
  19. Cooper, R. G. “The Drivers of Success in New-Product Development,” Industrial Marketing Management, 76, Jan 2019, pp 36-47: https://doi.org/10.1016/j.indmarman.2018.07.005
  20. Bronnenberg, J.J.A.M. & van Engelen, M.L. “A Dutch Test With the NewProd Model,” R&D Management, 18:4: 1988, pp 321-332.
  21. Cooper, R.G. “Selecting Winning New Products: Using the NewProd System,” Journal of Product Innovation Management, 2:1, 1985, pp 34-44.
  22. Matheson, D., Matheson, J.E. & Menke, M.M. “Making Excellent R&D Decisions,” Research Technology Management, 37:6, Nov-Dec 1994, pp 21-24.
  23. Cooper, R.G. “Accelerating Innovation: Lessons from the Pandemic,” Journal of Product Innovation Management, 38:2, March , 2021, pp 1-11: http://www.bobcooper.ca
  24. Cooper & Sommer, endnote 1.
  25. Cooper, R.G., “Where Are All the Breakthrough New Products? Using Portfolio Management to Boost Innovation,” Research-Technology Management, 156:5, Sept-Oct 2013, pp 25-32.
  26. This guide for the split in resources is based on a number of sources; see for example: Cooper, R.G., Edgett, S.J. & Kleinschmidt E.J, “Benchmarking Best NPD Practices-2: Strategy, Resources and Portfolio Management Practices,” Research-Technology Management, 47: 3, May-June 2004, pp 50-60. And: Industrial Research Institute, An update to the 2004 Benchmarking Best NPD Practices: Washington, DC: 2021.

Featured image via Pixabay.