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?
I regularly see questions in the press and in social networks along the lines of: “What is the right amount to spend on IT?” Often the debate descends into variations of: “It depends.” For years I used to smile quietly to myself as I watched these debates. Why? Because I had the secret formula! Simply count the number of knowledge workers in the organisation (better still the number of full-time equivalents) and multiply by a unit price (until recently £4K - £5K) and you would be pretty much there. Oh, I know there is a lot to challenge with my formula but it was much quicker, easier and no less accurate than all the debate or a benchmark from one of the big analyst firms. Unfortunately, in recent years, my secret formula has stopped working so I turned to some of my trusted advisers to find out what had happened and help me fix it.
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?
I am often amused by the heated debates about the future, or not, of the CIO. The fun comes from the combination of intense emotions, arguments heroically generalised from limited data and the dismissal of evidence which does not fit preconceived ideas. Before I attempt to set out my views on the role of the CIO let me try to eliminate some of the noise and confusion. Is the CIO really that unique?