The business driven portfolio approach

I have just been editing Jon’s chapter for the book on managing IT investments in the style of a business driven portfolio, and as is happening quite a bit on this project, it got me thinking and I couldn’t help incorporating some of my own views and advice (hopefully the joins won’t be that apparent in the final product!).


This whole area is actually really interesting, a classic “don’t lose sight of the wood for the trees” thing. I can’t remember the number of times I have sat in seminars and training courses listening to people talking about how best to calculate return on investment for a particular project or how to ensure that projects are delivered on time and to budget. Valuable though this might be, thinking and managing at this level is not really adequate to align IT expenditure fully with business priorities.


The discussion in the chapter we are working on is around the need to think and manage at a much higher level. While I can’t provide an actual quote (because we haven’t got the permission of the people we interviewed as part of the research for the book yet) one senior IT chap said that they would be happy if 80% of the 200 plus projects they are running at the moment would deliver 80% of the business value they were planned to, on the basis that this would move the business forward significantly in terms of operational efficiency and competitive edge.


The point he was trying to make is that it is the overall net contribution that matters the most when considering the value added to the business through IT investment and activity. The implication, of course, is that it is OK for the odd project to fail, indeed it is only to be expected, but by the same token, some projects will also over-deliver, contributing in ways that were unanticipated. The trouble is that the good projects are often overlooked and the bad projects are highlighted, leading to IT performance often being judged on the basis of how often projects screw up against their originally declared budgets and timescales. The thing that really matters, the all important net cumulative contribution of value, is frequently never even considered.


The concept of a business driven portfolio approach is designed to fix this. The idea is that if you look across the whole piece, with visibility of the costs, risks and contribution associated with not just ongoing and planned projects, but with the existing systems you are spending time and resource maintaining, you can optimise the overall delivery of value to the business much more effectively. Part of this is making sure you focus on the things that matter the most and avoid squandering time and money on stuff that doesn’t deliver value, but there is also a benefit that comes from better coordination.


As an example of the latter, consider a project to develop a new system. We could spend more time, effort and budget and implement it using the latest SOA approach on the basis that subsequent projects will benefit from the groundwork. Or, we could take the alternative view that the SOA approach would undermine the project level ROI case so cannot be justified. If the latter wins out, the short term numbers might add up better, but business is prevented from taking an important step into the future that would enhance the delivery of value from that point onwards.


The higher level portfolio driven approach avoids this kind of false economy, dictating that the short term or parochial notions of project level ROI are subservient to striving for the greater good and maximum overall contribution on an ongoing basis.


Of course building and maintaining the business driven portfolio is a different matter, and for some practical tips on that, you’ll have to wait for the book to be published J


2 Comments Add yours

  1. John Radko says:

    A contributing factor to this can be a generalized fear of failure. The portfolio approach is definitely the appropriate framework, but if people are too sensitized to failure it will lead to both too much attention to it, and also — somewhat paradoxically — more of it.

    Fear of failure leads to more failure because teams become unwilling to admit there are problems, i.e. “we are definitely NOT failing”. This actually increases the likelihood of projects imploding because symptoms are ignored. Even where projects are going well, excessive fear of failure can encourage teams to be overly conservative — which reduces the odds of an “over-deliver”.

    I look forward to the book!

  2. joncollins says:

    Good point John. One of the essential elements we are discovering is the importance of trust, which cannot be given, it must be earned. Both sides often have too much history – fear of failure on one side, lack of belief on the other – which needs to be countered with proven capability. It would be obvious if it wasn’t so difficult to do.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s