Leveraging Your Project Portfolio for Better Returns

By John Parkinson  |  Posted 02-05-2005 Print Email
Competitive advantage depends on making concentrated project bets. Is your project portfolio too cautious?

Modern market theory states that markets are so efficient that no one can perform much better than the market average for very long. Transparency—the notion that everyone can see what the winners are doing—will rapidly drive copycat behavior, forcing a rapid regression to the market's mean performance level.

It's also conventional wisdom that, because there are really many "markets" for different classes of investments, you should spread your capital across the different areas where markets are made. This lets you balance risk (that you might lose everything if a single market crashes) with reward (that you might get rich if you somehow bet exactly right).

This is the basis of asset-allocation strategies.

Judging by these theories, rather than try to pick winners, your portfolio should be as much like the market (and everyone else's) as possible. In the financial world this often means following an index (or a collection of indices) that mirror the structure of the market.

If you want to beat the market theorists, you only have three tools: concentration, turnover and leverage. In investment terms this means: (a) fewer but larger bets; (b) short time horizons for the bets to pay off; and (c) using borrowed capital to make the (bigger) bets with.

The basis of your bets is that you can find enough opportunities that the overall market has missed (and hence undervalues), cash in quickly before the market catches on (as theory says it must, eventually), and then move on to the next opportunity.

Notice that this is a very different approach from asset-allocation models that urge diversification across several uncorrelated asset classes, low turnover (to reduce trading fees), and periodic rebalancing of the portfolio as different asset classes go through cycles of performance.

What's all this got to do with IT—and how does it affect the CIO? Think of the typical IT organization as a kind of specialized investor employing an asset-allocation strategy. Using other people's money (business unit capital), the CIO makes bets that investments in technology will generate returns for the business via automation-powered leverage of various kinds—mostly to do with productivity, time to market, low cost of compliance or cost-effective scalability.

The CIO puts together a "portfolio" of systems that are similar to various classes of assets—core business automation, specialized capability, personal productivity and so on. Each of these asset classes has a required investment cycle (build or buy, deploy, support and enhance, retire) and a "yield profile" that should provide the basis for a return on the investment.

The challenge for the CIO—just as it is for the manager of financial assets—is in maintaining a balance among the asset types, most of which have very different yield profiles. Spend too much on core automation efforts and you won't be competitive in emerging areas. Ignore "infrastructure" and your operational costs will increase as changes in technology drive new cost-effectiveness opportunities that you can't take advantage of. Ignore the basics in order to do only innovation-driven projects, and core capabilities suffer. Getting the balance right isn't easy or obvious, but it is critically important.

Most of the CIOs I know have also opted for an IT version of "efficient-market theory," in part because they have limited discretionary investment capital these days. As a result, most IT portfolios look pretty much the same, making truly differentiated technology capabilities quite rare.

Add in the fact that most portfolios also have low "turnover"—new systems tend to be added to older systems rather than replacing them—and corporate IT takes on a "mature" (and complex) look. In financial investment terms the portfolio looks like a risk-averse, infrequently rebalanced 401K.

It doesn't have to be like this, and some CIOs have recognized that a different approach, one designed to beat the market theorists, is possible—although, as with successful financial investment, it takes hard work and it can be risky. Let's look at how our three "beat the market" tools—concentration, turnover and leverage—might apply to managing an IT portfolio.

Concentration.

In most big IT shops, there is still more diversity of technology and platform components than there needs to be. Simplification, standardization and consolidation over the past four years have had a big impact, but a lot more could still be done. CIOs tell me they don't like to be too dependent on a single supplier (they fear "lock-in" and a lack of pricing leverage), while bemoaning the cost of integration and support across multiple products and platforms. A more concentrated strategy does have risks (supplier viability among them), but a simpler, more standardized approach also lets us use our second tool—turnover—more effectively.

Turnover. Turnover affects the IT organization in two ways. First, shorter life-cycle stages (and the projects that we do to implement these stages) gets us to the available benefits of new technology sooner, and allows us to change course (if and when we need to) more frequently.

Frequent, small course adjustments are much better from an investment optimization point of view than large, infrequent course changes, although they require much more sophisticated measurement and decision-support systems.

Second, shorter overall life cycles require us to shift from an ROI model based on costs to one based on returns. In essence, we can choose between increasing our ROI by decreasing the cost for a given level of return, or by increasing the return for a given level of cost. This might seem a minor distinction, but in practice very different investment strategies (and mind-sets) are required to make the different approaches work. IP telephony is a good example.

Once we have gained the cost savings from switching, our attention should be focused on all the other (information-powered) applications that we can base on the new IP devices and capabilities.

Leverage. Our final tool is leverage—using "borrowed" capital to make investments so our bets can get bigger. We've already noted that CIOs use their customers' capital for investments in technology, even though this is often hidden in the ROI model. Yet we can go beyond this. With the right level of concentration and turnover in place, capital from one set of users can create capabilities that benefit others.

Master-data management and common infrastructure investments are good examples. We need to make sure that the first investor doesn't carry all the cost (or risk) when the benefit accrues to others, but as we shall see in future columns, there are several ways to do that.

There are a couple of final twists to worry about. Just as all investments don't have the same unit price or potential yield, not all IT projects have the same absolute cost or level of return.

It's tough to know whether to spend $20 million on one large project, $2 million on ten small projects, or something in between. This is another aspect of balancing the portfolio: In most organizations you want a mix of moderate but certain yields, and high but less-certain yields. Not all the projects bearing higher risks will come out right, but the mix, if managed correctly, will give you the aggregate yield you need. And you don't want anything that has a low and certain yield—unless you have no choice. Most of all, you don't want guaranteed losers—and it amazes me how many portfolios actually contain a few.

Accept the mixed-portfolio notion, and you'll also have to periodically dump investments that don't meet your yield criteria and replace them with ones that do. That means killing projects or platforms that don't work out, and that's always hard to do in IT. Get it all right (or mostly right—no one gets it all right), and you'll be in good shape.

So, what's in your portfolio?

John Parkinson is chief technologist for the Americas at Capgemini.



 

Submit a Comment

Loading Comments...