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

One of the principles we are advocating in the book is the need to create a common language between business and IT to ensure that there is a common understanding of what the business is trying to achieve, relative priorities, the role of IT, measurement of the business value of IT and so forth. A critical aspect of that common language is the avoidance of technobabble and a focus on the what not the how.

This post from Andrew McAfee regarding “Enterprise 2.0” highlights why this is so critical. In it, Andrew points to a number of definitions provided by contributors at Sandhill.com, including M.R. Rangaswami and Philip Lay:

Enterprise 2.0 is the synergy of a new set of technologies, development models and delivery methods that are used to develop business software and deliver it to users

[T]he three main pillars of Enterprise 2.0 [are] open source programming languages such as the interactive web application development tool Ajax (Asynchronous JavaScript XML), the increasing number of SaaS offerings, and the highly anticipated appearance of hundreds of SOA application modules in the form of re-usable web services.

and highlights the likely response from non-IT business leaders:

I felt that we’d lose the attention of non-IT business leaders as soon as we defined E2.0 as anything except the process of using the new social tools within companies. There’s a large role for business leaders in this process, and I’ve found that they’re willing, even eager, to discuss what that role is.

They’re a lot less eager to hear about software as a service, open source development methods, offhsoring. Their eyes glaze over when these topics come up, and I can almost hear them think “We have an IT department so I don’t have to think about these things.


One can imagine a similar glazing over of the eyes as IT organisations try to sell the technology capabilities of SOA, virtualisation, federated identity, composite applications etc to the business instead of focussing on what those capabilities enable.

Andrew’s conclusion says it all:

IT advocates too often make claims about technologies that are disproportionate to, or even divorced from, what the technologies actually do. Is it any wonder, then, that the IT-business dialog is so tenuous and marked by skepticism, and that IT so rarely has a real seat at the table during strategic discussions? How long should we expect businesspeople to believe technologists’ assertions that a brave new world is at hand, and that it can be inhabited after one more set of trends comes to fruition?

It’s all about the Suits and the Sandals!

I think this sums things up nicely:

Suits and sandals

In a recent post Nicholas Carr calls out a recent Harvard Business Review article (currently freely accessible) by Andrew McAfee, whose work I highlighted in August. In the article, McAfee sets out to help managers grapple with the challenges of technology adoption in the face of an abundance of technologies, a chequered history of IT project success, a more general questioning (thanks to Carr) as to whether IT really matters and whether organisations should actually be doing IT themselves. I certainly found myself agreeing with a lot of the context setting from McAfee.

McAfee goes on to explain that:

technology projects are increasingly becoming managerial challenges rather than technical ones. What’s more, a well-run IT department isn’t enough; line managers have important responsibilities in implementing these projects

Again, difficult to refute. IT and business are so intimately intertwined these days and the focus of IT investment is shifting away from the automation of non-differentiating business processes in the back office and towards those processes which do differentiate: the ones which are often ad-hoc, dynamic and collaborative in nature. Unless the business is involved in identifying the right technology and then facilitating its adoption, the chances of success are limited. Whilst the business knows this, the problem is

they’re not clear where, when, and how they should get involved
Why? According to McAfee it’s because managers lack a model for the role of IT, its organisational implications and what they should do to help it succeed. Our research here at MWD is certainly consistent with this. So, where does this model come from?

That’s where GPTs – General Purpose Technologies – and organisational complements come into play. GPTs are

innovations so important that they cause jumps in an economy’s normal march of progress

with IT following on from earlier examples such as electric power, the transistor, and the laser. Organisational complements are changes in the ways that organisations do things which multiply the effects of GPTs. In the case of IT, these complements are better-skilled workers, improved teamwork, redesigned processes and new decision rights. McAfee believes that IT is different from other GPTs in terms of the relationships to these different complements. He believes there are three categories of IT which vary in terms of the importance of the different organisational complements:

  • Function IT – assists with the execution of discrete tasks and doesn’t bring complements with it e.g. spreadsheets, CAD
  • Network IT – facilitates communication and collaboration between individuals and lets complements emerge e.g. email, blogs, wikis
  • Enterprise IT – specifies and implements business processes and imposes complements e.g. ERP, CRM, SCM

One could certainly argue with the classification since different technologies may fall into different categories dependent on the business process but overall it makes a lot of sense to me – it’s recognised, for example, that big enterprise applications often require changes to business processes and governance approaches.

This classification forms the basis of the missing model, since it provides managers with a way of thinking about the capabilities they need – task execution, communication etc – during technology selection; the complements they need to put in place to facilitate adoption; and the optimisation of complements they need to perform to maximise the return from technology. The article provides some useful case study-based examples of the model in use.

I think McAfee has done a great job of simplying things or, as Carr puts it:

in adding precision to the language we use to discuss complex subjects. It helps us get beyond big, ill-defined generalizations.

I, like Carr, think the classification of IT is too simplistic (but then it is a model!):

It can prevent us from seeing how categories blend together. By drawing bright lines between things, it can give the illusion that those things are more distinct than they really are. I sense that problem here (even while granting the usefulness of McAfee’s categorization). Take the identification of CRM as an enterprise information technology. Isn’t that assumption exactly what doomed so many big CRM projects? The projects lost sight of the fact that CRM is as much a functional tool, a tool that helps individual employees, like salespeople, do their work better, as an enterprise system. CRM, in other words, is as much FIT as EIT. And, in fact, there’s a lot of NIT in it as well.

However, I disagree with Carr’s conclusion:

McAfee’s article may not be quite as clarifying as it is intended to be.

Had McAfee had stopped at the classification then I would have agreed. It’s the marrying of the technology classification to the organisational implications where McAfee clarifies things, since it helps to facilitate a dialogue between business and IT in a language which both sides understand. Equally importantly, it moves beyond the technology selection phase to outline the role of the business during adoption and subsequent exploitation.