Programme, portfolio and asset management

On the surface this an attractive proposition: you regard your projects as a collection of investments. The spread of your investments should reflect your risk profile, and you balance your finite budget across your investments accordingly. If you’re a low-risk organisation you may choose to put, say, only 10% of your budget into high risk/high yield projects; others might balance things differently. (We might also want to know who classes a project as high risk, which might lead us to the programme equivalent of an independent ratings agency. This analogy could be fun.)

But scratch the surface and the analogy breaks down. Can you really “sell” a non-performing project? I think that’s difficult. Any project takes time to ramp up in its effectiveness — even agile projects with regular delivery. Selling is difficult. The exception is when your activity is predominantly business as usual (BAU), but most sizeable organisations don’t manage their work like this — rightly or wrongly.

The most enlightening insight, I thought, came from one of our number who said that instead of thinking of the portfolio as being a collection of projects we should think of it as a collection of our assets: the CRM system, the intranet, the finance system, and so on. This way the portfolio management becomes how much we invest in maintaining, developing and decommissioning these systems — and introducing new ones. We can manage our future by shifting our budget between asset development. I see this as being a very effective take on things. After all, the real value of development comes not from the development itself (the projects) but from the things that development produces (the assets).