Value-Driven IT Management

Iain Aitken

• Publisher: Routledge
• Year: 2012
• eBook ISBN: 9781136349843
• Topic: Business
• Subtopic: Business General
• Index: Business

Value-Driven IT Management explains how huge sums are wasted by companies (and governments) on poorly aligned, poorly justified and poorly managed IT projects based on 'wishful thinking' cost and benefit assumptions and that even 'successful' projects rarely seem to realise the benefits promised.

The author contends that the root cause of the disappointment and disillusion often found in senior management with the value extracted from its IT investments is a complacent corporate culture that can actually foster uncommercial behaviours in both users and internal suppliers of IT solutions.

The author sets out a detailed, pragmatic framework for commercialising the internal IT Function and measuring its value to the business. This is not to be achieved by deploying conventional IT best practices or by making the IT Function look like an external service provider. Instead the author proposes that the IT Function should transform its value to the business by embracing a small set of best value practices that will engender more commercial behaviours in both IT staff and users and will focus the IT Function's energies on delivering successful business outcomes that will win the respect of senior management.

Introduction

The rule is, jam tomorrow and jam yesterday – but no jam today.

Lewis Carroll – Through the Looking Glass

This is a book about transforming the business value of IT. It is about identifying what is relatively important in IT product and service delivery (and doing it extremely well) and what is relatively unimportant (and doing it acceptably well). It is, in short, about jam delivery today, the jam in this case being ‘value’.

A significant amount of research went into this book but I sincerely hope that that is not readily evident because my message is founded on practical experience, not pseudo- academic theory. So, trust me, you won’t find a single footnote or reference clogging up the text of this book! This book isn’t science, it’s personal. I generally don’t have much patience with the theories of the ‘management sciences’, although I confess that I have cherry-picked a few bits of management theory that did actually seem to correlate reality as I have experienced it. This book is not even based on ‘conventional wisdom’ because, as I intend to show, ‘conventional wisdom’ is often spouted by those with an agenda (namely, to sell you something) and, anyway, is often based on assumptions that do not bear commercial scrutiny. Therefore my attitude to the inclusion of advice in this book has been that if it will make a real (commercial) difference in the real (commercial) world, it’s in; if it doesn’t, it’s out. My goal is to be down to earth and pragmatic (occasional Buddhist flights of fancy aside), offering an approach to IT value transformation that is occasionally ingen- ious and, I hope, always ingenuous.

This book began with Chapter 5, ‘Measuring success’. I was initially asked to write a proposal for a consultancy assignment to advise a client on building a ‘balanced scorecard’ to help measure the performance of its IT function. The potential assignment came my way because within the consultancy firm I was regarded as the IT benchmarking ‘guru’ (in the land of the blind, the one-eyed man is king). What this really meant was that I was well acquainted with ‘conventional wisdom’ in the world of IT performance measurement. The trouble was that my extensive experience of seeing that conventional wisdom put into practice had left me increasingly disillusioned with the real business value of that ‘wisdom’. It had resulted in a history of ‘balanced scorecards’ that struck me as being highly un balanced, at least if you believed, as I did, that business outcomes ought to be firmly on one side of the scales. Whatever the measures told you about the performance of the IT product and service delivery ‘factory’ they seemed to tell you little to nothing about ‘customer delight’ with the quality and value of the products and services delivered. Furthermore they were typically charac- terized by measuring arcane things that IT people understood (or, at least, claimed to understand) and which were relatively easy to measure rather than things that actually told senior management something commercially meaningful about the value of IT to their business in a language they could understand. Pondering this caused me to back up further and ask myself questions about which practices and behaviours most critically needed to be changed or improved if we were to maximize the value of IT to the business (topics that I cover in Chapters 3 and 4). This, in turn, made me back up to the very question of ‘What is best practice?’, a topic dealt with in Chapter 2. So I have a story to tell, albeit in reverse.

What are my qualifications to write this book? Well, when I give talks and presentations I am almost invariably introduced as ‘an expert in IT business management’. Fine. But what is an ‘expert’, other than someone who is one page ahead of you in the manual? Well, the great physicist Niels Bohr said that ‘An expert is a man who has made all the mistakes, which can be made, in a very narrow field.’ Thank you Niels. Got me in one. Because that is certainly my key qualification – if I haven’t got it wrong personally then I have seen many a man who has. I would like to think that I have learnt something from that (although I give no guarantees). In particular, I spent 10 years ‘on the inside’ working in various technical and managerial roles in large IT functions (culminating in three years as an IT project manager in

Tesco Stores Ltd, Britain’s biggest and most successful food retailer) and the last 18 years ‘on the outside’ as a management consultant specializing in the performance improvement of large IT functions. Key clients I have advised over the years have included Marks & Spencer, J. Sainsbury, Reuters, Con- signia/Royal Mail, Barclays Bank, Cable & Wireless and Lloyd’s of London (all of whom will be very familiar to the British reader, at least). My qualifications rest on experience, therefore – the extensive experience of trying to increase the value realized from IT investment. In business there is no more valuable commodity than experience, and my experience of value is the value of my experience! Sorry, I just couldn’t resist that.

1.1 Why bother?

So do we have a problem with extracting value from our IT investments such that we need a book on the subject? Well, let’s look at just one important aspect of IT delivery, namely, project management. According to the Standish Group:

• about a third of development projects are recognized to have gone seriously out of control and are cancelled (eventually);
• over half of development projects are delivered at a cost of almost double the originally estimated budget;
• around half of development projects are delivered behind schedule or with reduced functionality.

And note that this is just the projects in which someone actually recognized and reported the problem! For every one of those, how many others were there? I could go on, so I will. The recently published IBM book, Troubled IT Projects, states that average IT project timescale overruns are 30 per cent, with only 5 per cent coming in on time and about half of all projects over- running by more than 30 per cent. Then there is Beam, in Software Engineering Productivity and Quality, who reports that ‘Of all software projects incorporating over 64,000 lines of code, 25% failed to deliver anything; 60% were over budget and behind schedule, and only 1% met requirements on time and on budget.’ And what about the survey of 1027 IT projects published in the 2001 British Computer Society Review, which showed that less than 13 per cent succeeded. Where these IT projects were software development projects, less than 1 per cent were regarded as having succeeded.

Now, admittedly, I tend to collect these sorts of statistics (yes, I know, it’s sad and I should really get a life), but let’s just say that there is ample evidence out there that we have a problem with the credible delivery of IT solutions, never mind delivering the value promised from those solutions.

In my own (pre-consultancy) experience, when I was doing a proper job working in industry, running a group of about 80 development staff, we estimated that around 20 per cent of the code we developed was never actually implemented and a further 20 per cent, although implemented (for reasons of avoided embarrassment), was never actually used by the business. This wastage arose for a variety of reasons, but principally was because either the users found that what we delivered was not what they thought they had asked for or simply because the business priorities or requirements had moved on since the initial request for the system had been made. So we knew that around 40 per cent of our effort was a complete waste of time and money but had no idea really about the extent to which the other 60 per cent of our effort truly added value to the business. And anyway, was that our problem?

On this basis alone it is not difficult to see that when senior business management are asked to give their views of their IT function their most typical lament can be paraphrased as ‘They cost too much, they take too long and they don’t deliver what they promise.’ This may be a cliche but that does not make it untrue. It is basically a more prosaic way of expressing my ‘First Noble Truth’ about the fundamental dissatisfaction with IT delivery (although, as we will see, it actually goes deeper than that). As an IT consultant, I have been listening to this lament for over 18 years and, although increasing IT literacy in the business community generally, and e-business specifically, has somewhat increased the empathy between the business and IT commu- nities, I do not believe the situation has improved significantly throughout those 18 years. There are obviously exceptions, but the overwhelming impression of senior managers with whom I have dealt over the years has been that while fully recognizing the importance of IT to the operation of their business, IT functions have repeatedly failed to deliver the value sought. This, quite simply, is a key driver of the ‘casualty’ rate of CIOs, the average CIO in the USA now surviving less than two years. They may cry out that their external benchmarking shows that (at least compared with their peers) they are not excessively expensive, slow or ineffective but ‘perceptions are reality’. At the very least they have not effectively managed their key custom- ers’ expectations.

1.2 The nature of the problem

So why is the delivery of IT value so difficult? Like any manufacturing business ‘all’ we are doing is developing a product (a system), implementing it and then providing ‘post- sales’ support. And the internal customer has generally already decided he wants the product so we don’t even have to sell it to him! All we have to do is persuade him to buy the product from us, the internal service provider rather than going directly to an external IT service provider (ESP). Since many IT functions today still are (by policy or in effect) ‘protected’ as monopoly suppliers of IT to the business, they might not even to have to do that bit of persuasion. Surely ‘all’ we have to do to be successful in our internal ‘IT factory’ is agree with the business which products it wants us to deliver, predictably deliver the products and then predictably run and support those products after they have been implemented, through to product obsolescence or replacement. It can be modelled very simply, as set out in

Figure 1.1

We, in the IT industry, have been doing these three things for decades but seem to be little better at delighting our customers now than in the 1960s. What are we doing wrong, and, more to the point, why do we continue to do it wrong?

1.3 Conspiracy theories

My experience suggests to me that the problems lie in a number of areas, but are primarily founded on a deadly combination of the ‘twin towers’ of collusion and illusion. By ‘collusion’ I mean a tacit conspiracy between the ‘buyer ’ (the business sponsor/ requester of the solution) and the supplier (the internal service supplier, the IT function). By ‘illusion’ I mean the typical failure of both the buyer and supplier to face certain realities that are clearly visible (but uncomfortable to confront).

First, collusion. The project sponsor wants the system developed. He or she sincerely believes it is important to the success of the business (or, at least, did so when the system was originally requested). And the IT function generally wants to develop it; it keeps them in a job, pays their mortgages and may enhance their CVs. So they immediately have a common goal, namely, to produce a project justification that will leap whatever hurdles the finance department ‘bean counters’ place in the way of its acceptance and, once those annoying, petty hurdles have been jumped (or sidestepped), to breathe a sigh of relief and get on with the interesting bit, the delivery of the system. In order to achieve these goals an ‘unspoken conspiracy’ typically arises in which, for example:

• assumptions about the importance of the proposed system to support business goals are exaggerated, the ‘strategic import- ance’ of the desired solution typically being based on ‘decibel management‘ (i.e. the senior manager who shouts hardest and longest) rather than any credibly ‘objective’ process;
• assumptions about the business revenue that the system will generate are exaggerated (or wildly optimistic, or just wishful thinking);
• assumptions about the business savings that the system will generate are exaggerated (or wildly optimistic, or just wishful thinking);
• assumptions about the speed of full adoption of the system by the business are unrealistic (or wildly optimistic, or just wishful thinking);
• assumptions about the practical difficulties of actually realiz- ing the system benefits are unrealistic (e.g. unions resisting the laying off, or even redeployment, of staff; users not acting on information provided by the system because they do not see it as serving their best interests);
• assumptions about the stability of the market in which the business operates and the stability of the business ‘strategy’ while the system is in development are unrealistic;
• assumptions about the stability of functional requirements while the system is in development are unrealistic;
• assumptions about the development risks (e.g. availability of skilled staff, commitment of key users to requirements specification or testing, new technology working first time) are unrealistic (or just wildly optimistic).

The key term in all my points above is, of course, ‘unrealistic assumptions’, and this is where the ‘illusion’ bit comes in. It is not so much that such unrealistic assumptions occur occasion- ally in IT delivery; in my experience of 10 years in the IT industry delivering IT solutions and then over 18 years consulting to the IT industry, most of these unrealistic assump- tions occur most of the time. Often these assumptions will not be explicitly documented. Even when they are documented it may simply be as a ‘get out of jail free card’ that the project or programme manager can use later to justify why the solution delivered is not actually delivering the benefits sought. (‘Of course the project has proved to be a failure – it was inevitable, because the fairytale world in which I set it failed to material- ize.’) In other words, the realization of value from the solution is being predicated on ‘assumptions’ that pretty much anyone with any significant experience of business or the IT industry knows to be unre...

Table of contents

• Front Cover
• Title
• Copyright
• Contents
• Computer Weekly Professional Series
• Acknowledgements
• Dedication
• Preface–the four noble truths
• 1 Introduction
• 2 Defining goals
• 3 Optimizing effectiveness
• 4 Optimizing cost-efficiency
• 5 Measuring success
• 6 Conclusion
• Appendix
• Index