• 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.

The following table illustrates where to draw the funding line, assuming a $10 million budget.

Notice in passing that we would not want to go below a B/C ratio of 1, since funding such a project would yield less benefit than it would cost.

What are the problems with ranking?

Ranking furnishes a fine first cut at an optimal portfolio, but fails to fully address the following situations — all encountered by our clients.

• Ranking cannot handle interdependencies. If project X is required before project Y can truly yield benefits, or even be undertaken at all, clearly looking at the B/C ratio of X alone is inadequate. A mesh of interdependencies is common with complex infrastructure or IT projects, for examples. In that case, a comprehensive optimization of this network of projects is indispensable.
• More commonly, ranking fails to consider alternative funding levels. Imagine that each of the projects on the list, instead of an all-or-nothing choice, could be funded in various cheaper alternatives than the all-out version, featuring a spectrum of lower costs and lower benefits. Conventional ranking would simply pick, for each project, the one alternative with the highest B/C ratio. However, it can sometimes be optimal to try to cut costs on one project to enable another project to be funded in a more expensive alternative.
• Finally, ranking ignores fine-tuning, i.e., the so-called knapsack problem. The knapsack problem is often perceived to be an academic and unnecessary complication for real-life portfolio optimization. In the remainder of this article, we go through a real-life case study to evaluate the validity of this perception.

What is the knapsack problem?

Bear with us as we indulge in one short theoretical paragraph. The knapsack problem goes as follows: imagine you have a bunch of objects of various values and weights, from which you have to select any number to fit into a knapsack. Your goal is to create the most valuable knapsack possible, without of course exceeding the allowable weight capacity.

Source: Dake under Creative CommonsAttribution-Share Alike 2.5 Generic license.

The parallel with portfolio optimization is obvious: value is the benefit, weight is the cost, and the weight capacity of the knapsack is your budget constraint.

A ranking approach to this problem, therefore, would order the objects by decreasing density: the yellow object right underneath the pack has the highest “value density” — i.e., B/C ratio — (2.5$/kg) and will go in first: it adds a lot of value relative to a small weight consumed. The green box at the top left will go last, if at all: its value density is the lowest (.33$/kg).

Now imagine we start fitting these objects into the knapsack by picking the highest-density objects first, very much like we ranked projects by B/C ratio in the table above and started funding them, until we hit our limit.

As many of us know from experience, we might then decide to make some changes “on the margin”: even though object 26 was the last one to go in, it leaves a lot of unused room in the knapsack. It turns out if I removed object 23 and placed object 27 instead, I would fill the entire sack, even though I have sacrificed a higher B/C object for a lower one. The degree of “shuffling on the margin” is difficult to build a good intuition for. Many practitioners dismiss this phenomenon as, precisely, marginal.

We wanted to put this question to the test: is ranking really insufficient? Do we really need to optimize and deal with the nagging knapsack problem, or can we be content with the simpler ranking method?

Does optimization really matter in real life?

Optimization really does better than ranking in “real life.” The following example is taken from a portfolio of 901 real client projects (the data has been disguised by linear rescaling, but the shape of the curves and the conclusions are strictly identical).

The red curve represents the efficient frontier of the simple ranking method. The blue curve represents the efficient frontier of a full-blown optimization.

Notice how an optimization is able to extract more value for certain budget levels than a straightforward ranking. Why is that? There are two main reasons why optimization fares better:

• Optimization switches alternative funding levels in and out as appropriate. Even though a given project may have one clear winner funding level, featuring a higher B/C ratio than other funding level alternatives for this project, it is sometimes appropriate to be less “greedy” and fund a less costly version so as to enable another high-yielding project to be funded. This is the dominant effect in area C of the curve, where optimization systematically beats ranking by about $8 million.There are actually very few projects featuring multiple, alternative funding levels in this database.
• Optimization can handle big discrepancies in project spending. Of course, the most dramatic benefit of optimization over ranking can be seen at A. A single, very expensive project “holds up” other projects from being funded in the ranking method because the expensive project still comes first due to its high B/C ratio. In the optimization solution, rather than holding up the budget gap, other, lower B/C ratios are “filled into the knapsack” until such time as the big project can be funded. At that point, the red curve abruptly catches up with the blue one. The same phenomenon happens at B with another project, and, to a smaller extent, in other places along the curve where kinks are visible. The more heterogeneous the project sizes, the more value a straight ranking method is likely to leave on the table. At its worst discrepancy ca. a $46 million budget, 19% of the value is missed by the ranking method.

This case study should not be interpreted as an indictment of B/C-ranking. But it clearly illustrates one of the advantages of optimization in the presence of multiple funding levels and heterogeneously sized projects.