When it’s Time to Kill a Project – Part 3

Previously, we created a hypothetical project portfolio to examine that very question. Let’s review…

Project Alpha was approved because it looked like a winner (part 1). But midway through the project, financial metrics took a turn southward. Even though project Alpha’s financial metrics are headed in the wrong direction, Alpha still looks like a decent bet compared to other projects in the portfolio based on a remaining cost basis (the correct way to compare alternative projects – part 2). And Alpha’s strategic score is still the highest of all the projects in the portfolio.

Strategic scoring is a way to evaluate your project portfolio on qualitative factors which are known to be drivers of new PD success for your company. Projects are scored by the team responsible for managing your gate process. Strategic scoring factors usually fall into categories such as:

• The product’s strategic fit and importance to the business strategy.

• The product’s competitive advantage in the eyes of the customer and relative to the competitive landscape.

• The attractiveness of the market in terms of size, growth potential and profitability.

• Your company’s core competency in terms of technology, operations, marketing and distribution.

• Program risks including technical feasibility and relative certainty of schedules and financial models.

Research by Cooper and Edgett show that strategic scoring, although not as popular as financial metrics, yields better results – i.e. project portfolios with higher valuation -- than financial metrics.

If you made a scatter plot of your projects using financial metrics versus strategic value, it is clear that projects with high financial value and high strategic value will get a green light. But, projects with high strategic value and low (or declining) financial scores need more consideration.

I had my own project Alpha once once. Without getting into the grisly details, we were under pressure to get this new product to market by a certain (perhaps arbitrary) date. The only way we could meet that date was to design a product with less functionality. For better or worse, that’s what we did.

The functionality we removed happened to be software interface features. To use an analogy, we decided to develop an iPod without iTunes. Now, would Apple’s iPod sales be lower without iTunes? Probably. The same was true for our product without the software interface features.

Our decision to proceed without the software interface features was not necessarily a bad one. Dropping the software features did shorten the schedule. Besides, we needed the new hardware platform with or without the software interface. This product brought new benefits to our customers and gave us an opportunity to introduce several high margin accessory products too. And, we could always add the software interface later if we wanted to make that investment.

The downside of our decision to proceed without the software interface was we had to temporarily scale back our sales expectations. Just like in the project Alpha example, sales and gross profit forecasts ended up being lower at later gate reviews than at the first gate review when the project was approved. But, just like Alpha, the strategic importance of our product warranted moving forward in the face of declining financial metrics.

We have not discussed how to handle risk and uncertainty in your portfolio management process. How do you make Go/Kill decisions when you are dealing with risk or uncertainty? Simply killing all projects that have high degrees of risk or uncertainty on the front-end will prevent you from making big mistakes. But, that approach means you will not have many big wins either.

You can use your gate process to manage risk by proceeding incrementally. Think of this incremental approach as buying options on the project. I’ll cover how to use your gate process to make incremental or “options” based decisions in part 4.