I am going to start this blog post with a quiz. Which of the following scenarios is the odd one out? A business services organisation did not recover all of the fees it was due because of poor quality customer data A telecommunications firm received a large licence charge from a major enterprise software vendor because they had unwittingly exceeded a key licence metric A transport business continued to provide maintenance services unnecessarily for buildings that it had sold off A government department delayed an expensive but critical applications upgrade in order to reverse engineer a business case for the project A utility company had no software support in place for an application because the two people who had the necessary experience took redundancy in a re-organisation. So which one did you pick?
Recently I read an article on the on-line version of Forbes by Mark Settle. Mark was proposing an IT operating model which he calls “Broker/Integrate/Orchestrate” as a replacement for a more traditional approach he refers to as “Plan/Build/Run”. The article is well written but I think Mark creates an artificial gulf between these two ways of looking at IT and neglects another useful alternative: an operating model based upon a portfolio of services.
A recent post by Gartner caught my eye this week. A key topic at one of Gartner’s events will be their views on how applications are managed and the shift they expect from a mainly project-based structure to a more product-based structure. I think this is a great idea and I have already written and presented a conference paper about how the approach to software maintenance should shift from projects to product life-cycles. I would really like to provide a link to the paper but it was the UK Military Computing Conference in 1991 and you will have to find a paper copy of the proceedings somewhere! In the 20 years since I wrote my paper the advances in IT have been astonishing. If you had met me in 1991 and described the technology I would use to write this blog I wouldn’t have believed you. If you had also told me that a product approach to applications would still make conference headlines 20 years later I would have known for sure that you were crazy. But, 20 years on, a product life-cycle approach to applications is still the exception rather than the norm. What have we been doing all this time?
There are many different definitions of Project Portfolio Management but at their core they share the concept of a business process for optimising a collection of projects and programmes. Projects are deliberately started, stopped, accelerated, delayed, split or merged to best achieve an organisation’s goals. Project Portfolio Management would appear to be a sensible management discipline so why would a CIO want to avoid it? The fundamental problem is that there are no IT projects and so the IT Project Portfolio should be empty. Nearly all projects labelled as IT explicitly include non-IT elements such as organisation or process changes and cannot achieve their objectives or realise benefits without these. Unfortunately, the remaining projects cannot be completed without risk or impact to the users or consumers of IT services and so also need to manage non-IT elements. Perhaps someone reading this blog will find an exception (in more than 20 years in this field I have not found any) but there will never be enough to justify an IT-only process.
If you were an artist, investment manager or a government minister you would describe a “portfolio” in very different ways. Even within the domain of the CIO the word has several distinct uses. Here is my attempt to summarise what constitutes the different portfolios that are relevant for a CIO. In subsequent blogs I’ll expand on what I have learnt about each of these from my research and my own experiences.