What Business Really Wants from IT: A Collaborative Guide for Business Directors and CIOs (Computer Weekly Professional)

What Business Really Wants From IT

This page intentionally left blank

What Business Really Wants From IT A Collaborative Guide for Business Directors and CIOs Terry White

AMSTERDAM BOSTON HEIDELBERG LONDON NEW YORK OXFORD PARIS SAN DIEGO SAN FRANCISCO SINGAPORE SYDNEY TOKYO

Elsevier Butterworth-Heinemann Linacre House, Jordan Hill, Oxford OX2 8DP 30 Corporate Drive, Burlington, MA 01803 First published 2004 Copyright © 2004, Terry White. All rights reserved The right of Terry White to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988 No part of this publication may be reproduced in any material form (including photocopying or storing in any medium by electronic means and whether or not transiently or incidentally to some other use of this publication) without the written permission of the copyright holder except in accordance with the provisions of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London, England W1T 4LP. Applications for the copyright holder’s written permission to reproduce any part of this publication should be addressed to the publisher Permissions may be sought directly from Elsevier’s Science and Technology Rights Department in Oxford, UK: phone: (⫹44) (0) 1865 843830; fax: (⫹44) (0) 1865 853333; e-mail: [email protected]. You may also complete your request on-line via the Elsevier Science homepage (www.elsevier.com), by selecting ‘Customer Support’ and then ‘Obtaining Permissions’.

British Library Cataloguing in Publication Data White, Terry, 1956– What business really wants from IT: a collaborative guide for senior business and IT managers. – (Computer Weekly professional series) 1. Information technology – Management 2. Information resources management I. Title 658⬘.05 ISBN 0 7506 60961 For information on all Elsevier Butterworth-Heinemann publications visit our website at: http://books.elsevier.com Composition by Charon Tec Pvt. Ltd, Chennai, India www.charontec.com Printed and bound in Great Britain by Biddles Ltd., Kings Lynn

Contents

Computer Weekly Professional Series

ix

Preface: What do all these people do in IT?

xi

1

There is no ‘F’ in IT Move over the librarians Where’s the ‘F’ in IT? Never mind the ball, get on with the game IT people are IT people When good words go bad Peddaling your bicycle faster won’t make it into a car

1 4 6 7 8 10 13

2

The three roles of IT in organizations Introduction to the momentum line Maintain business momentum Improve business results Provide aligned leadership

14 14 16 17 18

3

The new business-IT agenda Remind me again why we outsourced! Supply and demand IT demand management – three roles The three roles expanded Everything filters through The focus changes If you’re going to do something, try to have a reason for it Real IT performance

24 24 27 30 31 34 35 36 37 v

Contents

4

5

6

vi

Managing technology to maintain business momentum – the first pillar of IT performance Why manage IT (as against doing IT)? IT availability and stability Operations and efficiency Management of IT services benefits Asset management Performance, measurement and reporting Supporting business momentum Activities of an MBM manager Managing business results from an IT perspective – new rules, new challenges The unique unused gifts that IT people bring to the organization Developing the business case and accompanying benefits statement Achieving the benefits promised in the benefits statement Business measures Process management Information content The real life cycle of systems Portfolio management Step changing business Information leadership in the information age The reluctant technologist Interpreting the external inputs Internal influence and leadership activities – translating inputs into meaning and action within the organization The hard stuff is easy, the soft stuff is hard

39 41 42 45 45 46 48 49 49 52 54 55 58 61 63 64 65 69 73 74 75 77 83

91

7

A matter of survival – proving the benefits of IT What happens to costs and benefits over time? The benefits process Keeping it simple

93 95 99 114

8

Getting, keeping and using the cash – budgeting for IT 116 Back to the momentum of the business 116 Three types of IT activity mean three types of budget 120

9

Measures of IT – some principles of measurement Measures must be linked to objectives Measures must be understandable to the business

125 126 126

Contents

Measures must be communicated Measures must result in something – they must have a reason to exist Three IT roles equals three measurement frameworks Measuring the performance of technology Measuring improved business results brought about by the application of information technologies Measuring IT leadership Implementing measures Communicating to the business

127 128 128 129 131 133 134 138

10

New IT skills and people New skills for the three roles IT supply skills Maintain business momentum (MBM) skills Improve business results (IBR) skills Information leadership (IL) skills

139 139 142 143 145 146

11

Applying the model – check your mindset at the door What changes? Governance – three types of meeting: MBM, IBR, and IL Focus on business benefits IT’s survival depends on measurement and reporting Playing the three role game People

148

154 155 156 157

12

To boldly go … An implementation plan Impact analysis Syndication IT supply and demand Organization changes Strategy IL strategy Putting the implementation plan together

158 158 159 166 168 170 171 174 175

13

In the beginning

176

148 151

Bibliography

178

Index

181

vii

This page intentionally left blank

Computer Weekly Professional Series

There are few professions which require as much continuous updating as that of the IS executive. Not only does the hardware and software scene change relentlessly, but also ideas about the actual management of the IS function are being continuously modified, updated and changed. Thus keeping abreast of what is going on is really a major task. The Elsevier Butterworth-Heinemann – Computer Weekly Professional Series has been created to assist IS executives keep up to date with the management ideas and issues of which they need to be aware. One of the key objectives of the series is to reduce the time it takes for leading edge management ideas to move from the academic and consulting environments into the hands of the IT practitioner. Thus this series employs appropriate technology to speed up the publishing process. Where appropriate some books are supported by CD-ROM or by additional information or templates located on the Web. This series provides IT professionals with an opportunity to build up a bookcase of easily accessible, but detailed information on the important issues that they need to be aware of to successfully perform their jobs. This book is also relevant to both the IT professional and the business user of IT systems. Aspiring or already established authors are invited to get in touch with me directly if they would like to be published in this series.

Dr Dan Remenyi Series Editor [email protected] ix

Computer Weekly Professional Series

Series Editor Dan Remenyi, Visiting Professor, Trinity College, Dublin Advisory Board Frank Bannister, Trinity College, Dublin Ross Bentley, Management Editor, Computer Weekly Egon Berghout, University of Groningen, The Netherlands Ann Brown, City University Business School, London Roger Clark, The Australian National University Reet Cronk, Harding University, Arkansas, USA Arthur Money, Henley Management College, UK Sue Nugus, MCIL, UK David Taylor, CERTUS, UK Terry White, Johannesburg Other titles in the Series Corporate politics for IT managers: how to get streetwise Delivering IT and e-business value eBusiness implementation eBusiness strategies for virtual organizations The effective measurement and management of IT costs and benefits ERP: the implementation cycle A hacker’s guide to project management How to become a successful IT consultant How to manage the IT helpdesk Information warfare: corporate attack and defence in a digital world IT investment – making a business case Knowledge management – a blueprint for delivery Make or break issues in IT management Making IT count Network security Prince 2: a practical handbook The project manager’s toolkit Reinventing the IT department Understanding the Internet

x

Preface: What do all these people do in IT?

Business expects more from IT than they’re getting. And funnily enough it’s not more technology they’re looking for – it’s more business. David Taylor, the President of IT directors association Certus, has this to say about business expectations of IT: A recent meeting of chief executives identified three IT issues above all others. Was one of them investment in new technology? Perhaps the key issue was open source software? No? OK, it must have had something to do with the Web, then. Not at all. Their top concerns were, in order, ‘security, lack of return on investment, and the negative perception of the IT department’. As one chief executive said, ‘What do all those people do in IT? (Taylor, 2002)

This book will deal with the second and third concerns of chief executives. Taylor goes on: A few years ago I oversaw an IT department whose aim was to ‘always exceed our customers’ expectations’. That was not a mission statement, it was a suicide note – we didn’t know who our customers were, we had no idea what they expected of us, and had no chance of meeting, let alone exceeding their expectations.

This book is written to help business set their expectations of their IT departments, and for IT departments to manage business xi

Preface

expectations while delivering on the implied, but real, promises that IT make to their businesses. Ultimately we are looking for a clearer understanding between what business actually wants from IT and what IT can and should actually deliver. Finally Taylor goes on to recommend something close to my heart: Forget service level agreements. The term ‘provider of choice’ is an important and powerful one, combining an ability to balance our service between what our company wants, and what it can afford. Tear up service level agreements that measure your performance with meaningless statistics and introduce service charters – a partnership between you and other departments, showing who does what, why, and when.

This book gets real – how to really deliver IT to meet business expectations without recourse to pseudo-contracts between IT and the business. This doesn’t mean that SLAs are replaced by a void – there needs to be a close and constant relationship between IT and the business which makes contractual arrangements unnecessary. So IT needs to develop an effective communication capability. Sarah Scalet in CIO Magazine says: …if people don’t know what’s being achieved in IT, they’ll think nothing is. IS will be undervalued, budgets will be cut, and you might even be let go. (Scalet, 2002)

The problem is that IT people are IT people. Sarah Scalet again: ’Certain people go into certain fields that are a fit for their personalities,’ says Mitchell Marks, a San Francisco-based organizational psychologist. ‘I don’t want to generalize, but technology attracts more of an introverted type of person.’

So there is some doubt as to whether the CIO will be able to make the shift to general business person as is the expectation. Ellen Kitzis, Group Vice President for Executive Programs at Gartner believes that the role of the CIO will be significantly more general than IT: The biggest change in CIOs’ responsibilities will be the way they take ownership and oversee execution of major projects. Before, the IT organization was judged only on the success of technology projects. In the next five years, it will be measured more by how well projects and the organization itself help the business. (Kitzis, 2002) xii

Preface

While these quotes are hardly exhaustive, they are representative of the pressure of new expectations of the CIO and the IT function. I believe that making the change to meet business expectations is a matter of survival for IT functions in organizations in the long-term. The newly understood business expectations of IT will place personal pressure on CIOs: they will need to leave their comfort zone of technology and enter the serious business territory in which every investment must show a demonstrable return. They must chase down and prove the benefits promised in their project proposals. They must communicate these benefits in business terms. And they must provide effective leadership in both IT and business spheres. Oh yes – they must also provide stable and accessible IT infrastructures and systems as a matter of course. However, what is without doubt is that continuing to do the old IT things faster or smarter or more enthusiastically will not achieve the results expected of them. CIOs and IT functions will have to do it differently, not just better. Terry White [email protected]

xiii

This page intentionally left blank

There is no ‘F’ in IT

1

I believe that the vast majority of IT departments do not work particularly well within their organizations, and it is time they did. They seem to work really hard, but their frenetic activities often seem to miss the point of business. I know that most business executives hold that belief in some part as well. When I discussed the title of this book the IT people would invariably ask: ‘Shouldn’t it be “What business needs from IT” rather than “wants”?’ However, when I talk to business people they never raise the distinction between needs and wants. I believe that the business that pays the bills for their IT has a right to ‘want’ certain levels of performance and activity from IT. Yes they may ‘need’ security, IT capacity, forward compatibility and all those IT things but they ‘want’ something quite different. So I have approached this book from the business wants and expectations of IT, not from what they need. I really need to exercise more, drink less coffee and perhaps take more time off – but my wants are something quite different. This book is about what business wants. I have asked well over 50 CEOs what their expectations of their IT functions are, and their response can be summarized as follows: Deliver IT without fuss, get involved in business activities and give us good leadership.

The problem is that IT people see only the first two words of that sentence: Here are some real IT department’s vision statements: ●

●

‘We will be a world-class provider of choice to our organization, providing a stable IT platform which supports ongoing business operations.’ ‘We will support our business going forward by providing stable, flexible and cost-effective information technologies to meet their needs.’ 1

What Business Really Wants From IT ●

‘We will act in an aligned way to fulfil our client’s needs in information technology.’

The bad news is that the average IT person believes this to be how they go about adding value. But a cursory glance at these statements shows that IT places itself in a supportive role, sets IT apart from the business, and subtly distances them from adding any real business value. This book gives the average general business person, in medium to large organizations, the wherewithal to: ●

●

●

●

●

● ● ●

understand what valid expectations of his or her IT people he or she should hold engage IT people in discussions within a specific agenda, all in business terms help IT people think in business terms, while remaining within an IT domain measure IT performance, in terms of operations in IT, business performance of IT and strategic performance of IT define how, when and where IT expenditure should be managed define clearly the quality expectations of business to IT identify where IT people need to re-skill or be re-assigned most importantly: help IT people add real value to the business.

The thinking presented in this book has gained favour with both IT people and general business people. It is not about criticizing the IT function – they get enough of that already. Rather it is about clearing the table and adding a new agenda to business and IT discussions which allows them to communicate, operate and deliver in business terms. Many of the major IT research groups and the IT consulting houses are heading in the same direction as the ideas presented here. I’ve not yet seen one of these groups who have created a ‘Weltanschauung’ – a comprehensive ‘world-view’ which allows all aspects of IT and business to integrate. Mostly their views come from an IT perspective, often written by IT people for IT people. I started my business life as a technical manager running a geological, survey and mapping department within a mining company. I then became a Facilities Manager in an IT department for a university – I didn’t know much about IT then. I moved on from there to become a CIO for a large international engineering company. And for the last eight years I’ve been back in business, 2

There is no ‘F’ in IT

consulting in general business strategy, and in strategic use of information technologies. I have a foot in both camps, having a general business background, some intervening years of intense IT management, and now back in general business at a strategic level. Some of my frustrations evolve from the relationships I see between IT and business, with neither ‘side’ really understanding why the other has such a problem with their point of view. Let’s go back to the basic expectation that business has of IT: Deliver IT without fuss, get involved in business activities and give us good leadership.

IT people are happy to deliver IT – it’s in their vision statement after all. But ‘without fuss’? The IT people I speak to are frustrated because business just won’t take the time or make the effort to understand the important IT issues which affect business now and especially into the future. They complain that business rants about IT costing too much, and so hold back on important upgrades and force them into maintaining out-of-date technologies at even greater cost. Business people on the other hand complain that IT people are fixated on moving from: ‘Blitz 1.2 to Blitz 1.4, or RNT 6.5 to Union 3.2 because the upgrade path is so much more salubrious’ or some such gobbledegook. And so the misunderstandings continue. And when we say ‘get involved in business activities’, IT people say either of two things: ‘We want to get involved, but they just won’t let us’, or ‘Our job is to run the technology that allows them to do the business.’ Business people on the other hand tend to say: ‘Who’s holding who back here? The door’s open, just get on with it, do they want a gilt-edged invitation?’, or ‘Yes their job is to run the technology, but we think they could bring a unique perspective to the way we do business.’ The rift runs deep. In discussions with an academic friend of mine, he could not agree that IT should be involved in business. IT’s job was supportive, distanced and non-business. He said: ‘That’s where their expertise is, the job’s difficult enough without diluting IT efforts in doing actual business.’ The trouble arises in the difference in expectation: business expects a no-fuss delivery of IT, deep involvement in making the business run better, and real strategic input. But to generalize my research (which is unfair on the minority of IT departments who actually do deliver value), I have found that 75 percent of IT activities are to do with provision of 3

What Business Really Wants From IT

technology – in a cost-effective, stable, high-performance way. Twenty-three percent of their activities involve reacting to business needs, and 2 percent of IT activities can be said to be truly strategic or leadership related. One CEO defined true IT leadership for me in five words: ‘New products or new markets’. You will see later that there is a little more to IT leadership than this, but it’s a good litmus test: has our IT department developed any new product or market for us? I’ll get to this later in more detail, but here’s the summary of this entire book in one sentence: IT people are output people (deliver the system), rather than outcome people (get the benefits that the system was delivered for). The problem is their CEOs are outcome people: they expect results, everything else is seen as an excuse. In this book we will explore the extent to which IT people have painted themselves into their output corner, and what can be done to help IT genuinely add to the organization’s bottom line.

Move over the librarians About ten years ago, when I was the IT Director of a large multinational engineering and manufacturing company, my CEO said: ‘You IT people will never rise to the top of your organizations.’ Somewhat taken aback, I replied: ‘That’s a little rough, why do you say that?’ He explained: ‘Because you behave like librarians – you’ll check the books in, catalogue them, file them, check them out and even fine us if we bring them back late. But you just won’t read them!’ Much as I would like to assert that his opinion was unjustified, it was true for our IT unit at the time. For example, when we produced a monthly general ledger report, we would need a real accountant to rise very early, travel to our offices and verify that we could send the report out to the rest of the company. Mea culpa. At that time I thought that my job was to keep the systems stable and available, to produce the reports, to enable the business to do its business, and to deliver the systems that would enhance company performance. The important issue here is this. A CEO sees the standard IT vision of: ‘a stable IT platform, which supports business operations’ as the ticket to the game, the ground floor, the door opener – but not the final and full role of the IT function in his or her company. 4

There is no ‘F’ in IT

There’s another side to this issue. A recent study by the Gartner Group (2000) found that: ●

● ●

●

there is no correlation between IT spend and business satisfaction business management often believe that IT costs are too high IT people are too focused on technology and not on the business IT departments do not communicate, nor do they have the ability to market themselves within the organization.

This research supports my own findings, and begs an answer for both business and IT. And yet when I talk to CIOs they say their key worries are as follows: ● ● ●

How do I keep IT costs down? How do I add value, and be seen to add value? How do I align with my business?

The problem here is that they often are doing no value-add or alignment activities. So how can they perform in those areas? This book suggests a new way of doing IT in companies, led and guided by senior business people, and enlightened CIOs. Peter Drucker’s opinions about IT people are somewhat jaundiced: A new Information Revolution is well under way … it will radically change the meaning of information for both enterprises and individuals. It is not a revolution in technology, machinery, techniques, software or speed. It is a revolution in concepts. It is not happening in Information Technology (IT), or in Management Information Systems (MIS), and it is not being led by Chief Information Officers (CIOs) … and what triggered this revolution and is driving it is the failure of the ‘Information Industry’ – the IT people, the MIS people, the CIOs – to provide INFORMATION. (Drucker, 1999)

He continues: They (IT people) will not disappear. But they may be about to become ‘Supporting Cast’ rather than the ‘Superstars’ they have been over the last forty years.

So Drucker’s view is that there’s no ‘I’ in IT, and because of this IT people may soon be cast in the role of bystanders in the real information revolution. 5

What Business Really Wants From IT

Where’s the ‘F’ in IT? At the same time that the information revolution is unfolding, there’s another, equally important revolution underway – the business revolution. The paths of the information revolution and the business revolution will be crossing but will IT people be at the crossroads? In the last twenty-five years the business revolution is characterized by globalization of operations, by emergent strategies (strategy on the fly), by a fanatical outwards focus on customers and suppliers, and by the breaking down of boundaries between players in specific industries. At the same time technologies have moved from automation of functional processes, from megalithic mainframes and custombuilt systems, to world-wide webs where you can back your data up onto a server in Zurich, process your payroll in San Francisco, engineer your designs round the clock, with teams taking over as the turning of the earth brings daylight to the laboratory. Computer systems have moved beyond functional specialization to enterprise-wide integration, knowledge is being recognized as the asset it is, commerce is moving on-line and onto the web. The IT developments are yet to see a horizon. Through all of this, the boundaries between what is IT and what is business are blurring rapidly. Business people are significantly less intimidated by technology and are becoming increasingly empowered – there are no limits to what technology can do – the movies and magazines say so. But they are crying out for good guidance and leadership in IT. The convergence of these two revolutions requires a new role from IT. No longer are IT people the purveyors of arcane technical mumbo-jumbo. No longer should they be tinkering with applications. No longer should they have their own language, culture and acronyms. Business expectations are that there should be an ‘F’ in IT. IT must FIT. They are expected to be aligned – strategically, tactically and operationally. They must produce business results. They must lead the business from their unique IT perspective, oh, and they must deliver stable systems quietly and without fuss. This book is about the practical but demanding process of achieving real alignment between business and IT. However, the nature of alignment has changed. In the past, alignment of IT with the business will have taken a distinctly operational flavour. In an aligned company, the organization would develop 6

There is no ‘F’ in IT

its strategy, the IT department would analyse the strategy and produce a SISP (Strategic Information Systems Plan) to support and enable the strategy to happen. They would ensure that their development efforts aligned to business requirements and that their operations aligned to business operational needs. Now expectations of IT ‘alignment’ have changed. The very many senior business executives I have spoken to initially nod their heads at the above definition of aligned IT behaviour … but then a frown will crease their respective brows, and they’ll say something like: ‘No that can’t be all. IT is way too passive in that definition. Where’s the active involvement?’ And that’s the key difference in the role of IT in modern organizations. There needs to be a move from passive to active, without dropping the operational support elements. This alignment requirement represents a paradox. Because business progress requires constant change to meet changing demands and environments, and every IT professional knows that systems will be stable if you don’t keep changing them. So in order to become proactively involved in business activities, while maintaining systems and infrastructure stability, a different approach to IT development and maintenance will be required.

Never mind the ball, get on with the game The nub of the matter is that IT is not doing what business wants them to do. They are playing a different game to business. It seems to me that half of the problem is one of language. A common response to the questions we have been asking of senior business managers is: ‘I know what I want, I just don’t seem to be able to get the message through to IT’. There is a need for a common agenda, and this agenda must be in business terms. The second half of the problem is that technology is both complex and that technology evolves unbelievably quickly. Because of this, the average business needs technologists to manage and implement their organization’s technologies. But this complexity and rapid growth sets IT people apart, gives them their own language, culture, priorities and strategies. And so since the introduction of computing technologies, the wedge between business and technologists has been the source of constant friction between the two factions. This book aims to bring people together by giving them a common agenda and language, by opening up the channels for discussion of the purpose, intentions and expectations of both business and IT people. 7

What Business Really Wants From IT

This book is for business people because it offers an easy way of understanding what their expectations of IT should be – where they are reasonable or unreasonable, but also what additional expectations they should have. There is a caveat. In all the work we have done implementing these alignment and role ideas, the business expectation of IT has always outstripped the ability of IT to meet those expectations. So you’ll need to draw up a plan, and go step by step, even though the big picture of what the IT department should be doing is very simple to understand. The implementation is the difficult part, and I offer a sample implementation plan in the last chapter. But ultimately you will get your IT department to be part of the business rather than the outsiders they seem to be and want to remain, in spite of protestations to the contrary. The book is for IT people because it offers a way forward for those who believe that they are undervalued, or who believe that there has to be a different way of doing IT. Many IT managers have seen and liked the ideas presented here, and have used all or perhaps only some of the concepts to explain to their organization what they believe they should be doing within the company. However, I have found that IT people are more threatened by the ideas than business. So it takes some getting used to the new ways of thinking. I have been approached by outsource suppliers to try to work with their IT clients, moving them on from being purely technically oriented to dealing with the more organization-specific areas while leaving the technical stuff to them as they are contracted to do. I had a discussion with some IT people while I was writing the book and many wanted me to call it: ‘What business really needs from IT’. But needs are different from wants, and to tell the truth, business doesn’t want to be told what they need – they just want IT to get with the programme.

IT people are IT people I was an IT Director for ten years and have been involved in IT for twenty years. For the first three years in IT, when someone asked me what I did for a living I said: ‘I’m in IT’. Not: ‘I work for ABC Engineering’, but ‘I’m in IT’. There are implications here. A while back, a friend of mine said: ‘IT people have three or four loyalties – in descending order they are loyal to: ● ●

8

their technology their industry

There is no ‘F’ in IT ● ●

their company, if they are not contractors or outsourcers if they are contractors, the people who pay their salaries come fourth in their list of loyalties’ (Hattingh, 1993).

Obviously this is a gross generalization, but it serves to raise the question. It seems that IT people are technology people first, computer people second, and business people third. I have worked with Chief Information Officers from many companies for many years, and whether their background is from IT or business, they mostly express the same frustration: business and IT don’t understand each other. Of course there are exceptions; indeed, for a number of years I was involved in managing the Computer Society’s ‘IT Manager of the Year Award’, and one of the requirements was that the IT Manager be nominated by the business. We had a number of sparkling submissions and winners, but these cases represented exceptions to our general experience. Earlier in this chapter I talked about the survey which found that: ●

● ● ●

there is no correlation between IT spend and business satisfaction with IT IT is perceived as more expensive than it should be IT people do not communicate IT people are too focused on technology.

I believe these factors to be linked. Usually when I talk to IT people about their communication with the business, they sheepishly admit that they really don’t communicate very well. But they don’t realize that communication, and the attendant activities (measuring, reporting, consulting, listening), are the most crucial expectations that business has of them. Also that business perception of IT costs, and their focus on technology, reinforces their poor communication. The cycles are repeating. Earlier I reported on my research that showed that IT people are not doing the right things. It appears to be the 80:20 rule here – IT people are spending 80 percent of their time and effort on activities that businesses regard as 20 percent of their role. An important, nay crucial 20 percent, but nevertheless only one fifth of business expectations are being met. So IT people are IT people who do IT things. What does this mean for the business or IT function that is looking for true business alignment? Two things: Either the IT people 9

What Business Really Wants From IT

will have to get a significant dose of business knowledge, and exercise this knowledge in the business domain, or the aligned IT function will be staffed with a significant number of business people. There is still space for serious IT techies inside general business organizations, but as we will see later their technical expertise will have to be IT at an expert level, and they will have to be buffered from general business associates. With a few necessary exceptions the place for pure IT professionals is in IT companies. There is a history behind the current roles of IT in organizations. Initially IT (or data processing, as it was in those days) was used in business to automate repetitive and complex tasks, usually financial in nature, and so it was natural that the DP department report to the financial manager of the organization. This is still the case in many organizations, in spite of the fact that most computer applications today have little to do with pure finance. Customer relations, stock management, order fulfilment, people management, marketing, factory operations, sales and many other non-financial business areas concern the modern CIO, or at least the applications that support these business processes are. Financial applications are, by dint of their maturity in business, the least of a CIO’s worries. And yet some 40 percent of CIO’s still report to the financial director (Gartner Group, 2002). Interestingly, the study cited here shows that CIOs anticipate a change in their reporting lines in the next three years: Those surveyed anticipate that the 45 percent of CIOs reporting to the CEO will grow to some 75 percent, and the 40 percent who report to the CFO will shrink to about 15 percent. This anticipated trend is in the right direction. I believe the time has come for all CIO’s to be part of the executive of organizations. However, this role has to be earned. In a number of companies where we have done surveys of business/IT alignment, the CIO is on the executive – but their business contribution is still in question. Their position on the executive is often because of popular pressure rather than because they have earned their place. And they have to make the difference themselves – the door has been opened, but they are still IT people in a business setting – they still behave like librarians.

When good words go bad I once wrote an article entitled ‘When good words go bad’, in which I explored how words like re-engineering, value-add, downsizing, quality and others, start out in corporate life as 10

There is no ‘F’ in IT

powerful ideas, but over time they become over-used and applied to everything new in the name of progress and so lose their meaning and force in an organization. Their meaning then mutates, becoming negative and often harmful to company goals. When ‘re-engineering’ means ‘moving the deck-chairs on a sinking ship’. When ‘value-add’ means ‘a word used to justify a project, without any intention of actually applying the effort to achieve the supposed benefits’. And when ‘downsizing’ means ‘firing whole departments (but not the executives who’s leadership got us into this mess)’. And when ‘quality’ is used to mean ‘we will be tightening management control without examining underlying causes’, then you know that good words have gone bad. And what about the word ‘users’? If the word has come to mean ‘those annoying and stupid individuals who constantly mess up the IT systems’, or even ‘those on the outside of the IT inner circle’, then a good word has gone bad. So it is probably time to recognize the good words that have gone bad in IT and find alternative approaches and words to describe those approaches. If you ask your associates in your organization what words, methods or concepts IT uses that have a negative context you might find the words: service, stability, security procedures, service requests, help-desk, cost-justification, SLA, the IT budget, IT value-add, IT contribution, alignment, knowledge management, systems development life-cycle (SDLC), IT’s monthly report and many others appearing on your list. While not all of these will turn out to be ‘bad’ words in every case, I have come across a number of business managers who have had some beef about each of them, even if it’s only a comment like ‘service and IT don’t belong in the same sentence (unless you put the word “poor” before service’. Or even ‘oh, you mean the un-help desk’. Good IT words go bad. Of course most IT functions probably have only one or two bad areas – their service or stability may be rocky or their development or delivery of applications may be over budget or late, but the combined effect adds up to a net lack of confidence and the question: ‘What do all these IT people do anyway? They can’t even get this right’. This book will answer that question for general managers. And introduce a few new words in the process. But for now I would like to clarify my definitions of some key words. 11

What Business Really Wants From IT

CEO: This term covers the Chief Executive – the executive manager of the company. The head honcho, numero uno, the man or woman with the purse strings, and with no time to waste. CIO: Whether it is the DP manager, IT Manager, IT Director or CIO, I’m talking about the executive (he or she who executes the work of managing and leading the IT effort). Some IT managers have a hang-up about their title, which is deeply bound up with their insecurities inside the organization. Customer: There is, to my mind, only one customer – someone who pays for the products or services of the organization. Thus there can be no ‘internal customer’, especially for IT. I reserve the word ‘customer’ for the external client, because we want IT to focus on business results, not on internal support of business operations exclusively. There can be only one. Sponsor: While in the traditional project domain, a ‘sponsor’ is someone who supports the project, and often pays for it, my definition of a sponsor is closer to an ‘internal customer’. A sponsor is someone within the organization who commissions and ‘pays for’ an IT service or product. It is with sponsors that IT has its service charters. It is my hope that sponsors read this book and use it to update their expectations of IT. User: A user is someone who uses IT services or products. As simple as that. IT functions have these ‘internal customers’ as well, who have a say in how satisfied they are with the services etc. IT: There is a trend these days to talk about ICT (information and communications technology) to cater for the convergence of information and communications technologies. People also talk about IM (information management), which encompasses the wider management, strategy setting, business involvement domain. IT people feel the need to be precise in their acronyms. I don’t feel that need at all. When I talk about IT I am talking about the discipline involved in the installation and operations of information technologies. When I want to bring in the management side, I will say ‘IT management’ (but I won’t introduce a new acronym of ITM). Organization/company/business: I use these terms interchangeably. I have implemented the thinking in this book into a number of government organizations, and while they do not necessarily have the profit motive (with all the complications and politics that this brings), the successful organizations are very clear on their mission and objectives and are universally customer-centric. And this makes them close in operation 12

There is no ‘F’ in IT

principles to their profit-driven cousins. So when I discuss organizations, companies or businesses, I mean any organized group of people with a clear vision, mission and customer focus. And if you don’t have that, there’s even more work to be done, other than on the IT department.

Peddaling your bicycle faster won’t make it into a car The IT industry tends to limit the potential for CIOs to move out from under the technie umbrella in the way they define their positions in the organization. For example, Gartner’s (2001) seven competencies for the CIO are: ● ● ● ● ● ● ●

build and maintain the technical platform and service delivery ensure and demonstrate excellent value and performance develop IS technical, service, and management skills source intelligently from the external market create an environment of opportunity champion the impact of ‘e’ lead the business.

However, these seven key strategic areas are seen as a hierarchy of needs – you can’t do the last few unless you are performing in the first four. This is not what the business wants! They want their IT function to do it all, now, and to some level of competence but not necessarily to perfection. The IT people I’ve spent time with have a problem with the ‘do it all, now’ expectation because they maintain that you can’t create opportunities, exploit the ‘e’ world (more IT doublespeak), and offer leadership if you haven’t got your technical ducks in a row. And that’s one of the basic expectation failures which drives this book. As I said in the preface: maintaining an IT mindset and continuing to do the old IT things faster or smarter or more enthusiastically will not achieve the results expected of them by their businesses. CIOs and IT functions will have to do it differently, not just better. A dictionary definition of different is: ‘unlike in nature or quality or form or degree, or distinctly separate from the first’. And there’s the challenge for IT – to do something distinctly unlike what they have done before. Not faster or smarter, but different.

13

The three roles of IT in organizations

2

This should be a plaque on every IT person’s desk. This is what the business wants. However, we need to unpack this to see what business is really asking for. Business is asking for three things: ● ● ●

Deliver IT without fuss Give me business results for my IT spend Give me good, strategically aligned IT leadership.

But before we go into this in more detail, I need to introduce a useful concept.

Introduction to the momentum line Here’s a concept that I have found extremely valuable over the last ten years or so, in describing many concepts, activities, and IT budgets: imagine your organization has a momentum – the impelling force that gives your organization its normal revenue stream. The dictionary definition is useful: ‘the product of a body’s mass and velocity’. 14

The three roles of IT in organizations

To go back to school for a moment: momentum ⫽ mass ⫻ velocity velocity ⫽ speed ⫻ direction In this analogy, your organization has a mass: this relates to the size of the organization, its geographical spread, the number of employees, the number of branches or depots, customers etc. Your organization also has velocity: the speed at which it is heading in a certain direction. Your organization’s speed relates to how fast it gets things done and how dependent it is upon that speed – a mobile phone network or radio station cannot afford one second off-line, while a mining company might be able to move at a slower pace. I once asked the CEO of a steel foundry what his strategy was. He pointed at the processing plant and said: ‘This is my strategy – to make this thing work for the next twenty years’. An organization’s direction, in this analogy relates to its vision, mission, and objectives. When I explain this to CEOs they then modify their first expectation of IT: Maintain my business momentum using IT without fuss.

Performance

Let’s describe business momentum graphically (see Figure 2.1).

Maintain the momentum of the business through IT Mass ⫽ staff, branches, geography etc. Speed ⫽ how fast and how dependent on continuity Direction ⫽ vision, mission, objectives

Figure 2.1 Business momentum

Time

Seems logical, and indeed fits very well with IT’s expectation of themselves. But now we come to the two words that I have steadfastly included every time I talk about business expectations, 15

What Business Really Wants From IT

two critical words: WITHOUT FUSS! Business does not want to be bothered with this part of IT. They don’t want to be told that: ‘We can’t do this because of legacy systems’ or that ‘We need to upgrade to SCRIBBIT 4.7, or we’ll lose the maintenance cover from the supplier’. They don’t want to hear that ‘IT has met its SLA (service level agreement) targets at 98.1 percent availability index on the tier two network’, when you know that your PC hasn’t been able to connect to the remote network for the last four weeks.

Maintain business momentum To the business, pure IT is like a toilet – they don’t want to know about it unless it’s broken. This is bad news for IT people, because they believe that if the business is spending so much money on technology then they surely should show some interest or even make some effort to understand the issues. And the answer is no. Business in general doesn’t want to know. And why should they? Their expectation is that IT should ‘handle things’, guiding their organization through the technological landscape, applying their technological expertise to resolve the problems they keep bringing to the business table. In the human resources domain, there is a concept of ‘hygiene factors’ – lighting, desks, cleanliness, coffee, telephones, workstations, security, and so on … The idea is that if these are not in place, you can forget the fancy people motivation programmes, the training, the stock options etc. A little like the wellknown Maslow triangle – look after the basics before moving on to the next thing that makes people happy. In the IT mind, there is a basic hygiene factor triangle (see Figure 2.2). Most IT people I speak to are working hard at the lower five or so parts of this triangle. They’ll tell me they need to build the IT foundation by adding building blocks in order from bottom to top. And it’s little wonder they don’t spend a lot of time in the ROI (return on investment) block. But here’s the rub: business has no such triangle in their heads. They want it all. But interestingly the CEOs I have spoken to quite understand that their systems may not be perfect and that IT must keep on trying to get these things right, but they really want IT to focus on business involvement, and on leadership at the same time. 16

The three roles of IT in organizations

ROI Added functionality Core functionality User satisfaction Security Maintainability and upgradability

Figure 2.2 The hygiene factor triangle for IT

Availability and stability

Improve business results The business expectation of IT is that almost all of the triangle in Figure 2.2 is about maintenance of business momentum through managing technology. And it is just the ticket to the game, the hygiene factor of IT, the 20 percent of IT that must be done ‘without fuss’. Which brings me to the second element of the concept of business momentum: business expects IT to improve the business momentum over time, and to show where these improvements occur (see Figure 2.3).

ults

Performance

s res

Figure 2.3 Business expectation of IT – version 2

h oug

s thr

f the

mo

ove

r Imp

the

ntu ome

nes busi

nes busi

m

Maintain the momentum of the business through IT ‘The IT hygiene factor’ ‘Do it without fuss’ ‘The ticket to the game’

Time

Improving business momentum involves improving its mass (geographical representation, customer base, etc.) or its speed 17

What Business Really Wants From IT

(improved order-taking speed, procurement chain logistics, etc.) and direction (more focused marketing, meeting of business objectives etc.). And results are expected to be visible and in business terms – so something like ‘15 percent improvement in order-taking capability’ doesn’t cut it. What’s that in bottom line terms? Where’s the money? Business is looking hard at return on investment. When they spend money on IT, they expect a measured and proven return on that money. This kind of talk has major implications for IT people. I’ve given some two hundred odd workshops to IT people on this stuff, and at about this point I always ask: ‘Who here knows what a “post-implementation review” is?’ All the hands go up. (A postimplementation review is meant to happen after every IT project and is meant to ascertain whether the implemented solution has indeed achieved what it was meant to do (O’Brien, 1999).) Then I ask, ‘So who’s done one?’ – and about half the hands stay up. The final question is the clincher: ‘Who does one after every implementation, and continues to do them until the benefits promised by the system have been proven to have been achieved?’ All the hands go down. You see, IT people regard benefit realization as a business issue: ‘We’ve given them the system, they must get the promised benefits – it’s the business’s problem’. And there lies the snag, because in my book, that’s an output mindset, not an outcome mindset. And in Chapter 1, I said that I believed this to be one of the key gap creators between IT people and business people – IT people believe their job is to deliver the system, and business people believe that IT stops short every time. So we’re going to have to help IT people into this new outcome territory. Finally, the generic business expectation of IT is that they should ‘give us good leadership’.

Provide aligned leadership Yeah, yeah, we’ve all heard that before. But, what is leadership really, and specifically in an IT sense? As I said earlier, a CEO once told me that in his view leadership in the corporate world meant only two things – new products or new markets. I asked him, ‘What about new competencies?’ He frowned, and decided that the jury was out on that one. But I want to add to this CEOs definition of leadership for IT by including some inward-looking stuff. I believe a leader has a significant interpretation and translating role. In IT’s case it’s about interpreting the technological world and translating that into organizationally relevant messages. The emphasis is 18

The three roles of IT in organizations

‘relevant’. Nothing tires a CEO more than having his resident technocrat waxing eloquent about some sexy new technology, without linking it to the company’s strategy or telling him that this is going to change the way business is done (that’s what the dot.com crash was about, wasn’t it?). Let me talk about strategic relevance: I’ve done some work with a few large corporates in which I compared the corporate strategy with their IT function’s strategy – and the match was woeful – IT was concerned about ‘creating four images of the XXX ERP system and standardizing on two hardware profiles for the ERP supporting infrastructures’, whatever that means. This was IT’s key strategic goal. Their business on the other hand had articulated seven key strategic objectives, six of which were externally focused – increasing their global footprint, creating organic growth from recent acquisitions, improving customer satisfaction through improved service levels, opening new channels through uncharted competitive territory, etc. And IT’s contribution to this? Nothing. Nada. Zip. They came in on the seventh strategic objective which was: ‘Continue cutting costs through effective use of existing resources’. And so IT’s standardization efforts were lumped under this objective. IT of course had other strategic objectives, to do with standardization, network optimization, squeezing suppliers for better terms, implementing a new firewall, etc. When I drew a representation of the IT strategy fit with the corporate strategy it looked something like Figure 2.4. Business strategy Increase global footprint Create organic growth from recent acquisitions Improve customer satisfaction through improved service levels Open new channels through uncharted competitive territory

No IT strategy

Etc. Etc. Continue cutting costs through effective use of existing resources Create four images of XXX ERP system Standardize on two hardware profiles Optimize the network IT strategy

Create new supplier relationships Etc. Etc.

Figure 2.4

Fit (or lack of fit) between the business strategy and IT strategy 19

What Business Really Wants From IT

Only one of the business strategy’s objectives translated into the IT strategy. However, we should not confuse leadership with strategy. Strategy is a relatively small subset of leadership, which seeks to translate an intention into more formal goals. Rather, there is a whole set of competences and behaviours required from a leader that differ materially from a typical management model. Where a manager must communicate, a leader must influence; where a manager is concerned with improving the business, a leader is looking outwards and seeing where he or she needs to change the business, and deliberately strategizing how to introduce the change, and create a lasting new direction for the organization. Figure 2.5 summarizes my thinking on leadership. Technological world Business and economic world Organization‘s strategy IT strategy

Manage meaning

World domain

Organizational domain

Leader

Manage focus, manage attention Build frameworks, models, strategy, understanding New direction, cross new boundaries, challenge the status quo New products, new markets, new competences

Figure 2.5 20

The role of a leader

The three roles of IT in organizations

As you can see, ‘strategy’ is only one of the tools a leader uses to manage attention and direct effort. I have used some of the thinking of leadership guru Warren Bennis (1993), who defined the role of the leader as managing ‘meaning, attention, self and trust’. I have included the management of meaning and attention in my thinking. The job of the IT leader is to interpret the external world, particularly the technological world because that’s his or her specialized role in the company. The leader then applies knowledge of the business world, and filters both the technological and business knowledge through the organization’s strategy. This is critical, but seems to be done in an offhand way by CIOs. The key role of the leader is to then ‘manage meaning’: for example, if the organization chooses to be product focused, or customer focused or operationally focused (Treacy and Wiersema, 1996), then what does that mean? Organizational customer focus must surely mean that customer relationship management, data mining for customer opportunities, training at the customer interface, ease of customer interaction, etc. must all play a part in how the organization should view the world of technology. However, if there is a strong operational efficiency focus in the company, then the meaning of different technologies for the company must be different again. The job of the leader is to manage meaning in the organization, with a technological perspective where necessary. For instance in a consulting company, laptops and printers have special meaning, because it is these two devices that underpin all consultant’s outputs. Then the job of the leader is to manage attention. What are people doing? And is what they are doing appropriate to the organization’s strategy? This is difficult, not so much in getting people to take up a new challenge, but to stop doing the unnecessary stuff, which falls outside what is meaningful for the organization. In very large companies there is a significant amount of activity which is totally unnecessary, often a leftover from some long-dead initiative. The leader manages attention away from meaningless activity towards meaningful (in the company context) activity. The strategy plays a major role in managing attention, because it translates intention into measurable objectives. Another role of the leader is to build understanding within the organization. This is especially true of the IT leader. Figure 2.5 is an example of a model which, I hope, builds understanding of 21

What Business Really Wants From IT

the role of IT leadership for readers of this book. So an IT leader must be able to construct easy-to-understand, clear frameworks and models to build understanding of technology and IT concepts within the rest of the organization. And the IT leader must then be able to communicate these ideas. When I was a CIO I often found myself using analogies: talking about hosepipes with different thickness when discussing network capacity issues, or talking about a blueprint when discussing the SISP (strategic information systems plan) or technical architecture. If a CIO cannot talk in business terms, then he or she must be able to talk in analogous terms. Never in technical terms. It is not the responsibility of business to learn technology – it’s often a double-edged sword anyway, as there’s nothing more dangerous than a marginally informed amateur technologist in an organization. Ultimately the job of a leader is to use all this new understanding, meaning and attention to drive the organization away from the comfortable tried and tested paths, into new territories, crossing new boundaries, meeting new challenges and so on. Finally, the job of a leader comes back to the purpose of any organization – maintain sustainability into the future. For profitdriven companies, this involves new products, services and markets, while for not-for-profit organizations this often involves services and customer satisfaction. Whatever the sustainability drivers, leadership is about driving change into a new and constantly changing environment. This brings me back to my graphical representation of business’s expectations of IT (see Figure 2.6).

Performance

Provide aligned leadership

Figure 2.6 The three roles of IT 22

sults

ss re

ne busi

rove Maintain the momentum of the business through IT

Imp

Time

The three roles of IT in organizations

Immediately you will notice that leadership is a discontinuous thing – there is no direct line between what is happening now and the leadership role. This is obviously an over-simplification, but real leadership is about discontinuity, about creating new rules, about changing the direction of an organization. Management is about running the existing environment and improving on it. A little parable serves to illustrate the point: imagine you are a work team cutting a path through a forest, and laying a new road. The role of maintaining the current momentum requires a strict application of policy and procedures to ensure that the daily target of (say) 100 m of road is built. It involves tracking current performance, measuring results and taking action when it appears that you will fall below the required 100 m standard. The role of improving the momentum requires close scrutiny of current methods and processes, development of new ways of doing the work, simplifying, making more efficient, redesigning, and continuous improvement. Obviously improvements must be measured and reported on. The role of the leader in this road laying exercise is different: he or she is the one who climbs the highest tree, and calls down to the work party: ‘We’re in the wrong forest!’ Alright, I’ll admit this is a little tongue-in-cheek, but it serves to illustrate that the job of a leader is to be looking outside of the immediate work and environment, interpreting the facts presented, and changing the direction of the organization. In the next chapter we will see how this division of roles into three areas moves us inexorably in the direction of a new language. And it’s this language (only three words really) that allows a whole new relationship between IT and the business.

23

3

The new business-IT agenda

Remind me again why we outsourced! I was having a report-back session to the CEO of a large steel foundry group. His company had outsourced their IT function some years previously, and was paying some $30 million per annum for their IT to be provided by a specialist IT company. There’s nothing wrong with that. Except when I reported that his group IT function was spending 76 percent of its time dealing with technology and operational issues, he hit the roof! ‘Why’, he asked me, ‘if I am spending $30 million per annum on outsourcing, are my IT people doing their jobs for them?’ His view, which has some validity, was that if the work of maintaining his business momentum was background work, then it was the role of the expensive outsource company to do it. He acknowledged that there would need to be some guidance from his IT people, but that should constitute 10 percent of his group IT function’s activity and no more than 20 percent of his regional IT function’s time. He then drew a picture for me, turning my graphical representation of IT’s roles on its side. His picture was useful, and I have continued to use it ever since. Figure 3.1 shows what my original IT role description looked like. Figure 3.2 shows what his sideways picture looked like. While this says nothing of the performance of the organization – maintaining it, improving it or redirecting it – it comes in useful when he drew the next picture (Figure 3.3). He said, ‘You’re telling me my group IT function’s activity spread looks like this?’ Seventy-six percent of their time is about maintaining business momentum, 22 percent in improving business results, and only 2 percent in leadership. (I shied away from telling him that the 22 percent business involvement was 24

The new business-IT agenda

Performance

Provide aligned leadership

sults

ss re

ne busi

rove Maintain the momentum of the business through IT

Imp

Figure 3.1 The three roles of IT

Time

Maintain business momentum

Improve business results

Aligned technological leadership

Maintain business momentum

Improve business results

Aligned technological leadership

22%

2%

Figure 3.2 The three roles of IT – sideways view

Figure 3.3 Breakdown of IT activities into the three roles

76%

only when they were reacting to the business pleading for new systems. They were doing very little proactive work.) The CEO then went to draw me two more diagrams, and in doing so changed the expected role of his IT functions 25

What Business Really Wants From IT

forever: he wanted his central group IT function’s activity profile to look like Figure 3.4. Maintain business momentum

Figure 3.4 Expected activity levels for a central group IT function

Improve business results

40%

Aligned technological leadership

50%

10%

His logic was that a small amount of central involvement was necessary to keep alignment between the operational units – the setting of global standards, performance metrics, reporting guidelines and so on. Initially he weighted the leadership role at about 80 percent but then changed his mind, because there were corporate-wide business improvement initiatives that he wanted driven from the centre. Also the issue of centrally monitoring business use of IT was important to him – it was from this discussion that a central IT programme management office originated. Finally he coloured the 50 percent leadership area. ‘If my central IT function isn’t providing leadership, to both the business and to the regional IT functions, then who the **** is?’ (This was not a CEO to mince words – he provided the title of this book.) He liked the leadership model that I presented in Chapter 2 and went on to adopt it as his own and drive it through his company. Then he went on to draw his activity requirements for his regional IT functions (Figure 3.5) – there were nine of them scattered throughout the country. Maintain business momentum

Improve business results

Aligned technological leadership

60% Figure 3.5 Expected IT activities for a regional IT unit 26

20%

20%

The new business-IT agenda

He reasoned that the regional IT management function should have more involvement in day-to-day operations provision. But he stressed that this 20 percent was about managing the outsource provider, not about doing the work itself. His requirement for his regional IT functions was that they should spend most of their time improving business results. This involves being more business than IT in mentality, but without losing the IT perspective. This is important. Many of the IT people I talk to become uncomfortable about too much business involvement: ‘We will end up doing their jobs for them,’ they say. But the IT perspective is always important. IT people have an important role to play. They have more expertise and comfort in IT discussions, and it is their job to infuse that into the organization, and to ensure that the technological aspects of all business activities are covered. I’ll go into more detail in a later chapter. Finally he believed that there is a leadership role to be played by regional IT functions, where they take the corporate strategy, and the group IT strategy, assess their meaning and translate it into action at a local level. Also there is a role of being aware of technological advances as they apply in the local geography (for instance, one foundry was located about 500 km from the nearest large city, and as such had different technological requirements than the foundry located just outside the city limits). These technological requirements should be communicated to the centre, as well as to their local business unit.

Supply and demand There is an assumption buried within the above diagrams. And that is that these diagrams apply only to outsourced organizations. Or do they? In recent years the concept of ‘federalism’ in IT has grown into a generally accepted practice. The idea is that you can – and should – split the ‘supply’ of a service from the ‘demand’ for that service. The logic is compelling: the drivers behind ‘supply’ require an obsession with stability, availability, efficiency and cost-effectiveness, whereas the drivers behind demand require a deep understanding of what the business needs, and a determination to meet these business needs effectively. Return on investment becomes critical. The splitting of supply from demand is graphically represented in Figure 3.6. 27

What Business Really Wants From IT

Supply

Figure 3.6 The different drivers of supply and demand

Efficiency Costs Availability Stability Security Optimization Outputs

Demand Effectiveness Requirements Meeting needs Usefulness Return on investment Improvement Outcomes

It is immediately obvious that the supply side of the equation is deeply concerned with outputs (delivery of a service, product or system) and efficiency, while the demand side is concerned with outcomes (what happens in the organization as a result of having the service, product or system). There are of course many tensions set up between doing things right (supply) and doing the right things (demand): if a supply agenda prevails in an organization, their IT will be stable and available, controls will be rigid and standards will be immutable. However, the IT systems will be slow to change and it will be difficult to initiate new projects. On the other hand, if demand priorities dominate the organization, change will be rapid, often out of control, stability of systems will suffer, and the ‘next new thing’ will rule IT discussions. There needs to be a balance between supply and demand, and if the IT department tries to take on both sides of the supply/demand coin, they will often under-perform in both. So it is recognition of these tensions that is causing many organizations to split their supply from their demand functions. I have come across a number of companies in which supply and demand is split, not only in IT, but also in other central service functions such as human resources and finance. Indeed, the recent pressure on better governance in the wake of Enron and similar governance breakdowns has engendered a strengthening on the split between supply and demand – the demand side deciding what it wants done and how much they are prepared to pay for the service, and the supply side delivering according to those requirements. Back to IT though: even if your organization has not outsourced, it would be a good idea to split the ‘demand’ for IT from the ‘supply’ of IT. Even as sub-departments within IT, there can be 28

The new business-IT agenda

an infrastructure supply, a maintenance supply and a development supply section within the IT department. The important part is to make the supply part of the equation explicit – clearly defined and ring-fenced so that it can be managed as an entity, with different drivers, methods and measures. Whatever the organizational form, the three-role model can apply. This book assumes that the theory and practice of the supply element of IT provision is reasonably well catered for (there are numerous text books written about hardware, software, applications and the like) – rather, I will concentrate on the demand side of the equation, a subject not covered in extensive detail by most publications. However, the supply element of IT can be mapped as in Figure 3.7. IT demand roles IT supply

Maintain business momentum

Improve business results

Aligned technological leadership

Contracted

Figure 3.7 Where supply and demand meet in the IT domain

Ad-hoc

As you can see, the majority of supply in IT comes into the ‘maintain business momentum’ element of demand, usually in the form of a contracted service (outsource, in-source, co-source, etc.). A number of ad-hoc IT services are enlisted into all demand areas when required. For instance, an organization might get a systems development company to build them a system as per their requirements, or a consultancy to help them develop their IT strategies or architectures. But the demand side of the IT coin defines the requirements, for IT infrastructures and services, for the applications that they use and for the strategy that they are following. So this book deals with management of the demand-side of the equation, with the implicit understanding that the supply-side can and will be sourced when needed, and their outputs will be managed by the demand-side of the organization. 29

What Business Really Wants From IT

IT demand management – three roles The definition of roles expressed by senior business management, framed into three roles by myself, and finally depicted by yet another CEO as the three columns of activity, can be expanded into the following summary table (see Table 3.1), which represents the nub of the matter. Table 3.1 is really an expansion of the three columns drawn by the CEO I was talking to, but it’ll require some explanation. For the rest of this chapter, I’ll briefly describe the three roles, and then talk about how to use the model, and touch on some of the implications of this way of thinking. In the following three chapters, I’ll go into depth in each role. Finally I’ll talk about budgeting under the three-role (3R) model, measurement of IT’s performance within the three roles and explore how IT’s skills profile is affected by the model.

Table 3.1

The three roles of IT demand management Maintain business momentum (MBM)

Improve business results (IBR)

Information leadership (IL)

Purpose of the role

• Availability & stability • Operations & efficiency • IT outputs

• Business outcomes not IT outputs • Involvement with business improvement

• Create new business • Interpret technology, increase business understanding and drive aligned change

What drives the role?

• Deliver IT when and where it is needed • Service levels dictate MBM activities

• Deliver improved business results, not just systems • Be involved in business content

• External focus converted into internal change • New capacity to compete

Activity areas by role

• Manage supply of IT • Service management • IT performance management • IT finance management • IT reporting

• Business case review and follow-up • IT solutions • Business measures of IT contribution • Information content

• Operate at organization’s boundaries • Interpret trends and events • Change business and IT thinking

Outputs

• IT infrastructures • Applications maintenance & support • IT security and continuity

• Benefits realization • Translate needs/ opportunities into technology designs • Data-mined business opportunities

• New products, markets and competencies • Strategic models, frameworks and understanding

People attributes of role mastery

• Management of IT momentum • Supplier management • Reporting

• Management and achievement of business results

• Vision & judgement • Influence and drive

30

The new business-IT agenda

However, I want to tackle an issue that sometimes confuses people: these are not job descriptions, although they could form the basis of such. Rather, the roles depend on the organization. Imagine a start-up company – the founder fills many if not all of the management roles – he or she is the Operations Manager, the Financial Manager, the Chief Marketer and many other roles as needed. But as time goes on, the founder brings in a financially qualified manager to take over that role, and so on. In the same way, the above three IT roles can be carried out by one person, or one manager per role or multiple managers per role, depending on the organization’s culture, maturity and size.

The three roles expanded Maintain business momentum You can see that the maintain business momentum (MBM) role is concerned with managing the existing technologies to keep things going, stable, efficient and with keeping costs down. But the emphasis here is that this role manages the service providers, rather than does the work. And this management requires planning, organizing, management of execution, monitoring, measurement of performance and reporting. The MBM role acts as translator if you will. The MBM manager interprets business’s operational requirements needed to maintain their momentum, translates these into IT requirements, and manages the supply of these to the business. Initially I called this the IT management (ITM) role, but I got into long and confused debates around IT people’s perceptions of what managing IT was really about – with some people calling this just a rehash of the facilities department, or in some way that IT management goes back to the old DP departmental mindset. So I’ve moved away from using IT management as a descriptor of this role, because the role is so much more than any traditional IT role – it is a concerted focus on the management of the services provided by the IT department to their sponsoring business. And while I have searched for a clear and pithy acronym, I have been unable to settle on anything less cumbersome than the MBM manager. The role is driven by an obsession with service, finding what the business wants and getting it delivered. It then goes without saying that this obsession is fed by knowing what’s going on. Therefore performance measurement and monitoring is essential to the MBM role’s success. Also finances are important. Usually business momentum is defined in many terms (mass, speed, direction), but a key determinant of business momentum 31

What Business Really Wants From IT

in IT terms is delineated on a financial basis: ‘How much money do we need to spend on IT to maintain our business momentum?’, becomes the question that the Technology Manager expects from the business. And he or she manages, monitors and measures operating costs, capital expenditures and IT assets fastidiously. Which brings us to a discussion on IT communications: In Chapter 1 I reported a research house’s findings that IT people are poor at communicating. This is where things must start to change. The MBM role requires extensive reporting capabilities. And in business terms too – it’s not acceptable to talk LANs, WANs, VANs and FANs (whatever they are) – because the business expectation is that they will be spoken to in language they understand. So it is incumbent on IT people to become understandable and to communicate. Improve business results The improve business results (IBR) role is concerned with business outcomes – so what if they have a new system – what has improved in the business as a result of having this system. Traditionally IT people tend to withdraw from business activities once they have delivered the system, trained the users, bedded the system in and ‘handed over’ to the business. In this role, there is no ‘hand-over’. IT maintains an interest in how the system is running and more importantly in how many of the benefits promised by the system have been achieved. I will go into benefit definition and realization in some detail later in the book. However, two other key purposes exist for the IBR role – IT people acting in this role are concerned in interpreting business needs and identifying business opportunities so that they can be translated into IT solutions in a sensible and aligned way. It doesn’t matter how much outsourcing your organization has done, they must always retain people whose understanding of the business and the technology merge to allow for clever IT solutions. Many IT companies advertise themselves as solutions providers – but I believe that the key solutions providers are the in-house IT people acting in the IBR role. The other key IBR role element is to get involved in the content of business. They should work with business to interpret the information that washes through their systems, to extract meaning from it, and to focus the business on improvement opportunities. There is also a key element of this role which requires significant effort from IT people to translate their contributions into business measures. I get a lot of criticism here from IT people because 32

The new business-IT agenda

they tend to say that their contribution is part of something else, and therefore impossible to measure. I enjoy facilitating sessions with these detractors in which we define the IT contribution and translate it into business terms, however loosely. Then comes the fun part, in presenting these findings to business – they often had no idea that IT was doing so much. Which is exactly the point. IT people don’t believe they can define their contribution accurately, so they don’t even try. And in so doing they remain their usual uncommunicative selves. Even if business disagrees with their conclusions, at least they are communicating about IT’s value contribution, often for the first time ever. And here’s another observation: If 75 percent of IT’s time is currently spent in running the technology, in the ‘maintain business momentum’, and if all the ‘improve business results’ activity is reactive to business requirements, then how, how, how, can IT ever be seen to be adding value? Value is added when the contribution is visible and real, when IT is seen as an agent for business improvement, as a dogged pursuer of the benefits that systems were commissioned for in the first place. Value is further added if IT people are concerned with the bottom line, with returning value against every investment. Finally value is added when IT people bring something new to the party – a new insight, or way of doing things, or way of looking at the information currently available. So tell your CIO, if she is really serious about adding value, then she’d better get into benefit realization, content mining and contribution measurement and communication. Otherwise she’s just making the noises without the intention or commitment. Information leadership The purpose of the information leadership (IL) role is ultimately to create competitive capacity through the introduction of new products and markets. I like this simple purpose because it is unambiguous and forces IT people to focus on real business issues. Information leadership is not information strategy alone, although it uses strategies to achieve its ends. The leadership model I presented in Chapter 2 covers the IL role, but it is important to stress that leadership is not mega-management – it requires an external focus, an ability to make sense of what you see, to interpret that and convert it into something that makes sense to the rest of the organization. I like to think that if it isn’t reported in the organization’s annual report or stockholder’s report, then it’s not leadership. Warren Bennis, the leadership guru, has differentiated leadership from management with two simple acronyms. The management 33

What Business Really Wants From IT

acronym is ‘POEM’, where it means: ‘plan, organise, execute and monitor and measure’. This is quite different from the ‘MAST’ acronym, which signifies that a leader manages ‘meaning, attention, self and trust’. I have spoken about the management of meaning (what does this technological advance mean for my company?), and the management of attention (if this technology is important, then we’d better focus on the following activities). The management of self is fairly obvious although I’ve seen many CIOs transgress this simple principle by contravening their own IT standards or policies. Finally, the management of trust is another key leadership element. Trust is built on three foundation stones: goodwill, competence and commitment – if there is no goodwill towards someone, there won’t be trust. In IT terms the commitment and competence elements are critical. IT people often over-promise and under-deliver. This is true of most of the industry and internal IT people are forced into this situation by the industry vendors who are masters of ‘vapour-ware’. And internal IT people have to over-promise just to remain within the loop. True IT leadership will require a special brand of honesty if trust is to be built – this honesty tempers IT hype with business sense, and filters everything through the organization’s strategic intent. Meeting commitments becomes one of the cornerstones of IT leadership. Finally the issue of competence is not the same as IT competence – it is business competence, and only that. Yes, the CIO must have acceptable technical credentials (otherwise how will they bring their unique perspective to the table?), but the underlying, sustaining competence must be in business.

Everything filters through So what does the IT demand management model mean to business? I have experienced some profound changes in attitudes and activities as a result of business and IT people taking the three roles on board. I had explained the model to a senior IT person one morning. That afternoon he was chairman of a strategic IT meeting, one which involved business and IT people getting together to steer the IT strategy. Halfway through the meeting he awoke to the realization that all they had talked about was technology. Even the business people were into the swing of it: new releases of this, upgrades of that, standardization of the other and on and on. He stopped the meeting, took five minutes to explain the three roles, and challenged the participants to talk business improvement using IT for the rest of the meeting. This changed the flavour of the meeting and spawned three new sessions, each focused on one of the roles. 34

The new business-IT agenda

Almost everything IT does can be viewed through the three roles. I call it the three lens game. Imagine you view the same issue through an MBM, IBR, or IL lens and you’ll see something different each time (see Figure 3.8).

Maintain business momentum

Improve business results

Information leadership

Figure 3.8 The three lenses – playing the game

Let’s take one simple example: data. Viewed through a ‘maintain business momentum’ lens, it is the responsibility of the IT function to provide the data where and when it is needed. If they have to provide the infrastructure in the form of a data warehouse, or a database, then that’s what they do. They keep the data store stable and available, ensure backups are performed and that the right security protocols are in place. They can source this data store externally if they want, their only concern being the provision of a data store service to their organization. Looking through an ‘improve business results’ lens, we start to get into content. What data is stored here? What does it mean? How can it be used to improve performance? Is the business using this data effectively? Can we help them get more from their data? And so on. Data viewed through an ‘information leadership’ lens begs the questions: Is this the right data? What additional data is needed? Is there a new info-product that we can create? How well does everyone in the organization understand data and the role it plays in our success?

The focus changes Another implication of adopting the 3R (three roles) model is that there should be a change in focus of IT activity. Obviously 35

What Business Really Wants From IT

both business and IT need to give their inputs on activity levels in each role, but I believe that if IT wants to add value, and business wants to feel confident with IT’s contribution to their efforts, then there needs to be a swing away from 75 percent of IT’s activity being in the ‘maintain business momentum’ role, and a major push to get IT people doing the business improvement activities should be initiated. I’ll say it again: if IT does no significant proactive actions in the IBR and IL roles, they cannot add value. It’s as simple as that. And the evidence that places them firmly in the MBM role show why IT people are not seen to add value, and have lost the trust of business (almost every Fortune 500 company has cut back on IT expenditure in the last few years). The IT people I talk to like the IL leadership bit. This looks like fun. But they tend to shy away from the IBR role – that looks like hard work. ‘And besides which,’ they equivocate, ‘business doesn’t want us doing their work for them, treading on their toes, making waves’. While individual business unit managers may feel that way, you can bet that, if IT people can generate real business improvements, their CEO won’t mind one bit whose toes they trod on to get the results. And there’s a way to be involved with business that falls entirely within IT’s mandate – it’s called benefits realization, which I’ll go into detail in a later chapter.

If you’re going to do something, try to have a reason for it I think it was Forrest Gump who said this. And the three-role (3R) model gives both business and IT an agenda for discussing IT’s role in business. Many IT people come up through the ranks, having started in programming, moving into business analysis, upwards into project management and finally into management. Their experience of business has been filtered through a technological perspective, and through little fault of their own, all they can see is the technology. I hope this model, either in the hands of a business person or directly, will give IT people a wider view of the business world and will help them with new ways of being in IT but adding real value at the same time. Each role has different measures by which to assess activity and progress. The maxim that you can’t manage something if you can’t measure it holds true here, but the new measures of IT’s performance can make the average CIO blanch: When I asked 36

The new business-IT agenda

a CIO if she was happy committing to delivering $10 million in new products, services or markets through providing leadership in IT, she turned very pale. These are not the criteria IT people are used to being measured by. But to drive a change in focus, to give new purpose to the different roles in IT, such uncomfortable measures are essential.

Real IT performance One of the major benefits of adopting three new lenses for viewing IT activity is alignment. With IT paying close attention to business needs, business improvements, business content and business strategy, there can only be more alignment between IT and their organization. Which brings me back to the three prime worries that CIOs have: ● ● ●

How do I keep IT costs down? How do I add value, and be seen to add value? How do I align with my business?

You keep IT costs down by defining them in terms of business momentum, then managing them with insight into what effect IT costs have on that momentum. You also never talk IT costs without talking contribution and benefit. And to do that you’d better get involved in IBR activities. You add value by doing the activities that add value: benefits realization, business improvement, measurement of contribution, process mapping and improvement and communication. And you align with the business by doing business, not IT. Sounds harsh, but there it is. Internal IT people need to become business people with an IT perspective. These answers are facile. It’s not that easy. But the road to value and alignment lies in clearly understanding IT’s role in business, then structuring IT’s activities into these roles. In their book Jumping the Curve, Nicholas Imparato and Oren Harari (1994) talk about the definition of performance as having changed. They say that the old definition of performance was: P⫽A⫻M Or, performance equals ability times motivation. But they’ve added a new variable into their equation: P ⫽ A ⫻ M ⫻ ARP 37

What Business Really Wants From IT

where ‘ARP’ means ‘accuracy of role perception’. In other words, you can be capable and motivated, but if you ain’t doing the right thing, you ain’t performing. And IT functions in many organizations are not seen to be performing. They need to accurately perceive their roles in the organization, they need to shift their activities into more value adding roles, then they will be seen as performing in business terms.

38

4

Managing technology to maintain business momentum – the first pillar of IT performance Maintain my business momentum using IT without fuss.

This is the expectation of business for their IT function. We don’t want to get too pedantic about the concept of momentum, suffice to say that it helps us understand that any organization has a current level of activity, in its current market place, selling its current services and products. The first step for a business person wanting to work with the IT function is to take a quick stab at defining its momentum. Don’t go into too much detail, because the value of the concept is more in the distinction between what exists now versus what’s new. Table 4.1 may be helpful as a first take on your organization’s momentum. Fill in those parameters that apply to you, add parameters etc., but get a sense for how large, how fast and in what direction your business is going so that you can initiate a discussion with your IT people. Don’t sweat over this table. All we are trying to do at this stage is get an understanding of how large the organization is that is supported by the IT department, how dependent it is on its computing, and if everyone knows what is expected of them. In my experience, it’s a rare organization that has all these answers. And have a thought for the IT people – many organizations don’t know this stuff about themselves and yet they expect their IT function to provide infrastructure and services well into the future. I worked for a company once that didn’t have any strategy. All they had was an annual budget. And they expected me as CIO to plan five years into the future, based on some vague 39

What Business Really Wants From IT Table 4.1

Sample momentum parameters

Momentum parameters

1 2 3 4 5 6 7 8 9 10

11 12 13 14 15 16 17 18 19 20 21

Mass parameters Number of staff Number of computer users Number of branches Staff at head office Number of suppliers (use the 80:20 principle) Number of customers (use the 80:20 principle) Number of products and services Is the organization international?

Speed parameters How fast must you fill orders/supply services? (From the time the customer places an order) What continuous services must you provide? What hours does your core organization work? What days (5 or 6 or 7) of the week? Is your core process/es clearly defined? How many staff work on the core process vs. ancillary processes? How long can you afford to have your core processes unavailable to your customers? How many new products/services are introduced by your organization? How often does your company strategize? At what rate is your organization growing?

Direction parameters 22 23 24 25 26 27 28 29

40

Does your organization have a clear sense of purpose? Does everyone know why the organization is successful (or not)? Does everyone know what the organization produces and how these products/services perform? Does your organization have a strategy (how we will convert our sense of purpose into action)? Is the strategy clearly communicated? Does the organization have a clear IT strategy?

Answer

Managing technology to maintain business momentum

notion of where they wanted to be in a few years time. We succeeded in doing the planning by conducting interviews with the top 50 managers, asking them what was important to them now and into the future, and then putting together an ‘emergent strategy’ which we presented back to them. After another cycle of talking and prioritizing, we were able to cobble a plan together for IT and for the company. The big thing is not to see the above table as an end, rather as a beginning of discussions. Now let’s get back to the agenda. The three roles of the IT function required by business are to manage the technology without hassling or hustling the business, get involved in business matters and provide IT leadership. So the first question is how to manage IT without fuss.

Why manage IT (as against doing IT)? The emphasis is on the word: manage. Here’s the thing: the supply of information technologies is now to a large degree a generic matter. David Birchell and Laurance Lyons (1995) describe a trigger point which was reached in the relationship between business and IT. They suggest that before the mid-1980s, businesses needed more from IT than was available. IT people held the upper hand – they were in demand. If you remember, the PC was still a hobby novelty in the late 1970s. It took until the mid1980s for PCs to become standard business tools, with enough software to meet business and personal needs, and with hardware that was getting cheaper by the day. From that time onwards the average businessman had more computing power in his study at home, compared to that which his in-house IT function was able to give him, and the writing was on the wall for traditional IT methods, organizations and people. It is a logical conclusion that because the average businessperson’s needs are being met in a different way, in-house IT functions must provide services in a different way as well. They need to provide the management expertise over the IT suppliers such that their organization’s needs are communicated correctly and more importantly are met. They also need to ensure that the technologies used by the organization work together and cut down on the amount of time spent ‘between systems’ translating data and formats and the like. In terms of ‘managing business momentum’ the MBM manager is deeply concerned with availability and stability, but from his or her organization’s perspective. They act as agents for the organization, in ensuring 41

What Business Really Wants From IT

that the services needed are provided by the suppliers (whether they are in-house or outsourced). They select the suppliers, brief them on requirements and they manage the suppliers in the delivery of the IT services. I have seen one government organization who tried this and got it woefully wrong. Their MBM managers became gatekeepers rather than agents and succeeded in slowing IT delivery processes to a crawl. So the difference is that the MBM manager makes a commitment to the organization for whom he or she works. They then manage the delivery of their commitment to the organization. Ultimately the IT service provided by whomever they use, is their measure of success or failure. They live and die by service. So ‘business momentum management’ through the provision of IT services is what drives MBM managers. They are passionate about: ● ● ● ● ● ●

availability and stability operations and efficiency management of IT services asset management performance, measurement and reporting supporting business momentum.

IT availability and stability MBM managers maintain their business’s momentum by ensuring that IT infrastructures and systems are available when and where they are needed. And being available includes the service’s stability – its dependability. This in itself is a full-time role, driven as it is by the standard processes used by IT people (Figure 4.1).

1

2

3

Need/ requirement

Inquiry/ study

Design

Figure 4.1

4 Build

5 Install

6 Optimize

7

8

Maintain, track & report

Decommission

The standard availability/stability process for IT

There’s nothing special about these 8 steps – some IT functions have more, some less – and some haven’t formalized their thinking to this extent. Any standard IT textbook will fill in all 42

Managing technology to maintain business momentum

the pieces for you. However, there is more to this than meets the eye. We’ll go into detail at a later stage around who does what, but the average IT department’s mindset often excludes step 6 and 7 and almost always excludes step 8 from the equation – usually with the argument that this is obvious and will happen as a matter of course. And then it doesn’t happen. See the later section, ‘Performance, measurement and reporting’ (p. 48) for a discussion on the business expectations of IT’s communication. The main elements of the above process for the maintenance of business momentum assume that the technology or system has been correctly specified and acquired. Now it should be installed where and when it is needed – in other words it should be made available to the business. This is the concern of the MBM manager. Generally this involves a system roll-out plan and an incremental growth plan. The roll-out plan is needed for a new system or technology, while the incremental growth plan (which is often neglected by MBM managers) recognizes that as the company grows, so will the system requirements. And so too will the organization’s momentum. So making systems and technologies available to the business to maintain their momentum is a moving target – but it need not be an unknowable or unclear target. The job of the MBM manager is to know what systems and technology are currently deployed in the organization, and to plan for growth (or shrinkage) of the momentum of the organization. The incremental growth plan must establish criteria needed before technology is deployed, should estimate what the incremental growth will be for any given budget period, and should budget appropriately, including getting out the original business justification and recalculating the benefits – I discuss this in detail in Chapter 7. Finally, the incremental growth plan should establish a process for authorization of the growth, and then importantly should be left to run within the parameters approved during the budget process. This means removing the constant stream of approvals from the IT department and giving them to the business to perform. This is a departure from the way things normally happen – usually the business requests a new technology or service, and IT approves or rejects it. However, in the 3R model, IT establishes the acceptance criteria with the business, and provided the application falls within the incremental growth plan, IT will merely acquire and install the necessary technology. 43

What Business Really Wants From IT

As far as stability goes IT needs to monitor all ‘momentum’ systems, prevent failures as far as possible, and resolve failures as quickly as possible. And the measure of success in this area is the final availability to users at each workstation – in business terms. Business should insist on a little more sophistication in reporting availability than just a single percentage figure (which IT will try to give you because it averages out its peaks and troughs into something quite high), but the basic requirement remains the same – user availability at the workstation. Availability and stability requirements also have a time dimension. When should the technology or system be available? This is a business decision, often based on the times during which the business operates, but it has IT implications. If you want the systems to be available from 6 a.m. until 8 p.m., the technological requirements are substantially different from a 24/7 availability. And the costs are not linear either – it is significantly cheaper to provide IT for a 6 a.m.–8 p.m. operation. Business should be aware of the implications of what they are asking for. When I was a CIO, my sponsors would get really carried away with over-the-top requirements. I would calmly list their requirements, and would then prepare a sliding-scale costing, from the bare minimum requirement all the way to the grandiose technological requirement specified by the sponsor. It was always a logarithmic scale and always we would settle on a more realistic technology outcome. If the IT department doesn’t give business a number of options for any of their requirements, you should be concerned. There are other time-related measures for stability: you want to know the workstation/system ‘mean time between failures’ or MTBF, as well as the MTTR or ‘mean time to repair’. The first measure indicates how long workstations/systems are stable without disruption, and the second (MTTR) lets you know how long it takes to fix things when they go wrong. Finally, you will probably want to assign severities to problems when they occur. I usually assign three severity codes – severity one indicating that core business operations have stopped as a result of an IT failure, severity two indicating that business operations are compromised (slowed down, patchy availability, etc.) by IT failure, and severity three meaning they are inconvenienced by IT failure. A final word on step 8 of the process: very few, if any, IT functions pay attention to decommissioning of systems and infrastructures 44

Managing technology to maintain business momentum

as a planned and scheduled event. Normally they will upgrade the old system or implement a new one, and run ‘in parallel’ until all users have moved to the new system. Then they may delete the old system and its data files from the infrastructures. Often they don’t do this, because there is one stubborn user left, or they just want to have a fallback position. Decommissioning old systems is part of the asset management element of the MBM manager’s role.

Operations and efficiency The MBM manager is also concerned with how effective and efficient their IT services are. They become involved in IT operational processes, constant process improvement – redesign if needed. Once they are sure their IT processes are effective and are being followed by their suppliers, they keep an eye on the process efficiency; and by definition the cost of providing IT services becomes an issue. They act as guardians of the organization’s IT spend on IT services needed to maintain momentum. Therefore they also have a budget, to which they must adhere, and of course they compile the future IT budgets with all that this implies. I will go into budgeting and measures (including costs) in a later chapter. Again I must stress that the MBM manager commits to their organization to meet certain operations and efficiency targets. They then manage the suppliers of the IT services to ensure that they meet these commitments, and comply with their operational practices. They expect their IT suppliers to report on their performance, and they manage that performance stringently, because their reputation and commitment is at stake in their organization.

Management of IT services benefits I am of the firm belief that IT people should never, never talk about the cost of IT without having a firm grip on the benefits that such technologies bring to the organization. There is a whole chapter in this book devoted to the determination and validation of IT benefits, and IT infrastructures and services benefits are included here. However, IT people often tell business that there is no way of determining benefits for most IT infrastructures and services, because the specific technology is generic and services a number of systems across a number of businesses. There is of course a way, but the effort required to 45

What Business Really Wants From IT

determine such benefits is extreme, and a decision must be taken on whether the effort is worthwhile. I believe that the effort to establish ball-park benefits is significantly less and should be made. I believe that a week’s worth of work can establish an 80:20 rule of thumb for the benefits of providing IT infrastructures, workstations etc. Ultimately the bottom line is this – IT has the responsibility to establish what benefits their services bring to the organization. And they have the responsibility of reporting these benefits on an ongoing basis, and of assessing the impact on this benefit stream, for any change to their systems and infrastructures.

Asset management Maintenance of business momentum requires the management of IT assets. This usually gets the nod from the average IT person, but I haven’t yet seen an IT department that manages (plans, executes and monitors) IT assets over their entire life cycle. I devote a chapter to the measurement of IT, and a significant element of this is moving away from ‘snapshot’, annual measures of IT performance, to life-cycle measurement of IT performance and assets. If an IT person tells you that they do manage IT assets, ask to see the entire spend on a particular system from the design stage until the present time. I still wait in anticipation for a single IT department to be able to do this for me. (I’m hoping this book will flush a few exceptional IT departments out of the woodwork, so that I can use them as exemplars in future writing.) I’ll go into measurement and management of IT over entire life-cycles in a later chapter, but Figure 4.2 is the kind of performance graph that business should look for from their IT people. In operations terms, this is called a ‘bathtub’ curve, because once implemented, a system’s operating costs should decrease to

Figure 4.2 Life-cycle measures of IT systems performance 46

Cost/month

Development Early life

Standard life

Time

Late life

Managing technology to maintain business momentum

a level, remain at that level for a number of years and then, as the system ages and loses fit with business operations, should increase again. This graph is true too for the number of problems being experienced with the system.

Problems

But usually the IT department is guilty of what I call ‘postagestamp’ reporting in which a graph like this…

Time

Problems

… gets translated into a graph like this…

Time

… by making sure that their sponsors only see a postage-stamp sized portion of the big picture. This postage-stamp seems to indicate that there is a net decrease in problems over time, which of course does not represent the big picture. This does not mean that IT is being dishonest or even deliberate, because often they only measure performance in postage-stamp sized chunks, and they are also trying to put their performance in the best light, as would any normal person. But it is the business’s requirement that they get to see the whole picture. Later we will discuss other significant interpretations that can be made from life-cycle measures, especially when these are combined with benefits derived over the life-cycle of a particular system. IT financial management is another part of the MBM manager’s portfolio – ensuring that delivery of services and technologies matches the invoices for that delivery. Preparing the MBM budget or technology budget is a specialized activity that we will go into in Chapter 9, where I discuss a budgeting model that fits with the three roles. 47

What Business Really Wants From IT

Performance, measurement and reporting Do you remember in an earlier chapter that I showed findings in which IT people were not seen to be good communicators? Well this is where it starts. IT people may be deeply concerned about the performance of their infrastructures and systems. They may even measure system performance in detail (although this costs money, as IT performance measurement software is complex and expensive). But here’s where the chain breaks – IT reporting tends to be too technical, too equivocal, and too ‘precise’ to be of use to the business. When I talk about being too technical, I am reminded of a proud network manager who showed me his graphs of network availability for his two-tier network – firstly, as an outsider I didn’t know what a two-tier network was and also I was interested in one thing only – how stable the entire system was. Because IT systems and infrastructures are all interlinked – as a chain which provides end-user services, there are complex algorithms which have been derived to account for availability of the system but unavailability of the network, for instance. IT systems work both in series and in parallel. For ‘in series’ devices, imagine a single hose-pipe linking a number of garden watering units – a failure at any one point in the pipe causes all ‘downstream’ devices to fail. Devices connected in parallel (imagine a number of hosepipes to one watering unit) may fail, but have little effect on the final unit. Now of course IT devices have both types of connections with key bottlenecks etc. – so while the host application system may be unavailable, but the network remains stable, users may be unable to perform order-entry work, but may be able to send emails. This makes measurement and reporting complicated, and intimidates most IT people. But their survival depends on it, because in recent years IT and its purported benefits have become the subject of extreme business scepticism. I deal with this more in Chapter 7, with a quote from Kit Grindley (1991), who studied what CEOs thought of their IT functions. One of the CEOs responded: Like other chief executives, I feel I’m being blackmailed. Not just by the suppliers, I expect that. But by my own IT staff who never stop telling me what the competition are spending.

So the reporting of IT performance must be regular, real and from a business perspective. And who better to judge its efficacy than business people. 48

Managing technology to maintain business momentum

Supporting business momentum Ultimately the MBM manager must have his or her eye on the business momentum – its size, geographical spread, its speed and its direction. The performance of IT must be viewed through a business perspective: ● ●

●

●

How is IT contributing to individual business objectives? How does the existing IT infrastructure and systems support the organization’s strategic intent? How is the business momentum changing over time? (There is no better role than for IT to keep the business informed about transaction volumes in all its major processes.) Finally, how does the organization view the IT service provided by the MBM manager, who has committed to providing these services?

Service management is the key to the MBM manager’s business life and performance. Many IT departments like to have service level agreements (SLAs) with their users. This is a quasicontractual agreement on what services IT will provide, how they will provide them and to what quality standard. My view is different. I worry about the ‘contractual’ nature of service level agreements. There is the story of an American negotiating team visiting a Chinese company, and reaching an agreement on supplying some goods. Everyone was happy, hands were shaken, and the Americans said: ‘Well, that’s settled then. We’ll just get our lawyers to draft the contract and we’ll be seeing you real soon’. The Chinese businessmen were affronted – hadn’t they just shaken hands, hadn’t they agreed? And that’s the problem with service level agreements. They tend to become contractual real soon. That the nature of IT services needs to be spelled out, at least in broad brush strokes, is worth some debate. It’s a little like a marriage contract – the only time you refer to it is when things have already gone wrong. Rather, I would prefer to see a ‘service charter’ or even an IT services agenda or menu, specifying what services are available, with what quality criteria, and at what cost. This agenda then guides discussions between the MBM manager and his or her business sponsors. And in doing so, it guides the MBM manager in what he or she measures and reports on.

Activities of an MBM manager I want to reiterate: the person or people responsible for fulfilling the role of ‘maintaining business momentum’ through the 49

What Business Really Wants From IT

management of IT, make a commitment to the organization to provide a service, and then manage the provision of that service. Typically an MBM manager would draw up an IT Services Agenda with the headings similar to the following (recognize the first section?): ●

●

●

●

●

50

Business momentum parameters ❍ number of staff ❍ number of computer users ❍ number of branches ❍ staff at head office ❍ number of suppliers ❍ number of customers ❍ number of products and services ❍ number of international links ❍ business speed parameters ❍ how fast must the organization fill orders/supply services ❍ continuous services the organization must provide ❍ hours the core organization works ❍ days of the week ❍ strategic intent of the organization ❍ key organizational objectives IT services and infrastructure availability parameters ❍ provision of new infrastructures ❍ incremental growth parameters ❍ capacity planning IT stability parameters ❍ key MTBF (mean time between failure) and MTTR (mean time to repair) objectives ❍ key IT performance objectives (response times, turnaround times etc.) ❍ backup objectives/services ❍ security objectives/services ❍ IT supply management service Infrastructure and applications management and support ❍ planning objectives/services ❍ organizing (resourcing) objectives/services ❍ operational objectives/services ❍ monitoring objectives/services ❍ reporting objectives/services ❍ budgeting objectives/services IT architecture – data and technical models ❍ standardization objectives/services ❍ IT architecturing services

Managing technology to maintain business momentum ❍ ❍

data management services etc.

Now if you’re anyone like myself, your eyes will have glazed over by the third main bullet point. However, there are a number of key points that come out of the above list: ●

●

●

●

●

Notice how the list starts with what the business is doing: how big it is, how fast it needs to move, what it sells etc. IT people have this need to be aligned with the business, but for some reason they avoid this first section in many of their documents. Even if it’s just for clarity of purpose, this section should be included in the IT services agenda. Notice also that many of the bullet points talk about ‘objectives/services’. This depends on the organization and its relationship with its IT department. Perhaps you want to set things up as objectives for the IT department to meet, or they may feel comfortable in providing ‘services’ to the organization. This is a matter of choice and culture. However, the MBM manager is making a commitment around these objectives or services. I prefer ‘objectives’, because they imply we’re all on the same side, and ‘services’ tend towards a contractual flavour again. Included in this list are monitoring and reporting objectives. Don’t take this lightly. The relationship between IT and the organization depends on these two parameters. Again, I must stress, that I prefer to see the above list as an agenda for discussion between the MBM manager and the organization, rather than as an agreement or contract. Finally there is no reason why the final agenda and reports on performance against the agenda should not be made available on the organization’s intranet, open for discussion, comment and improvement.

Whatever the final agenda, it is likely to be more detailed and complex than the one above. However, the simpler things can be kept the better, for the sake of effective communications, and also to keep the organization from getting bogged down in the detail and losing sight of the key role of the MBM manager: Maintain business momentum through the use of IT.

51

5

Managing business results from an IT perspective – new rules, new challenges

In Chapter 1 I talked about how my CEO told me that IT people were like librarians: cataloguing, managing, shuffling, storing and securing, but never reading the books. This chapter deals with how the IT department should ‘read the books’, which ‘books’ they should read, and when and why they should read them. Because while it is not the job of IT to do the work of the business directly, it is their job to be involved in how the technologies are used to best effect for the organization. It is important to always stress that IT people bring a unique perspective to the organization and if they use that technological perspective in its widest sense in collaboration with the business, then the potential for improving business results is manifold. And it is this unique IT perspective and its power that this chapter will explore. In terms of the ‘improve business results’ (IBR) role, there are five unique competencies that IT is underutilizing, largely because they are so focused on the first role of IT – maintaining the business momentum through information technologies. And the time they spend in designing new systems for the organization tends to be focused on the technological feasibility, often as I have observed, in reactive mode: the business wants something, and IT tells them whether it can be done or not. The ‘traditional’ way of developing IT solutions for the average organization involves something called the ‘systems development life cycle’ or SDLC. In the textbook SDLC there are five or six steps in the development process. There have been a number of academic papers published which compare the different systems development life cycles which have been proposed by various academics and development companies. I have taken a 52

Managing business results from an IT perspective Table 5.1

General comparison of system development life cycles (SDLCs)

Broad comparison of different author’s definition of the SDLC Generic SDLC

Laudon and Laudon (1995)

O’ Brien (1999)

Ward and Griffiths (1996)

Project definition

• Problem analysis

• Systems investigation

• Strategic study • Tactical study

Systems study

• Problem understanding • Decision making

• Systems analysis

• Detailed system design

Design

• Solution design

• Systems design

• External design • Technical design

Programming

• Implementation

• Systems implementation

• Construction

Installation

Post-implementation review

• Implementation/ transition • Production • Systems maintenance

• Post-implementation review

small sample here, and as you can see in Table 5.1, most of the ‘differences’ amount to arranging the deckchairs on the Titanic – of no material importance. None of these methods is wrong. In fact most authors go out of their way to point to shortcomings in the approach – but their shortcomings deal with the way systems are developed, and point out modern alternatives like prototyping, customizing system packages and outsourcing your development. And keep in mind that we are looking at texts written from an IT perspective. Let us take a business perspective and examine business people’s expectations of their IT departments. Business people don’t care about the SDLC or any other IT acronym, they just want their IT department to meet their processing and technology needs – and these include building or acquiring systems, installing the technologies needed to support the systems, running and maintaining the systems, managing system costs, updating the system when needed, and ultimately retiring the system when it ceases to be useful or costs too much. And the business sees this as pretty much run-of-the-mill activity for IT – their base level of performance. So when a textbook is written about these activities, it will naturally focus on the technologies and management techniques required by IT people. Do you notice something about the ‘systems development life cycle’?: This so-called ‘life cycle’ isn’t really a life cycle at all. 53

What Business Really Wants From IT

These ‘life cycles’ end in something called a post-implementation review or with a step called ‘maintenance’, but none is concerned with the real life (and death) of the system. You can’t tell from Table 5.1, but in the detail of the SDLC description, you will find that in all cases they are concerned with working with the business to develop a business case, a feasibility study, designing and building the system, and finally implementing the system: ●

●

●

●

●

None is concerned with the business expectation that IT will be partly responsible for achieving the benefits that the system promised. In fact none suggest that the business case is, from an IT perspective, anything more than a way of justifying the funds to build the system. None is concerned with ongoing changes to business processes to fit the system and the business more tightly together. None is concerned with improved measures of business performance that are enabled by any new system, and with the subsequent improvements to the business, that are made possible by these new measures. None is concerned with the content of the information that flows through the system. None is concerned with the way this system behaves in the service of the company over time, and how this system fits with all the other initiatives happening now and in the future in the organization.

And then CIOs tell me they want to add value. But how can they possibly add value if they don’t meet business expectations by doing this additional stuff? This is where the IT traditionalists come out fighting. They’ll say that their job is largely over once they get sign-off on the implementation – all that remains is ongoing maintenance. They say that it’s the organization’s job to get the benefits, to measure its performance, to fit this initiative with all the others, and on and on. Finally they say that if a librarian reads all the books, then they won’t have time to be librarians, will they? And as with all contentious issues, they will be partly right in all their arguments.

The unique unused gifts that IT people bring to the organization At the beginning of this chapter I stressed the unique perspective that IT people bring to the table, and I believe that organizations 54

Managing business results from an IT perspective

are losing a significant set of skills and IT is losing a significant opportunity to add value if they stop at the SDLC or any other traditional way in which IT interacts with the business. The unique perspective that IT brings to the organization includes all the skills and competence needed to execute the SDLC, but it also includes (or should include) a competence in: ●

●

●

●

●

●

●

Developing the business case and accompanying benefits statement: IT needs to develop business cases and benefits statements with the intention of achieving the benefits with the business. Achieving the benefits promised in the benefits statement: IT’s involvement needs to change from a ‘not my problem’ attitude to a collaboration with the business in ensuring that the technology is used to its best potential. Business measures: IT is in a unique position to measure business activities and be proactive in providing measurement models, systems and indices for business use. Process management: in order to develop a system IT needs to map the business processes. Once the system is developed, IT shelves its process maps. But there are significant ways it can continue to use these process maps to improve business results. Information content: most IT people still consider data and information as the property of the business. Their role is to provide the tools for its collection, storage, organization and interpretation. Their untapped competence lies in their ability to interpret and act on business data themselves. The real life cycle of systems: IT people break system life cycles into two distinct stages – development and maintenance. But the business expects them to take a view across the entire life cycle of the system. Portfolio management: IT is in a unique position to see and manage all initiatives within the organization, to the benefit of the organization.

I’ll describe each competence briefly and then use a hypothetical example of how each competence is applied.

Developing the business case and accompanying benefits statement The important thing here is to focus on benefits to be realized as if you will have to actually achieve those benefits, within timeframes 55

What Business Really Wants From IT

and according to a measured standard. This means that considerable effort goes into identifying the benefits that will derive from a system, defining what those benefits mean for the organization, and identifying what actions must be undertaken to achieve the benefits. By the way, the business case should present a probability matrix of benefits, because these are benefits which are predicted based on a number of assumptions. I stress to business people that if their IT department tells them: ‘The cost of the system is $1.5 million, but the benefits are $6.3 million’, send them away. They haven’t thought things through – there are significant assumptions that they will have made in both the cost and the benefit areas, and there can be no definite single number on either the cost or the benefit side of the equation. This ignores also the complicating factor of time – you may have to bear the $1.5 million cost in the next six months, and wait for the next six years for your benefits. A serious business case spends a considerable amount of effort defining what I call the ‘outcome space’. This is as clear a picture as you can get of the financial, people, technological and process conditions that will apply once the system is implemented. If the IT department is serious about adding value to the organization, it will have to show a sober intention of attaining the benefits that are proposed in the business case, with the business’s help of course. Outcomes not outputs The bottom line of IT intention must be their focus on outcomes not outputs. An outcome in dictionary language is: ‘something that results’, while an output is: ‘a thing produced’. And there lies the difference – outcomes thinking is concerned with results while outputs thinking concerns itself with producing a ‘thing’. In IT terms, outputs are systems, infrastructures, services, plans and architectures. Outcomes on the other hand ask the question, ‘So what?’ (Table 5.2). Table 5.2

56

The correlation of IT outputs and business outcomes

IT outputs

Business outcomes

Infrastructures (networks, workstations, etc.) Systems (applications, processes etc.) Operating systems (security, user mgt. etc.) Services (development, project mgt. etc.) Architectures, standards

Access, availability etc. Business results, benefits, etc. Security, ease of use IT value add Stability, interoperability, etc.

Managing business results from an IT perspective

A hypothetical case study The question for the IT person whose role is to ‘improve business results’ (for the rest of this chapter we will call this person the IBR manager – although there are many titles you can formulate for your specific culture) must be: ‘You delivered the customer tracking system. So what does that mean for the business?’ Let’s use the previous bullet list to pose some outcome-based questions for this hypothetical customer tracking system: When the business case is developed for a hypothetical customer tracking system, the focus must be on business outcomes: ‘So what if we can track our customers better?’ ● ● ● ●

●

Will we interact with them more often? Will we identify risky customers? Will we identify sales opportunities? Will we address our customers by name, know their likes and dislikes, and have tracked their interactions with this company? How much on average will our business return be as a result of each of the above proposed benefits? (There are financial benefits that can be quantified for each of these outcomes – I’ll deal with defining benefits in more detail in Chapter 7 – it’s not difficult, you just have to have the will to do it.)

Many IT people stop short of this last bullet point, labelling the benefit as ‘intangible’. But if the will is there, no benefit need be intangible. If you and the IT department are serious about defining the outcomes and benefits, you will then go through another round of ‘so whats?’ and you will also specify ‘how’ you will achieve these benefits. Remember, the primary difference between an outcomes-based approach and an outputs-based approach is the intention to actually realize the benefits once the system is implemented. So your next round of ‘so whats?’ will ask the questions: ●

●

So what if we interact with our customers more often? How will that affect our customers’ behaviour? How will that have a revenue result? How will we interact with them more often? Will we talk to them on the phone? Will we email them? How?

By the time you’ve finished this second round of questioning, you’ll have started to build a good idea of what the ‘outcome space’ will look like once the system is implemented. An ‘outcome 57

What Business Really Wants From IT

space’ is a picture (mental or real) of what the end-state of the fully implemented system looks like – in business terms. This line of questioning will also suggest, nay insist on, a course of action to be followed once the system is implemented in order to realize the benefits that you have identified. Again – if your IBR manager is serious about his or her role in improving business results, he or she will have the definite intention of achieving the benefits stated in the benefits statement.

Achieving the benefits promised in the benefits statement Who is best equipped to study the system/business interactions and make recommendations on how business can improve its operations using its technologies? In my experience, the needs/requirement step is usually executed well – mostly because it is driven by the organization’s generic acquisition processes, which requires the usual return on investment, internal rate of return calculations. In order to get these, the IT department has to work with the business to show what benefits will be derived by the business, how much those benefits are worth, when they will be achieved and so on. Attaining the benefits will obviously have to happen in collaboration with the business, because it really isn’t the job of IT to take sole responsibility for this activity. However, they can add an invaluable impetus to this work, if they take a united approach – work with the business in looking at why the system was implemented and chasing the often elusive gains the system was meant to achieve. This includes putting in place a programme to achieve the benefits from any new system, as well as from existing systems. There is an apocryphal statistic that I have heard for some years now: business only uses between 10 percent and 20 percent of the functions built into any system. The real statistic doesn’t matter (did you know that 74 percent of statistics are made up on the spot? (including this 74 percent statistic)). What is important is that when I talk to CIOs they universally regard the 20 percent as being unacceptable. So whose responsibility is it to get better use of the systems? I believe that senior business managers want IT to push improved use of systems. So IT should initiate a programme that looks at existing systems, identifies the as yet unattained benefits and does something about achieving them. One CIO I worked with believed that she could achieve a 20 percent improvement on existing use of her systems. When 58

Managing business results from an IT perspective

we came to translate this into numbers, she became a little less adamant: because IT was costing the company at least $24 million. She believed that it was reasonable to assume that the benefits derived currently at least equalled the IT cost (we proved later that benefits were only 78 percent of the cost – IT was a net loss to the company). So I suggested that she commit to a programme that would generate 20 percent more benefits from better use of existing systems, or $4.8 million in added benefits without any major IT spend. The CIO turned pale: this type of commitment starts to get uncomfortable for IT people. But how else will they prove the value of their systems? IT can also add value by tracking these benefits for the business. They have the tools, the information flows through their systems and it is in their interests to track the benefits that their systems bring to their organization. IT people often labour under the false notion that it is the business’s job to achieve the benefits of a system. An IBR manager who has the intention of helping his or her business achieve the benefits has no such misconceptions. So the IBR manager will begin the benefits realization process with a post-implementation review. (Notice I said ‘begin the process’ where most IT academics and authors think the post-implementation review is the end of the process.) There is a difference between a post-implementation review and a post-mortem. Many so-called post-implementation reviews examine how well the project went, or didn’t go; whether the original budget was exceeded; whether the full scope of the requirements was satisfied and whether there was scope creep; whether the project came in on time and according to the quality specifications. There’s nothing wrong with a post-mortem, in fact it is essential if you’ve outsourced your development to an external company. But a post-mortem has nothing to do with improving your business results. It has everything to do with IT’s efficiency and effectiveness and is definitely the concern of the MBM role, but not of the ‘improve business results’ (IBR) role. The post-implementation review conducted by the IBR manager takes as its foundation, the benefits statement. Attendees at this review are mostly business people with some IT people as well. The IBR manager goes through each benefit, including the ‘how will we achieve the benefit’ sections, and begins the programme of benefit realization. Initially, some of the benefits may be dependent on some level of IT critical mass: either the number of problems with a particular part of the system must 59

What Business Really Wants From IT

reach an acceptable level, or there needs to be six months’ worth of data in the database, or the roll-out of workstations to branches needs to be completed, and so on. Which is fine, because the IBR manager is managing the implementation and use of the system. But a number of benefits will be attainable by the business immediately. Or the business is under-utilizing the system and a programme to draw people into the system needs to be drawn up. Or functions that are available in the system are not being used. Or reports are not being used or need to be changed. The point here is that the IBR manager is coordinating a combined effort between the business and IT to get better use out of the system, and as a result to get improved business results from the system. The hypothetical case study In our hypothetical example of a customer tracking system, a number of benefits were postulated before the system was approved. Now is the time to revisit them and review the actions that were suggested to attain those benefits (see Table 5.3). Table 5.3

Translating benefits into actions

Benefit

Revenue/pm

Actions

Interact with customers more often

$60 pc (pc ⫽ per customer)

Identify risky customers

$113 pc

Identify sales opportunities

$145 pc

Address our customers by name etc. Total benefit per customer

$10 pc

• Identify which customers call us regularly • If a customer doesn’t call within his/her regular timeframe, phone them • Record why the calls have stopped • Include latest marketing material in letter to customer • Consider loyalty programme for customers who call more than once per week • Identify customers who default on payment by more than 60 days • Add interest charge to ⫹60 day payments • Three times defaulters become COD customers until six non-default payments • Link customers to products list • Set up an ‘also buys’ list • Identify related products and link to customer • Offer related products to customer at 10 percent discount • Link customer tracking system to call centre • Predictive phone dialling

Total benefit (800 cust)

$262 400

60

$328 pc pm

Managing business results from an IT perspective

Now this table isn’t what the business case benefits statement looks like – for that see Chapter 7 – but it is a summary of the business case. The important thing is the actions on the right. On the right of these actions should be a list of measures which track when the actions are implemented. The IBR manager works with the business to ensure that these actions are executed, that they are spread throughout the organization and that they are inculcated into the daily operations of the company.

Business measures When a system is implemented, there is usually a benefit that states that ‘the new system will give the organization a new set of measures’. If you’re lucky, the IT department will include development of management reports as part of the system, but my experience is that as deadlines approach and costs exceed budgets, the first thing that is regarded as expendable is something called change management. Then quality checking and stress testing of the system is ditched. Then development of management reports is moved into ‘phase 2’ of the project. But this is one area that IT can add real value. Not just in reacting to business requirements for information, but by ‘pro-acting’ (if that’s a word) – looking at the information that flows through the systems and offering new measures, check digits and automated triggers, new ways of looking at business functions and new insights. The hypothetical case study Continuing with the hypothetical customer tracking system, we find the IT department is in a unique position to assist the organization in measuring its activities. Firstly when you and the IT department are working on the original business case, you will have to come up with some existing indication of business activity. For instance, in order to claim a benefit of interacting with customers ‘more often’, you had better have an idea of how often you interact with customers right now. You might come up with something like Table 5.4. As you can see, we are concerned with the 80:20 rule, focusing on the customers who are worth the most to us. If you don’t have any of this information, there is a way of getting it involving an adaptation of something called the ‘Delphi technique’, 61

What Business Really Wants From IT Table 5.4

Customer metrics

Metric

Measure

No. of customers (20 percent bringing 80 percent of our revenue) Average number of interactions per customer Highest number of interactions Average revenue per 80:20 customer Average number of new customers per month Average number of lost customers per month etc.

800 2 per month 7 per month (90 percentile) $1202 per month 62 58

which I cover in Chapter 7. But to my mind, there is no reason why measures cannot be derived. The next step is to estimate the improvement targets against these baseline figures. Even if the baseline figures are an estimate, you need to do this, because the next step is to establish exactly how you will measure each metric. I will go into measurement in some detail in Chapter 9. An important principle to realize here is the difference between form and function. Many organizations have a ‘customer service department’ (the form) but give lousy customer service (the function). Some companies measure the number of customer complaints (the form) but do very little about preventing the complaints in the first place (the function). The IBR manager is interested in measurement of business transactions, and processes (the form), because she is in the best position to perform those measurements, but mostly because she is in a position to improve the business (the function) by intelligent interpretation of the measures and then by engaging the business from her IT perspective to effect the changes necessary. This is an outcomes mindset. The IBR manager is interested in measures (outputs from the systems) only because of the business outcomes that can be derived. There is also no reason why IT cannot be proactive in business measurement: there they are, with information and data washing around their systems, and they are more concerned that it flows than with what’s in the information. In this situation a CIO will be able to say: ‘Yes I could see that the company was failing months ago’, but have done nothing to prevent that failure. So IT can put in place intelligence which identifies thresholds of business activity, or identifies key strategic parameters which give early warning to the company, in good time to take appropriate action. 62

Managing business results from an IT perspective

Process management There is a ‘white space’ in most organizations that is owned by no-one. When any system is developed, the IT people religiously develop a process map for the particular business function being computerized. And then they usually shelve these process maps. What if they used their IT competence to make these process maps a living thing? To link these processes to other processes? To constantly examine these processes for business improvement opportunities? The hypothetical case study Now we have a customer tracking system. When we designed it, we mapped how customers interact with the company. We traced volumes of traffic along our different channels, we identified bottlenecks and weaknesses in the process, and we were able to remove all the unnecessary steps in the company’s interaction with customers. We drew up process charts, input/output diagrams and applied measures and controls to each activity. And then once the design was completed, we shelved all this work until next time. But a true ‘improve business results’ mindset, an outcomesbased mindset, will not stop here. The IBR manager will look at these process flows, and wonder, ‘Does that really happen? Was that process really implemented the way it is depicted here? Were those controls really put in place? Did the predicted outputs really materialize?’ And if not, why not? (the IBR manager is in for some sleepless nights). It seems strange to me that IT will do all this process work during the design of a system, and yet not follow up, or verify the results after the system is implemented. And while you’re at it, IT should be checking how the existing customer tracking process interfaces with other processes. Whenever I consult, I always find numerous areas for improvement in other areas of the business, which because they are not directly related to my particular assignment, I merely note in my report and leave them. IT projects are no different. Whenever a design team starts scratching below the surface, they will see numerous other inconsistencies and problems, which are not directly related to the system they are designing. A committed IBR manager will document these, and add value to the company by proactively solving them or at least drawing them 63

What Business Really Wants From IT

to the attention of the business manager concerned. Whether our IBR manager wins any popularity contests depends largely on his or her attitude of cooperative improvement and his or her personality. Diplomacy is an important characteristic.

Information content Here the IT librarians stand firm – they say the data belongs to the business. And so miss the value adding opportunity staring them in the face. IT people can bring enormous value to the organization, merely by looking at the information. An example comes to mind: in a bank I worked with, a data warehouse system tracked the amount of time that was spent working with defaulters in a motor finance company. It showed that the company spent 98 percent of its time working with the 30 percent of the clients who defaulted on their repayments. It also showed that this time expenditure was valuable in that only 10 percent of these defaulters turned into bad debts – their cars had to be repossessed. But no-one saw that the data warehouse was also capable of tracking the non-defaulters, the low-risk clients. And it could automatically send a letter to these clients three months before their loan was repaid, offering them new finance, linking them to new vehicle opportunities, and even offering a discounted interest rate as long as they never defaulted. That would have added real value to the bank. Unfortunately the IT department was of the opinion that the data was owned by the users, so nothing ever happened. We have talked at some length about getting deeper into information than the current: ‘watching the information flow by, and as long as it flows, that’s my job done’ attitude. Many IT departments aren’t even concerned with the cleanliness of the information, this being, according to the party line: ‘a business problem’. That the business is responsible for the quality of its data is generally accepted, even by the business. But must IT be so ‘handsoff’ about data cleanliness? If they wanted to add value to the business in this domain, they would be looking at automated data-cleaning programmes, filters and input verification systems. (Beware that these tend to slow business processes down and seriously annoy data capture functions.) They do this in cooperation with the appropriate business person. They are outcomes driven: ‘We have all this data? So what?’ But they also get involved in the actual data. Artificial intelligence and data gophers are much better understood by IT people, 64

Managing business results from an IT perspective

and with some intelligent mining, they can bring new insights to the business. The hypothetical case study Coming back to our customer tracking system they might be able to say something like: ‘Even though the average revenue per customer is $1202 per month, this average for our new customer as a first-time purchaser is $2365. Now what is driving this, and can we strengthen the trend? Can we attract more firsttime buyers without losing our established customer base?’ And so on. This is all hypothetical, so it’s easy to invent favourable scenarios. In the real world things are more complicated, but I want to illustrate a point. IT in general isn’t doing this kind of value-adding work. Why? Because they are focused on the technology … because they are acting like librarians.

The real life cycle of systems Remember the ‘bathtub’ curve in Chapter 4? That’s a life cycle: it begins with tracking expenditure and benefits of a system when it is still on the drawing board. This tracking continues until the system is implemented – then additional life cycle measures are tracked related to systems stability and availability. Then when the system is old and grey, the cost/benefits/ availability/stability measures give an indication that it is time to upgrade or replace the system. Finally, once the system has been replaced, it is decommissioned, and the tracking of its cost and benefits can stop. That is a real systems life cycle. And no-one has the competence or will to do it except the IT department. Earlier I suggested that the systems development life cycle is not really a life cycle. It certainly isn’t a system’s life cycle which, in cost terms, looks like Figure 5.1.

Figure 5.1 Typical life-cycle costs of a system

Cost/month

Development Early life

Standard life

Late life

Time

There are a few things to notice from this figure. Firstly the ‘SDLC’ (systems development life cycle) covers only the first 65

What Business Really Wants From IT

two stages of this system’s life cycle, handing over the ‘standard life’ and ‘late life’ to some ‘just do it’ portion of IT’s activities. Maintenance and decommissioning is not exciting stuff in the IT world – when I was CIO we battled to find maintenance programmers, or to keep developers on to do the maintenance of the systems they built. Of course business doesn’t care about this, because they don’t break the life cycle of a system into compartments the way IT people do. They want to see the whole picture. Notice something else: most of the costs of the system appear to occur in the first two stages of its life. Development costs a significant portion, but in the ‘early life’ of the system there are teething problems to be ironed out, implementation and training costs to be borne, and IT usually uses this opportunity to do the things that they should have done earlier but ran out of time for – like reports, quality checks and documentation. However, notice that although the intensity or rate of spend on IT is at its highest during the first two stages, IT spend on a system continues for the life of the system, increasing again at the end of a system’s life. This final spurt of IT spend occurs because the system no longer does what the company now does – there is a loss of fit with the business. So changes are made to the system, and these cost money. Also because these changes tend to be add-ons to a usually poorly documented system (IT people hate documenting their systems), they cause problems with the previously stable system and the costs rise. If we were to convert the bathtub curve into a cumulative graph we would get something like Figure 5.2.

Figure 5.2 Cumulative costs of a system over its life-cycle

Cumulative costs

Development Early life

Standard life

Late life

Cumulative costs

Time

So you can see that the costs of running an IT system don’t disappear after the SDLC ends, the rate of spend just slows down. If you’re lucky. Because many businesses change so rapidly that an almost continuous ‘development’ team is needed to keep the system in synch with their constant change. 66

Managing business results from an IT perspective

But even if the IT department measures the costs of their system over the entire life of the system, they will still only be clapping with one hand. Because if they don’t track the benefits that the system was supposed to deliver and actually does deliver, they will always be seen as a net cost to the business. I am so adamant about this that I would call it the first law of IT management: Never talk IT costs unless you talk IT benefits!

I will repeat this refrain from here on. If you ever hear IT people talking about costs, ask them about benefits, and if you ever hear them talking about benefits, ask them about the costs. You can’t allow one without the other. This is a mindset change for both business and IT, but if there is one change that you make as a result of reading this book, it should be this one. And the IRM manager should track both the costs and benefits at the same time (Figure 5.3). Development

Figure 5.3 Mapping costs and benefits of a system over its life-cycle

Cumulative cost/benefit

Early life

Standard life

Late life s

fit

e en

eb

u

m

Cu

iv lat

Breakeven

sts Cumulative co

Time

There are some things to observe here. Firstly there is a thing called a breakeven point, where the cumulative benefits exceed the cumulative costs. It is only after this time that IT adds value and can be seen to do so. IT people will argue that a significant number of the benefits from their systems are ‘intangible’ and therefore not measurable. They will also argue that tracking benefits is difficult because they are mixed in with all sorts of other revenue streams and generators. I argue that this ‘nocan-do’ attitude is why IT are seen as a net cost and their value is doubtful in many organizations. IT people are convinced that 67

What Business Really Wants From IT

they add value, they know it. And probably they do, but it’s like playing a complicated piano solo without the piano: they know how beautifully they are performing, but everyone else looks on at their crazy gyrations and wonders: ‘What on earth are these IT people actually doing?’ Chapter 7 deals with developing business cases, understanding and quantifying benefits, and the tracking of those benefits over the life cycle of every system. The hypothetical case study The hypothetical customer tracking system life cycle track will of course be incomplete, but there is no reason why it can’t be predictive, projecting its costs and benefits into the future (Figure 5.4). Development

Figure 5.4 Cost/benefit curve for a hypothetical customer tracking system

Cumulative cost/benefit

Early life

Standard life

Late life

ts

efi

ve

ati

ul

n be

m

Cu

Breakeven

Cumulative costs

Time

The curve in Figure 5.4 differs in three ways from the previous generic cost/benefit curve, in that much of the curve is projected as dotted lines into the future. Also notice that we haven’t completed the ‘late life’ section of the curve, more as a perception management tactic than anything else. If it is important for you to show that costs are expected to rise and benefit to fall at some later stage, feel free to do so. Finally, here’s a subtlety that you may have missed. Usually a system can only derive benefits once it has been implemented. But here we are claiming benefits while the system was still in development. This is because during the investigation stage, the IBR manager had his eyes open for opportunities to improve business results, and noticed that the call centre had quiet times. He introduced a manual recording 68

Managing business results from an IT perspective

of regular customers and created a call-back process in which the call centre staff used their quiet time to increase the company’s interactions with their clients. The IBR manager also tracked the benefits and saw an increase in sales as a result of this call-back process. And he started reporting the benefits, increasing the business sponsorship of the new system, and reducing resistance to change. And the system hadn’t even been implemented.

Portfolio management Another area where IT has a unique competence and position within the organization, is its ability to take a big-picture, crossfunctional view of business activities – certainly when technology is used. Some IT departments call this portfolio management or a central projects office, and they stolidly manage multiple IT projects from this position (of course their interest often stops when the SDLC stops – they tend not to manage the entire life cycle of multiple projects). But they can add more value by taking a wider view of company activities, by tracking all initiatives for the organization. This means in cooperation with the organization, not as the police force tracking and punishing transgressions. So the IT department can use their project management skills, their prioritization skills, their life cycle tracking competence and their benefits management skills to combine into a value-adding service of tracking and synthesizing the organization’s initiative for and with the organization. When I left my job as CIO of a large industrial concern, I was reporting to the Financial Director. He didn’t want me to go because he understood better than I did that because technology was pervasive throughout the organization, IT was in a position to see everything that went on in the business. And this was a position of power that he cherished, because he had forewarning of every important event and political choke-point in the organization. IT is at the nerve centre of most organizations. Some IT managers realize this and use it, and those people tend to become CEOs. Most CIOs didn’t get into business to do business, and so miss or avoid the opportunity of rising further in their organization. Multiple projects But this central position, this watchtower if you will, can serve the organization in numerous positive ways that still fall within the IT mandate. 69

What Business Really Wants From IT

They have project management, and prioritization skills and tools, and it is a short step to involve multiple projects. This is not a project management exercise, but rather a ‘cross-project’ management process. And because we are managing across projects the IT department needs information about the project intention, projected resource usage (people, skills, cash, business time), projected benefits, and progress. They track all these initiatives for and on behalf of the business, reporting the activity level of ‘project work’ within the organization. I define a project as anything that has a specially approved budget and that takes more than three months. The text book definition of a project usually goes something like this: ‘A project is a planned undertaking that has a start and an end, and has specific measurable objectives which must be met within acceptable time and budget constraints’. You choose which definition is useful to you. In most of my change management work there is a common theme running through the general resistance that people have to change, and this is what I call ‘initiative overload’: there are too many managers pushing their individual projects (each of which has approval from the executive). This constant change sets up interference patterns within the organization where, for example, the IT people are computerizing the staff skills tracking system at the same time that the HR department is changing their approach to training programmes and their definitions of skills. This seems to be a little far-fetched, but I’ve seen it too often. Even if all the activities are aligned, consider the poor foot soldier at the customer interface. They are being bombarded with instructions and new procedures, and new measures and technologies until they get severely stressed and respond by becoming cynical, surly and withdrawn. And these are the people you expect to be open, friendly and energetic when dealing with your customers. Some organizations shoot themselves in the foot while shooting for the stars. Because they don’t manage all their initiatives at a macro level, and IT is ideally suited to undertake this work. Programme management The central project office, or whatever you want to call it, can add real value once it has identified all initiatives currently underway or planned within an organization. It does so by ‘theming’ the initiatives. Looking at projects, identifying synergies and mutual goals, smoothing out overlaps and offering 70

Managing business results from an IT perspective

cumulative views of individual actions. Then they organize the initiatives into themes. It’s a well known fact that the human brain can deal with between 5 and 9 things at one time. So why consolidate all the organization’s initiatives into the same number of themes? We usually find a medium to large organization has between 75 and 250 initiatives on the go that have their own individual budgets and will take longer than three months to complete. We also find that 80 percent of these initiatives can be fitted into the requisite 5 to 9 themes. And sometimes the themes even align with the organization’s strategy, but don’t count on it. Which brings up the next step once you have your themes. These themes depict the organization’s emergent strategy – or the real strategy that is being enacted by the organization irrespective of what the published strategy says. Henry Mintzberg (1994) claims that this divergence between published strategy and emergent strategy occurs because of structural delays in the organizational systems. I take a simpler, but harsher view. I believe that real strategy differs from published strategy because of poor leadership, simple as that. Remember in Chapter 2, I mentioned that leadership involves the management of meaning and attention: if you decide to adopt a particular strategy (get close to the customer, expand your overseas operations, or whatever), what does that mean? For every person in the organization. I’ll tell you that it almost certainly means that you should stop a few maverick projects which have nothing to do with your goals. That’s called managing attention and it is difficult to do, because invariably some manager somewhere has an idea, has the budget and has the motivation. And here you are telling them that it doesn’t fit the company’s strategy. No-one said it would be easy. Portfolio tracking Finally the competence that an IT department can add to the organization involves tracking multiple initiatives across the organization. I’ll focus on just the cost and benefit element of the portfolio, but there are numerous other portfolio elements (e.g. resources, percent alignment, ROI, capital, etc.) that can be tracked. But stick to costs and benefits for a while. Tracking a portfolio requires layers of detail from projects and sub-projects up to departments or business functions, up to themes and finally the grand picture of costs versus benefits for the entire organization. If you do this just for the IT systems, 71

What Business Really Wants From IT

you will have a final picture of the value that IT adds to the business (Figure 5.5). Organizational view Thematic view

Figure 5.5 Different layers of detail of (say) costs of projects in a company

Functional view Project view

Notice that items don’t necessarily map upward, because you may have a project that benefits two or more departments. This doesn’t matter if you are clear that you are looking at different views of the same thing. Your cumulative cost/benefit graph looks similar to the single project graph, except that you add all the costs and benefits to each other. This creates a slightly stepped graph as projects are started, and systems are implemented.

Figure 5.6 Actual organization’s top ten system’s cost benefit graph

Cumulative cost/benefit

Figure 5.6 is based on an actual organization’s assessment of its top ten systems, and it took them three months to prepare because they had no information to start with.

s efit

en eb

tiv

ula

m Cu

Breakeven

Cumulative

’00

’01

’02

’03

’04

’05

’06

’07

costs

’08

Time

Notice that they project a breakeven for IT as a whole some time into the future (they derived these graphs in mid-2002). It is interesting that until that breakeven, more is being spent on IT than is being benefited from the technology. Notice also that the benefits more or less match the costs until 2005, and then a significant differential starts to open up. But will it really? Because surely in 72

Managing business results from an IT perspective

2005, there will be some new project initiated and the intensity of IT spend will rise again. But that’s fine because IT will map those costs and benefits onto the same graph and show the cumulative effect of IT effort over time. In Chapter 7 I’ll talk about using the cost/benefit graphs to a greater level of interpretation.

Step changing business None or all of these above activities are necessarily new and revolutionary, all the same most are not being done by IT departments. And let’s not lose sight of the fact that all of these activities are within the competence of the IT department, and don’t involve a coup d’état in the business, although many IT people are fond of telling me they do. The activities stay within the role and mandate of IT but are significantly more involved in the business activities and improving business results. They also bring a unique perspective, an IT perspective, which can add real value to business improvement activity. I must report, however, that many CEOs feel I haven’t gone far enough – that IT should impose solutions on the business, that IT should drive change in spite of business protests, and so on. I feel this is a little self-defeating. I know of a very large organization whose IT department approached everything through a process approach, mapping and tracking all business processes. Rather than IT staging a coup d’état, the business abdicated their role, and left IT holding all the business problems firmly in their laps. This is not healthy either. So the issue is one of balance. And true alignment can surely only occur if IT takes a cooperative role, rather than a confrontational one. Many IT people tell me that business won’t buy into their interfering with how they use their systems, how they measure their performance, how they manage their projects and how they improve their business in general. But most business people tell me that the door has always been open, and that its only IT’s self-defeating attitude that holds them back. I imagine the reality is somewhere in the middle. So work in cooperation with IT, go gently in measured strides, and yes IT can be aligned and add value if the will to do so is there.

73

6

Information leadership in the information age

The world bombards the average CEO with messages about technology, initially about how wonderful it is, but lately about how caution is needed when dealing with matters concerning IT. I used to pull my hair out when one of our business people would come into my office and indulge in a little of what I call ‘magazine management’. This person would sit down and tell me that they had read, or heard or been told on his last airplane flight by a friendly IT salesman sitting next to him, about a company that had cut all its paper from its operations, or turned all its sales force into overnight shipment managers, or cornered the market just by having a web presence, or had solved the world peace problem, pollution and overpopulation just by using Spigot’s latest software (the names of products and companies have been changed to protect business people from magazine management). The media is full of hype about how IT is revolutionizing business. It has to be, given the current cynicism about the value of IT, the sales/hype engine has been cranked up to maximum. To support my argument I quickly trawled a few websites and magazines and picked up these headlines: Spigot architects the ultimate office: Spigot’s ‘Bunghole’ netware platform could be the company’s best bet for developing office comms that will have it all. Customers were given a look at some of the fruits of the company’s $5 billion R&D bill today. (IT website) Connecting the unconnected: Cooperation among stakeholders could extend mobile communications networks to millions of customers in emerging markets – with rewards for all involved. (Consulting house customer magazine) Pain-Free CRM: By taking the time to integrate data for its online CRM system, a regional health plan has succeeded where other large insurers have stumbled. (IT website) 74

Information leadership in the information age

Today, enterprise to enterprise integration is not a choice, it’s mandatory. (IT advertiser) Thought for the day: Instant productivity gain – Instant messaging will revolutionize business communications. (Web magazine columnist)

And while these messages are not particularly profound or even loud, their delivery is constant and insidious. Business really, really wants someone they can trust who can tell them what is important to notice and what to ignore. But when the CIO joins the cacophony, delivering these same messages with all the enthusiasm of a newly converted trout fisherman, who is the executive of the business to believe?

The reluctant technologist Business wants measured and considered interpretation of IT developments. It wants opinions to be tempered with a keen judgement on how this fits with their organizational goals. They want a gatekeeper who shields them from all the hype, but who is not so closed to new ideas that they become ‘abominable no-men’. They want a reluctant technologist. Of course I’m generalizing here, because there are many types of organization, at many stages in their organizational path: some companies want to be at the forefront of technological advance and will take the associated risks knowingly. Others want to be fast followers, some are main-stream plodders when it comes to technology and still more are laggards, being dragged kicking and screaming into the twenty-first century. But all need their CIO to match their requirements with well considered views and opinions. They want someone who can tell them what all this hype means, can translate it into language that has significance for them, and can influence the organization to follow the path which best fits their risk/reward profile. Figure 6.1 was presented in Chapter 2 and it re-appears here. This diagram says it all. However, it is possible to summarize the IT leader’s role into three specific areas of activity (see Figure 6.2). There are two sides to the IT leadership role: the external side and the internal side. The external side has inputs: technologies, suppliers, business trends, economic trends, world events, and competitors. Then internally, the IT leader interprets and develops 75

What Business Really Wants From IT

Technological world Business and economic world

Organization’s strategy IT strategy Manage meaning

World domain

Organizational domain

Leader

Manage focus, manage attention Build frameworks, models, strategy, understanding New direction, cross new boundaries, challenge the status quo New products, new markets, new competences

Figure 6.1

The role of a leader

Figure 6.2 Three major activity areas of IT leaders

External leadership inputs

Internal leadership influence

External leadership outputs

strategies, manages meaning and attention, creates understanding and challenges the organization to cross boundaries and develop new products and markets. Finally the external outputs are of course customer and stockholder focused in new products, new markets, saleable competences and ultimately stockholder returns. Two other external output areas involve the community within which the organization operates and the natural environment which the organization may affect, for better or worse. Charles Handy (1994) talks of six sets of stakeholders in any organization, and you can see these stakeholders in the 76

Information leadership in the information age

above thinking: ● ● ● ● ● ●

financiers suppliers employees customers the environment the community.

Many companies seem to think they only have one stakeholder – their shareholders. Their vision statements invariably have the last few words as follows: … to meet our stockholder’s expectations.

This is either very clever or very narrow in outlook. It might be clever if the organization realizes that meeting stockholder expectations is the cherry on the top of the cake – and if the cherry is green then all is well, or if it is red then the business is in trouble. But that is all it is – a very high level signal indicating a company’s status at a single point in time. Sort of asking for the score of a critical football game and being told ‘we’re winning’. This might give you a warm feeling, but actually tells you very little about the state of play, the performance of the teams, the strengths and weaknesses of players etc. I suspect that executives invest far too much importance in this external mercurial traffic light. In the aftermath of the Enron scandal and a number of other stock price influencing disasters, I wonder whether this remains a valid position for the executive of an organization to take. Rather, they should be looking at the wider definition of stakeholders. Examining the above list of stakeholders you will see that of the six, five are external to the organization. So having an external focus is integral to the effective leadership from an IT perspective. And so should IT leaders be looking wider in their leadership endeavours.

Interpreting the external inputs The IT leader should look at the ‘input’ side of the external world by focusing on: ● ● ● ●

technologies suppliers business trends economic trends 77

What Business Really Wants From IT ● ●

world events competitors.

These factors are depicted in the leadership model (Figure 6.3). Technological world Business and economic world

Technologies Suppliers Business trends Economic trends World events Competitors

Organization’s strategy IT strategy Manage meaning

World domain

Organizational domain

Leader

Manage focus, manage attention Build frameworks, models, strategy, understanding New direction, cross new boundaries, challenge the status quo New products, new markets, new competences

Figure 6.3

Leadership’s inputs to outward focus

While all six elements of input to the IT leader are important and shouldn’t be ignored, they are probably applicable to every leader. You should expect the IT leader to bring their unique IT perspective to the table by focusing particularly on technologies and suppliers of those technologies. Focusing on technologies and suppliers Who’s keeping an eye on developing technologies, deciding whether they will be useful to – or dangerous for – the organization? The IT leader is expected to use their expertise and particular technological competence to provide this input to the 78

Information leadership in the information age

organization. Useful technologies are those that will advance the operations of the company, while dangerous technologies are those that threaten the organization, in much the same way that postal services are surely threatened by a technology like email. So the average business person should expect the IT leader to keep a table similar to Table 6.1. Table 6.1

IT leader’s technology scanning table

Organizational objectives

Technology that affects the objective

How the technology affects the objective

Opportunity, threat or neutral

Organization’s position on technology

Objective 1

Objective 2

Objective 3 Opportunity objectives

Notice that the first thing in this table concerns the organizational objectives. This fits with what I believe to be the second law of IT management: Everything IT does must link to an organizational objective.

It is a business expectation that IT remains relevant and aligned with business objectives. Therefore, if the IT department cannot link almost all their activities to organizational goals and objectives, then they cannot hope to be aligned. There is a place in the IT leader’s technology scanning table for what I call ‘opportunity objectives’ which do not fit with the current set of organizational objectives, but again the objectives in this block must still be organizational objectives. A word of caution: in my many years of seeing IT people’s perspectives on technologies, they often believe that just about any new technology will show up as an opportunity. This is where the judgement of the IT leader comes to the fore. This is where he or she gains the trust or otherwise of the organization. This is where the IT leader shows their business acumen and alignment: their opinions and recommendations must be measured, well structured and linked to the organization’s objectives and performance. 79

What Business Really Wants From IT

The second column in this table is generic indeed – it talks about ‘technology that affects the objective’. Notice first that we haven’t decided yet if it affects the objective positively or negatively. IT people and some business people often ask me: ‘What do you mean by “technology”? That’s such a broad category.’ My response is that this category is as broad or as narrow as you choose, and this choice will depend on the circumstances in which you make it. For example the IT leader may choose to look at networked communications as a ‘technology’, or drill down a bit further and look at email or business to business communications, or drill down even further and look at ‘Outlook’ versus ‘Netscape’ as they affect the organization’s objectives, or even further when you look at Release 4.5 versus 5.0, as it affects the organization. The choice is open, but the principle is the same: you want to see what effect the technology has on the organization’s goals and operations. The next column deals with how the technology affects, or has the potential to affect, the organization. For example, email has allowed millions of people to bypass the sending of Christmas cards over the festive season. And while the effect on the postal services is obvious, what is not immediately apparent is that this technology has severely undercut the charities that depended on Christmas card sales at the end of every year. An IT leader in a charity should have been scanning the technology and foreseen the effect that email would have on the charity’s income stream. The IT leader would have seen email as a threat, or possibly an opportunity, if he or she recommended that the charity start up an internet Christmas card service. The final column is important, and again comes back to the question which examines outcomes rather than outputs: ‘So what?’ What position will the organization take about the technology? Will we ignore it, watch it, actively use it, or place our entire future in its hands? This ‘position’ should obviously be arrived at in consultation with the business. This table of course isn’t the end of technology scanning. The IT leader must communicate with the business, must influence the direction that an organization takes as a result of his or her focus on the outside world. That is leadership. You may want to try your IT leader on what I call ‘the thirtysecond message’: when I was a CIO I used to ask my technology scanning expert to be prepared to give me a ‘thirty-second’ message on any particular technology. So I’d walk into his office and say to him: ‘Your thirty-second message on transponders (or whatever)’ please. He would sit for ten seconds, then say 80

Information leadership in the information age

something like: ‘Hasn’t crossed the chasm. Good speculative prospect, especially in our warehouses. But if it’s to be mainstream, wait 18 months.’ Now this sounds like code, and indeed it is, but given the pressures on my time and his, it worked very well. Let me translate. I knew that his thirty second messages were supported by deep research. That’s what I paid him for. I also knew that I could trust his thinking. The translation goes like this: I told him that I or someone in the business was thinking about using transponders somewhere – very often I would tell him where, if I knew (but my message also fitted into thirty seconds). The thirty second message depends on having a common language that takes a lot more than thirty seconds to develop. We would sit for hours discussing concepts and ideas until we had a shared meaning. In this particular thirty second message, when my colleague said, ‘Hasn’t crossed the chasm’, he was referring to a book by Geoffrey Moore (1991) entitled Crossing the Chasm. He was telling me that transponder technology was relatively immature in that it was a hot new technology that cannot be easily translated into business benefits. The technologists love it, but its practical application in the business world is limited. Also standards are a problem – there are no accepted standards at the moment that we can rely on into the future. Finally the product itself may eventually fail, not because it doesn’t work, but because alternative solutions may yet win the acceptance of business in general. All that in four words. But provided we had both read the book, understood its message and discussed its meaning and application in our organization, four words was all that was necessary. I won’t translate the rest of his thirty second message because, again, he was referring to models, ideas and shared concepts that would take quite some time to explain. Thirty second messages are possible between IT and the business, but as you can see, your relationship, communication, and shared understanding of various models and concepts must be quite advanced. The other aspect of looking outwards at the supply side is of course looking at the suppliers of the technologies. The IT leader needs to be aware of the quality of services and technologies available from various suppliers. Equally importantly he or she needs to be aware of the relative costs for the quality of service or product available. Finally, a good IT leader should take a view on the stability of the supplier organization. I have experienced a number of situations in which a supplier provided technologies to their customers shortly before becoming insolvent, or closing down operations in that particular country. This left 81

What Business Really Wants From IT

the customer in a risky situation as they found themselves with technologies that were inadequately supported. I have gone into some detail about technology scanning because that is expected to be the IT leader’s particular competence. However, he or she needs to have a handle on other ‘input’ areas to developing a leadership position. I have summarized these as follows: ●

●

●

●

●

●

82

Technologies ❍ track old and new technologies ❍ know where they are in their life cycle ❍ know which technologies are opportunities, threats or neutral to the organization Suppliers ❍ know the general product sets ❍ know the company – reputation, reliability, service, culture, etc. ❍ know the quality/risk trade-offs ❍ know the supplier’s financial standing and strategic progress Business trends ❍ understand changing trends in business governance, business stakeholders, boundaries, etc. ❍ understand business structures – mergers and acquisitions, joint ventures, etc. ❍ be aware of generic business strategies (product, customer or operations focus, people strategies, balanced scorecard, etc.) ❍ understand people trends and track changes to the psychological contract – understand knowledge management, telecommuting, paternalistic to peer management styles, complex adaptive systems, etc. Economic trends ❍ understand broad economic concepts ❍ understand the difference between the traditional trade-based economy and the ‘flow of money and information’ economy ❍ track the technological economy within the world economy ❍ understand globalization and its implications World events ❍ keep track of world events and take a position on the effect they will have on the economy, business, technology and your organization Competitors ❍ track the business progress of your organization’s competitors, their financial health and technological capabilities ❍ identify technologies that can be opportunities or threats to your competitors

Information leadership in the information age ❍

keep an eye on the competitors of your major technology suppliers.

The above list was easy to generate: it includes all the ‘should do’ activities for an IT leader. Of course it’s not easy to act on the list with equal vigour. So while you can show the list to your IT leader it would be best to prioritize your expectations, placing technologies, suppliers and competitors at the top of the list in that order.

Internal influence and leadership activities – translating inputs into meaning and action within the organization Matching strategies We have insisted that even the external scanning of inputs is tied back to the organization’s strategic intent and objectives. So now the time comes to formalize IT’s involvement with the strategy. Sadly, in most of my work I struggle to find direct links between the IT department’s strategy and the ‘host’ organization’s strategy. And I believe that this gap in fit between strategies underlies much of the friction that often exists between IT and the business. In my research into what CEOs want from their IT departments, I found only one instance in which the CEO wanted his IT department to merely provide the tools for them to do their business, without getting involved in business activities or providing aligned leadership from an IT perspective. Which was fine – everyone knew what was expected of them. But overwhelmingly, CEOs expect IT leaders to give input to their organization’s strategy. This differs from many traditional views of the strategic role of IT: in this traditional view, the IT department develops their strategy after the business has put its own strategy together. My view requires more interaction during the organization’s strategy development process. Typically your organization’s strategy should have the following elements: ●

●

Strategic imperative. The overriding driver of the organization’s strategy – ‘Over the next three years we want to consolidate our position in Europe.’ Business definitions. The role and purpose of specific businesses, the activities and offerings of specific businesses, and the boundaries of specific businesses – ‘These are the businesses we are in, the products we sell, the channels we use, etc.’ 83

What Business Really Wants From IT ●

●

●

Strategic themes. Key areas of the organization’s strategic endeavours – clearly articulated, concise topics which focus the organization’s staff on the key elements of the strategy – ‘We will consolidate our position in Europe by attacking the weaknesses of our competition in Europe, by creating a European brand position and by locating offices in key centres.’ Typically strategic themes last more than a year. Strategic initiatives. Specific actions that need to be taken to give effect to the strategic themes. These are typically once-off actions or projects which have specific, measurable objectives constrained by budgets and time parameters. Strategy management processes. Processes, policies and parameters governing the strategic process. Parameters on planning, timing and target setting.

If your organization has more than one strategic imperative, or if they have more than five to nine strategic themes, then you should expect there to be confusion and fatigue amongst your staff. The same holds true of the IT department. They should not have more than one strategic imperative and a few strategic themes. The time for detail is within the strategic initiatives, but these should be linked to the themes and imperative directly. There are two roles for the IT leader to play during the strategy formulation stage: he or she should be contributing to the development of the organization’s strategy, and should be constantly interpreting the strategy as it is formed for its IT meaning and impacts. We have covered the input that the IT leader brings to the organization’s strategy in the previous section. And the IT leader should be present during strategy formulation to assess its technological feasibility, provide a technological sounding board, and understand the magnitude and impacts that a specific strategy will have on the technologies of the company. As you can see, neither of these roles is possible if IT take a poststrategy interpretation role. Once the organization’s strategy has been developed, the IT leader needs to translate it into technological meaning. This is where the traditional approach is useful. However, we have seen many instances where IT can’t see a role for themselves in a particular strategic theme. That’s why they need to do this work in an untraditional way – they should load their thinking team with business people. For example, we were doing exactly this when we came to a particular company’s strategic theme of ‘acquisitions and mergers’. The IT people saw this as an executive activity and of very little importance to them, other than to 84

Information leadership in the information age

complain that once a company had been acquired it took them forever to synchronize the acquired company’s systems with their own. (This was a dairy company which tended to acquire a new dairy every year, but take 18 months to synchronize the systems.) When the business asked them what they could do that was proactive, they realized that they could prepare a systems integration ‘due diligence’ without knowing who the target company was. This ‘due diligence’ exercise caused them to realize that their systems were a significant part of the problem, and that they could improve system integration time significantly if they sanitized their own systems. When we did the benefits statement for this work (which all IT strategic initiatives and projects must have) we discovered that by being proactive in standardizing their systems and data, and by conducting systems due diligence exercises they could reduce synchronization time to less than six months, and also reduce significantly resistance to change on both sides. They later went on to create a dairy meta-data model which they were able to sell to non-competing dairies. So IT needs to be able to link every one of their activities to the organization’s strategy, and to examine their contribution to each strategic theme and initiative. This takes time, but reaps rewards for both the organization and IT. Attracting the attention of your people There is a statistic that may or may not be true but which strikes a note with most people that I talk to: in any large, mature company, 30 percent of their activities are totally pointless. Often these activities involve the collection of data and the writing of reports that are never used. But I believe that most unnecessary activity comes from the history of a company – either people are doing something because ‘that’s the way we’ve always done it’, or people are performing activities for processes that have evolved and changed over time, although the activity remains. Also people often duplicate work unnecessarily. I once worked with a small agricultural bank that gave loans to farmers. They captured the same information about their customers six times, in different ways. There was even one department that didn’t trust another department’s systems so they recaptured data into their system from printouts sent to them by the other department. The data was available in digital form, but they recaptured it anyway. Finally, the most difficult form of unnecessary activity to manage is that which doesn’t fit with the organization’s objectives. 85

What Business Really Wants From IT

This often takes the form of a pet project of some manager or engineer or sales person somewhere. This person toils away or has their department working away at some activity which may or may not prove useful at some future date. The role of the IT leader is to manage attention. This involves being aware of the activities of his or her people, as well as the activities of everyone in the organization if they use technologies. Some IT managers I have met have taken a police or ‘bigbrother’ stance towards unnecessary activity. I prefer taking a softer and less controlling way of leading, of allowing staff to decide whether some activities are important, and others not. David Whyte (2003), poet and corporate consultant, said: Our corporations want vitality, adaptability, creation and passion. None of these can be coerced. There is no lever to pull.

I believe the same is true for managing attention. There is no lever to pull. Or if you think there is, that lever will have many unintended effects elsewhere in the organization. So I take the approach of motivating people to use their judgement correctly. To do this, I believe in using aphorisms – short pithy instructive sentences. For instance, when my users were demanding workstations on every desk, in every corridor, at the water cooler and possibly in the rest rooms as well, I worked out that the real cost of each workstation was six times the hardware cost (which was the only figure the business had taken on board). So when managers started hearing that ‘every workstation costs this company $7000’ there was a universal move to cut back on the number of workstations requested. But the best pithy statements should be saved for the strategic imperative or strategic themes. I take time to work on words with my clients. (The Hanuoo peoples of New Guinea have a different name for 92 different types of rice, and the Inuit have 23 words for ‘snow’. And how many meanings does the word ‘customer’ have in your organization?) I believe that language and its use is probably the single most influential attentionmanagement tool that you have at your disposal. The problem is that we think in pictures and symbols, and we talk in words. The potential for confusion is enormous, because the same word means different things to just about everyone in your company. So when we develop strategies and strategic themes, we spend some time examining the words that we use to describe what we want from our people. 86

Information leadership in the information age

This comes back to IT’s documented poor communication ability. An IT leader should be self-aware enough to realize that he or she doesn’t communicate well enough, and should secure the services of a communications specialist to get their message across if needs be. Measurement is another way of managing attention. Measure the positive things that you need from any given IT initiative. Sometimes I wonder if a SWOT analysis (strengths, weaknesses, opportunities and threats) doesn’t do damage by programming negative words into the organization. I’ve not done this yet, but I would like to try to do a ‘SO’ analysis (strengths and opportunities) and see if the results differ from the traditional SWOT analyses. Or would we end up with a Pollyanna-ish (unrealistically optimistic) strategy. Measurement of IT is both a performance management exercise and an attention-management exercise. It defines areas which are deemed to be important enough to expend effort on an ongoing basis. But equally importantly correct measurement allows for continuous communication in these important areas. Frameworks and models – increasing understanding in the organization The role of IT leadership is also to create understanding in the business. While the business needs to understand technology and the role of IT within the organization, they don’t need to have technology rammed down their throats or to be forced to comprehend arcane technological concepts. Rather their route to understanding should be through models and frameworks which abstract IT concepts into generally understood business concepts. The three role model (3R model) of IT roles presented in this book is one such framework, and as such it provides leadership to both the business and IT. The leadership model presented in this chapter is another such example. So the IT leader needs to be capable of abstracting and translating from technology to business. I have seen a product marketed by LEGO (www.seriousplay.com) which is used in an activity they call ‘serious play’. It is used in strategy development, project management, idea generation and team-forming exercises. There is no reason why this form of representation cannot be used in describing IT concepts. I have also used the services of cartoonists to render complex ideas into accessible images to enhance business understanding. I use these methods especially when the ideas are complex or frankly boring. There’s nothing 87

What Business Really Wants From IT

like the irreverent and un-IT savvy mind of a cartoonist to find idiosyncrasies, loopholes and silliness in IT thinking. New boundaries, new challenges Ultimately the role of the leader is to drive the organization towards new frontiers, new ways of doing things, new ways of looking at familiar things and seeing something different. Gary Hamel and C.K. Prahalad (1994) suggest that true leaders are those who can ‘reframe’ the same picture that everyone sees in such a way that it presents opportunities and excitement in business. They believe that traditional thinking can be a millstone which holds progress back: When environment changes rapidly and radically, these (traditional) beliefs become a threat to survival.

So the challenge for the IT leader is not only to see things differently and help others to see things differently, but to also help people dismantle their traditional beliefs. And that for IT is difficult, because not only can people be fairly rigid in the way they approach work and the world, but they can also fear technologies. I do a fair amount of work on the management of change, and I always approach a change from the viewpoint that ‘people don’t fear change, they fear loss’. I doubt if anyone would fear being given a better car, or house or laptop, unless they were suspicious of your motives, but introduce a new system, and you affect people’s power base, knowledge base, performance criteria and possibly threaten their further employment within the organization. That generates enough fear to create all the resistance to change that you can handle. So in looking at challenging people to do new things I always start at the personal benefits – the WIIFM (what’s in it for me?) question. And I am often amazed when I am called in to help out with a difficult acceptance problem in an organization, that the sponsors of the change haven’t thought through, crystallized and communicated the benefits of the change – the ‘why we are doing this’ statement. ‘But, it’s obvious’, tends to be the response I get. However, it is not obvious to staff members who fear the loss of some privilege or the addition of workload. Therefore when trying to challenge people to adopt a new system or new behaviours, I always start at the benefits statement. And I am often surprised that the IT department doesn’t have, or has lost, the benefits statement. But that’s not the end of the 88

Information leadership in the information age

world, because I have helped a number of companies develop benefits statements long after the system was implemented. It’s actually easier to do so after the event, because you can see where the system is being used, and where there are gaps or shortfalls in expectations of what the system was meant to do. Either way you start with the benefits statement, look for personal benefits, translate them into messages that people understand and then communicate, communicate, communicate. If you can’t find personal benefits for a particular change, you will have to take the ‘for the good of the organization’ route which is far less powerful a way of inducing change. All this talk of managing change implies that there is some kind of formula for challenging people to cross boundaries and adopt new challenges. There isn’t. Because true leadership is an ongoing conversation with the organization, where the leader walks the talk and manages themselves in such a way that they build trust in their opinions and perspectives, and here lies the rub – leadership is as much about personality as it is about technique.

Out into the world with new products, markets or competencies The ultimate goal of all this leadership activity within the organization is to move out of the organization again with new products and new markets to meet customer requirements and ultimately to satisfy the stockholders of the business. I was once working with a CEO and his CIO, and we were examining how IT could provide leadership. One of the organization’s strategic themes was to expand into the emerging economies of the world. But one of the key problems was in getting their product, a bulk raw material, into the various emerging industrial centres. The CEO said: ‘The way I see it, is that we have the product, and we have the willing buyers. All that’s left are the logistics of getting the product across the water and into the specific emerging economy rail system, while tracking quantities, breaking of bulk shipments into smaller product parcels, customs and excise tariffs and so on. It’s an IT and logistics problem.’ He turned to his CIO and said: ‘True IT leadership would be where you approach a shipping company, form a joint-venture, develop robust systems to operate in emerging countries and get our product out there.’ His CIO nodded sagely, but back in his office, he turned to me and said: ‘He’s always coming up with these impossible requests. I need to lose it in the long grass for a while, 89

What Business Really Wants From IT

until he moves on to some new crackpot idea.’ And in so doing, the CIO demonstrated why he will never be on the board of the company. An IT leader would look at the idea and see an opportunity. It might not be as grand as the CEO’s brainwave, or even achievable in the format described, but IT leaders would at least devote a day or two to exploring the idea, because they know that leadership is about crossing boundaries, about breaking rules and about asking: why not? New products The failure of numerous dot.com companies has obstructed the view of a number of very successful products which are based on information technology. We are not necessarily talking about internet or networked products. One of the early IT-based products is the business school favourite of American Airlines and SABRE. Very briefly, American Airlines made their in-house flight and seat booking system, called SABRE, available to travel agents in 1975, effectively allowing the agents to do away with the clumsy paper-based books which took up space and time and frustrated agents and travellers alike. By 1985, more than 10 000 travel agency offices were using SABRE for travel reservations. In 1987 SABRE became available by personal computer. This is an example of IT leadership, turning technologies into products. There are numerous other examples: ●

●

W.L. Gore (makers of Gore-Tex) creating an international collaboration space for all employees, in which they can communicate with each other in real time to meet customer requirements, test products, plan product releases and shipping etc. So successful has the system been that their IT organization began calling itself the communication and collaboration team – an important change (Anthes, 1998). Millipore Corporation, a maker of purification products, uses their website to ask their customers what they want. Then they give it to them (whether it is a change to a product or a new way of ordering), thus entrenching their existing customer base and creating a new market from people who appreciate responsive suppliers (Catalano, 1998).

The common theme that runs through these and many others is an outward focus on what technologies are available and then a clear-headed assessment of how a particular technology can solve a business problem. What is also interesting is that most 90

Information leadership in the information age

commercially available ‘products’ started as internal systems in which the IT leader saw the opportunity to create external revenues. They usually then piloted the system with a few willing customers before making it generally available. However, there is a caveat with the simple goal of new products and markets. While the intention is to create a new product or market as a result of IT leadership, it is obvious from the leadership model that there are a multitude of activities from external scanning and internal influencing that add value from IT in the leadership domain. A pure focus on: ‘What technology can we sell?’ falls into the old technology trap that IT people easily mistake for real contribution. With a few exceptions, the new product or market should be entirely within the organization’s strategic imperative, serving the company’s customers within the company’s domain of operations. So be conservative when setting new product and market targets for the IT department. Rather, measure them on their contribution to the net leadership effort of the entire organization. An element of contribution in leadership that IT can add value is in the domain of competence. I use the word to include the skills, experience, abilities and even motivation that staff use in the completion of their duties. So for example, IT can improve the competence of the sales team by providing them with instant access to the catalogue, price lists and creditor information needed to make a sale. They can improve the competence of the call centre by providing better customer information: when they last called, what the problem was, solutions to similar problems etc. Can you see why the one CEO I was talking to balked at including ‘new competence’ in his definition of IT leadership? Before you know it, everything that IT does can be classified in this category – even brewing fresh coffee can be said to improve the competence of the office workers in some way. So the trick is always to come back to the company’s strategic imperatives, themes and objectives. And if ‘customer intimacy’ is one of the strategic themes, then surely improving the call centre’s knowledge of past customer transactions fits within that theme?

The hard stuff is easy, the soft stuff is hard It is easy to sit at a laptop and write about what leaders should and shouldn’t do. It is significantly more difficult to practise true leadership. The debate on whether leadership is an innate trait or a learned skill has been going on for years in academic and human resource circles. And will no doubt continue for 91

What Business Really Wants From IT

many years. My opinion is that with all bilateral debates, the answer lies in the middle. Leadership can be difficult or natural for individuals. But for the IT department to provide useful leadership in their organization, they need to be making sense of the outside technological world translating technological trends and business strategies into meaningful activities for IT and the organization, and creating something new – either products, markets or competence.

92

A matter of survival – proving the benefits of IT

7

This is probably the most important chapter in the book. However, I stay away from the pedantic approach to benefit derivation and proof. There are many textbooks available on the subject which you can refer to for more rigorous approaches to benefit calculation. I was, in fact, a contributing author of a book entitled: Maximizing IT Benefits, a Process Approach – so I’ve done the textbook angle. Rather, I want to focus on why IT needs to show how they benefit the business. I want to give you a simple and practical approach to actually defining the benefits of IT’s endeavours, and I want to convince you of the need for IT to be constantly tracking IT benefits and to communicate these benefits on an ongoing basis. As I have said before, I have often seen a business case and benefits statement developed for no more reason than to get a project approved at board level. This attitude is the start of why business often doesn’t trust IT – they don’t believe they are serious about delivering business outcomes – and they may be right. IT people have their systems development life cycle, but as we have discussed previously, their ‘life cycle’ doesn’t extend over the lifespan of any IT system (see Figure 7.1). 1

2

Need/ Inquiry/ requirement study

3

4

Design

Build

Syst ems development life cycle (SDLC)

Figure 7.1

5 Install

6

7

8

Optimize

Maintain, track & report

Decommission

Benefits release

Stable

Late life

The systems development life cycle and beyond

You can see that a system’s lifespan extends all the way from when a need is expressed or an opportunity is identified, to the decommissioning of a system. Even though the SDLC stops after step 6, this entire lifespan should also be the lifespan of a benefits statement. The benefits statement is developed during the needs/ 93

What Business Really Wants From IT

opportunities process, but should be used for every step in the process. However, the benefits statement has different uses and is applied in different contexts during each stage. I explain each stage in more detail, but here is a summary. Table 7.1

The life-span of benefits release

Stage Concept and development Need/opportunity

Systems study/enquiry

Design

Programming

Benefit release Install

Post-implementation

Optimization

Stable Maintenance

Late Late life

94

Benefits statement usage • At the same time that the business case is built, the benefits statement is developed • The benefits statement must show how the benefits will be achieved • Assess whether IT can achieve required benefits • Test benefits and functional requirements against possible solutions • Test whether the benefits can actually be achieved • There will be changes to the original concept. Make sure that the benefits are not lost • Beware scope creep and goal drift • This is where IT disappears for a few months – keep an eye on their activities because there is a net drain on cash, while benefits have not been reaped • The big cash and capital expenditure happens here • Set base lines for potential benefit areas. Track cost and benefit flows • The post-mortem examines how the project went • The benefits review examines the anticipated benefits and sets up a plan to realize those benefits • Aim to get the system stable, the problems minimized and the costs under strict control • Implement benefits release activities • Costs are stable. And the benefits stream is steady • All anticipated benefits should have been released into the benefits stream • Watch for the break-even point – celebrate • Costs rise, benefits sink, decision time: new release or scrap the system? • Remove benefits stream from routine calculations

A matter of survival – proving the benefits of IT

As you can see, there are four major stages in the life of a system: The first is when it is being conceptualized and built, the second when it is implemented, settled in and optimized and most importantly the benefits are chased, the third stable stage is when all potential benefits have been released, and the fourth stage is when the system starts to lose fit with the organization’s processes. It is clear to me that the Forrest Gumpism: ‘If you’re going to do something, try to have a reason for doing it’, holds true for IT systems. Especially IT systems, because their contribution to business performance is often obscure or dissipated across numerous other business processes or is intangible – not able to be ascertained. So the benefits statement should be a live document for the entire life of a project, in order to constantly track and affirm the value that IT adds to the organization.

What happens to costs and benefits over time? In Chapter 4 I showed you what happens to costs and benefits over time, but I oversimplified matters. Costs tend to do three things over time. Firstly they may follow the idealized cost curve – costs per month rise during the development stage, reducing during the optimization stage, remaining stable during the majority of the system lifespan, and finally rising in late life (Figure 7.2).

Figure 7.2 Standard costs per month over the lifespan of a system

Cost/month

Develop Optimize

Stability

Late life

Time

However, a common theme that I have seen in costs of systems over time is that not enough is spent during the development stage because: ● ●

●

The business needs something quickly. Poor project management has allowed the scope to creep (functions are added). Business people make IT decisions and cut budgets for ‘superfluous’ IT requirements – like test databases, quality assurance, change management, sophisticated reports etc. 95

What Business Really Wants From IT

There is goal creep – where the pain of change starts to be felt, and the business decides they don’t really need to make the change after all. After a number of these shifts in objectives, the system is delivered, and the business is dissatisfied with the amount it has spent because ‘nothing is any better’.

●

The culpability (if it must be found) probably lies both with the business and IT in equal parts. However the net effect is that costs do not start dropping soon after implementation, because now the IT department is playing catch-up on all the things it didn’t have a budget to include. Plus the business is usually swamping the IT people with requests for additional functions, reports and changes. Whatever the cause, the cost graph tends to look like Figure 7.3. Develop

Figure 7.3 Comparison of costs of an ideal versus actual system

Stability

Cost/month

Optimize

Late life

Actual Ideal Time

And while this may not appear to be too drastic, compare the areas of the curve differentials (Figure 7.4).

Figure 7.4 Differentials in early cost cutting versus late cost drain

Cost/month

Develop Stability

Optimize

1

Late life

2 Time

Area 1 is significantly less than area 2, which would imply that the system cost significantly more over its lifespan than was necessary had the business spent the necessary cash early on in the process. However, the implications run deeper than this. Because if the business spends the amount required by IT at the birth of a system, then IT had better be in a position to guarantee that the cost curve of the system will follow the ‘ideal’ path. And they had better measure and report spend against the system for the life of the system. Finally the ‘ideal’ curve requires that the business doesn’t make constant changes to the system. This may be 96

A matter of survival – proving the benefits of IT

do-able or not, depending on the speed of business change – dependent on the momentum of the business. Whichever way, it requires discipline from both IT and the business (mostly the business, because IT are usually happy to make no changes and have stable systems). To follow the lower curve, you need to develop, implement and optimize the system, then leave it alone! Whatever the cost curve looks like, knowing what it is in its entirety must surely improve business decision-making – and IT performance. So insist that IT tracks costs throughout the lifespan of the system. There is another cost curve that arises as a result of systems which have a very high human component. This is a standard operations management dictum, that where people are involved, it is sadly generally true that a period of high profile concentration on the system reduces the problems (and costs) associated with it, but as time continues and boredom and complacency creeps in, or people’s attention is diverted elsewhere, the problems mount and associated costs rise (Figure 7.5). Develop Cost/month

Figure 7.5 The cost curve for systems with a high people input

Optimize

Stability

Late life

Time

The question I raise is how will you take pre-emptive action if you don’t track the stability record of a system over the life of the system? It is possible, even desirable, to track benefits over time in the same manner (Figure 7.6).

Figure 7.6 Benefits per month over the lifespan of a system

Benefits/month

Develop Optimize

Stability

Late life

Time 97

What Business Really Wants From IT

However, when it comes to benefits, it is preferable to use a cumulative set of graphs (Figure 7.7). Develop Cumulative cost/benefit pm

Figure 7.7 The cumulative costs and benefits of a system over its lifespan

Optimize

Late life

Stability Benefit

Breakeven Costs

Time

The period of time that follows the breakeven is important, because costs must be kept in check, while the stream of benefits must be protected. This requires business and IT discipline in equal measure. But the real value of these lifespan graphs lies in the comparison between systems (Figure 7.8). 1

2

Good benefits over time

Figure 7.8

This system should be scrapped

3

Costs have gone up, but so have benefits

Comparison of cumulative systems benefits against costs

As can be seen from Case 1, the system has achieved its benefits early in its life, costs have been kept under control and the differential between benefits and costs adds a constant stream of revenue to the business’s coffers. Case 2, on the other hand, is a sadder story altogether. The system broke even very late, but costs have climbed and benefits have dropped away. Immediate management action is required. Interestingly I recently came across two identical systems which had been implemented in two different regions, and the curve for region one looked like Case 1, while the curve for region two didn’t even break even. This was an example of exactly the same system, but region one went out of their way to manage system costs and chase the business benefits. Region two, because of organizational politics, supported another system and refused to do anything to achieve the benefits, or indeed to keep costs down. 98

A matter of survival – proving the benefits of IT

Case 3 allows me to state one of my key principles again: never allow IT to talk costs unless they talk benefits. Because even though the costs have climbed, this particular IT department did their homework and revised the benefits statement to show the benefit of spending the additional money on the system. In reality, most systems are a hybrid of the above graphs, but each graph as well as the comparison between graphs allows for informed business decisions.

The benefits process One of the favourite refrains from many of my clients in IT is that benefits for technologies are difficult to derive or are intangible, are difficult to track and measure, and the net effort required exceeds the worth to the organization. My view is different: ● ●

●

all benefits can be derived and made tangible tracking, measuring and reporting benefits is a matter of survival for IT if the effort required exceeds the worth, reduce the effort using the 80:20 rule.

These opinions are simplistic, because I don’t want to get into a debate with the consultants and academics who have made it their mission to derive accurate, provable benefits no matter what. Their contribution to organizations is valuable and valid, and if your organization can afford their services, then please use them. However, I have chosen to take a deliberate business stance, which optimistically and even naively assumes that we want a good idea of what value IT is adding for what cost, with the minimum effort from both sides. The process requires a number of steps (Figure 7.9). Identify

Quantify

• Delphi 1 • Describe • Filter outcome • Brainstorm • Delphi 2 benefits • Action list • Filter • Categorize • Describe each

Figure 7.9

Match

Base-line

Monitor

• Current • Point by • Costs performance • Benefits point • Actions • Tracking • How mechanisms • Scope creep • Feedback • Goal drift cycles

Actions • Benefit release • Include in feedback cycle

Report • Lifespan • Feedback loops • Actions

Steps in deriving, tracking and reporting benefits

Already this looks complicated, but it isn’t. Rather, see it as a mindset for you and IT to have about benefits. 99

What Business Really Wants From IT

Identifying and quantifying benefits Remember there is a reason we want to identify and quantify benefits in the first place – no, not just to put a value on the project so you can get it past the approval committee. An aligned IT department sees benefits as stage one in any of their processes, they want these benefits to result in improved business performance, and they want to prove that these benefits have been achieved. They want outcomes. So they begin by focusing on the outcome. Ask the question: ‘Why do we want to do this in the first place?’ Ask what the outcome picture will look like – I often ask people to draw pictures rather than use words. Everyone involved in the process must have a clear idea of why the organization is doing this. Once you have a clear picture of the outcome, you can begin identifying benefits by brainstorming what benefits can be derived. I use a particular brainstorming process which requires all participants to generate as many ideas as possible, without judgement. To do this I tend to use those sticky note pads with one idea per note. Then I allow people to filter these ideas, firstly by placing each note somewhere on a whiteboard or flip-chart paper. They then gather in groups and filter the ideas based on practicality and importance to organizational strategic themes, rearranging the notes into clumps. Finally we assign categories to each clump of notes. From this exercise you will have some obvious and large benefits, and some dubious benefits. Notice I don’t ask you to categorize the benefits into the usual textbook categories of ‘tangible and intangible’ benefits. I believe that if a benefit is large or important enough, it can be made tangible and measurable. The issue of direct vs. indirect benefits is an important one, but we’ll come back to it when we talk about benefits measurement. The last thing to do is to describe the benefit using a table similar to Table 7.2. Table 7.2

Simple benefits description

Outcome description: Benefit

100

Which strategic theme?

Value & direct/ indirect

Measurement

Benefit realization action

A matter of survival – proving the benefits of IT

In describing the benefit, try to concentrate on the outcome space. To illustrate the benefit derivation, I have tried to choose a highly intangible automation project: let us suppose that you want to put the organization’s leave forms online. The outcome would be that staff query how much leave they have available, and apply for leave on the company’s intranet. An email is sent to their supervisor (this is one of those companies that still thinks its people can’t decide whether the company can afford to have them on leave or not), the supervisor applies his or her digital signature, a copy is sent back to the employee, and the leave database is updated automatically. In this outcome, we need to brainstorm some benefits. So we do so, do some filtering and now are ready to describe the benefits. Here’s a first cut: ● ● ● ● ●

save on an administrator’s time and effort cut down on supervisor’s leave approval time save on employee’s time in applying for leave automated updating of leave database improved employee morale.

As you can see, probably only the first benefit is tangible – as for the rest – so the online forms will save some time and people will be happier, big deal! Let’s work on the first and easiest benefit.1 Assume the organization has 800 people who take leave on average twice per year with one sick-leave application as well. So that’s three leave applications per employee per year – 2400 applications. Now assume that it takes the employee ten minutes to apply, but once online will take three minutes. And the supervisor takes three minutes to process an application, but no-one is sure if the automated system will cut that time down. Then assume it takes an admin clerk five minutes to process each application, with another ten minutes per employee per year for queries. Assume we’ll cut the query time for the admin clerk down to two minutes per employee on average, and because the system is automated we’ll be cutting out the five minutes processing time altogether. So the reworked benefits look like this: ●

Save on an administrator’s time: 200 hours per annum admin time, 106 hours query time

1

Note that this will take a lot longer to read than to apply, but once you have the basic principles you can take the thinking into most discussions with IT. 101

What Business Really Wants From IT ●

●

●

●

Cut down on supervisors’ leave approval time: currently 40 hours p.a. – but no-one’s sure of the reduction the system will bring Save on employees’ time: 280 hours total or 21 minutes per employee per annum Automated updating of leave database: improved data, datamining opportunity Improved employee morale: better productivity?

As you can see we’ve described a total of three hundred admin hours time as a definite benefit, and all the rest are a little hazy. First thing’s first though. Let’s work as if we intend achieving all these ‘benefits’. So we need to ask the ‘so what?’ questions. So what if an administrator saves 300 hours of time per year? That’s two months or so, but we can’t retrench the clerk for two months. Can we get him to take on more work, if so precisely what work? (This is important – IT needs to have the intent of achieving the benefits – so an action plan must be forthcoming.) So let us assume that this organization has decided to improve its customer intimacy as one of its strategic goals. So we can tie this benefit to the customer intimacy goal only if we give that clerk the job of (say) tracking employee/customer contact time. Can you see how having the intention of achieving a benefit drives a new set of actions? Now of course we will have to add some revenue figures to the benefit. Most people say that the clerk’s salary is $3000 per month, and he will save two months’ work so there is a benefit of $6000 in a year. But what about the effect of the clerk checking on employee/customer contact time? There will be benefits there. Assume that we use the Delphi technique described below to generate a potential benefit of $2000 per month. Coming now to benefit number two: saving on supervisor’s time. Some people believe that the system will save on time, others believe not. Because IT has taken on board the intention of attaining the benefits, someone actually checked how long ten supervisors took to process the leave forms manually, and then did a trial run of opening a dummy email leave request, studying the contents and attaching a digital signature, and found that no time was saved at all. So the benefit was dropped from the list. The third benefit followed the same route as benefit one, in that the question was asked: ‘So what if our employees save 21 minutes per year in applying for leave?’ And the resultant answer disappointed the proposer of the system, because it was generally 102

A matter of survival – proving the benefits of IT

decided that the only material benefit would be improved employee morale. And that isn’t much of a benefit at all, or if it is, the benefit is entirely intangible. Or is it? At this stage in the proceedings it is decided that testing this ‘improve employee morale’ benefit is important because it fits with another one of the company’s strategic themes which is: ‘create a can-do culture’. So now some effort will be expended on making the intangible benefits tangible. Firstly a group of ten or so people, who are in a position to have an opinion on employee morale, meet for an hour or so. In this meeting, you explain the issue and ask the question: ‘Will having our leave forms on-line improve employee morale?’ Some people are of the opinion that this will add to the other employee morale improvements by 10 percent, others feel that any morale improvement will only be temporary, while one lonely soul sticks determinedly to his opinion that there will be no morale improvement at all. All of these opinions are fine, because we will use a variation of the Delphi technique to get some kind of benefit figures from people. The general discussion has agreed that the online leave forms will contribute to morale improvement by between 0 percent and 5 percent. Now we need to ask the ‘so what?’ question. You ask the attendees to estimate what the net revenue effect will be if morale improves by 0 percent, 1 percent etc, and you record the results as in Table 7.3. Table 7.3

First round Delphi technique for estimating benefits

Respondent

1 2 3 4 5 6 7 8 9 10 Average Average with extremes removed

Percent morale improved 0

1

2

3

4

5

0 0 0 0 0 0 0 0 ⫺10 000 0

0 20 000 0 0 10 000 0 100 000 0 0 10 000

0 30 000 10 000 5 000 10 000 0 200 000 0 0 10 000

50 000 40 000 10 000 5 000 30 000 0 300 000 0 15 000 10 000

50 000 50 000 10 000 5 000 30 000 0 400 000 0 20 000 10 000

100 000 60 000 20 000 5 000 50 000 10 000 500 000 0 25 000 30 000

⫺1 000 0

14 000 5 000

26 500 8 125

46 000 20 000

57 500 21 875

79 100 36 375

103

What Business Really Wants From IT

As you can see, ‘Respondent 8’ stuck to his guns in not seeing any benefit from improved morale, and ‘Respondent 7’ is a really optimistic person. The first average simply adds all the benefits and divides by the number of respondents. The second calculated average is the average of eight respondents, first having removed the topmost vote and the lowermost vote from each column. This creates a lesser average, and it’s up to you to decide whether removing the extremes is really discounting the unrealistic opinions or whether each respondent can make a good case for their opinion. Usually if they are unable to support their argument, I tend to remove the extremes. But notice something important here: no-one said that a 5 percent morale improvement will increase revenues by millions and millions, and almost everyone agreed that by the time we get into the 3 percent and up range, there will be some positive revenue effect for the company. So the opinions of the people we’ve talked to have allowed us to quantify the order of magnitude of the benefit, and this in itself is a major break with IT throwing their hands up in the air and saying: ‘it’s intangible’. The table is unrealistically simple, and certainly not statistically rigorous, but what matter? We have established that if the online leave system can improve morale by 3 percent or more, there is likely to be upwards of $20 000 revenue benefit for the company. Importantly also we have discounted unrealistic projections, both positive and negative. The Delphi technique depends on one principle: if you ask people who are in a position to have an opinion about a certain topic, their averaged responses tend to be more than 80 percent accurate. And if you circulate the first round of responses to the original respondents, their opinions are likely to become more refined and hence more accurate. But the important thing here comes back to the intention: if you intend achieving and proving these benefits, then you had better develop a very clear idea on how or what will release the benefits, what actions need to be put in place and what measures will track the benefit. So now our team has come to a collective opinion that if we implement an online leave form, and can use this to improve staff morale by more than 3 percent, then it is likely that revenues will increase by between $20 000 and $46 000 with an upside for every additional percentage in morale increase. So the question now becomes: ‘What must be done to achieve a morale improvement as a result of having online leave forms?’ 104

A matter of survival – proving the benefits of IT

In this particular case, the team might come up with the following actions: ● ●

●

●

Measure the current morale – establish a base line Ask a selection of people what benefit they might get from online leave forms Communicate the online leave form intention, and the benefits to individuals Measure the morale three months after the system goes live.

All of these actions relate only to the benefit associated with improving morale. The same process can be undertaken for every benefit identified should they be deemed to be important. Remember that the intention is important, because that intention drives actions, and the actions drive business improvements. There’s one other item on the original table on benefits, and that is the question on whether the benefit offers direct or indirect value. Direct value can be attributed directly to actions – for example if the administrative staff member actually stops working on leave forms for two months of the year, this is a direct benefit. It is easily measured, and importantly, if the action has been successfully implemented, you can count the benefit as having been achieved. So let’s come back to the original table of benefits (Table 7.4). As you can see the net benefit is $6000 per month, of which $3000 is direct (can be attributed to direct actions and processes), and $3000 is indirect, based on improved morale. In this example, let’s say the on-line leave forms facility is a module of an existing personnel package, and the cost of acquiring the module is $50 000. The conversion of the module to the organization’s processes will take another $15 000, and ongoing monthly maintenance is anticipated to be $1660 per month. So the final presentation to the sponsors of the system will look something like Figure 7.10. There are some things to notice here. Firstly, as expected, the benefits only start after the module has been customized. During the optimize stage, two things happen – the costs (and problems) are stabilized, and the benefits are actively sought, implementing the actions in the benefits statement. The next major action point is at the breakeven point, and it is IT’s responsibility to ensure that the costs and benefits are tracked and reported, and the breakeven is actually achieved. (Perhaps a small celebration is 105

What Business Really Wants From IT

in order.) After the breakeven point, standard tracking should allow IT to report a benefit to cost differential of about $10 000 per three month period or $40 000 per annum. It is also important to note that IT must track actual benefits as far as possible, especially direct benefits, but it is possible to claim indirect benefits if the actions that were proposed to achieve those benefits have been successfully implemented. Table 7.4

Sample benefits table

Outcome description: Staff query how much leave they have available, and apply for leave on the company’s intranet. An email is sent to their supervisor who applies his or her digital signature, a copy is sent back to the employee, and the leave database is updated automatically Benefit

Which strategic theme?

Value & direct/ indirect per month

Measure

Benefit realization action

Administrator’s time

Customer intimacy

$2500 direct

2 months p.a. freed up

Cut two months Add customer/ employee check

Supervisor’s time

Cost control

Not material

Employee’s time

Can-do culture

Not material

Automated updating

Quality

$500 direct

From 5 to 2 QA problems

Data mining

$1000 indirect

Establish current QA baseline Track QA problems Report Mine leave data for staff trends

Improved morale

Can-do culture

$2000 indirect

3 percent improve

Measure morale Track morale Establish personal benefits Communicate benefits

Customize

106

Cumulative costs/ benefits per month

Figure 7.10 Projected costs versus benefits of a hypothetical on-line leave form system

Optimize

Stability

Cost fit

Bene

3

6

9

12

15 18 21 24 Time (months)

27

30

33

36

A matter of survival – proving the benefits of IT

The big trick comes when cost and benefits measures are added for all the major systems implemented by IT. Then the cumulative value as well as the future value of IT to the company will be tracked, in business improvement terms. I must stress again that I have been extremely simplistic in my approach here, because the techniques are less important than the principles: ● ● ●

●

●

●

●

IT must never talk about costs unless they talk benefits IT must track costs and benefits IT must track costs and benefits over the lifespan of every system There is no such thing as an intangible benefit. The amount of effort in verifying assumptions and deriving the benefit dictates how ‘intangible’ you choose it to be All benefits should match to an organizational goal or strategic theme The activity of deriving benefits is valuable for the numbers and measures, but is more valuable for the actions needed to realize the benefits IT should take responsibility for benefits realization.

Be aware that these benefits are not guaranteed, and sometimes IT people should develop a table which shows that the benefits differ based on which of these are actually achieved (Table 7.5). This table is really fairly simple again, merely demonstrating that benefits are variable. Table 7.5

Table showing variable benefits, dependent on the actions taken to achieve each

Benefits in $ 000 Option

1 2 3 4 5 6 7 8 9 10

Cut admin time

Auto update

Percent morale improvement

Admin

Custmr

Quality

Data

0

1

2

3

4

5

6 6 6 6 6 6 6 6 6 6

24 24 24 24 24 24 24 24 24

6 6 6 6 6 6 6 6

12 12 12 12 12 12 12

0 0 0 0 0 0

0 0 0 0 5

0 0 0 8

0 0 20

0 22

36

Total

84 70 68 56 53 48 48 36 30 6 107

What Business Really Wants From IT

A quick look at project risks and benefit types A more sophisticated approach requires that you look at risks as well, and offset these against benefits (Pierce, 2003). Risk types: ●

● ●

●

●

●

Investment risk: the cost of purchasing and implementing a system offset against the potential for the system in achieving its benefits. Demand risks: the system may or may not be used. Project risk: associated with the chances that the project is managed well and delivers according to the requirements. (Of all software projects incorporating over 64 000 lines of code, 25 percent failed to deliver anything; 60 percent were over budget and behind schedule, and only 1 percent met requirements on time and on budget (Beam, 1994).) Opportunity risk: the risk associated with not doing something – usually associated with the need to upgrade a system, or implement a security package etc. Operating base risk: the risk of compromising the organization’s operational base, irrespective of the nature of the business. Most risks here are associated with what IT calls their infrastructure systems – the network, operating systems, desktop systems etc. Less obvious risks include marketing risks (will the company have a marketing disaster as a result of systems malfunction?), capital risk (some companies have had to re-capitalize as a result of IT spend), liability risk (does the system put the company at risk of claims against it etc.), financial risk (often associated with interest rates, exchange rates, etc.).

There are a number of computer packages that allow you to assess the risks involved and perform thousands of probability iterations to quantify the risks against the benefits. When I think about benefits types, I like to think of compression: ●

●

108

Compression of time allows us to do things faster, as in most classical automation of tasks Dimensions can be compressed, and continue to do so at an alarming rate, so that one is now able to use a palm computer where once a large workstation was needed. Mobile phones have also followed the dimension compression route

A matter of survival – proving the benefits of IT ●

●

●

●

One of the main benefits of computer communications is that we can compress distance. So staff can converse with each other, access data, cross time zones, etc. without leaving their desks Costs can be compressed, in that computing can allow us to do our existing operations cheaper, or indeed the computer technology itself is cheaper, allowing us to buy more powerful computers at reduced costs Mistakes can be compressed or reduced to more manageable numbers, because automated systems tend to cut human error from daily mundane tasks Finally it is possible to compress data into a database, store it, organize and filter the data and use it to gain new insights into the way the organizational environment works.

There are many secondary benefits that derive from the above list – customer satisfaction may rise because we can do things faster, at a great distance with few errors. Customer intimacy may improve because our data allows us to target specific customers with specific products. And so on. I have taken some time to deal with the identification and quantification of benefits, because in my experience this is a weak area for IT people. Matching benefits to technologies The usual IT process involves seeing an opportunity or meeting a need, defining the opportunity, developing a business case (including the benefit statement) and getting a proposal passed by the executive of the organization. Essentially: ‘We know what we want, what it’ll do for us, and we have the money to get it!’ So now begins the process of getting the right technology for the business. This usually starts with a Request for information, or Request for proposal, in which your organization states the problem, identifies in rough terms what technologies they need, and asks IT suppliers to quote on their solution. There’s some tricks of the trade that happen here. Firstly you get organizations who ask for proposals on how suppliers will solve their particular problem, then use these ideas without using the supplier. Sneaky, but it happens. Some suppliers now require their customers to pay for a ‘proof of concept’ stage, which if proven, guarantees the full implementation of the system. I also know that there are many suppliers who will say they can deliver anything you ask for, without being sure if they 109

What Business Really Wants From IT

can: ‘get the work now, worry about delivery later’, is a maxim they tend to use. So the ‘improve business results’ (IBR) role requires a wide-awake assessment of technologies and the suppliers of these technologies. But more importantly, the IBR role takes the benefits that were derived and ensures that the proposed solution can deliver on them. Be aware that a technologist tends to look at a technology and say: ‘Can this solution meet the functions I require?’ while the business focused person looks at the same technology and says: ‘Will this work in my business, and will it achieve the benefits that we require?’ The emphasis is different, one focusing on the functionality and the other focusing on the business fit, and business performance improvement. Don’t let the IT people say, ‘Yeah, yeah we do look at the benefits’ – they are simply too busy with the technologies and project to look to the business improvements and benefits. I recently came across a project which had cost $20 million so far. The vision was farsighted and revolutionary, the technology was the latest web-enabled multimedia, the supplier was committed to delivering on the specification, and the system just did not work in the organization. The technology worked, but there was no way that the organization could use it in their day-to-day activities. In one instance the idea was to have a totally paperless system by scanning the many government documents and forms that came into the department. Well and good – the technology can handle that. But most of the documents were hand-written, and there was a small loss of resolution in the scanning, and it took clerks minutes longer to read a document than before. Add to this the fact that the clerks generally accessed six of these documents at the same time, cross referring to all of them, and you have a system that can’t work. The system would have to have much better resolution (and would thus take longer to load), and there would need to be six screens open at the same time on the same desk. After spending $20 million, and frustrating and angering many of the staff, the project was scrapped. So it is the ‘improve business results’ role that looks at how the technology will work in the organization, given their culture, working conditions, politics, skills levels, strategic objectives etc. You look at the benefits and the outcome description and track exactly how each benefit will be achieved given the technology. And then you ensure that the benefits are achieved. There is a thing in projects called scope creep and goal drift. Most IT people know about scope creep – this occurs when the business 110

A matter of survival – proving the benefits of IT

does not define their requirements well enough and needs to make constant additions to what they need. So the project gets longer and longer, and costs more and more. Goal drift, on the other hand, is not a well known term (mostly because I have just invented it). I have not invented the syndrome, however, and have seen it operating in a number of organizations. Goal drift occurs (not just in IT), where the implications of the vision or objectives become clear for the organization, and the sponsor of the change decides that this will be too disruptive and painful for the organization, so they allow that objective to be downscaled. Again and again, until you reach the end of a project, and nothing has changed at all, because the goal has drifted back to where you are rather than where you want to be. Goal creep occurs when the real cost or the organizational cost is deemed to be too great. It is the IBR role to ensure that scope creep and goal drift are recognized for what they are, and the implications of each phenomenon are recognized. You don’t have to stop either necessarily because then you would become extremely rigid and unbending as an organization, but the IBR manager needs to raise the flag whenever he or she sees these conditions, to examine the implications and communicate them. Establishing a base-line and monitoring benefits If IT has the intention of achieving the stated benefits in any project, it will be serious about identifying the measures of these benefits. And step by step they will track these measures. To start they identify what can be used as a benefit measure. For example, using the previous example they may want to track employee morale. Any human resources person will tell you that there are many dimensions of morale, and the IT people will need to specify their particular needs. Then you will establish the baseline of the benefit against which future measures will be compared. Often this is done as part of identifying and quantifying the benefit for the benefits statement. So it may be a simple matter of ensuring that the same measure of the same dimension is taken again. Often employee morale measures are tracked using some form of ongoing automated survey software. It is important to stress that the tracking mechanisms are formalized, so that they can form a stable base of measurement into the future. Also the question of feedback cycles needs to be 111

What Business Really Wants From IT

considered. I once had a staff member who watched a system die over a period of weeks, but he believed that he could fix the problem, so he didn’t report the problem until it was too late. We lost a month’s worth of data. Lost, not temporarily misplaced, because this was a backup system that this employee was dealing with. Had I established a regular feedback routine, defined thresholds after which issues should be escalated, and generally believed that things could go wrong we might have avoided the problem. While the above example is one of problem tracking, benefits tracking is as important to have the mechanisms in place with automated reporting as far as possible. So once you are tracking benefits, it becomes important to do four things: ● ●

● ●

automate the tracking of benefits agglomerate benefits into specific systems/applications/infrastructures report the benefits that IT adds to the business act on any areas in which benefits start to shrink.

This seems like a lot of work, and it is during the set-up phase, but once the initial processes have been put in place, this becomes standard practice for the IT department. More importantly, it also becomes standard practice for the business to expect a constant stream of benefits from IT, to be able to identify individual benefits and to be able to make business decisions about its IT and its systems. Benefit release Ask most IT people, and they’ll tell you that the business uses only 20 percent of the available functionality in its computer systems. (What they don’t tell you is that they themselves often use only 20 percent of the available functionality of the systems that they use to manage the company’s information technologies.) While this 20 percent looks like a vastly unacceptable amount, remember that much of the functionality built into any system is of no use to the current organization in any case. Take this current Word package that I am using. Firstly I don’t use any of the web functionality that they build into the programme. I prefer not to use any of the ‘Wizards’ that they have on offer. Because my publisher wants me to submit each chapter as a different file, I’m not using the Word programme’s sophisticated ‘long document’ management tools, although I may do so once I have finished the book, to generate the contents pages and the 112

A matter of survival – proving the benefits of IT

index. I do all my drawings in another package, so I don’t use any of the Word package’s drawing facility. And so on. One final thing: I find their thesaurus totally inadequate for my needs, so use a free package that I downloaded. But in order to write this last paragraph, I used the Word package’s help facility and have just discovered that there is a ‘word-count’ toolbar that I have never used, but will use from now on. So you can see from this simple example that a number of functions are useless to your organization, but they may be used extensively by other organizations. Other functions are not used by your organization as a matter of choice, either because they don’t work that way, or they use other tools and software. Some functions are also used only on occasion. But we must not lose sight of two important areas in which IT can help the business improve its operations: using functions which help the organization at their best performance levels, and using functions which are available but are ‘undiscovered’. I have a picture in my mind of the functionality available in systems, some of which represents fertile ground for the IT department to add to business performance (Figure 7.11). Total available functionality of the system

Usable functionality

Undiscovered functions Intended for use, but never implemented

Figure 7.11 Schematic representation of system functionality

Used functionality

So when people say you only use 20 percent of the system they are right, and wrong, at the same time. You can probably never use more than 50 percent or 60 percent anyway. The emphasis here is to focus on the functionality that was intended for use but never implemented, because you will find a direct link here between these functions and the benefits promised in the benefits statement. There is also benefit to be derived from looking at functions which may be available to the business, but which were not particularly specified in the requirements. 113

What Business Really Wants From IT

Keeping it simple I have discussed at length the identification and quantification of benefits, which includes a description of the benefit and an action plan to actually derive the benefit. The role of the IT department in this stage of the process is manifest. If the IT department wishes to add value, then they must also become involved in carrying out the action plan, managing progress towards objectives and doing their portion required in each action. They must also track progress towards achieving the benefits and report on that progress. They must also report on the benefits ‘stream’. Again I have a picture in my mind of a literal stream of benefits contrasted against a stream of costs (Figure 7.12). Promised benefits

Benefit release actions

Cost sinks

Figure 7.12

Literal benefits stream

Is this too simple a view of the world? Perhaps naïve? Interestingly, this simple view of costs versus benefits has been used in numerous presentations to business and IT people alike, because there are a few issues that need resolution when talking to IT: ●

●

●

●

114

There is a big difference between promised benefits and actual benefits A benefits release programme is needed to convert promised benefits into actual benefits How do you know the actual benefits exist if you don’t measure inputs to the benefits stream? What are we doing to minimize the cost sinks?

A matter of survival – proving the benefits of IT ● ●

Is the net flow of benefits greater than the net flow of costs? Is the benefits stream getting ‘wider’ as time goes on?

This discussion assumes that IT must pay for itself, in that the net flow of benefits is greater than the cost of providing the IT. In many businesses this is the case, but in some, strategic decisions have allowed for the net flow of costs to exceed benefits. In these cases, however, I would still want to know what the stream looked like.

115

8

Getting, keeping and using the cash – budgeting for IT

If my simple view of benefits in the previous chapter was a little hard to accept, you’ll find my ideas about budgeting for IT to be even more troublesome. I was doing some work for a large engineering company whose IT budget constituted some 2.5 percent of their annual turnover. Their CEO had given all sections an instruction that the annual budget was to be presented on a single sheet of paper. The IT department struggled to present their budget in so simple a way, and eventually presented their budget as a spreadsheet printed on A3 sized paper with a font size of ‘8’. From top to bottom, the rows listed all the IT activities that were being budgeted for, and across the top the columns listed all the approved account codes for budget expenditure, and against which IT activities would spend the proposed money. In the bottom-right corner, as with most spreadsheets, was a final total. The CEO took a short look at this wealth of data, looked at the bottom-right figure, and put a pen stroke through the lot, telling his CIO to cut it all by 20 percent. When I met with the CEO he was distressed that his IT people could not meet his simple requirements, that they could not simplify their budget and that they of all people seemed unable to present him with information he could use to make business decisions. I’ll come back to this case, and how we were able to simplify matters for all parties concerned. But firstly we need to do a little revision.

Back to the momentum of the business Remember the ‘momentum’ of the business? In it we proposed that a business has a momentum – its mass (size, geographical 116

Getting, keeping and using the cash – budgeting for IT

spread, etc.) times its velocity: a product of direction (strategic intent, vision, culture, etc.) and speed (how fast business happens).

Budget

This momentum takes on a new meaning when we discuss budgets. If we calculate the budget based on maintaining the business momentum, and we plot this figure on a graph, we will result in a diagram of the business’s momentum line (Figure 8.1).

Figure 8.1 The momentum line

The momentum line – the amount you need to spend to maintain business momentum exactly as it is

Time

Obviously over time, we are hoping that the business’s momentum will increase, and therefore the amount you need to budget to maintain the momentum will probably increase as well. Now if we look at the IT budget through the momentum line, the question we will ask ourselves is: ‘How much do we need to budget in order to maintain the business’s momentum?’ If we then take the three roles of IT: ● ● ●

maintain business momentum through IT improve business results information leadership

and map these roles, and the budgets for each of these roles onto the momentum line, the resultant graph will look like Figure 8.2. There’s nothing particularly new or revolutionary about breaking IT budgets, and the corresponding tracking of IT expenditure, into three groups. Many IT consultancies and IT research houses recommend this approach. The three categories tend to be broken into: expenditure on existing operations; expenditure on new projects; and spending IT dollars on more risky cuttingedge exploratory type technologies. What makes a difference about Figure 8.2 is both the linkage of the expenditures to the momentum line, and the linkage of the 117

What Business Really Wants From IT

Information leadership

Budget

Improve business results

Information leadership

Maintain business momentum

Figure 8.2 Budgeting for the roles of IT and the momentum line

Momentum line

Time

entire budgeting process to three primary roles of IT in the organization. You’ll notice also that each budget ‘floats’ at different levels. The MBM budget is obviously largely below the momentum line. This depicts IT expenditures which are in the main part about keeping the momentum of the business going. There is some MBM expenditure above the momentum line, because this is the amount that IT will have to spend in order to keep up with increasing business momentum – the new branches, or workstations or whatever. The ‘improve business results’ budget tends to ‘float’ above the momentum line, because these are new projects that are directed at improving business performance. Some projects, however, are new expenditures directed at maintaining business momentum – non-discretionary projects which have to take place (I think for instance of the Y2K projects, which had absolutely nothing to do with improving business performance, but which if not done, may have had disastrous effects on business momentum). Typical below the line IBR expenses occur as a result of government legislation, or forced changes to systems caused by suppliers and customers and so on. Finally there is the strangely split case of information leadership: initially I placed only one box high above the momentum line, to represent speculative expenditure on new products or new markets, but I have come across numerous situations where it is possible to exercise information leadership as within normal 118

Getting, keeping and using the cash – budgeting for IT

business momentum operations. Most of these cases happen as a result of the company opening a new branch or processing plant or factory in some location. Normally the IT budget for this would be represented above the line in the ‘MBM’ block. But here’s an opportunity for IT to exercise real leadership by applying new or different technologies to existing business processes. In most cases of expansion in IT, they are held back by having old or legacy systems which were designed years ago, and which now have such a wide footprint in the company that changing them is becoming increasingly problematical. (It’s a little like taking your car in for an oil change, and being told to keep the oil and change the car.) Not so in the case of new branches or factories etc., because here is a perfect opportunity to pilot new and cheaper technologies in a site that is usefully distanced from the rest of the organization. So that is why there are two information leadership budget boxes. After this brief explanation of possible IT budget classifications, the CEO who had drawn his line through the IT budget and told them to cut 20 percent sat back and said: ‘Oops!’ He took my diagram and said: ‘I’ve just drawn a line through everything’ (Figure 8.3).

Budget

Information leadership

Figure 8.3 If you present an undifferentiated budget, you get an undifferentiated response

Improve business results

Maintain business momentum

% y 20 b Momentum line ets g t u b Information IT t leadership u C

Time

‘This means that they’ll cut from the least visible parts of their budget, their “information leadership” and “improve business results” roles, in order to give themselves some leeway in the most visible part, the “below the line” MBM role. No wonder I never get leadership from IT, because that’s the first thing to go when the chips are down.’ 119

What Business Really Wants From IT

This CEO realized that while there were three roles for his IT department in his organization, there were also three ways of budgeting as well. He also realized something else: that if he forced a cut of the IT management budget by 20 percent, he would be forcing a cut in his own business momentum. However, the IT department were to blame, because they had never presented the budget information to him in a way that he could make simple business sense of it. From this moment on, the CEO requested that his IT department present their budget to him in the momentum line and three roles format.

Three types of IT activity mean three types of budget Budgeting for the manage business momentum (MBM) role Because the MBM role is tasked to ‘maintain business momentum without fuss’, their budget must necessarily be tied to the momentum of the business. This doesn’t mean they have to rush out and count every staff member, customer, supplier, nut and bolt in the organization. In practice maintaining business momentum is more a question of recognizing what’s new and what exists already. So MBM budget defines how much your organization spends on its technology to maintain the current pace of business. It assesses what, within the existing product and market set, will be new – organic growth of existing operations if you like. Then it presents its budget based on these two categories: ●

●

this is how much we will have to spend on IT to keep things the way they are, and this is how much must be spent because we will bring three branches and one depot on line in the next year.

Simple as that … you add up the cost of running the existing IT infrastructures needed to maintain business momentum, include the new costs anticipated because of increased momentum, and voila! Of course, compiling the figures will never be as simple as that, and there is another dimension to be added to the MBM budget because budgeting is an opportunity to drive cost efficiencies, so MBM budgets need to have some kind of improvement targets. Certainly ‘cut everything by 20 percent’ is unreasonable and may even be damaging to the company’s momentum. 120

Getting, keeping and using the cash – budgeting for IT

I usually suggest that the MBM budget be tasked with a stretch goal of between 5 percent and 10 percent lower than the budget initially presented. Notice also that the MBM budget tends also to be cost based, so it can track rising costs and either zero-base the budget or take last year’s budget and add a cost plus or minus factor. There is also the opportunity of tying the MBM budget to some unit of IT – for instance the number of workstations in the company. So MBM could expect to cost $3500 times the number of workstations in the company. The business generally approves of this approach because it is simple and manageable in business terms. IT people tend to dislike the approach because it boils all that complexity down into one number. However, the business is used to thinking of its entire operation in terms of one number – the stock price – so perhaps IT should capitulate on this point. There is another benefit to having MBM costs tied to a specific unit: it allows the easy calculation of increased business momentum. IT infrastructure costs do not grow in a linear way – there is a baseline cost, irrespective of how many workstations you have. But the unit cost can be expected to drop as economies of scale come into play.

Figure 8.4 Reducing unit costs as economies of scale occur

Unit cost per workstation ($ 000)

The graph for a simple scenario in which a server (at $20 000) can accommodate 16 workstations (at $2000 each) would look like Figure 8.4. 22

4.3 3.8 3.25 1

3.25

16 32 Number of workstations

3.25 64

A single workstation with one server would have a unit cost of $22 000, but this would quickly drop to $3250 per workstation when 16 had been attached to the same server. However, workstation 17 would have a higher unit cost of $4300, which would again reduce as computing capacity was used. IT people have much more advanced algorithms to calculate capacity requirements, and can offer much more sophisticated unit cost figures. 121

What Business Really Wants From IT

Similar unit cost figures for the IT management area of activities are: ● ● ●

● ● ● ● ● ● ●

MBM budget as a percentage of revenue MBM capital budget as a percentage of revenue Hidden MBM spending as a percentage of revenue (IT expenditure outside the IM organization) MBM budget per employee MBM budget per IT end user MBM budget per one IT workforce headcount Percent workforce that is IT workforce Number of users to IT workforce Revenue per employee Revenue per one IT workforce headcount.

As you can see, the unit cost measures you choose are numerous and only make sense if they are of use to your budgeting process. Budgeting for the improve business results (IBR) role While the budget for IT management is closely linked to the momentum line and to existing cost bases, the IBR budget is more likely to be project based with a focus on specific initiatives and benefits to be achieved from those initiatives. You still have to prepare projections of how much is likely to be spent on IBR activities, but I suggest that both business and IT understand that more flexibility is needed in this budget area. In my experience, about 30 percent of budgeted projects do not happen in the year they were budgeted for, either because of capacity issues (mostly the business capacity to accommodate new systems and processes), or because events overtake the proposed project and it is scrapped or postponed. However on the other side of the coin, about 30 percent of projects that do happen were not predicted in the previous budget. So it is important to realize that while the IBR budget needs to be set, some adaptability needs to be built into the process. The IBR budgeting process involves the aggregation of all the project costs (both existing and future) to be borne in the next year, compared with the sum of the benefits to be gained from proceeding with these projects. It’s a classical return on investment (ROI) exercise. However the complication comes in recognizing that IBR costs and benefits have a time component to them. In the first four stages of a system’s life, the system is a cost drain on the company. 122

Getting, keeping and using the cash – budgeting for IT Table 8.1

Budget activities during the system’s life cycle Stage

Cost vs benefit

Need/opportunity

• Costs included or • Focus on initial ROI hidden in day-to-day • Ensure real benefits are operations identified – future budgeting credibility depends on proven benefit realization

Systems study/enquiry

• Initial cost estimates • Full project costing • Cost drain

• Budget for ‘x’ number of systems studies/enquiries per annum • Present aggregated ROI for active and pending projects

Design

• Cost drain

• Manage costs against budgeted projections

Programming

• Cost drain

• Manage costs against budgeted projections

Install

• Cost drain • Capital drain

• Manage installation costs against budgeted projections

Post-implementation review

• Cost drain • Prepare a benefit realization plan, • Benefit release begins with timeframes for budget presentations

Optimization

• Major benefit release

• Track and communicate costs and benefits

Stable

Maintenance

• Stable costs • Stable benefits

• Track and communicate costs and benefits

Late

Late-life

• Rising costs • Decreasing benefits

• Track and communicate costs and benefits • Budget for replacement/ upgrade/decommissioning

Concept and development

Benefit release

Budget related activities

IT’s credibility in its IBR budgeting projections will be strengthened or weakened by their ability to prove that the benefits promised in the previous budgets have been actually realized. Therefore it is imperative for IT and the business to focus on real benefits and on the actions that will be needed to achieve these benefits. Finally of course it is essential for IT to communicate, communicate, communicate. Budgeting for the information leadership (IL) role This area of IT’s budget is usually prominent by its absence. Mostly IT struggles to gain acceptance of any cutting-edge activities because their credibility in the other budget areas is held in some doubt by their business, and because the business often sees IT ‘leadership’ as techno-junkies needing their next 123

What Business Really Wants From IT

fix – they imagine the IT manager saying: ‘I bought my company some really good software for me to play with’. Because of these perceptions, budgeting for IT leadership activities needs to be grounded in two areas: new products, markets or competencies for the business, or internal leadership activities such as strategy development, communication, boundary pushing activities etc. The easier and most likely IL budget to be accepted is of course related to new products and markets. There should be a clear understanding that much of the activities in the IL area are to some degree speculative, and therefore guarantees against returns should be avoided. However, it is possible to budget for IL activities in an incremental way, requiring approval against progress in various stages of the IL activities proposed. Prototypes and proof of concept approaches hold more sway. Also, risk-linked budget approaches are appropriate here. Use accepted risk analysis software to produce a table which identifies qualitative and quantitative risk factors and probabilities for executives to study before making their decisions. Ultimately however, there is one test of true business leadership whether from IT or elsewhere, and that relates to the performance of the company or organization in the larger scheme of things. So comparison of your organization’s performance against other organizations plays a role, and IT’s contribution to that performance is a good yardstick of the quality of information leadership within the company. Budgeting for new products or market IL activities requires that you identify the strategic contribution that the particular activity will have, as well as an identification of the size of the market or product set. You also need to take some position on the potential returns on investment, as well as provide indications of new revenue streams, new markets, sustainable competitive advantage, market responsiveness etc.

124

9

Measures of IT – some principles of measurement

I think the oft-quoted statement: ‘if you can’t measure it, you can’t manage it’ is both facile and very often a cop-out from dealing with the soft stuff in business. As David Whyte, a corporate poet, says: What companies most need from their people is vitality, adaptability, creation and passion … none of which can be coerced or measured … There is no lever to pull to make it happen, no magic button. (Whyte, 2003)

But it is equally facile and an equal cop-out to use this argument to justify why nothing must be measured. As with all things, when offered two opposing points of view, the answer usually lies somewhere in between. I personally consider everything to be measurable if you choose to do so, but the amount of effort and the usefulness of the measurement should guide you. In this I subscribe to Occam’s Razor: William of Occam (1284–1347) was an English philosopher and theologian. In his writings, Occam stressed the Aristotelian principle that entities must not be multiplied beyond what is necessary. In science, the simplest theory that fits the facts of a problem is the one that should be selected. In business it translates roughly into the well-known KISS (or keep it simple, stupid) principle. And that’s what needs to be done with measurement. Of course there will always be cases for complex measures, by the rule of thumb here is to go for the simplest measure – simple in terms of getting the data, and simple in terms of ease in understanding. It might be useful to the deep-space techies to know that the transfer rates of the middleware are performing at 83 percent of the optimum, but when it boils down to it, what is the outcome? Focus on the outcome to get to the simplest measures, and the simplest reporting media. 125

What Business Really Wants From IT

There are a number of key principles, other than KISS, that guide us in our measurement thinking:

Measures must be linked to objectives If IT makes use of the simple yet rich ‘Balanced Scorecard’ process (Kaplan and Norton, 1996) it forces them to link their measures to the company’s strategy and by implication their own IT strategy. However, the direct translation of balanced scorecard measures into IT measure and vice versa, is not necessarily easy. In the balanced scorecard, there are financial, customer, internal business process and learning and growth measures. Each of the measures asks respectively: ● ●

● ●

How should we appear to our shareholders? How should we appear to our customers, to achieve our vision? What business processes must we excel at? How will we sustain our ability to change and improve?

As you can see, these measures are focused on outcomes. We shall look at the linkages between the three roles and the balanced scorecard at a later stage in this chapter.

Measures must be understandable to the business This seems to be self-evident, but I have seen too many examples of technical measures which may have meaning for the technical team but have none for the people who sponsor the IT effort. While these measures may be essential to the technical team, they should not go beyond the doors of the IT offices – unless they’ve been translated into business terms. Most business people understand the concepts of ‘delay’, ‘just-in-time’, business process optimization etc., and they certainly understand costs, but they want to see benefits and returns associated with these costs. So the challenge for IT people is to translate their measures into business measures. For example, if IT is detecting a degradation in network response times because of increased traffic and bandwidth constraints, their job is to find out why the traffic has increased, before communicating this to the business. In my experience there are four main causes for network traffic 126

Measures of IT – some principles of measurement

increase: firstly increased business transactions, secondly poor training of users (repeating messages, or sending unconscionably large files and attachments – yesterday I was sent a 6 Mb two page word document!), thirdly unauthorized network traffic (jokes, pictures, internet downloads etc.) and finally technical optimization issues (into which I put viruses, worms etc.). The point is that the suggested actions for each of these reasons is entirely different. It is unacceptable for IT to report an increase in network traffic without knowing why. It is also unacceptable not to have a business resolution for the measures. It is the ‘librarian’ IT people who think that reporting a bandwidth crunch is enough to justify IT expenditure. Their days are numbered. They need to ‘read’ the business books, to have a business explanation for their IT measures and be mindful of a business outcome for their IT expenditure proposals.

Measures must be communicated I am amazed by the number of CIOs and senior IT managers who complain to me that the business doesn’t understand IT, but who have no-one in IT responsible for communicating with their business. Yes, ‘communicate with the business’ might be buried deep in various IT people’s performance criteria, but this mission-critical action does not enjoy prominence in almost every IT function I have worked with. At best I might find an IT department who has ‘Business integrators/Analysts’ or some such position – people whose specific job is to connect between IT and the business. But when you look at their job descriptions, communication takes its place after job functions such as service level monitoring and improvement, business analysis, requirements comprehension and translation into IT actions, project management, and so on. Again, communication is subsumed in the job description somewhere. Certainly these people never went for training in communication. I maintain that translating IT-speak to the business and vice versa is one of the critical success factors for IT in general. And not just communication, but innovative communication (and yes, why not make it fun as well?). Where are the intranet pages that display IT service and performance measures in real-time on-line mode? I once came across such a site which used an accepted cultural symbol for the organization in which good performance was depicted by a balloon floating above the crocodile-ridden swamp. IT picked up on this and displayed their performance in exactly these terms. Users would log on 127

What Business Really Wants From IT

daily to see where their particular system’s balloons were floating. If a system was down, the deflated balloon was in the swamp, with attendant gnashing crocodiles. This IT department even went so far as to have an animation of some poor bloke with a teaspoon trying to drain the swamp. That’s communication. When you get home after a hard day at the office, do you turn on the TV to watch a bunch of graphs? Or are there other images which attract your attention? Graphs aren’t bad – in fact they are a whole lot better than a list of figures – but often there are many other ways of depicting information. And putting ‘communication’ high on the list of IT’s performance criteria might get you some way towards improving your relationships with business.

Measures must result in something – they must have a reason to exist I believe a measure is pointless if it doesn’t cause something to happen. Even if that something is the generation of some communication that ‘all’s well’. But my main concern relates to feedback loops and actions. Why did you measure this particular datum in the first place? It’s that ‘so what?’ question again! So you need to look at the drivers of the measure, the business objectives, and importantly, whether this measure contributes to actions which advance the achievement of these objectives. Each measure should be associated with possible actions, and of course each action should be tracked and managed accordingly.

Three IT roles equals three measurement frameworks Actually there are four frameworks, because there is a difference in measuring IT infrastructures and measuring IT applications. The measures are included in tables below which try to define ‘drivers’ for the measures, the measures themselves and the mechanisms you would use to perform and report on the measure. I have not mapped each measure onto a driver or mechanism, because each situation is relatively unique, but when you do the same, you should have one driver and a corresponding evaluation mechanism for each measure. Some of my clients have wanted to map actions against each measure, others have mapped responsible parties, and yet others mapped outcomes 128

Measures of IT – some principles of measurement

(or whole sets of measures which contribute to outcomes). The choice is yours, but the basic principle remains: ● ● ●

●

know what drives performance in a specific area know what metrics define the drivers know what methods you will use to quantify (or qualify) the metric most of all – know why you’re measuring something and do something with what you know.

Measuring the performance of technology As can be seen below, I have split the MBM measures into two, specifically IT related measurement areas – infrastructure and applications. And if there is one area in which IT should measure its performance for itself (and not the business) then it is in the maintain business momentum role, largely in the area of infrastructure performance. There is a tricky issue of what is infrastructure and what is an application system, and I leave it to you to decide for your particular business, but in general, infrastructures tend not to run business processes while applications support these processes directly. (I was talking to a CIO the other day, and he believes his most effective system, the one without which his company would suffer dearly, is email. Now is this an infrastructure or an application? – That’s why you need to decide.) In the final analysis it is important not to get too deep into the semantics of infrastructures, applications, systems, and all the fun things that seem important to technologists – if it serves the business to see things a certain way, then that’s the way to see stuff. So getting down to the measures, here’s a sample list of IT infrastructure measures (Table 9.1).

Table 9.1

Measures for IT infrastructures

Maintain business momentum – Infrastructure

Drivers

Metrics

Evaluation mechanisms

• • • • • • •

• • • • • • •

• Problem mgt. stats. • Process stats.

Availability Stability Access Efficiency Effectiveness Cost IT buying decisions

Unit costs MTTR etc. Request turnaround IT cost per employee No. of users/staff Stability & availability Return on IT assets

129

What Business Really Wants From IT

While there are many more technical measures available to you in the fundamental depths of the technologies that run our systems, in business terms we are really only interested in the tip of the proverbial IT measurement iceberg. And therein lies a problem, in that it is possible to summarize ad absurdum – or until the measures make no sense. So the emphasis must be on usefulness for the business to understand what’s happening in the technologies to help them in their business decisions – decisions which allow them to understand how well or poorly the technology is performing: ●

●

●

●

●

●

Is the infrastructure available to the business where and when they need them? Is the infrastructure stable enough to place dependence on for core business processes? Are the right people getting access to the infrastructure, in due time, and importantly, are the wrong people being denied access? Are the company’s IT infrastructure resources efficient (not wasting time and expense), and effective (producing the intended results)? How much does IT infrastructure cost, and is this cost within acceptable benchmarked limits? Are we acquiring, upgrading and disposing of our infrastructure technologies to keep pace with our company’s growth? Are we using our infrastructure capacity effectively?

The measures for IT application systems are different in that they directly support business processes, and as such are more visible and obvious to business sponsors and users. So the measures need to focus on the support of the application. Table 9.2

Measures for IT applications

Maintain business momentum – IT/IS Applications

130

Drivers

Metrics

Evaluation mechanisms

• Support/service: • Availability • Stability • Access • Efficiency • Effectiveness • Cost • Integration/re-use • Interoperability • Transportability • Application life-cycle decisions

• • • • • •

• Service management mechanisms • User surveys • Benchmarks • Programme management office • Post project reviews • Budget monitoring • ROI modelling • Communities of practice

Budget TCO Service levels Benchmarks Life cycle monitoring On time, budget, specification • Level of customer satisfaction

Measures of IT – some principles of measurement

The service mandate (or service level agreement, if that’s your approach) drives the measurement ethic for applications. However, there are some key IT-related concerns which must be reflected in the measures as well – and it is incumbent on IT to present these concerns to the business as well. So the questions that the business should be asking of its IT application systems are: ●

●

●

Are the application systems meeting their mandates? In other words, if a system was implemented to allow the business to take orders in less than five seconds, then is this actually the case? Also each system will need to have its own stability, access, efficiency, effectiveness, cost and buying decision measures. How well do the applications work within their own right? Are they integrated with the other applications and processes in the company? Can elements of one application be used elsewhere? (For instance is there a common database?) Is training learned in one application re-usable in other applications? All of this goes towards the total cost of ownership borne by the business for their applications, and points to why ERP systems have been so sought after in recent years. Where is the application in terms of its life cycle? What is the total cost picture for a particular application – and by total, we mean both at some point in time, and over the entire life of the application? This element of measurement goes hand-inglove with the measurement of benefits. As I’ve said before: IT should never discuss costs without discussing benefits.

One of the essential governance elements of application service provision must be a service forum in which both the measures of IT of the application by IT people and the business experience of the application are shared and compared, differences are highlighted and acted on. Most importantly, expectations of both business and IT are managed.

Measuring improved business results brought about by the application of information technologies While the previous measures were distinctly focused on the technologies, infrastructures and applications which support the business, the IBR and IL measures must be grounded in business performance. 131

What Business Really Wants From IT Table 9.3

Improve business results

Measuring business benefits through the use of IT Drivers

Metrics

Evaluation mechanisms

• Production volumes • Staff output • Fulfilling business commitments • Business reliability • Business responsiveness • Complexity of business processes • Product quality • Cost competitiveness • Confidence in decisions • Customer intimacy/ satisfaction • Productive supplier relations • Customer lock-in

• ROI • Return on portfolio • Hidden IM spend (outside IM budget) • Business outcomes • Productivity • Business case measures • End user involvement • Business results • Cross process metrics • Level of customer satisfaction

• Quality management • ROI analysis • Post-implementation review • Impact analysis • Financial analysis • Outcome tracking • Risk assessment

I’ve focused on deriving business benefits at some length, and this section merely formalizes the idea that business benefits address. And as you can see above, all the measures are to do with business performance and improvement. At this point many IT people have challenged me on whether it’s their job to measure business performance. My reply always comes back to the business expectation, which of course is: ‘If IT don’t measure the effect they have in my business, how can they possibly claim to be contributing to the business?’ But just because IT is expected to measure the effect that technology has in the business doesn’t mean that they do so in isolation or even in spite of the business. If IT is measuring business performance without business being involved in the process, then there is a serious problem. IBR measurement must take place in concert with the business process concerned. My experience is that once IT expresses the will to be involved in measuring business performance for the good of the company and the process concerned, business people tend to welcome their involvement. Another concern that IT people tend to raise relates to the difficulty of identifying the cause of the benefit – was it IT or was it the business? My answer has to be: ‘who cares?’ If the performance of the business is improving, who really worries whether it was business or IT who caused it? Indeed, if IT had been involved in the business process and had been measuring the performance of the process over a long time period, it should be possible to 132

Measures of IT – some principles of measurement

Number of purchase orders processed per user per month

show how certain applications of technology have affected the process (Figure 9.1). 1200 1000

Implementation of new PO system

800 600 400 200 0

J F M A M J J A S O N D J F M A M J J A S ON D J F M A M J J

Time

Figure 9.1

Business improvement linked to application of technology

Now whether the improvement shown above was caused by IT, or the new system, or by improved processes resulting from the re-engineering exercise that accompanied the system implementation is of no consequence. Business performance has improved, IT was involved and IT continues to be involved – especially when they add another performance to Figure 9.1: ‘Expected PO throughput as a result of the benefits calculation ⫽ 1000 per month’, and they are actively working towards helping the business achieve this next level of performance. That’s when you know that IBR measures are working for IT and for the company.

Measuring IT leadership Measuring leadership is often problematic. But coming back to the original definition of leadership given by a CEO should make it a lot easier: ‘leadership involves adding new products or new markets to the company’. And that should be really easy to measure. I’ve often motivated CIOs to get into the business definition of leadership by telling me what they intend doing which will be described in the company’s annual report. Many are stumped for an answer. Because they see theirs as a backroom support role. Which is not what business wants – they want new business, either through expanded markets, new products or new competencies. Measurement of other less definite elements of leadership, the management of meaning, attention, self and trust is a touch more difficult, but it is possible. I described earlier a two-day workshop in which the IT department successfully quantified the 133

What Business Really Wants From IT Table 9.4

Measuring IT leadership

Information leadership

Drivers

Metrics

Evaluation mechanisms

• • • • • • •

• New markets • New products • New businesses/ acquisitions • New corporate competence • Level of investor satisfaction • Revenue growth

• • • •

New opportunities Clear direction Business performance Products Competitive edge Learning Competence

Strategic review Business review Exposure analysis Innovation index

contribution, current or potential, that they made to helping the company achieve its strategic objectives. This is one approach. Other measurement approaches require a qualitative assessment (surveys and questionnaires) to assess IT leadership. A further measure of IT leadership will come during the 360° review process, should you have one, in which everyone involved in the performance of IT has a subjective say in how well they (or the CIO) lead the organization. Adding up a significant volume of subjective opinions tends to allow you to make a call on the performance of an individual or department.

Implementing measures Many organizations subscribe to the balanced scorecard to ensure they have a wider perspective in measuring their performance. It is possible to populate the balanced scorecard with the IT measures described in Figure 9.2. It is clear to me that the balanced scorecard is ideally suited to representing IT performance and to changing business perceptions of IT. Because Kaplan and Norton developed the scorecard to expand on the existing financial accounting model to help companies in the information age engage with the real world, past, present and future: … financial measures tell the story of past events, an adequate story for industrial age companies for which investments in long-term capabilities and customer relationships were not critical for success. These financial measures are inadequate, however, for guiding and evaluating the journey that information age companies must make to create future value through investment in customers, suppliers, employees, processes, technology, and innovation.

So if one wants to take a coarse stab at matching the MBM, IBR and IL roles to the scorecard, it becomes obvious that the financial 134

Measures of IT – some principles of measurement Financial How should we appear to our shareholders? • TCO of technologies • Cost vs. benefit ratios • IT cost per employee • ROI • Budgets: Above and below the momentum line Customer

Internal business processes

How should we appear to our customers?

What business processes must we excel at?

Vision and strategy

• Business responsiveness to customer needs • Customer satisfaction • Business outcomes in customer terms

• Process measures • IT service measures • Efficiency and effectiveness of infrastructures and systems

Learning and growth How will we sustain our ability to change and improve? • Information leadership – new products and markets • Workforce competence • Experience capture • Staff morale, focus, empowerment

Figure 9.2

The balanced scorecard and IT measures (after Kaplan & Norton, 1996)

Table 9.5 Rough matching of the balanced scorecard to the three roles of IT Balanced scorecard

Three IT roles

Financial perspective Internal business processes

approximates

Customer perspective Learning and growth

approximates approximates

(Old style management of IT) Maintain business momentum Improve business results Information leadership

accounting model, which has been applied to measure IT performance for so long, is woefully inadequate (Table 9.5). Although the situation is changing rapidly, there are still many CIOs who report to the Financial Director in the company. And whilst the reasons for this reporting line are probably historically defensible, the current mismatch between just about everything that IT does and the pure financial perspective is not. It’s time to make the change from seeing IT in financial terms only and to move your company into the information age. 135

What Business Really Wants From IT

Kaplan and Norton (1996) offer a ten step process to implement a balanced scorecard measurement programme, which I have followed with success in a number of organizations: Task 1: Select the appropriate organizational unit Many IT functions spread across multiple business units and have a central head office IT function as well. Kaplan and Norton suggest that to initiate a scorecard process across all units is less successful than choosing a specific strategic business unit and piloting the measurement process there, where objectives tend to be more definable, visible and manageable. Task 2: Identify the SBU/corporate linkages It is important to define the corporate objectives for the SBU in question, enumerate the global corporate themes (which apply to all SBUs), and identify commonalities with other SBUs (common customers, competencies, products etc.). From an IT perspective it is also important to identify common infrastructures and services supplied from either an outsource partner or a central IT service. (The responsibility for service to the users in the SBU remains always with the SBU IT department – they need to apply the usual IT management role described in Chapter 4.) Task 3: Conduct a first round of interviews to build consensus around the strategic objectives Talk to stakeholders – I define stakeholders as anyone who has a right to know what’s happening, as well as anyone who can materially affect the particular initiative. The aim is to introduce the measurement approach, get inputs on the usefulness of the measures to the business, get input on the translation of strategy into tangible measures and deal with issues and concerns that managers and concerned individuals might have. Task 4: Synthesize the interview findings Identify the key measures which mean the most to stakeholders and prioritize them. Classify measures into balanced scorecard categories and identify where categories are weakly supported by measures. (The measures must represent the SBU and IT strategy.) Identify possible issues and organizational resistance and develop a preliminary change management plan. 136

Measures of IT – some principles of measurement

Task 5: Executive workshop first round Begin the process of gaining executive consensus and support for the measurement process. Show the linkage between the measures and the corporate strategy and how the balanced scorecard works. (There may be a spin-off in terms of a wider acceptance of the balanced scorecard throughout the organization.) Task 6: Select and design the measures Define each measure in terms of its exact wording, sources of information and linkages to other measures. It is important at this stage, even though Kaplan and Norton are not explicit about it, to establish exactly what outcomes will result from the measurement programme. Get to the ‘so what?’ questions. ‘So we have a measurement programme, how will that result in a new outcome for the organization?’ I find this relatively difficult because participants usually say something like: ‘it’s obvious’, and leave it at that. But the real challenge is to devise the feedback processes and the actions that will arise from metrics which are out of desired ranges of performance. Task 7: Executive workshop round two Present the measures, their metrics, linkages and the actions that will arise from the measurement programme. Apart from gaining approval to proceed, you are looking for executives to start to take ownership and begin to communicate to all employees in the SBU. Task 8: Develop the implementation plan Kaplan and Norton map out a 16 week timeline for implementation of a general balanced scorecard in a specific SBU. A simplified timeline is as Figure 9.3. Kaplan and Norton recommend that any company implements the balanced scorecard within 60 days. I believe that in IT’s case the process may be speeded up. Task 9: Executive approval Reach final consensus on the measurement programme, and get approval for the implementation. 137

What Business Really Wants From IT Week 1–3 Project definition • Plan project • Select SBU • Define linkages etc.

Figure 9.3

Week 4–7 Interviews and synthesis • Interview stakeholders • Analyse findings • 1st executive meeting

Week 8–13 Design • Design measures • Design collection processes • Design feedback/ communication loops • Outcome action plan

Week 14–16 Rollout plan • Implementation plan • 3rd executive approval meeting • Implement

Sample measurement implementation plan (after Kaplan and Norton, 1996)

Task 10: Implement Follow the implementation plan in organizing the implementation team, executing the plan and as always developing and executing the benefits realization actions.

Communicating to the business A final word on measurement: if you are measuring away, and know how well (or badly) you’re doing, there’s almost no point to all your efforts if you don’t communicate. Communicate through the governance forums, in individual meetings, through the intranet, through on-line newsletters, emails, videos, and internal advertising campaign … and on, and on. I am currently working with a large company whose CIO is sponsoring the writing of a book not unlike the many ‘Idiot’s Guide to IT’, or ‘IT Made Easy’ books that you find in your bookstores – but this book is specific to the company, its strategic objectives, and its applications. It tells users how to know if their system is working well, how to get in touch with IT, how to interpret IT strategies, why there are standards, what the IT budget looks like, and so on. It is taking a while to put together, but that’s because we are developing the material on-line with interactive updating of current measures, statistics, phone numbers, contact details etc. The style, however, is totally unlike any corporate communication that workers have received in the past, and the initial indications are that it will be exceptionally well received. So communicate, communicate, communicate – IT’s survival depends on it.

138

10

New IT skills and people

It’s obvious that new skills will be required in IT if it is to fulfil the three roles in the 3R model. Or is it so obvious? Because the skills required are largely not IT skills; rather, they are real business skills. These skills need to be ‘real’ because although they may have a foundation in MBAs and other generic business education, they need to be specific to the company’s operations and industry. So if an IT person wants to fulfil the three new roles, he or she had better understand the business they are in, and the industry in which that business operates. I need to repeat that these are roles, and not necessarily jobs, so the more a specific IT job spans across the roles, the more skills will be required.

New skills for the three roles When we are talking about skills, we need to recognize that there are in fact four broad role categories in IT. But I have been focusing on the three IT demand roles that most businesses want to retain within their organization. The fourth IT role is of course the IT supply role – one which the company may wish to outsource or insource. This supply role requires more of a generic specialist technical IT skill – a contradiction if ever there was one. One of the reasons outsourcing is so attractive, both to the company and the outsource supplier, is that the supplier is able to concentrate specialist skills in one supply organization, and leverage off their specialization to provide exemplary IT services while challenging the specialists with a wide variety of environments across many organizations in which to exercise their chosen discipline. It’s a win-win situation for everyone. Ask any CIO what his or her primary personnel challenge is, and they’ll tell you that retaining specialist skills is high on their list – keeping them stimulated and up-to-date within one organizational environment. 139

What Business Really Wants From IT Supply roles IT supply 100% -

Demand roles Manage business momentum

Improve business results

Information leadership External focus World trends, industry trends, technology trends

75% Business management skills Strategic mgt., relationship mgt., mgt. of information, financial analysis, vendor and contract mgt.

50% -

IT management skills e.g. project management, service management, IT asset management, information management, communication

25% -

Technical skills e.g. languages, tools and network administration

0% -

Figure 10.1

The four skill sets required for the 3R model

So Figure 10.1 details four skill sets required by the 3R model. The first IT supply role could be outsourced, while the rest are ‘demand’ roles – the roles that we have dealt with throughout the book. Figure 10.1 represents a selection of the types of skills required in each of four skill sets: ●

●

●

140

Technical skills – those skills which relate specifically to the technologies, whether they be infrastructure technologies, networks, applications, etc. These are the traditional technical skills, acquired by attending vendor organized training and through intensive submersion in the technology. IT management skills – the management of IT requires service management, project management, IT asset management etc. Into this skill set I also place architecture and architecture management. I have had this debate about where architecture sits within the three roles, and we generally agree that architecture as a discipline cuts across the three demand roles, depending on the type and level of architecture involved. Obviously an enterprise architecture is going to be developed by the IBR and IL roles, while a technical architecture will be developed by the MBM and IBR roles. Business skills – while the figure above includes generic business skills, the true IT practitioner will strengthen his or her position and contribution in the organization by having skills

New IT skills and people

●

specific to the business or venture. So if you are an insurance company, or a transport company or a mining house, then those specific skills will strengthen the IT position within the company – especially when it comes to the IBR and IL roles. This doesn’t mean that someone without specific business skills can’t succeed – indeed IT people are extremely fast learners, perhaps more so than any other discipline. So the skills background would depend on the individual filling the role, or the organization’s culture and objectives. External focus competencies – these are not solely leadership skills, as one would imagine. As I get more exposure and experience of the executive levels of organizations, I lean more towards the belief that leadership is more an innate competence than a learned one. However, the specific skills we are looking for here with an IT perspective require a focus on three specific external areas: the world economy, external business developments, and technology trends. I deliberately include the world economy because if globalization is driven by one thing, it’s technology. So knowing what’s happening everywhere in the world is becoming one of the more essential competencies of a modern leader. Focusing solely on the technology would be a little like looking at one side of a set of scales. The other external focus is on the business environment specific to your business. For some reason ‘best practice’ seems to have lost some of its glitter, probably because there have been numerous abuses committed in the name of ‘best practice’, but the underlying principles are still sound. What are other organizations in your industry doing, and can we emulate them or do it better? Of course technology scanning is one of the primary leadership competencies for the IL role, but it must be tempered with a large dose of common sense – the CEOs I’ve spoken to don’t want Quixotic tilting at technological windmills. The information leadership role requires a blending of a world view, a keen insight into possibilities and opportunities in the specific industry and an understanding of how technologies can be best applied against these perspectives to create new products, markets or competencies. Oh yes, and also mix in a generous dose of innovation!

Having broadly described the skill sets, we can now draw a vertical line through these skill sets to get a generic profile of the four different roles in the 3R model (Table 10.1). Of course these percentages are merely a guideline to give a sense of what you should expect from people who fulfil each role. 141

What Business Really Wants From IT Table 10.1 Skills set distribution across the four roles in the 3R model

Technical skills IT management Business management External focus

IT supply

Maintain Improve business business momentum results

Information leadership

50 percent 35 percent 10 percent 5 percent

25 percent 40 percent 25 percent 10 percent

10 percent 15 percent 40 percent 35 percent

15 percent 25 percent 45 percent 15 percent

IT supply skills These days in large organizations the IT supply role tends to be outsourced. However, if it is not outsourced, I recommend that you ‘in-source’ this role to maintain clarity of objectives and delineation of responsibilities. ‘In-sourcing’ requires that you differentiate between the supply and the demand elements of providing information technologies and their associated services to your organization. I dealt with the issues between supply and demand in IT in Chapter 3, so won’t go into it here. Rather, I will concentrate on the skill set required by the practitioners in the IT supply role. When you talk to outsource suppliers their maturity in respect of treating the supply of IT as a business naturally surpasses that of an in-house IT supply role. So there is some learning to be done, both by the IT people and by business people. Coming back to a diagram from Chapter 3, you will have seen that the drivers of the supply role are significantly different from those of the demand roles, but we need to really understand these drivers now, so that we can better understand the skills and mindsets required in each role (Figure 10.2). IT supply role

Supply

Figure 10.2 Supply and demand in an IT context 142

Efficiency Costs Availability Stability Security Optimization Outputs

MBM

IBR

IL

Demand Effectiveness Requirements Meeting needs Usefulness Return on investment Improvement Outcomes

New IT skills and people

One of the primary drivers for a commercial outsource unit is to provide the agreed IT outputs (usually infrastructures on which the client runs their applications, or the applications themselves) in the most efficient way so that they can maximize their profits. As we have said before – economies of scale are the name of the game. Their outputs are solely directed by their service level agreements with their clients. Because they need to offer their clients a better service than they could provide themselves, usually at a lower cost, their ability to maximize their utilization of their resources is the difference between profit and loss. So they focus on two things: ●

●

What are we committed to providing? ❍ services ❍ infrastructures ❍ availability and stability of services and infrastructures ❍ how well are we meeting our commitments? — quantification of services — tracking and measurement of service provision — communication of services provided How cost effectively can we meet our commitments? ❍ asset management ❍ efficiency and throughput ❍ leverage of resources across as wide a base as possible.

Of course this second priority tends not to get discussed with the outsource client but it does get tracked, measured, discussed and acted on within the outsource organization. As it should be by the IT supply function within the organization. The IT supply role skills have about a 75 percent technological bias to them, about 20 percent IT management and 5 percent business focus (that is focus on the specific issues concerning the particular business to whom they supply services). This breakdown of percentages often concerns IT supply role people, but the emphasis is right: they need to be fully focused on the technology, and how it functions in the provision of services to the organization. A strong management of technology skill needs to be brought to bear – network management, security management, service management and so on, and I include this in technology skills for this role.

Maintain business momentum (MBM) skills Between this skill set and the IT supply skills set, is where I tend to get the most misunderstanding and, if you will, resistance 143

What Business Really Wants From IT

to change. Possibly because people in IT understand these roles best, they tend to fit them to their conception of IT management. But we need to continuously check ourselves here – we are looking at business expectations of IT in the IT management domain, not IT’s view of what they think they should supply. So business wants IT to manage the technology with one end in mind – ‘Make my business run smoothly – without fuss’. Again we come back to that ‘F’ word – fuss. So business doesn’t want to be hassled by the things that IT people find important, essential and interesting. This mismatch in priorities requires a new management mindset from IT – one in which communication and facilitation of understanding plays a prominent role. So the skills set required by the MBM manager (remember in Chapter 4 I called the MBM manager anyone: ‘whose direct job it is to manage information technology in pursuit of the MBM role’) is high on communications. The MBM manager manages the interface between the technical IT supply people and the business people. The MBM manager represents his or her company to the IT supply community so must have a good grasp of the business and the business strategies and objectives. As you can see from Figure 10.1, business knowledge comprises anything between 20 percent and 40 percent of the required skill set. This business knowledge is a twoedged sword for the MBM role manager – certainly he or she must be able to represent his or her organization’s interests, but the more difficult task is to represent IT priorities to the business. This is not easy work given the business stated desire not to be involved. However, real business cash has to be spent on technological initiatives which are essential to IT operations, stability and security, and while these initiatives may fall into the ‘don’t bother me with this stuff’ category, someone has to be able to communicate the need. In this instance, the MBM role is best served by having credibility in the business – if the MBM manager understands the business and if other IT roles (IBR and IL) are actively involved in the business, then their word will carry weight. If, however, there is evidence (real or perceptual) that IT people are in the technology for technology’s sake, then expect an uphill battle. 144

New IT skills and people

Improve business results (IBR) skills These skills required in this domain marry business with IT. Essentially people with this role are involved with: ●

●

●

working in and with the business to deliver real business improvements managing benefits to deliver the intended results from information systems understanding measurement of both business and IT performance.

This all sounds simple until we break it down (Table 10.2). Table 10.2

Skills required for improve business results roles

Activity

Skill requirement

Working in and with the business to deliver real business improvements

• Strategic understanding: business and IT strategies, including IT trends • Strategy development • Planning skills • Relationship management: Communication, negotiation, conflict management, etc. • Budgeting and finance skills

Managing benefits to deliver the intended results from information systems

• Business case development • Measures and metrics • Post-implementation review and action planning • Project management • Vendor and contract management skills • Service management • Some technical understanding

Understanding measurement of both business and IT performance

• IT asset management • Metrics and reporting skills • Understanding of drivers and outcomes (cause and effect) • Communication skills

There are obviously many layers we can peel away in each of these skills sets, but probably the most important message here is this: focus on business outcomes. This may require some headto-head confrontations with both business and IT, but one of the most successful people I have ever seen working in this domain worked exactly to this format: when things became political or unclear, she would always ask: ‘What’s the business outcome we are trying to achieve?’ She would then weigh each argument or proposed solution against that outcome. By focusing on the 145

What Business Really Wants From IT

business outcome she would often bypass the naysayers or highlight the fact that one part had focused on the output (deliver a system) rather than what that deliverable was meant to achieve. She was unreasonable when it came to the business outcome, and even stopped projects when they deviated from the outcome. What’s this to do with skills? Everything, because whatever the skills required in the IBR domain, their final focus must be on business outcomes.

Information leadership (IL) skills The outcome for the information leadership role is simple: new products or new markets, and perhaps new organizational competencies. So with a focus on these outcomes we can get a handle on the type of skills required for the role. The obvious inference from Figure 10.1 seems that an information leader must know everything about everything (and possibly nothing much about anything as a result of being too thinly spread). Instead we should concentrate our thinking by asking the question: ‘Will this skill help me lead the company to achieving the outcome of new products, markets and organizational competencies?’ If the answer is yes, we may be looking at an information leadership skill. I say ‘may be’ because I am wary of giving IT people a licence to read glossy technology press releases, or those research reports that companies pay so much for, and then calling that leadership. Your business outcome is the thing. So an IT leader needs to have enough technical skill to understand the concepts, and to be able to maintain an acute realism about technology. The IT leader will develop specific technical understanding in response to a need to deliver an outcome rather than develop a wide unfocused technological competence. An information leader’s IT management skills are similarly focused on business outcomes. So they will use project management in mapping out the route to get from where they are presently to some future end state. And their project management skills will allow them to drive the process forward. In the IBR role the focus on information is around understanding the content of information, and doing something with that information to improve business results. In the IL role, the idea is to create new information, to look at the world that everyone else sees, and to see something different. So an intuitive creativity is required. But this must be allied with a compelling communication ability. It is not leadership to come up with amazing 146

New IT skills and people

and deep insights, unless you can get others to buy into the new idea. Obviously, if the information leader is focused on new products and markets, he or she needs to have an acute understanding of business in general, and their own business in particular. In Table 10.1, I give a distribution of skills requirements across the IL role, and I allocate a whopping 75 percent to business skills and to external focus. This is uncomfortable for many IT people, because this is often outside their experience base. But that’s what is needed if you want to be on the board of your company – an ability to operate knowledgeably within the business and external worlds. How do you build those skills? Well, generic business skills can be built by following the MBA route, and external skills can be built by extensive reading of trade and business newspapers and literature. But the crunch, in leadership terms, comes in the application of these skills.

147

Applying the model – check your mindset at the door

11

The fundamental change required here is one of mindsets. IT people’s mindsets change from seeing their raison d’être as moving from ‘I’m in IT’, to ‘I’m in business. I bring a particular perspective to everything that my business does, and this perspective can change everything we do in the organization.’ And business people’s mindsets change from believing that IT is still the old ‘data processing’ department, to a mindset which requires IT people to deliver business results, in business terms and communicating in business language. This sounds a little onesided in that business gets to make all the demands and IT gets to do all the work. But a true business mindset change understands that IT people come with a certain history and technological background and that some partnering and mentoring will be required.

What changes? The mental model I have seen that the most profound change is the mental model that people use to see everything. Firstly priorities change, where delivering IT loses its all-encompassing central place in the minds of IT people. IT people try to see everything through the three lenses of maintaining business momentum through the effective and efficient operation of IT, of improving business results by focusing on business outcomes, and of providing real leadership by generating new ideas and information which creates new products, markets and real competencies. I have seen some IT people recoil and say that if they focus on ‘the other stuff’ then the IT service will fall apart. They don’t get it. Unfortunately IT still works on zeros and ones – it’s either on or off – and that attitude tends to follow through to some IT managers – either you do IT and nothing else, or you don’t do IT at all. These people are ideally suited to the IT supply side of 148

Applying the model – check your mindset at the door

the equation – but not the business side, because business has become quite demanding in its approach to IT. In the old days it was ‘either IT or business’, but now business demands a ‘both IT and business’ view of the world. To meet these expectations IT people have to do it all: to become specialist-generalists. The ‘both/and’ demands place more pressure on IT people, but they must rise to the challenge or as Peter Drucker says: ‘They will become the Supporting Cast’ of business. Business expectations of IT will change quickly One of the more interesting changes that I have observed is the readiness of business to accept the new way for IT to operate, and with this readiness comes an expectation for things to be different immediately. Business expectations for change in IT far outstrip the ability of IT to meet those expectations. Firstly there is the mindset change required of IT people, and this is no trivial thing. Secondly IT’s management systems and processes, their skills and organization and their technologies tend to be directed at maintaining business momentum – after all they have spent 75 percent of their time doing this stuff for years. So changing processes, skills, organizations, performance measures, and the systems that are needed to work in the improve business results and information leadership roles is not a quick thing. An example is the CEO who took a look at the three-role budgeting process, and said to his CIO that from now on this is how he wanted to see IT budgets. While breaking the current budget into three categories was a relatively simple thing, implementing the monitoring and measurement system, communicating the new concepts and managing budgets in three different ways took more than a year to implement. So changing roles tends to take between two and five years to bring about. And the management of business expectations is one of the key first actions for IT if they decide to move down this path. The changes need to be planned just like any other project (in the next chapter I give you a sample project plan for effecting this change). Maintaining business momentum is NOT the same as facilities or operations management I have said this at length before, but it needs repeating because this is one of the more subtle changes required of IT: initially 149

What Business Really Wants From IT

I named this role ‘IT management’, or even ‘IT demand management’, but I have constantly come up against people who saw it as facilities or operations management – not much different from the way they do things now. So the three roles model was merely a question of adding more responsibilities in the business and leadership areas. This is not correct. This model requires a fundamental shift in the way people see their role in the IT operations and facilities domain – there is no way that you will move from a 75 percent focus on managing the technologies to the business requirement of 20 percent: ‘delivering IT without fuss’ if you see the three role model as some kind of add-on to what you are doing now. So I came up with the rather cumbersome name of ‘maintain business momentum’ to focus people’s attention on the changed role. In the same vein, I used to present the three roles as a vertical model with maintain business momentum at the base, improve business results in the middle and information leadership at the top. Some people immediately saw this as an organizational hierarchy with IT operations at the lowest (and least important) rung on the ladder. So the model has changed to representing the roles side by side. And just because the business expectation of IT is to split their activities something like MBM (20 percent) IBR (60 percent) and IL (20 percent), it doesn’t mean that the MBM role is less important. But the fundamental change is this: in order to spend only 20 percent of their time on maintaining business momentum, IT people cannot do the work, they need to manage the work being done by IT supply specialists. (We have discussed that this may be an in-source specialization or an outsource approach.) The MBM role requires this fundamental shift: ‘My job is to assure the delivery, without fuss, of IT services to the business, so that they can get on with doing their business.’ To do that you need to get into IT supplier management, business demand management, and monitoring and reporting. It is the job of the MBM role to represent the business within the IT supply domain, to ensure that they get the services they need, at the quality they need. Head office IT – unit IT relationships change The split of activity between a corporate or head office IT function and the business unit has been defined as something like Figure 11.1. As you can see there are some significant differences between the roles at centre and the roles in the business units. This means 150

Applying the model – check your mindset at the door Corporate IT activities Maintain business momentum

10%

Figure 11.1

Improve business results

40%

Business unit IT activities

Aligned technological leadership

Maintain business momentum

Improve business results

Aligned technological leadership

60%

50% 20%

20%

Split between corporate and unit IT activities

that the business units are going to have to delegate some of their IL (information leadership) activities to the centre, and importantly, the centre is going to have to keep their noses out of how the units maintain their business momentum and how they interact with their businesses. So this implies some sort of agreement between the parties as to what gets done where. I still prefer the federal concept of ‘reverse delegation’, in which the business units delegate their IL requirements to the central IT unit, while the central unit delegates elements of MBM and IBR to the business units. This requires an initial negotiation and clarification of services supplied to the business, but more importantly it implies a service provider/receiver relationship between the parties. It would go something like this: ‘I in the business unit need you, the centre to look at IT trends for me so that I can fulfil my IL role in my unit. These are the reports I require, in this format at this frequency etc.’ Can you see the shift here? The unit requires a service from the centre. I shy away from suggesting that there should be a service level agreement between the two (they do both work for the same company, and there is no formal customer/supplier relationship), but there should be some understanding of the split in roles and of the performance requirements for those roles.

Governance – three types of meeting: MBM, IBR, and IL One of the essential drivers of the three role model is the governance structures that you put in place to make it happen. The moment an organization decides that their IT steering committee is going to be run along MBM (20 percent), IBR (60 percent) and IL (20 percent) lines, the playing field changes. 151

What Business Really Wants From IT

I remember being phoned by an IT steering committee chairman one day telling me that they had a monthly full-day IT steering committee. (They had 22 business units and it took a long time to get through the full agenda with unit report-backs etc.) He said that he was sitting there looking at the agenda and it dawned upon him that they were spending the entire day looking at how they run their IT operations – their MBM role. Whilst there’s nothing intrinsically wrong with that, they never looked at how they could improve business results or provide meaningful leadership to their business. So he made the suggestion that they finish all their operational stuff by lunchtime and spend the afternoon looking at where they could add value or provide leadership to the business. It would be nice to report that everyone liked the idea, but they didn’t. Some grandstanders wanted their fifteen minutes of fame, others worried that the operational stuff would fall apart, others were concerned that he had sprung this on them and what political game was he playing, and so on. So instead of fighting that battle there and then, he and I redesigned the governance of the organization. The IT steering committee still meets, but only to make decisions or discuss work from the IT services forum (their MBM), from the value add forum (their IBR) and the architecture forum (a version of IL). The IT steering committee meeting has been cut to a halfday session with their attention being divided between (guess what) 20 percent services forum work, 60 percent value add forum work, and 20 percent architecture work. So through management of the governance structures, we were able to bring about the shift in focus that has the company well on the way to focusing on the three roles in the proportions that they need. A further element of governance has already been discussed, and that is delegation of authority. As I said before, I prefer the federal approach to this governance activity of deciding who does what, when and to what standard. I once ran a two-week process of workshops in which key decision makers in IT and business went through, amongst other things, a long list of IT activities and voted on who should do what. Averaging out these produced a weighted list on ‘MBM’, ‘IBR’ and ‘IL’ roles (Figure 11.2). These are actual figures from the client report I did (that’s why IM – information management – is represented) so it is messier than a purely theoretical model. This work was done some time before the formalization of the three role model, and there is 152

Applying the model – check your mindset at the door

MBM IBR

IL Proactively create new business capability Manage IT assets and infrastructure Manage IM ROI Develop, implement and maintain architectures Relationship management Realize business solutions Deploy business solutions Manage operational services delivery Manage IM people

Figure 11.2 Summary results from an exercise to break IT activities into the three roles

Manage information context Provide enterprise IM management system IM quality management

some confusion between the roles and whether they happen at a central or local entity. In fact for this figure, read MBM ⫽ local, IBR ⫽ consult between local and central and IL ⫽ central. However, it is instructive to see how the votes finally tallied up: creating new business capability fits well with creating new products and markets, but was regarded as a central and leadership activity. There is also reverse delegation under ‘Provide enterprise IM management system’. Essentially this included the design and functioning of the governance and management systems for the IT operations throughout the company – when and how strategies are developed, what steering committees operate under what mandate and so on. The regional units saw this as a leadership issue to be handled by the centre. But they did insist that consultation occurred and that the performance of the IM management system was open to scrutiny. Interesting as well is the recognition that IM quality management is an MBM thing more than anything else. Which is good – there is a recognition that quality begins and ends at the ‘workface’ – the operations or ‘manage business momentum’ should be the centre of quality. 153

What Business Really Wants From IT

A final observation is that the central ‘role’ of IBR is so prominent. In this specific instance, however, this was not an expression of a desire to work together on business improvement initiatives – rather, it showed a need to keep an eye on each other – Group IT on Regional IT and vice versa – when dealing with the business. But these were early days in the process, and as the IT function in the company gets more into working with the business for the betterment of all parties and processes, these barriers and distrusts are being dismantled.

Focus on business benefits This becomes something of a doctrine in IT – they want to know what the business benefits are before they start out on an initiative, they want to know when and how these benefits will be achieved, and they track the ongoing benefits release from the work that they do. Sometimes they get involved in actually achieving these benefits for and with the business, and sometimes they need to get heavy – driving the benefits release where there is a lack of resolve. Does this make them popular? Yes, it does – with people to whom business performance is of great value. However, those people in the business who defend their turf, who build their empires, who hold forth their opinions without the concomitant action, will find IT people focused on business benefits release very threatening. As with all ‘black and white’ statements such as the one above, there are always exceptions – IT people cannot march blithely into business claiming to know what’s right for everyone. Rather, they need to act with circumspection, focusing on the benefits that they can most easily help the business achieve, and indeed avoid rocking the boat unnecessarily. I had a conversation with a technical consultant yesterday, in which he recounted how he had told the business to: ‘forget upgrading their existing messaging system until they made use of the workflow aspects of the previous system, because after all that was the core of the system, and not just the email that they currently used’. This is the wrong way to win business friends, no matter how right the technical consultant was. Rather, he should have initiated a discussion in which he introduced the aspects of workflow that were currently available, and didn’t they want to explore some of these processes on a stable platform before moving to the next upgrade? And if this technologist was worth his salt, he would have done some work on business benefits and outcomes available through the use of workflow. Three days ago I was chatting with a company’s implementation team of a worldwide user domain rationalization programme. 154

Applying the model – check your mindset at the door

The objectives are to have a single login ID, which is recognized with all its security and profile attributes no matter where the business person happens to be in the world. ‘Great’, I said, ‘what are the business benefits?’ ‘Well’, said the technical director of the project, ‘users will have better security, and it’ll be less hassle moving from one domain to another’. Assuming these are the only benefits of this expensive project (which they’re not), I asked how long it currently takes to login, and how many security breaches there currently are. He couldn’t answer. Neither did the project have a plan for tracking benefits after the system was implemented – that was ‘someone else’s problem’. One of the things about being passionate about business outcomes is that you need to know what is happening now – to baseline the benefits. Then you need to track the benefits, from before the system is implemented, through until the benefits promised have been achieved. And you need to take action when there is slippage.

IT’s survival depends on measurement and reporting Another thing that changes is IT’s passion for measurement and reporting. This is difficult for many IT people now – they see their job as getting the technology to the business, making it robust and available, and ensuring ongoing stability. Very noble and correct. But the new IT breed of person also understands that unless they track their performance in all three roles, their efforts are severely undermined. And this measurement and reporting must be in business terms, which is difficult and expensive. I am busy helping a company outsource its generic IT functions, preparatory to adopting the three role model. However, we have a requirement of our outsource partners that they report their performance in terms of business experience of their services. There is much sucking of teeth and casting of eyes ceiling-ward. This will add to the cost of the deal, and will make measurement difficult. Because they are able to measure with great accuracy the up-time of each component, but the sum total of the components in the chain to the user’s desk are more difficult. Luckily the company that I am working with have understood the MBM role, and have undertaken to work from their side, and will put in place ‘user measures and perceptions of service’ through the use of simple polling of workstations and on-line user surveys. The MBM manager is passionate about measuring IT from a business perspective, and 155

What Business Really Wants From IT

he quite understands that the techies in the outsourcing company are unable to see beyond the technical problems of producing a user service measurement. He even understands that his measurements from the business side of the MBM role don’t even have to be all that accurate initially – all they have to do is reflect current user and business perceptions of the service. So he will start with a relatively crude assessment of user perceptions, before the outsource contract is awarded, and will measure through the transition stage, well into the future. He is passionate about measurement and reporting because he knows the success of this outsourcing initiative will depend on user perceptions as much as on the cost savings and added functionality available.

Playing the three role game IT people play the three role game with everything that they come across in their working day: they see the world in terms of running the IT operations for the business, of finding business advantage and improvement in all the systems and technologies at their disposal, and in providing new insights on technology which will allow their business to enter new territories and deliver new services and domains. So an MBM manager understands that her job is about maintaining business operations, from moment to moment on a 24/7/365 basis. But here’s the thing: she knows that she needs to understand enough about business operations, throughputs, products, marketing or whatever business process her systems support, so that she can make a call on business momentum (volumes, velocities, rates of change, size of operations and so on) when it comes to technologies. And more than this, our MBM manager knows she has to act as an agent for her company with her IT supply companies and organizations to deliver IT services without fuss. And the IBR role drives IT people to look at the business as an evolving, constantly improving organism whose cells are its servers, whose arteries are its networks and DNA is the information that allows it to grow, change and respond to its environment. The information leadership role sees itself at the forefront of its organization, translating the world of technology into new products and markets for the company. There is an entrepreneurial drive asking: ‘How can we use this technology to create something new and useful to our customers?’ 156

Applying the model – check your mindset at the door

People And of course the biggest change is people: their mindsets, their skills profiles, their daily activities and their priorities. That’s a lot of change. So it won’t be easy. If the new way of things is going to be different from the old, not just an improvement on it, then we shall need to look at everything in a new way. In the long perspective of history it may seem that the really influential people in the last 100 years were not Hitler or Churchill, Stalin or Gorbachev, but Freud, Marx and Einstein, men who changed nothing except the way we think, but that changed everything. (Handy, 1990)

So the challenge is to look at the same thing that everyone else sees, and to see differently. To think differently. And to act on those thoughts.

157

To boldly go …

12

I read somewhere that: ‘Of the 10 percent of managers who buy business books, only 2 percent get past Chapter 1’. So if you’ve gotten this far – well done. But of course now the real work starts. It was Dr Laurence Peter, source of the oft-quoted ‘Peter Principle’, who came up with a less well-known but equally important principle: Sooner or later, everything degenerates into work.

But before the work starts, you have to do some serious thinking (which in itself is hard work). As Henry Ford said: Thinking is difficult, that’s why so few people do it.

An implementation plan I have put together a generic project plan for implementation of the three role model, but in my experience, each organization is different, comes from a different place, and is going to a different place: Their momentum, their direction, speed of doing business and their mass is unique. However there are some common areas of activity that can be implemented. In general you will need to conduct the following activities; the order will generally follow the list below, but you can choose to do some of these things in parallel: ●

●

158

Impact analysis: if you are going to embark on this path, it is critical that you know why you are doing it, what will be affected and how you are going to get from here to there. Part of the impacts analysis is a benefits analysis. Syndication: you will need to test your ideas with key stakeholders, and if they find favour, you will need to get approval

To boldly go …

●

●

●

●

and buy-in from the appropriate decision makers and affected people in the organization. Supply and demand: much of the three role thinking is predicated on the split of supply and demand within the IT delivery framework. You will need to be clear on where IT ‘supply’ comes from and what constitutes ‘demand’ functions within the organization. Organization design: there are a significant number of organizational changes that need to be designed and planned before you proceed. Strategies: step one in the strategy process is to match your IT related strategies to your organization’s strategies – this isn’t trivial. After this there are three linked strategies which will come into play. Not surprisingly, these three strategies relate to the three roles. Roadmaps: two types of roadmap need to be generated – a business roadmap and an IT roadmap. The business roadmap is less about telling the business what they need to do so that IT can operate in a different way, and more about looking at the genuine business outcomes which result from following the 3R model. And the IT roadmap is about how you create these business outcomes.

Impact analysis First thing’s first – if you want to move towards the three roles expected of IT by business you need to assess the impact of what this means to you, the IT function and your organization. Doing such an analysis takes time, but the upside is that it costs very little, and probably the greatest benefit is that it doesn’t raise expectations until and if you are ready to proceed. You may decide that this is not for you, or that you should ask your business what their expectations really are. If they respond differently to ‘deliver IT without fuss, get involved in business improvement and give us good leadership’ then you have two decisions – you can develop a plan to meet their expectations, or you can change their expectations to meet your chosen direction. When doing an impact analysis, I prefer to follow the simple but thorough process of asking the five ‘W’ questions: ● ● ●

Why do we want to do this? What will change? Who will be affected? 159

What Business Really Wants From IT ● ●

When will we do it? Where will the effects be felt?

(There is usually a sixth question – How? – associated with this list of questions, but the ‘how’ is really the implementation plan. Besides, ‘five W’s and an H’ doesn’t sound nearly as cool as ‘five W’s’.) Why do we want to do this? Good question. You might have any or all of the following reasons: ●

●

●

●

●

●

●

160

Outsourcing: you might have outsourced or be about to outsource and you want to make the roles of all parties clear and meaningful to the organization. Outsourced but still the same: this is actually quite a common reason – I have come across numerous organizations who have outsourced, but who do not seem to have reaped any material benefits from the exercise. Supply and demand confusion: again, I come across this in many organizations in which the internal suppliers of IT are also the demanders of IT. In this confusion, effort, motivation and performance is dissipated, until everyone knows they are working really hard, but aren’t sure what’s being achieved. In-sourced: a number of organizations have chosen to ‘insource’ their IT function – to ring-fence the supply of IT so that costs of IT supply are more visible, and focus on delivery is sharpened. The 3R model hones this focus, and drives the demand side of the in-sourced equation. Next level: I was asked by one large IT function what the ‘next level’ of corporate computing was. In fact this was the question that initiated the interviewing of so many CEOs and the development of the 3R model. They believed that they were delivering IT well, but in their constant search for improvement wanted to move to the next level. There’s something else: this is similar to the above, except that it’s not necessarily driven by a desire for improvement, so much as a feeling that there is something missing from the IT functional offering in the organization. Business person runs the IT function: I have come across this instance as well, in which an accountant or engineer has taken over the running of the IT function, and wants to know what needs to be done – keeping both business and IT priorities in mind.

To boldly go … ●

●

●

●

●

●

●

Alignment: some organizations may feel that there isn’t sufficient alignment between the business and IT strategies, objectives and activities. Some CEOs have known that their IT functions are travelling different paths to theirs and want to ensure that real alignment occurs. Alternatively, many CIOs I have met have felt that they and their departments are sidelined, and relegated to mere technologists where they know they can add more to the business. Strategy: an organization may be placing a singular strategic load on its IT function, but there doesn’t seem to be any time or resources available to get on with the strategic initiatives – rather, IT seems to be sinking between a deluge of technical minutiae that is choking its ability to deliver strategically, and creating a sense of letting great strategic opportunities slip away. Return on investment: businesses may be asking: ‘Why does IT cost so much, and why don’t I seem to be getting any returns?’ The 3R model approach drives us to consider the business returns on IT spend. It looks at IT spend over the entire life cycle of the spend (this isn’t just a TCO – total cost of ownership – argument; rather, it’s a portfolio view of IT over time). And the 3R approach requires us to look at everything through business eyes. IL imperatives: there may be a need to show leadership in the organization. Clarity and focus: there may be a need to clarify, both in the business mind and in the IT mind, just what it is that everyone is actually doing here. And whose role it is to do what within the organization. This may of course finally answer the question of ‘What do all those people do in IT?’ Business processes: there may be a need to become more focused on business processes – I have seen numerous costcutting exercises begin with a focus on processes – the 3R approach focuses both on IT processes and on business processes. Information content: one organization I dealt with needed to implement a knowledge management system – but they found that the ‘system’ was the least of their problems. Rather, they needed to focus on how the organization uses knowledge and information, and how its processes should change as a result of its knowledge. This was one of the more fascinating projects I have worked on, because armed with a staunch management commitment to do things differently, this organization was able to change itself through what it already knew about itself and its customers. 161

What Business Really Wants From IT

What will change? I know that I have dealt with this in general terms in Chapter 11. In general we can expect changes to: ● ● ● ● ●

mindset activities focus drive for benefits measures and reporting.

But now you have to ask the ‘so what?’ questions, and extrapolate your thinking into the impacts that these changes will bring about in your organization. If there is a mindset change – people start to see IT functions in three areas – whose minds are going to change and how? Will business people become more demanding, or protective of their turf? Will IT people gravitate towards the MBM role and treat the IBR and IL as someone else’s problem? Will your CEO be supportive, negative or neutral towards what is happening? Obviously each organization has a specific culture (‘the way we do things around here’) and you need to think through the mindset shifts that will occur. It’s worth an hour or so of effort. I sometimes find it useful to draw a force field of mindset shifts: ●

List all the positive and negative views of the change, and then putting positive comments on one side of a vertical line, and negative comments on the other. Then you rate them according to impact on a scale of one to five. This gives you a view of what mental pictures will change and how influential the different mental pictures will be. The most important part of this force field study is of course the list of actions that you develop to mitigate negative mindsets and to reinforce positive ones.

The most important change will of course be the activities of both IT and business people. I deal with this in the later sections of the implementation plan, specifically under ‘organization design’ and ‘strategies’. The focus of everyone’s attention changes under the 3R agenda. In Chapter 3 I discussed the difference between management and leadership as being POEM (plan, organize, execute and monitor) versus MAST (meaning, attention, self and trust). This is where the management of meaning and attention comes in. If the focus is to shift, what does it mean, and how will you direct 162

To boldly go …

people’s attention towards the correct focus and away from the incorrect focus? So you need to look at what focus will shift (people become more business focused and less technical, and, people become more management of supply rather than actually doing the supply, etc.). Then you need to assess the impacts of such shifts in focus. Finally you need to give some thought to how you will reinforce positive focus changes and discourage negative or old focus changes. The upcoming drive for business benefits underpins much of the 3R model change. You will need to think through how, having IT driving for benefits – developing up-front business cases and benefit statements, constantly referring back to benefits during development and implementation, developing plans and actions to work with the business to achieve the benefits, tracking and reporting costs and benefits over the life cycle of any system – will affect the way business relates to IT and vice versa. These can be imposing impacts. How will business people react to the new drive for benefits? Importantly, what will be the impacts on the organization of a comprehensive focus on benefits? (This is important because you will need to think through the question: ‘What are the benefits of focusing on benefits?’ – a little convoluted but necessary thinking.) In the same way as you look at the impacts and benefits of focusing on benefits, you will have to look at the consequences of measuring and reporting IT activities, costs and contributions more effectively. Again, you’ll need to look at the benefits of being more ‘measurement and reporting focused’. One of the new activities that should arise from this focus is to formalize the IT communication role to a much greater extent. Finally, you need to go through the ‘why’ part of your impacts analysis and look for what will change as a result of the ‘why’ impacts. Who will be affected? So who’s going to be affected by the change to a 3R agenda? Obviously the IT department will be affected, but I prefer to get a little more methodical about this. Firstly a generic list of who’s affected is as follows: ●

CEO and Exco: my experience of both the CEO and executive management committee stance on this kind of announcement is either a wild swing in expectations based on an ‘Aha, so this is how IT should perform and be managed’ kind of reaction, 163

What Business Really Wants From IT

●

●

●

●

or a more cautious ‘I’ll believe it when I see it’ reaction. Either way you’ll need to identify the reaction and manage the impact and expectations that arise: what decisions are required and how much support do you need? What will the CEO and Exco see as outcomes from this approach? Also, some organizations may need to include their board of directors in their thinking, and you’ll need to think through impacts at this level as well. Business management: this is where the track-shoe hits the tar. What will be the impact of the 3R model at a business management level? If you’ve done your force-field analysis under the mindset shift work, this should be relatively easy to assess. Business users: users are often forgotten as a significant stakeholder group. But what will the impacts be? IT people: probably the most affected group of people will be IT. Some serious impacts will be felt – performance, roles, activities, skills, you name it – a lot will change. Supply partners: it has been interesting to note how many suppliers of IT services and outsource partners treat the 3R model with some suspicion. Often because the 3R approach requires the supplier to perform according to their contracts and SLAs without offloading a fair bit of work back onto their clients. But usually after it’s explained, your IT suppliers see this as a positive development and one which allows them to get on with delivering the goods without constant ‘interference’ from their client. Many IT suppliers feel that their clients are unable to let go of the ball, and the 3R model clears up responsibilities nicely. Nevertheless there is a lot of work to be done in this area.

Your ‘who’ impact analysis shouldn’t stop at identifying the people affected. It should also assess how particular groups are affected, and what influence they will have on the change. Later in this chapter I talk about ‘syndication’ which will use the above stakeholder analysis to work out how and who you will need to communicate with and bring on board. When will we do it? So when are you going to get going? The obvious IT type question is the ‘big bang versus incremental’ one, and we’ll deal with this. But other questions such as timing related to budgeting cycles, strategic initiatives and urgency in making the change must be thought through. 164

To boldly go …

When discussing the urgency of change, I am often reminded of the aphorism that: Some organizations change only when their backs are to the wall, some change when they can see a wall coming, but very few say: ‘Wouldn’t this be a good place to build a wall?’

So where are you? Both as an organization and as an IT function? Again this relates back to the ‘why’ part of the impact analysis. When it comes to the question of big bang versus incremental, it does of course depend on the urgency of the change. I prefer incremental change, even running a pilot study of the change if possible. And in this regard you will need to look at the impact of the change as to the speed and timing required. Where will the effects be felt? The ‘where’ question depends on how your organization is structured, what geographical spread you enjoy and how split your supply is from your demand. Here is the time to get out your organization charts and, given all your previous analyses, map out where the most impact will be felt with respect to the change. Some areas of the business need not change at all. Indeed, I once worked with a company who decided that the major change should be a head-office one, and that the regional IT functions should be left well alone for the moment. Some organizations are spread across the globe, and in these situations we usually take the decision to move country by country, choosing the current country that is closest to the desired state, or most open to the required change. Finally with respect to where the change will occur, you need to look at how effectively your supply and demand functions currently are, because this will affect which parts of the organization or your supplier’s organization are affected. Who wins what? This is a rather cheesy way of getting to talk about benefits under a ‘w’ heading. Sorry about that. But the final part of an impacts analysis must, must, must be a benefits analysis. And obviously I’m not about to rewrite the 165

What Business Really Wants From IT

chapter on analysing benefits, but some words on extracting the benefits of the 3R approach are worth repeating: ●

●

●

●

You need to use the above impacts analysis to develop an up-front business case for adopting the approach. You will need a feedback and referral process to ensure that you are constantly driving towards the benefits during implementation of the 3R model. You need to develop a benefits realization plan for once the approach is implemented. You will need to track and report costs and benefits of the 3R programme.

Syndication So now you know why you’re doing what you want to do, what the impact will be and what the potential benefits are, it’s time to tell people. Step one is to identify the key stakeholders in IT’s performance: a stakeholder is any person or group of people who can affect the progress of an initiative, or who have the right to know what’s going on. If you’ve done your impact analysis correctly, you’ll have a good handle on who is affected by the change – these tend to be your stakeholders. The next step is to map the impact on these stakeholders as well as the influence that different stakeholders have within the organization. I like to use a little table which maps impact and influence (Figure 12.1).

Hi

IT staff IT management Users

Impact Business management Suppliers

Figure 12.1 Mapping the impact/ influence matrix for key stakeholders 166

CEO Exco

Lo Lo

Influence

Hi

To boldly go …

Obviously your mapping will be different, but the emphasis here is on influence. You will need to have those stakeholders of high influence give their buy-in to the process. Normally I start with those stakeholders in the top right of Figure 12.1. These people must actually be committed to making this thing work, not just giving their go-ahead, but actually becoming change agents for the process. Then you need to move to the bottom right quadrant, the group of stakeholders who need to give their support of the process. Their active involvement tends to be less essential, although they need to lend influential weight and sponsorship to the initiative. Then you need to move to the top left quadrant with a change management process. While fairly simplistic (and frankly out of fashion in academic terms) I quite like the first two steps of the Lewin model (1958) of change which is summarized as ‘unfreeze, move, freeze’ (I’m not sure you should freeze again – that just brings on the resistance to any other changes). Basically the thinking is that you need to create dissatisfaction with the current environment, then offer a way out of it. Creating dissatisfaction is a delicate task, because you’ve probably spent years trying to get people to work the way they are now. And here you are saying this is not good enough – there has to be a better way. This is why I have spent so much time on the impact analysis – now you need to put together some facts and figures to support your five ‘w’ impacts. As I have said previously, I believe that people do not fear change – rather, they fear loss. So this is why the benefits analysis becomes paramount, because if anyone has anything to lose, it’s the people in the top left quadrant of the table; those who are affected deeply by the change, but who have little influence over the change. I tend to communicate in a four step process of: awareness, information, commitment and operationalize. You need people to be aware that the current environment is not acceptable. Then you feed information – facts, figures, and benefits for moving to a new environment. Only then can you look for commitment – this is where the benefits statements and the impact analyses become important. Creating commitment tends to be a face-to-face affair as well. Only once this is done can you work on how the actual changes will work in the operational environment. Finally we move to the poor cousins – the bottom left quadrant – those without influence and frankly those who won’t be affected. But I have been surprised by stakeholders from this area, who we had ignored, but who it turned out came leaping out of the 167

What Business Really Wants From IT

woodwork with a resounding: ‘You can’t do that!’ Of course we could do it, and there was little they could do about it, but it does make good business sense to keep these people in the loop, to solicit their inputs and to communicate regularly to them. You will need to build a communication package for each of the stakeholder groups – with perhaps the high impact/high influence people being the least formal, and the low impact/high influence stakeholders being the most formal. And remember one of the New Year’s resolutions for the 3R agenda is to take communication more seriously. So here’s step one in meeting that resolution.

IT supply and demand The three role model does require that the IT function thinks and acts within the IT delivery framework. You will need to be clear on where your IT ‘supply’ comes from and what constitutes ‘demand’ within the organization. We’re not just talking about whether you have outsourced or not. I have conducted many exercises in companies who are wholly in-sourced, but in which the roles of the individuals and sections within the IT department are confused. One of the advantages of following a 3R agenda is that it clears up roles, mandates, and responsibilities. Furthermore it allows you to focus people’s activities and importantly to reward them for delivering in their specific performance area. To recap, the split between supply and demand is based on the different drivers and outcomes required from the different roles (Figure 12.2). Supply

Figure 12.2 Recap of supply and demand split

Efficiency Costs Availability Stability Security Optimization Outputs

Demand Effectiveness Requirements Meeting needs Usefulness Return on investment Improvement Outcomes

Both sides of the equation are equally important, and the real issue is to find the drivers and motivations for people in each role. I have found that most technical IT people gravitate 168

To boldly go …

naturally to the supply side, once clear on what the deliverables are, and how they go about delivering. It allows them to concentrate on the technologies, solving technical problems, creating robust systems, testing and implementing new technologies and so on. I remember when I was a young and inexperienced facilities manager, remarking to my boss that we would really be able to provide a great service if it wasn’t for the users. He frowned and said that if it wasn’t for the users, we wouldn’t actually have jobs of course. Which set me thinking: I had been concentrating on the technologies, making the services more efficient and robust, only to have ‘users’ demand changes and different services. And therein lies the quandary – because to have a truly stable and efficient IT service all you need to do is change nothing. However, the business world is constantly changing, and needs reciprocal changes in their IT systems. So the job of the demand side of the equation is to balance this business need for constant change with the supply side need for no change. And it is easier for technologists and operations people on the supply side to deal with demand side technologically aware business people than it is to deal with the business direct, who don’t understand why something can’t be done, or takes a lot of time, or costs a fortune. I won’t go into the supply/demand argument again, but it is important that you take every single IT process and activity, and those business activities that deal with IT, and clarify their purpose and positioning given the supply/demand equation.

In-source/outsource Many organizations have outsourced their IT supply, which makes the implementation of the 3R model easier – but even then you will still have to accommodate a new relationship or even a new mandate. I have helped a number of organizations work with their outsource suppliers to renegotiate their mandates and relationship given their new three role thinking. Interestingly very little of this work was to do with the service level agreements, and more to do with the execution of the work and the way in which people and organizations related to each other. And invariably there was a distrust between the outsource supplier and the client, or at least a deep cynicism about the relationship. Why? Because the relationships were often unclear, with the supplier complaining that the client was ‘keeping a dog but still doing all the barking’, while the client argued that the so-called partner was doing the bare minimum to get paid and 169

What Business Really Wants From IT

there was so much that they still had to do. Most of the issues are resolvable by having an honest discussion within the 3R framework. Those organizations that have not outsourced, or have outsourced portions of their IT supply, have a slightly more complex task ahead of them, in that they will usually specify four roles: IT supply, MBM, IBR and IL, with IT supply being a supply role and the other three roles being demand roles. In this instance the IT supply role is usually the larger in terms of staffing and so is not trivial or unimportant. Often the organizations I have worked with have appointed two people of equal seniority, one to head up the supply role and another to head up the three demand roles. Sometimes the IT supply head reports to the head of demand, or sometimes both report to someone in the business (usually the finance director). Having an IT supply function in-house means providing them with specific objectives and drivers, and consequently different performance criteria. Some organizations have ‘ring-fenced’ their IT supply in order to track all costs that cross the supply/demand line, others have treated them as a section within their IT department.

Organization changes Obviously all of the above is going to lead to organizational changes, either in splitting supply from demand, or if you are outsourced, in restructuring the IT department along MBM, IBR and IL lines. This does not necessarily mean that there will be separate departments for each of these demand roles, but in larger organizations this tends to be the pattern. There is of course a major skills and competence impact which needs to be accommodated, as all roles will have to take on new skills and competences according to the new expectations of them. Typically organization changes would use the following steps: ● ● ●

●

170

Understand the drivers behind each role. Develop broad objectives and measures for each role. Split broad objectives into jobs based on their span of control, impact on the organization etc. (You will have to use the services of an HR professional here.) Design the organizational structures (again with the help of HR). These structures should include lines of reporting and governance structures (spans of control, delegation of authority, forums and steering committees, processes of control etc.).

To boldly go … ● ●

●

●

●

Match jobs to people in the current organization. Map the competences and skills of current staff in the light of the new organization. Identify those people who do not fit the new roles and develop transfer, placement or even retrenchment plans for them. (I personally am strongly against retrenchment and would only regard it as the last resort, once all other avenues have been explored.) Identify where gaps exist in the organization and develop a plan to fill these. Often business people will be able to fill many of the new roles. Develop performance contracts for each of the jobs, and associated career paths.

The above list of steps is really just a starter, and you will need to involve a human resources professional from within your organization to ensure that you get it right, that you use the correct protocols and procedures and conduct the exercise within the organization’s guidelines and frameworks.

Strategy The newly actualized 3R model for how you intend to do IT into the future will require some strategic thinking to be done. I recommend that you do this thinking in broad terms before you make any announcements or reorganize any departments. One of the key reasons for this is that you want to set people off down the 3R road as soon as possible. If you make announcements and then get the new role-players together to say ‘What do we do now?’ you may lose momentum or credibility. This isn’t to say that you can’t include new incumbents; rather, that you should have 70 percent of the thinking done so that you can guide people appropriately. The IT strategy MUST derive from the business strategy. Take the business strategy and look at it in terms of the 3R model. Identify areas that you need to merely provide MBM inputs and list them. More importantly however are the new contributions that you can make with an IBR and IL mindset. Look at what the business is trying to do, and establish areas where you can effect business improvements given IT’s unique position within the organization. Also look at where IT can help the business develop new products, markets and competencies. Sometimes this exercise can take a few days and it’s always an eye-opener for the participants as to how much IT can align with business strategies and often, how little they have aligned to date. 171

What Business Really Wants From IT

You will then need to develop four strategic subsets of the IT strategy: the IT supply strategy, MBM strategies, IBR strategies and IL strategies. IT supply strategy Even if you’ve outsourced, you will need to work with your service provider to identify exactly what needs to be done to provide the services required by your organization. In this domain, you will need to look at necessary upgrades, continuity planning, where variances exist between actual IT supply and your expectations, look at performance against SLAs etc. MBM strategy The MBM strategy looks at what the business expects of IT in terms of meeting its ‘deliver IT without fuss’ mandate. This strategy takes a deliberate ‘demand’ view of the world: ‘What do we need from IT operations to maintain our business momentum?’ The strategy then translates these business expectations into service management expectations: ‘What services will we need, how will we get these services, how will we measure and manage them?’ and so on. You will need to look at your service provider, at their strategy and performance in relation to your requirements. You will also need to develop an MBM strategy for how you will manage IT assets (hardware, software and applications) and how you will track and report on their performance. The MBM strategy will also include a measurement and reporting strategy. You need to work out how you will get the correct measures together to track how effectively and efficiently IT is meeting business expectations. You will also need to understand the factors that go into making up your organization’s momentum line, and how you will track and report on the momentum line. Your reporting strategy will need to include an analysis of what gets reported to whom, and when. IBR strategy Firstly you will take the business strategy and identify areas where they are looking for improvement. Then you need to see how IT can add to that improvement. Finally there are areas that IT can provide improvement in, where the business is not particularly paying attention – this provides rich pickings for IT. 172

To boldly go …

I have asked numerous CIOs if they know of any systems which had been implemented recently, but which were not being used as intended or were being significantly underused. The answer is always affirmative. So if you set a target of just getting 20 percent better use out of the currently installed systems, you will improve business performance significantly. The strategy part comes in deciding which systems to target, how to go about the work, who to deal with in the business etc. Your IBR strategy will also have to include a business case strategy. If you don’t have one you will need to develop a business case template. You should identify an initiative in which you will pilot the business case according to the new template. And what about a business case review programme, in which you look at past implementations and review their business cases and develop action plans to achieve the benefits that were promised? Your IBR strategy will need to consider how you will identify and report on IT’s contribution to the organization. How will you calculate that contribution, and importantly how will you gain acceptance of its validity? What tracking process will you need to put in place to ensure ongoing IT contribution analysis and reporting? You will need a strategy to manage system life cycles (in this respect I consider ‘management’ to include the planning, organizing, execution and measurement of system life cycles). And you will need to consider on how you will budget given the 3R agenda and the tracking of the contribution – for the first time presenting the business with both sides of the equation. You will need a systems portfolio development and maintenance process, and will need to decide on whether you’ll have a programme management office to manage the portfolio of existing systems and systems in development. Your IBR strategy may wish to look at how you will capture and update business processes and how you will initiate process improvements. Many organizations include a knowledge management strategy within their IBR strategy detailing how they will ensure that information content is converted into action. But if you are to adopt the 3R model, you will also need to consider how you will convert your IBR role personnel in IT from librarians to information content readers. Will you work with business through some of the more important reports that IT produces? Will you introduce check digits or even an on-line scorecard to track 173

What Business Really Wants From IT

business performance? The information content strategy is not trivial – I know of several companies which have spent millions on business intelligence, developing a list of drivers of their strategies, identifying the measures needed to track performance against these drivers and then implementing the necessary systems to track these measures. Seldom has this initiative been started by IT, but it should be.

IL strategy We’ve dealt with strategic alignment in the first part of this section. However, you need to develop a mechanism that will ensure strategic alignment between the business strategy and IT’s strategy is meaningful – and dynamic. There is a strong business expectation that IT should track new technological trends and bring strategically important technologies to the table. What strategy do you have to put effect to this? If it’s just a question of you looking at trade magazines and attending seminars, the chances are you are falling woefully short of business expectations. You need a real strategy to ensure that technological developments are being tracked – usually outside research agencies will do this. But the next element of your technology trending strategy requires that you filter these technologies, through your organization’s strategic intents, through some sort of viability and maturity analysis, through a contribution/ possibility synthesis, and finally to the preparation of a position paper. A position paper presents to your organization the ‘position’ that you and they should be taking with respect to a particular technology. As you can see this is substantially different from you reading magazines and telling people about it. I have often been asked where IT architecture fits in the 3R model. And while my response tends to be that architecture crosses all roles depending on the level of architecture, I tend to think that the IL strategy is the breeding ground of all IT architectural thinking. So you’ll need to give some consideration of how architecture will start here and how it will flow into the rest of the three roles. General IT strategy So here is where you bring it all together strategically – you will combine your organizational strategy overview and how IT plans to contribute to each part of it. You will split your IT strategy into four strategic subsets based on the supply and demand side of the 3R model. 174

To boldly go …

But you will also need to do some strategic thinking in areas that cut across all the roles. You will need an IT marketing and communications strategy, a budgeting strategy, and a measures and reporting strategy which all address each of the roles. Do yourself a favour and visit your marketing people. Or look at their strategies for the company, and then model your thinking on their efforts. I’ve covered your budgeting strategy under IBR, but you need to make sure that all roles are catered for under the budget. And finally your measures and reporting strategy should likewise deal with all roles. And no good strategy can possibly be effective without being translated into action. So you will need to develop a high level action plan which details the required actions and objectives.

Putting the implementation plan together I usually follow the ‘roadmap’ route when developing an implementation plan. The first thing you need to do is identify the key action areas that need to be addressed. Then break these down into sets of actions which will synthesize together to achieve your objectives. Then you will look at dependencies – what needs to happen before a particular activity can happen. Finally, resources and timing needs to be brought into play. You are going to need to do this twice though, once for the IT side of the equation and once for the business which details IT milestones and business involvement. The implementation plan then, is a combination of all of the sections in this chapter, and I won’t repeat each section. All any plan is about is knowing in some detail what needs to be done, and developing a coherent way of getting it done.

175

13

In the beginning

IT has been alive and well in most businesses and organizations since the late 1960s or early 1970s. Before that IT tended to be something of an esoteric technology for use by universities and large government organizations. Throughout IT’s business history it has gone through a number of stages of contribution to the business world notably: the stage of automation, in which repetitive tasks were computerized; the stage of information, in which automated processes were used to provide improved ways of doing business; and the stage of transformation, in which information technology provides the foundation for doing business in a totally new way (Zuboff, 1988). Of course all three ‘stages’ still exist in many companies while some companies have yet to progress beyond stage one. And in spite of this thirty year history, a feature that doesn’t seem to have changed in many cases is the way in which IT sees its role within the organization or the way in which IT operates. They still think their role is to build and support the technologies for their business to use. A major turning point in IT’s relationship with their supporting organizations came as Birchall and Lyons (1995) identified in about the mid-1980s. This was when PCs started to gain general acceptance as a business tool and when business people started to source their information technologies directly from the supplier. In-house IT departments generally treated the PC as a desktop office automation device or as a glorified dumb terminal that maybe could think a little. What they didn’t seem to see was that their users were becoming more literate and more demanding and their expectations of the role of IT were changing. Then along comes the internet, a technology which is following the classical growth path of world-changing ideas, and according to this growth path a technology which is still in its infancy. 176

In the beginning

Yet IT often treat this development as somehow peripheral to their activities possibly seeing it as a glorified on-line business directory, not realizing that it will forever change business expectations of them. And while outsourcing is another idea whose time has come, it is interesting to note that outsourcing started in the early 1980s, failed and was written off (remember we called them bureaux?). And here they are back again, bigger, better, more mature and effective (and you can still expect the same from the internet). But outsourcing still has a way to go – why? – because IT’s view of how outsourcing should be applied, and how they should relate to outsourcers has not evolved appropriately. I believe that IT is at a crossroads: to continue straight is to see itself as a support role in the business world – building and running their systems for them, but believing that business people must do the business stuff. To turn left is to be wedged between advancing business competence in the IT domain and between aggressive outsourcers and solutions providers – to follow this road is to go downhill to insignificance and eventual disappearance. Or to take a bold turn to the right – to understand what business really wants from IT, and to meet that expectation by remodelling the way IT works and to challenge the role that IT plays in business. This is a business role, with a strong IT perspective. But this way leads uphill. This road is long and hard and beset with challenges and chasms. But how else will IT get to the top of their organizations? This could be the beginning or the end. Your choice.

177

Bibliography

Anthes, G. (1998) Learning how to share; Computerworld, Feb 1998, pp. 75–78. Beam, K. (ed.) (1994) Software engineering productivity and quality, IS Analyser, 32 (2). Bennis, W. (1993) Learning some basic truisms about leadership. In: The New Business Paradigm. G.P.O. Putnam & Sons. Birchall, D. and Lyons, L. (1995) Creating Tomorrow’s Organization. Pitman Publishing. Catalano, C. (1998) Look, listen, ask and respond. Computerworld Emmerce, March 9, 1998, pp. 6–7. Drucker, P.F. (1999) Management Challenges for the 21st Century. ButterworthHeinemann. Gartner Group (2000) Gartner Measurement Experience in SA. Gartner, Johannesburg. Gartner (2001) http://dijest.editthispage.com/discuss/msgReader$364. Gartner, (2002) CIO Agenda – Keep your balance – presentation. Gartner, Johannesburg. Grindley, K. (1991) Managing IT at Board Level. Pitman Publishing. Hamel, G. and Prahalad C.K. (1994) Competing for the Future. Harvard Business School Press. Handy, C. (1989) Age of Unreason. Random House. Handy, C. (1994) The Empty Raincoat. Arrow Business Books. Hattingh, B. (1993) Personal communication (Bryan is one of the leading IT people placement experts in South Africa). Imparato, N. and Harari, O. (1994) Jumping the Curve. Jossey-Bass. Kaplan, R.S. and Norton, D.P. (1996) The Balanced Scorecard, Translating Strategy into Action. Harvard Business School Press. Kitzis, E. (2002) In: Kaplan, S. and Prewitt, E. (eds), The future role of the CIO. CIO Magazine, March. Laudon, K.C. and Laudon, J.P. (1995) Information Systems – A Problem Solving Approach, 3rd edn. The Dryden Press, p. 402. Lewin, K. (1958) Group decisions and social change. In: Swanson, G.E., Newcomb, T.M. and Harley, E.L. (eds), Readings in Social Psychology. Holt, Rhinehart and Winston. Mintzberg, H. (1994) The Rise and Fall of Strategic Planning. Prentice-Hall. Moore, G. (1991) Crossing the Chasm; Marketing and selling Technology Products to Mainstream Customers. Capstone Publishing Limited. 178

Bibliography

O’Brien, James, A. (1999) Management Information Systems – Managing Information Technology in the Internetworked Enterprise, 4th edn. Irwin/McGraw-Hill. Pierce, G. (2003) Risk/benefit analyst, personal communication. Scalet, S. (2002) Get the credit you deserve. CIO Magazine, January. Taylor, D. (2002) A recent meeting of chief executives identified three IT issues above all others. Computer Weekly. June. Treacy, M. and Wiersema, F. (1996) The Discipline of Market Leaders. HarperCollins. Ward, J. and Griffiths, P. (1996) Strategic Planning for Information Systems, 2nd edn. Wiley. Whyte, D. (2003) Bringing your Soul to Work, Public Lecture, Johannesburg, 15th March (read also Crossing the Unknown Sea – Work and the Shaping of Identity, 2001, Penguin). Whyte, D. (2003) Bringing the soul to work, Public Lecture, Johannesburg, 3rd April. www.seriousplay.com LEGO, the knob and the brick configurations are trademarks of the LEGO Group, and SERIOUS PLAY is a trademark of Executive Discovery LLC. Zuboff, S. (1988) In the Age of the Smart Machine: The Future of Work and Power. Basic Books.

179

This page intentionally left blank

Index

Adding value, 10–11, 37 Alignment, 6–7, 37, 161 strategic, 173–5 American Airlines, 90 Asset management, 46–7 Attention, management of, 34, 85–7 Availability of IT, 42–4 Balanced scorecard process, 126, 134–8 Benefits, See IT benefits Bennis, Warren, 21, 33 Birchell, David, 41 Breakeven point, 67 Budget, See IT budget Business, 12–13 Business benefits, 154–5 See also IT benefits Business case development, 55–6 Business measures, 61–2 See also Measurement Business momentum, 15–16, 39–41, 116–17 supporting, 49 See also Maintain business momentum (MBM) role Business processes, 161 Business results, See Improve business results (IBR) role Business revolution, 6 Business trends, 82

CEO (Chief Executive Officer), 12 Challenging people, 88–9 Changes: focus, 35–6, 154–5 governance, 151–3 measurement and reporting, 155–6 organization, 159, 170–1 people, 157 playing the three role game, 156 See also Mindset changes CIO (Chief Information Officer), 10, 12 competencies, 13 See also Information leadership (IL) role Common agenda, 7 Communication, 32, 87 IT performance measures, 127–8, 138 IT reporting, 48, 155–6 need for, 9 Company, 12–13 Competitor monitoring, 82–3 Costs, See IT costs Customer, 12 Data, See Information content Decommissioning of old systems, 44–5 Delphi technique, 102, 103, 104 181

Index Demand management model, 30–1, 34–5 See also Supply and demand Downsizing, 10–11 Drucker, Peter, 5 Economic trends, 82 Efficiency of IT services, 45 External inputs: external focus competencies, 141 interpretation of, 77–83 suppliers, 81–3 technology scanning, 78–83 Federalism, 27 Functionality, 112–13 Goal creep, 96 Goal drift, 110–11 Good words gone bad, 10–11 Gore-Tex, 90 Governance, 151–3 Grindley, Kit, 48 Hamel, Gary, 88 Handy, Charles, 76–7 Harari, Oren, 37 Hygiene factors, 16, 17 Impact analysis, 158, 159–66 Imparato, Nicholas, 37 Implementation plan, 147, 158–9 impact analysis, 159–66 IT supply and demand, 168–70 organization changes, 170–1 strategy, 171–3 syndication, 166–8 Improve business results (IBR) role, 17–18, 32–3, 52–4, 151–4 achieving IT benefits, 58–61 budgeting for, 122–3 business case development, 55–8 business measures, 61–2 information content, 64–5 matching benefits to technologies, 109–11 measurement of, 131–3 portfolio management, 69–73 process management, 63–4 skills, 145–6 strategy, 172–3 182

systems life cycle, 65–9 unique perspective of IT people, 54–5 In-sourcing, 160, 169–70 Incremental growth plan, 43 Information content, 64–5, 161 Information leadership (IL) role, 18–23, 33–4, 75–7, 151–4 attracting attention, 85–7 budgeting for, 123–4 IL strategy, 173–5 increasing understanding, 87–8 interpretation of external inputs, 77–83 matching strategies, 83–5 measurement of, 133–4 new boundaries and challenges, 88–9 new products, 90–1 skills, 146–7 Information revolution, 5–6 IT, 12, 176–7 alignment with business, 6–7, 37, 161 availability and stability, 42–5 business involvement, 3, 24–7 communication needs, 9 expectations of, 1–4, 8, 24–7 mindset changes, 149 focus changes, 35–6 head office IT–unit IT relationships, 150–1 management of, 41–2 roles of, 10, 24–7, 30–1 See also Improve business results (IBR) role; Information leadership (IL) role; Maintain business momentum (MBM) role vision statements, 1–2 IT benefits, 18 achievement of, 58–60 benefits process, 99–113 benefit release, 112–13 identifying and quantifying benefits, 100–7, 132 matching benefits to technologies, 109–11 monitoring benefits, 111–12 benefits statement, 55–6, 59, 93–4 changes over time, 97–9 costs and, 67–8, 114–15

Index focus on business benefits, 154–5 management of, 45–6 types of, 108–9 IT budget, 116–20 for improve business results (IBR) role, 122–3 for information leadership (IL) role, 123–4 for maintain business momentum (MBM) role, 120–2 IT costs, 37 benefits and, 67–8, 114–15 changes over time, 65–7, 95–7 See also IT budget IT people, 8–10 changes, 157 competencies, 55 unique perspective of, 54–5 IT performance, 37–8, 48 measurement of, 36–7, 48, 87, 129–31, 155–6 IT applications, 129, 130–1 IT infrastructure, 129–30 See also Measurement IT reporting, 48, 155–6 IT Services Agenda, 50–1 IT supply skills, 142–3 See also Supply and demand KISS principle, 125 Language problems, 7 Leadership, 18–20, 33–4 See also Information leadership (IL) role Life cycle, See Systems development life cycle (SDLC) Lyons, Laurance, 41 Maintain business momentum (MBM) role, 16–17, 31–2, 41–2, 151–4 activities of MBM manager, 49–51 asset management, 46–7 budgeting for, 120–2 IT availability and stability, 42–5 IT benefits management, 45–6 mindset changes, 149–50 operations and efficiency, 45 performance, measurement and reporting, 48 skills, 144

strategy, 172 supporting business momentum, 49 Management, 33–4 Meaning, management of, 34 Measurement, 48, 125–6, 155–6 business measures, 61–2 communication of, 138 implementing measures, 134–8 improved business results, 131–3 IT benefits, 111 IT leadership, 133–4 IT performance, 36–7, 48, 87, 129–31 IT applications, 129, 130–1 IT infrastructure, 129–30 IT stability, 44 principles, 126–8 measures must be communicated, 127–8 measures must be linked to objectives, 126 measures must be understandable, 126–7 measures must have a reason, 128 Millipore Corporation, 90 Mindset changes, 148–51, 157 business expectation of IT, 149 head office IT–unit IT relationships, 150–1 maintaining business momentum (MBM) role, 149–50 mental model, 148–9 Mintzberg, Henry, 71 Momentum, 14–15 business momentum, 15–16 See also Maintain business momentum (MBM) role Moore, Geoffrey, 81 Multiple project management, 69–70 New products, 90–1 New skills, See Skills Occam’s Razor, 125 Operations, 45 Opportunity objectives, 79 Organization, 12–13 changes, 159, 170–1 Outcomes, 56, 100–1 Outputs, 56 Outsourcing, 24, 139, 142, 160, 169–70 183

Index Performance, See IT performance Portfolio management, 69–73 multiple projects, 69–70 portfolio tracking, 71–3 programme management, 70–1 Post-implementation review, 18, 59 Post-mortem, 59 Prahalad, C.K., 88 Process management, 63–4 Programme management, 70–1 Project risk types, 108 Quality, 10–11 Re-engineering, 10–11 Reluctant technologist, 75 Reporting, 48, 155–6 Return on investment, 163 Reverse delegation, 151 Risk types, 108 Roadmaps, 159 SABRE system, 90 Scope creep, 110–11 Self, management of, 34 Service charter, 49 Service level agreement (SLA), 49 Skills, 139–42 business skills, 140–1 external focus competencies, 141 improve business results (IBR) skills, 145–6 information leadership (IL) skills, 146–7 IT management skills, 140 IT supply skills, 142–3 maintain business momentum (MBM) skills, 144 technical skills, 140 Sponsor, 12 Stability of IT, 42–5 measures for, 44

184

Stakeholders, 76–7 syndication, 166–8 Strategic relevance, 19 Strategy, 20–1, 71, 83–4, 159, 171–3 alignment, 173–5 improve business results (IBR) strategy, 172–3 information leadership (IL) strategy, 173–5 IT supply, 172 maintain business momentum (MBM) strategy, 172 matching strategies, 83–5 Suppliers, 81–3 Supply and demand, 27–30, 159, 160, 168–70 IT supply strategy, 172 Supply role, 139 IT supply skills, 142–3 SWOT analysis, 87 Syndication, 158–9, 166–8 System roll-out plan, 43 Systems development life cycle (SDLC), 52–4, 65–9, 93–5 Technology scanning, 78–83 Thirty-second message, 80–1 Three role (3R) model, 30–1, 87 See also Improve business results (IBR) role; Information leadership (IL) role; Maintain business momentum (MBM) role Trust, management of, 34 Unnecessary activity, 85–6 User, 12 Value-add, 10–11, 37 Whyte, David, 86, 125 W.L. Gore, 90