In part one, we discussed the notion that while most portfolios of corporate programs and projects look pretty much the same, there are ways to construct a portfolio that “beats the market.” I gave three “beat the market” concepts, or tools — concentration, shorter life-cycle projects and leverage.

John Parkinson 2017 Tech

Now let’s look at approaches to justifying and funding three specific kinds of projects: extensive infrastructure development and deployments that will eventually benefit everyone but that have only a few initial users; projects and technologies that benefit a few users a great deal but will never be widely leveraged; and pilot projects based on promising early-stage ideas that may not pan out.

Most CFOs have to deal with all of these kinds of project from time to time; some face them all of the time. The distinctions are important for several reasons.

First, it’s generally impossible over the long run to fund only projects that have a certain return on investment and that benefit everyone equally. Second, few businesses are so homogeneous internally (even after standardization and simplification) that every part of the organization gets equal benefit from every project. Third, the politics and sociology of organizations and their trading partners makes “rational decision making” in the pure economic sense of the phrase very difficult. Fourth, it’s really not possible to get sustainable competitive advantage from the same ideas and business tools that everyone else has and uses. Someone has to be first to make the differentiation work.

So, given that a CFO can’t avoid the hard parts entirely or all the time, what should he or she be doing about them?

The first situation — investing in infrastructure — is the easiest of the three to attack. No department wants to be asked to bear the total infrastructure cost of a new capability just because they it was the first to see the potential benefit and ask for it. And often, potential users want to be last to sign up because they know that by then the bills will all have been paid and they’ll get something close to a free ride. CFOs faced with these situations (which are actually quite common) have a few options:

• Use “corporate” funds to make an initial investment and repay the “loan” by charging a “tax” on use to everyone as they implement the capability. This works well where there is a clear business case and high probability of successful deployment. The chief information officer is essentially investing on “margin” on behalf of all users.

• Find other users who are willing to be early adopters. In many cases this means going outside the enterprise to your business partners (suppliers and customers) and creating a “consortium” of adopters who together represent a substantial commitment but where no individual member is bearing the entire cost. Many early and successful attempts at this were in the supply chain area.

• Get key technology or service partners to  fund the project either on a “pay as you go basis” or by substituting external investment for the corporate funds in the first option. Generally this will cost you more than paying for it yourself, even on a discounted cash flow basis. But if you don’t have the available capital and the ROI is there, it’s a viable option. All the large technology vendors offer some form of project financing to meet this need, often at very competitive rates.

In the right situation, you can use a combination of all three tactics. Getting the rate of return right isn’t easy, but the necessary financial models are well established and the skills needed to use them should already be in the finance organization or the portfolio management office.

The section kind of project is harder. The challenge of funding projects that will never benefit a majority of users — but will be of enormous benefit to just a few — is one of the core drivers of “shadow projects,” especially in IT. If the CFO won’t approve it, business units use their own money and often go outside the organization for project resources. Some of these resources get to stay around, because the lifecycle costs of these projects are a lot larger than just the initial development cost (think of the early days of the Blackberry or iPhone).

In some organizations, this is exactly what happens. If you have strong governance (so that standards are understood by business units and adhered to) it can be exactly the right answer. Corporate focuses on 65% to 80% of the portfolio and gives “license” to user departments to undertake the rest. Users can negotiate their own hurdle rates and can trade off the capex and opex consequences against other things they might want to invest in — not against the projects of other departments.

What we have done is switched the yield dimension away from a “global” view (all of corporate spending) and towards a proportion of more “local” portfolio views across all spending in an operating business. It gets interesting when you run the yield models both ways to get a range of possible portfolio designs, with clear and quantified trade-offs.

Business managers can now make informed decisions about priorities — you can even implement a system of trading credits to allow departments to swap priorities. You also can and should re-run the models from time to time to see that the optimization trade-offs between global and local remain valid.

We have looked at what the portfolio mix should be in large companies and concluded (this is a reference model, not a prescription) that about 60% of portfolio spend should be managed centrally to provide common services to all users. About 25% should be allocated to projects that benefit some, but not all users, and the remaining 15% should go to focused projects that have relatively few beneficiaries but deliver very large benefits.

The problem in practice is that strong governance is rare and the resulting lack of common approaches and platforms (anti-standardization and simplification) raises business costs significantly — usually without raising returns very much. In effect, the gains from localizing aren’t enough to offset the global inefficiencies they cause. This is another of the really hard parts to portfolio management. Here again, though, there are tools to help and an emerging body of knowledge about how to use them.

Finally let’s look at the challenge of innovation, especially in technology. Big organizations are often encouraged by their technology vendors to work with very early-stage technologies, and there are lots of ideas being pushed by smaller and newer players. Without trying very hard you can burn a lot of time and money trying out these early-stage ideas, most of which (even from the major players) never really make it into the mainstream market.

Sure, somebody needs to be trying all this new technology out (otherwise it will be even less well designed than a lot of what we now get to work with) – but does it have to be you?

It turns out that the answer in most cases is clearly “no, it does not” and “no, it should not.” Very few organizations are effective experimenters, measured by how much of their experimental work directly influences their subsequent mainstream activities. Less than 5% of the companies we have studied or worked with qualified as good or excellent in this regard. You may have other reasons for working with new technologies – rewarding high performing employees for example, or responding to a trading partner’s directive; but in most places it’s a waste of resources. And in the information rich world we mostly live in, you can learn just about as much by being a skilled observer as you can be being a participant — and at a much lower cost.

This is one kind of project that shouldn’t be in most portfolios at all.

John Parkinson is an affiliate partner at Waterstone Management Group in Chicago. He has been a global business and technology executive and a strategist for more than 35 years.