Project interdependencies pose a particular challenge in portfolio optimization. Such dependencies fall into two broad categories:

• Hard dependencies: project A is required for project B to be funded. This is typically the case of infrastructure projects. For example, project A might represent an investment in a new data center (IT), the acquisition of a protein crystallography capability to improve drug discovery (biotech), or the implementation of a pilot smart meter project with a view to a broader smart grid implementation later (utilities). In all of these cases, project A by itself is likely to have a very poor benefit-to-cost ratio. Its sole raison d’etre is to enable other projects — the prizes on which we truly have our eyes.
• Soft dependencies: project A affects the value of project B. This dependency can be positive or negative, and occur on the benefit side or the cost side. For example, there has been much talk recently about whether Apple’s new iPhone 3GS cannibalizes the market share of the iPod Touch (an unfavorable benefit dependency). Conversely, the launch of a new line of product leveraging some of the supply chain elements of an existing offering should create cost-of-goods-sold benefits (a favorable cost dependency).

In this post, we only concern ourselves with hard dependencies. The wrench that foundation projects throw into a portfolio optimization effort is this: how do we prioritize projects that seem to provide little intrinsic benefit, yet are indispensable for “juicier” projects to be available? A simple examination of their benefit-to-cost ratio is clearly inadequate if by benefit we only mean their intrinsic benefit. But is there a possibility of simply redefining what benefit means for such foundation projects? Is it possible to somehow augment the benefit of these foundation projects with the benefit of the projects they enable? Unfortunately, the answer is no: things get more complicated in the presence of multiple dependencies. The following example gives us a window into why.

Illustrative Example

Consider the following mock portfolio. We simplify the presentation by reducing each project to two numbers: its benefit and its cost (we won’t go into the details of how we boiled down the benefit to a single value, here). An arrow represents a requirement: the project at the origin of the arrow is required for the project at the end of the arrow to be available.

The following table tells the story of what the optimal portfolio looks like for an increasingly higher budget. (The reader could easily verify this by hand.)

This table showcases some of the subtleties associated with the valuation of a foundation project. If somebody were to ask, what is the “full benefit” of project #2 (not just its intrinsic benefit), the answer would be very different (if at all defensible) depending on the line we examine in this table.

At the heart of this difficulty lies the following fact: in the presence of dependencies no easy ranking method allows one to decide how or when to fund certain foundation projects. Instead, a full-blown optimization is required, taking into account the entire universe of projects. We have already discussed this topic in this previous post.

Folio Priority System automatically handles such complex dependencies in a seamless and user-friendly way.