Optimal project selection is easier said than done. It is easier for two projects at a time, as it was in our aquarium example, because there are only four options to consider: take neither, take one, take the other, or take both. But the complexity quickly explodes when there are more projects. For three projects, there are eight options. For four projects, there are sixteen options. For ten projects, there are about a thousand options. For twenty projects, there are over a million options. (The formula for the number of choices is 2N , where N is the number of projects.) Even the simplest corporate projects can easily involve hundreds of decisions that have to be made. For our little aquarium, there are about 54,000 different fish species to consider—and each may interact with many others. These choices do not even consider the fact that some projects may allow other projects to be added in the future, and that many projects are not just “accept” or “reject,” but “how much project to take.”
To help us determine which projects to take, we need to find suitable heuristics, i.e., rules that simplify decisions even if they are not always correct. One common heuristic algorithm is to consider project combinations, one at a time. Start with the project combination that, if you were only allowed to take two projects (one pair from a set of many different projects), would give you the highest NPV. Then take this pair as fixed, i.e., treat it as a single project. Now see which project adds the most value to your existing pair. Continue until adding the best remaining project no longer increases value. Computer scientists call this the greedy algorithm. It is a good heuristic, because it drastically cuts down the possible project combinations to consider, and usually gives a pretty good set of projects. There are many possible enhancements to this algorithm, such as forward and backward iterations, in which one considers replacing one project at a time with every other option. Full-fledged algorithms and combinatorial enhancements that guarantee optimal choice are really the domain of computer science and operations re- search, not of finance. Yet many of these algorithms have been shown to require more time than the duration of the universe, unless you make simplifications that distort the business problem so much that the results seem no longer trustworthy. Fortunately, economics is in our finance domain, and it can also help us simplify our project selection problem.