30,99 €
STAYING THE COURSE AS A CIO: HOW TO OVERCOME THE TRIALS AND CHALLENGES OF IT LEADERSHIP
The shelf-life of a Chief Information Officer can be shockingly short. Few survive in post for more than a few years. More often each falls prey to insurmountable problems and their careers come to a sharp and ignominious end. In this book, a global CIO with over thirty years of experience in major corporations examines the main reasons why this happens. Readers will understand which types of issue can cause problems for an IT Leader and more importantly, they will learn strategies of how these problems can be minimized or even avoided.
IT is often seen a technical backwater, but it is a discipline which has the capability to add massive value to an organisation whether it is in the private or the public sector – provided of course it has the right leadership doing the right things.
Aspiring IT Leaders will need to deal with a common set of recurring trials and challenges. These include:
· Overcoming the challenge of managing diverse and conflicting stakeholders
· How to deal with large and complex projects
· Making sense of software and how to handle the rapidly changing technology landscape
· Knowing when to outsource and how to get the best out of an outsourcing partner
· Harnessing the intellectual power of consultants to help you meet your goals
· And last but not least, how to develop a set of strategies that are aligned with your corporate goals and then make sure your resources are properly targetted so that the IT function generates maximum positive impact for the enterprise.
For IT professionals looking to fully integrate their function into the enterprise, 'Staying the Course as a CIO’ is a valuable source of practical advice, all based on real experience.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 455
Veröffentlichungsjahr: 2014
Founded in 1807, John Wiley & Sons is the oldest independent publishing company in the United States. With offices in North America, Europe, Asia, and Australia, Wiley is globally committed to developing and marketing print and electronic products and services for our customers' professional and personal knowledge and understanding.
The Wiley CIO series provides information, tools, and insights to IT executives and managers. The products in this series cover a wide range of topics that supply strategic and implementation guidance on the latest technology trends, leadership, and emerging best practices.
Titles in the Wiley CIO series include:
The Agile Architecture Revolution: How Cloud Computing, REST-Based SOA, and Mobile Computing Are Changing Enterprise IT by Jason Bloomberg
Big Data, Big Analytics: Emerging Business Intelligence and Analytic Trends for Today's Businesses by Michael Minelli, Michele Chambers, and Ambiga Dhiraj
The Chief Information Officer's Body of Knowledge: People, Process, and Technology by Dean Lane
CIO Best Practices: Enabling Strategic Value with Information Technology (Second Edition) by Joe Stenzel, Randy Betancourt, Gary Cokins, Alyssa Farrell, Bill Flemming, Michael H. Hugos, Jonathan Hujsak, and Karl Schubert
The CIO Playbook: Strategies and Best Practices for IT Leaders to Deliver Value by Nicholas R. Colisto
Enterprise Performance Management Done Right: An Operating System for Your Organization by Ron Dimon
Executive's Guide to Virtual Worlds: How Avatars Are Transforming Your Business and Your Brand by Lonnie Benson
IT Leadership Manual: Roadmap to Becoming a Trusted Business Partner by Alan R. Guibord
Managing Electronic Records: Methods, Best Practices, and Technologies by Robert F. Smallwood
On Top of the Cloud: How CIOs Leverage New Technologies to Drive Change and Build Value Across the Enterprise by Hunter Muller
Straight to the Top: CIO Leadership in a Mobile, Social, and Cloud-based World (Second Edition) by Gregory S. Smith
Strategic IT: Best Practices for Managers and Executives by Arthur M. Langer and Lyle Yorks
Transforming IT Culture: How to Use Social Intelligence, Human Factors, and Collaboration to Create an IT Department That Outperforms by Frank Wander
Unleashing the Power of IT: Bringing People, Business, and Technology Together by Dan Roberts
The U.S. Technology Skills Gap: What Every Technology Executive Must Know to Save America's Future by Gary J. Beach
Architecting the Cloud: Design Decisions for Cloud Computing Service Models (SaaS, PaaS, and IaaS) by Michael Kavis
Staying the Course as a CIO: How to overcome the trials and challenges of IT Leadership by Jonathan Mitchell
Dr Jonathan M Mitchell
This edition first published 2015 © 2015 Jonathan Mitchell
Registered officeJohn Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom
For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please visit our website at www.wiley.com.
The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. It is sold on the understanding that the publisher is not engaged in rendering professional services and neither the publisher nor the author shall be liable for damages arising herefrom. If professional advice or other expert assistance is required, the services of a competent professional should be sought.
Library of Congress Cataloging-in-Publication DataMitchell, Jonathan M., 1961– Staying the course as a CIO : how to overcome the trials and challenges of IT leadership/ Dr. Jonathan M. Mitchell. pages cm.—(The Wiley CIO series) Includes bibliographical references and index. ISBN 978-1-118-96887-1 (hardback) 1. Chief information officers. 2. Information technology—Management. I. Title. HD30.2.M577 2015 658.4′038—dc23
2014025612
A catalogue record for this book is available from the British Library.
ISBN 978-1-118-96887-1 (hardback) ISBN 978-1-118-96884-0 (ebk) ISBN 978-1-118-96886-4 (ebk)
Cover image: © Jonathan Mitchell Cover design: Wiley
Introduction
Chapter 1: Dislocated Stakeholders
Wooden Poles with Holder
Because They're Worth It?
The Joys of Middle Management
The View from the Top of the Tree
Bored Boards
The Relationship Conundrum
Could I Have Something Impossible Please?
Notes
Chapter 2: Pathogenic Projects
IT Projects are Harder than Climbing Everest
Not Everyone Gets to be a Pharaoh
Don't Start Anything You Can't Finish
Stalinist Project Management
Being Nostradamus
My Piece of String is Skewed
The Gates of Wrath
Looking Up from the Pit
Notes
Chapter 3: Seriously Shaky Software
Software Just Doesn't Wo..
Being Immune to Tangerines
The Unfortunate Side-Effect of Moore's Law
Patched, Leaking and Lost in a Maze
The Wobbly Stack
Stabilising Shakiness
Chapter 4: Obsessive Outsourcing Compulsion
Outsourcing an Empire
Strains of Outsourcing Compulsion
Finance is not about Engineering Anything
Faster than a Speeding Bullet …
Everyone Needs to Win
In Summary
Chapter 5: Chronic Consultancy Syndrome
Consultants—The Hummingbirds of the IT Jungle
Spotting Hummingbirds in the Wild
An Expensive Dose of Aviary Assistance
What Consulting Isn't …?
But What Consulting Perhaps Should Be?
How Hummingbirds Turn into Cuckoos
And Finally
Notes
Chapter 6: Strategy Schizophrenia
Types of Strategy
Strategy Schizophrenia—Balancing the Unbalanceable
Summary
Note
Chapter 7: Bleeding Budgets
A Beginner's Guide to Building a Roulette Table
Putting Today and Tomorrow's Investments Together
Putting the Final Touches to the Roulette Table
Other Funding Profile Examples
Summary
Chapter 8: Epilogue—What Might Overcome You?
It's Always the Same Culprits, Except When it Isn't
Failure and Folklore
IT Leadership Morbidity Tables
The Unknown Unknowns
Acknowledgements
Bibliography
Index
End User License Agreement
Chapter 1
Figure 1.1 The CIO's Major Stakeholders
Figure 1.2 How to Win Friends and Influence People?
Figure 1.3 The Relationship between Management Span and Organisational Size
Figure 1.4 A Well-Connected IT Organisation
Figure 1.5 A Poorly Connected IT Organisation
Figure 1.6 The Much-used but Fundamentally Flawed IT Operating Model
Figure 1.7 How a Supplier Should See Things
Figure 1.8 How a Customer Should See Things
Figure 1.9 Heroic Failure and How to Accomplish it
Figure 1.10 Expectation Management—Keeping a Little Bit in the Tank
Chapter 2
Figure 2.1 The “Ungrouping Group-Think” Wizard
Figure 2.2 The Positively Skewed Distribution Curve
Figure 2.3 Percentiles and Probability: How to Guesstimate Accurately
Figure 2.4 Work Breakdown Structures
Figure 2.5 How to Create Private and Public Plan Estimates
Figure 2.6 Probing the Mysteries of Distribution Curve Shapes
Figure 2.7 The Rolls-Royce “Derwent” Gated Process
Chapter 3
Figure 3.1 A Simple Wobbly Stack of Corporate Software
Chapter 4
Figure 4.1 The Reason Why People Outsource
Figure 4.2 The Difficult Job of the Outsourcer
Figure 4.3 The Seductive Charms of Contract Accounting
Figure 4.4 Runaway Trains and Corporate Amnesia
Chapter 6
Figure 6.1 The Strategic Landscape
Figure 6.2 The Better Tomorrow Strategic Landscape
Figure 6.3 The Grand Plan Strategic Landscape
Figure 6.4 Strategic Approaches: Which to Use, When and by How Much?
Figure 6.5 The Conflicting Requirements of Stakeholders and the Consequences of not Dealing with Them
Chapter 7
Figure 7.1 IT Budget as a Percentage of Sales—the First Board Level Metric
Figure 7.2 Investment versus Operational Costs—the Second Main Board Metric
Figure 7.3 The Operational Boxes
Figure 7.4 The Third Incarnation of the Metric Model—Investment versus Operations
Figure 7.5 An Example of a Boston Consulting Growth Share Matrix, Showing the Success Sequence (Stern & Deimler, 2006)
Figure 7.6 Our Business as it is Today. Core Functions Together with Everything Else that Supports the Business
Figure 7.7 The Opportunities We Have to Change our Business Tomorrow
Figure 7.8 The Completed Investment Grid
Figure 7.9 The IT Budget Roulette Table
Figure 7.10 The “Before” and “After” State of our IT Function
Figure 7.11 The Support Organisation Profile
Figure 7.12 An Extremely Aggressive Strategic Investment Profile
Chapter 8
Figure 8.1 One View of the Relative Priorities of CIO Dangers
Cover
Table of Contents
Chapter 1
xi
xii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
Do you want to be a great IT leader? Why not? For those in corporate or public sector life, becoming a Chief Information Officer, a Senior Vice President or perhaps even a Chief Digital Officer in a large organisation is seen by many—quite rightly—to be the very pinnacle of achievement in the world of Information Technology. Today, an increasing number of IT leaders have become Board or Executive Team members in their companies. Almost all exert high levels of power and influence. However, the life expectancy of this corporate rainmaker is shockingly short. IT leaders often seem to enjoy a span no longer than a mayfly as they flutter away in the turbulent waters of the corporate pond. Few seem to stay the course for much longer than a couple of years and it is rare to find anyone making it to half of a decade or more. Some organisations even change their CIO every year. And most of the endings are not happy ones either. Very often something, or more commonly a whole bunch of somethings, goes horribly wrong and the reign of the noble IT leader comes to an abrupt and brutal end. In some cases the disaster takes the form of a slow-motion train wreck. With growing inevitability, it can be months before the inadvertent act of hara-kiri is finally completed and the inevitable mushroom cloud of dust and the smell of doom imperiously rise from the tangled mass of mangled locomotives, twisted rails and spilt cargo. More often however, the end is quicker and much more sinister. Whispered rumours around the water-cooler are shortly followed by a curiously empty executive office and a bland corporate announcement referencing “Special Projects” or some similar metaphor. It's all very sad. After all, the incumbent had probably spent twenty years or more of their life assiduously building their career and preparing for this great opportunity. Who would have thought it would end with little more than a cardboard box full of belongings, a tearful goodbye from their executive assistant and a lonely trip down the service elevator? The displaced IT leader will be wondering what happened and what, if anything, they could have or should have done. They will also believe that life in the IT industry is unfair, which of course is also true.
What this IT leader and many more before them may not have fully appreciated is that the IT industry is riddled with a bewildering arrangement of trials and challenges. Each of these horrors has been carefully designed by Mother Nature to cause you the maximum amount of pain, suffering and even career death. There are however, a few, sparse straws of hope onto which you can clutch. As you contemplate the vistas of vicissitude ahead of you, be aware that others have gone before and some have even stayed the course. The very few wise, battle-scarred warriors who have lived to tell their tale know that these same horrors appear again and again with relentless regularity. It doesn't matter which business or public sector organisation you work in. It doesn't even matter whether you are trying to run a relatively small IT function on a single site or a complex enterprise scattered across far distant geographies. Suffering is pandemic at least as far as leadership in IT is concerned.
In this book, we will examine some of the worst trials and challenges you might well run into on your quest to be a world-class IT leader. Some you may be able to side-step and we will look at various methods of fancy footwork you might employ. But unfortunately many will already have a firm missile lock and you will have to endure some pain as well as dealing with the aftermath. Only the most careful attention before, during and after the event will give you any chance of staving off disaster. A strong constitution is also required. I was once given an indispensable piece of advice by a wonderful lady aviator who taught me how to fly (few are immune from their mid-life crisis). “What should I do if things go wrong up there?” I asked. She broke into a broad smile, laughed and said. “Panic slowly of course”.
Dr Jonathan Mitchell Ashbourne Derbyshire UK
“Where is the ‘any’ key?”
(Homer Simpson, in response to the message, “Press any key”)
Stakeholders, as one of my colleagues once said to me, “should be tied to one”. He was definitely in the “Joan of Arc” school of stakeholder management. “It's all very good when they are feisty and swashbuckling,” he continued, “but when they start to get irritating, you should tie ’em to a pole and light a bonfire.” This approach has obvious attractions, but there are few people who can avoid the scourge of the irritating stakeholder whose mission in life is to make your life a misery. King Henry VIII, the sixteenth-century King of England, was one of the few heroes of history who was able to buck the trend. As most British schoolchildren will know, Old Henry had a penchant for doing his own thing. It was never a good idea to be his wife when he got bored (which happened at least five times it seems). Kings in olden days generally didn't have that many stakeholders to worry about especially if they had bags of charisma and a large, loyal army at their disposal. Henry therefore pushed the boundaries of his not inconsiderable power to the limits. During his reign he worked his way through six wives, as well as starting a war with France (which is something every good British monarch feels they have to do). He also created the Royal Navy (Loades, 2009) and is even thought by some to have written the quintessential English song Greensleeves (Trow, 2010). Henry was certainly a colourful and decisive monarch and he knew how to please a crowd. When he became King at the tender age of 17, one of the very first things he did was to order the execution of the two men his father had employed to collect heavy taxes from the fair folk of England. All but two people in the land thought that this was a great idea. He was also fond of hunting, gambling and dancing. It is said that he only spent an hour a day on government business (Spartacus Educational, 2013).
Perhaps Henry's biggest moment in history came when he decided to divorce his first wife, Catherine of Aragon. Popular culture suggests that Henry grew bored of Catherine. Knowing the response he'd get from Pope Clement (who wasn't much of a fan of divorces, especially when they involved Catholic Queens), he apparently decided that he would stick his fingers up at the Catholic Church and invent a whole new religion. This we now know today as protestant Anglicanism. While it is true that Henry was eventually excommunicated by the Pope, the divorce from Catherine was probably only one symptom of Henry's problems with his stakeholders (Weir, 2002). Henry was a fiercely independent chap by all accounts and his motives and methods were devious—at least when it came to finding ways that allowed him to operate in a completely unconstrained fashion. He was also thought to be a good Catholic, but Henry just couldn't live with the concept of an old guy with a beard in far-off Italy telling him what to do. Between 1532 and 1537, he instituted a number of statutes that dealt with the relationship between himself and the pope. For example, in 1534 he mandated that the clergy could only elect bishops nominated by him. For an encore he then declared that the King was the only “Supreme Head on Earth of the Church of England”. So there! All in all, Henry must have been a very fine megalomaniac even if he did over-eat a bit as he grew older.
We, unfortunately, do not have the freedom of action enjoyed by people such as good King Henry, or any other historical giants for that matter. We therefore need to understand the identity and motivations of the stakeholders who hold influence over all that we do (at least in the work place context). Tudor-style, summary execution is frowned upon today. This means that it is a relatively unlikely outcome if you do somehow become detached from your stakeholders. But be warned, there are plenty of other nefarious and deeply unpleasant methods of punishment available to people in corporate life today. Dislocation is painful and if you do not rapidly connect things back together properly, then they will become detached forever and it won't be long before someone decides to put the pieces in the air-lock so that they can be blasted out into space.
So who are our stakeholders and what do they want?
In its simplest sense, a stakeholder is a person, group or organisation that has interest or concern in an organisation (Business Dictionary, 2013). The days when people felt they needed to carry wooden poles around with them disappeared with the wizards of Middle Earth. Stakeholders also have nothing to do with vampires, though if you do unhappily have a vampire infestation on your hands, driving wooden sticks through the hearts of the un-dead while they sleep in their coffins is widely considered an effective pest control measure. These days life is much easier. Modern vampires tend to be good-looking teenagers with a conscience. It was never like that in Bela Lugosi's day.
“We don't vanquish vampires so don't call us stakeholders!”
Jackie Sadek
So while a few of our stakeholders may be brandishing wooden sticks, more often their weapon of choice is the pointed word. And you will find plenty of those out there—both words and people. There are of course, a wide range of different stakeholders who are affected by IT. In fact, pretty much everyone in the company, together with all your suppliers and customers, receive the delicate ministrations of your organisation in some form or other. Figure 1.1 shows some of the major stakeholders you will encounter. The strong arrows show the strong connections while the dotted arrows represent a looser stakeholder engagement. There may be some corporate outward-looking IT functions which have very intimate relations with customers and suppliers but for most of us, it is the Board of Directors and the leadership of the company, our beloved middle managers and the common or garden users who will demand most of the management time of an IT leader. We should look at each in turn.
Figure 1.1 The CIO's Major Stakeholders
Let us look first at our user community, or to use a better term—the workers. They are the most voluminous group of your stakeholders and they are comprised of real people doing real jobs. Workers are really cool people. They actually get to do stuff other than emails and meetings. On occasions, what they do get up to can even be useful to the company. It doesn't matter whether they are on the floor of a factory bending metal, or in an office creating what I believe is known these days as “intellectual property”; these people are precious and you have to look after them as best as you can. However, as far as a voice in IT is concerned, most of these folks will strictly be in the silent majority category.
“Every day I get up and look through the Forbes list of the richest people in America. If I'm not there, I go to work.”
Robert Orben
That said, the needs of the many are simple and straightforward—at least from their perspective. When I've spoken to computer users over the years about their requirements, the answers they give me are fairly consistent. I'm sure it will be the same for you. These good folk will want the latest models of phones and tablet computers and they will want to change them as frequently as they change their socks. They believe they cannot live without the most powerful laptops and personal computers known to man. They will also want to store infinite amounts of email in their inboxes and send and receive massive PowerPoint files that run into terrorbytes. They will demand full and unfettered access to the Internet, so that they can use whatever social media, home banking or any other e-commerce sites take their fancy. Some will want you to fund small pet projects because they naively believe that technology will make their working lives easier. Finally, everyone wants a helpdesk that is instantly answered by a beautiful, courteous person who has bucket loads of empathy to hand. Some may even want these people to solve their problems.
While such requests are easy to understand, responding to them sensitively can be tricky. Many IT leaders faced with the enormity of the task just throw up their hands and subscribe to the pleasing mantra “The only good user is a dead user”. The security needs of your network will of course, horribly constrain the things that you can do for them, but it is pointless explaining this to anyone. They won't understand and they won't care. Why should they? Your users will just see a computer that's much the same as the one they have at home, except that this machine is probably older and of course they can't change their wallpaper or replace the arrow cursor with a banana that peels itself. When people come to work, they will demand and expect all the freedoms they enjoy on their virus-laden, spyware-riddled, zombie-bot, home computers, smartphones and tablets. However, despite all the corporate problems, allowing “reasonable personal use” on company computers is a policy you should strongly consider championing. It is a winning (if sometimes painful) strategy. It is particularly helpful if you want to promote computer literacy amongst your workforce. There are of course always unexpected and sometimes unpleasant things that can happen when you give human beings a bit of freedom. Kings worked this out pretty early on, which is why they were so fond of the operating system we know as Feudalism. Basically, they got to be the Lords while the rest of us were “vassals” and had to do what we were told (Abdy, 2012). Back here in the twenty-first century corporate life is slightly more egalitarian. This new freedom allows any miscreants to get up to amazing things. I have seen some horror stories that would make Mary Shelley blush.
Some years ago I recall that we lost a complete night's worth of backups in a data centre I was managing. This was because a computer operator spent his entire shift downloading gigabytes of video files of his favourite soccer team—it was Manchester United as it turns out. The network was so overloaded that all the applications eventually timed themselves out and backed out of the rather important job of backing things up. Imagine people running all around the computer room like headless chickens. Meanwhile the operator in question, oblivious to the chaos he had caused, quietly sat in the corner of the office repeatedly watching videos of his favourite stars with spray tans and hair transplants kicking a ball and waving garish trophies around.
Then there was the time when we found an employee who clearly didn't like his job. He spent every single minute of every working day surfing the Internet. He usually started five minutes after he had clocked in and continued until he stopped for lunch. Forty-five minutes later he was at it again, only to finish five minutes before he clocked out. This went on for weeks on end. When we looked at the usage logs, we could even calculate how long it took for cups of coffee to pass through his system. Before you think “too much information”, let me reassure you that we could work it out quite simply from the breaks he had taken in between surfing sessions. It was about an hour and half if you are interested. The incandescent HR Director wanted to fire the individual. He was not amused by my suggestion that we put the employee's name forward for some kind of Guinness Book of World Records nomination. Clearly supervision and motivation had failed this person in abundance in his day job, but I certainly couldn't have surfed with anything like the dedication he showed. The individual's manager was the one who ended up with the biggest rocket however. He was told in no uncertain terms that from now on he was expected to harness the dogged conscientiousness of his loyal employees.
My all-time favourite “user howler of the century” story however, happened shortly after the 9/11 terrorist attack in New York. A Middle East-based employee, appalled by what he had seen, decided to send an email to every other employee in the company. He wanted to tell everyone that people in his part of the world condemned the terrorist action. His plan was to express solidarity with his colleagues in North and South America, Europe, Asia, Africa, Australasia and even a polar station in Antarctica. Normal controls within the network meant that our intrepid hero was not able to simply send an email to the 105,000 employees on the payroll at that time. Bulk emailing was both discouraged and curtailed by company policy. Nevertheless, undeterred by such a flimsy set of obstacles, our hero spent many, many hours and probably several days putting together a dazzling number of distribution lists. The size of each was carefully crafted so that it slipped just under the “number of recipients” restrictions that the computer administrators had put in place. The results were spectacular. Sending off his emails in batches, the disaster unfolded with delicious slowness. First, local servers became clogged, after which regional servers started to choke. Within a couple of hours network diagrams at Network High Command began to glow with angry tones of red. The “Clark Kents” at Network crisis control struggled into nearby telephone boxes to don their “Superman” outfits. In the command centre confused reports suggested that a virulent virus was spreading uncontrollably across the globe. Blizzards of sandy emails marched across North Africa scattering bloated, overfilled, groaning mailboxes before them. Even Field Marshal Rommel and his Afrika Korps would have been impressed as first Egypt and then Tunisia ground to a halt. It took several more hours of headless chicken antics before the panicky network team had calmed down enough to diagnose the problems in the Middle East region. Network traffic was eventually throttled back and re-routed via various improbable countries. The over-impressively large “world domination” screens covering the walls of the Crisis Command Centre began to turn amber and eventually, to everyone's relief, they settled to a soothing, verdant green. Later that day, most of the offending messages had been identified and a mass deletion process was underway. The countries initially affected found their computer systems disrupted for a few days, but the damage was, to be fair, fairly limited. It did take some time however, to persuade the authorities that we did not have another terrorist on our hands. Happily, our employee with a conscience was neither shot nor disciplined nor was he even sent to an American holiday camp on a Caribbean island. Everyone lived happily ever after, except perhaps the network manager, who I am told is responding well to medication.
All this goes to show that everything has its price. Indeed the price of electronic freedom can be very expensive for its custodians. But it is still nonetheless a recommended course of action for the avant-garde IT leader. You will be fine as long as you are the type of person who is not easily surprised by the wit and wisdom of man or woman.
If you consider the business applications that people use in their day-to-day jobs, however, the situation is not good. This is because the views and opinions of actual workers are rarely considered by their leadership when new computer applications are conceived, developed and introduced on their behalf. The average worker must have the patience of a saint when you consider what their senior colleagues have done for them. Many applications designed to help them do their jobs more efficiently don't generally help them one little bit. Indeed, the programs have probably been horribly customised by colluding tribes of middle managers and analysts aided and abetted by geeks from the IT department. The “cool” ideas of the geeks and a range of unsatisfactory committee-spawned, camel-like design compromises may render the application completely unusable. You don't have to look far in the trade press for lurid examples of new processes and systems which have caused untold misery to all concerned. Some shock, horror, noun-stack nightmares even make it to the national newspapers, such as the demise of the UK National Health Service project (Daily Mail - £12bn NHS computer system is scrapped, 2011). Some conspiracy theorists out there may even believe that programmers’ tool- kits come with all these handy features built-in (Figure 1.2).
“So much of what we call management consists in making it difficult for people to work.”
Peter F. Drucker
Figure 1.2 How to Win Friends and Influence People?
But there is some good news out there. There are some ways for you to calibrate yourself with the datum of reality in the work place. Some companies are really very good at it. A colleague of mine who worked for a large supermarket chain in Europe described to me a fantastic model that I would recommend to anyone. Each year, all the senior managers and executives of the company up to and including the Chief Executive are obliged to spend more than a week of their time carrying out relatively unskilled tasks in the company's retail outlets or distribution centres. Some even got to meet real customers. This laudable act was intended to keep the feet of the anointed firmly on the ground. It also gave the executives a chance to understand what working at the sharp end was really like. Finally it was a great morale booster for the checkout staff as they watched their hapless leaders struggle to weigh a pound of apples or puzzle over the pricing of a kumquat.
When my friend returned from his short sabbatical, I quizzed him on his experiences. First of all, I noticed that he was limping and he had a bandaged hand. “It's a lot more physical than you would expect”, was his response when he noticed me staring. “What did you learn?” I asked. He narrowed his eyes and looked at me threateningly. “Doors!” he cried, “I never realised how impossible doors can be.” I was taken aback. The only software package I had heard of that had “doors” in the name had nothing to do with retail warehousing. “Well” he continued, “the way that my people designed the warehouse systems means that anyone using it had to walk through at least three doors for every single transaction they did. That's how I damaged my hand. Someone was coming the other way at just the wrong time.” With rising emotion he continued. “When I get back to the office the very first thing I'm going to do is to remove all the doors in our warehouses and make a great big bonfire with them. Then I'll make the project team redesign their system from scratch. This time we will really make sure that things work smoothly and reliably. Finally, we'll put the implementation team to work in the warehouse in real life for a good few weeks. When they complain, we'll make them work a few weeks more. That'll teach them.” With a disturbing glint in his eye, he hurried off. It had definitely been a formative experience.
“Great Spirit, grant that I may not criticize my neighbour until I have walked a mile in his moccasins.”
Native American Prayer
On the other side of the coin, an example of how to do this “process thing” really well also occurred in a warehousing project. The particular warehouse in question was critical to the company as it shipped over £120m of material and spares each week. The project team had found out that there was an industry-leading package to do this type of work, but unlike everyone else in the industry they curiously decided to use the package as it was designed. After they had installed their un-customised software, they took over a small warehouse building where a simulation of the proposed system was built. Each process was developed and tested exhaustively. Many, many members of the real workforce were intimately involved throughout the whole exercise. When the team was satisfied that it would all work, they proceeded to the implementation phase. They then carried out three full dress rehearsals with real data before the system went live. The last of these involved complete and full parallel running of both the old and the new systems. This was done with production data from the full, burgeoning databases of dirty data that comprise “real life” usage. This approach meant that each transaction had to be carried out twice, once in each system. They had, of course, to roster two sets of shift teams (comprising hundreds of people in each) to adequately staff the expensive parallel operation.
When the system did go live, it was notable that performance metrics did not fall away as expected—in fact they improved. A few very minor glitches did appear in the days that followed (largely through data integrity issues), but the project team and the workforce swiftly dealt with each of them without undue impact. The parallel running regime meant that customers would not have been impacted anyway. In fact, the cunning inventory-building program that the Stalinist project manager had introduced in the preceding weeks to buffer the inevitable unexpected problems meant that he was well insulated from any transition glitches. The project team also stayed in place, watching as well as participating. After three weeks and one full business cycle of live use had passed, a number of improvements were identified together with one or two minor howlers that needed to be corrected. These were swiftly implemented, regression tested and released. The result was a happy workforce that was considerably more productive than they had previously been. Unlike most IT projects however, the celebrations only started once the new warehouse was stable and transacting at the higher volumes stated in the business plan, rather than when the code was “delivered”. The key point here is that it was the business outcome that was celebrated, not the IT project.
The outdated concept of projects being celebrated when they go live, rather than waiting until they have actually delivered benefit to the organisation is a nasty and dangerous practice. It should be consigned to a list of “bad things we promise we will not do any more”. Imagine a situation where a surgeon and his team down tools, whoop with joy, crack open the champagne and start celebrating a few moments after they'd cut out your tumour? Mercifully for us, they do bother to sew us back up again. They also continue to monitor us with professional aftercare to make sure the problem really has gone away. We really could do with a great deal more of that sort of TLC in the IT world. Any IT project teams who toss a lemon of a project over the fence onto the heads of the defenceless user community and run away deserve everything that they get. Having a warehouse door slammed in their face would be a good start.
Just who are the middle managers in an organisation? What do they do, where do they come from and why are there so many of them? Well, we could enjoyably argue about the definition until the end of time, especially if we let any middle managers join in the discussion. However, let's just for the purposes of this debate define them as people in the organisation who report to a manager, but also have managers working for them. In other words, they are not directly connected either to any real work that goes on, nor to the leadership who are making strategic decisions at the top. This insulation from reality means that these creatures can sometimes live in a strange and wondrous world of their own, where the skills of managing meaningless meetings and enduring endless emails have risen to the status of high art.
“Meetings are indispensable when you don't want to do anything.”
John Kenneth Galbraith
Much fun is poked at middle managers, and they are often parodied as being faintly ridiculous. However, they are creatures of nascent danger to any IT leader. This is not because they are bad people, but because they are managers. As managers, they will feel that they are able to make things happen, not only on their patch but elsewhere in the organisation as well.
Middle managers who use computers often feel that they have a right to both demand and get a shiny new software application to help them do their job. This “right of entitlement” is an unusual concept in corporate life that seems unique to IT. Managers certainly won't dare ask for new carpets or large office plants. The management grading system has taken care of that. Woe betide you if you are a grade 17 manager asking for some grade 19 foliage. But ask these people about computers and they will become deeply agitated about their urgent need for an expensive new departmental application that could cost millions. Managers will also fervently believe that their application must be grotesquely customised to meet their every whim. Whether you like it or not, most of the impetus for new IT investments in your company will come disproportionately from the middle management. My own personal record was to discover nearly 700 active IT projects in an organisation of only 40,000 people. With a project budget of a mere £20m, this meant that each project was spending £28,571.42 each year. It's hardly surprising that few were ever finished.
Q. “How can you tell the difference between a Middle Manager and a Senior Manager?”
A. “The Middle Manager always thinks he needs more resources and more people to get things done. The Senior Manager is just the opposite—he thinks he is expending too much resource with too many people.”
Anon.
Is this a bad thing? Well, it need not be so, but certain obstacles get in the way of having an effective middle management community living in a utopian harmony of peace and love with the IT organisation. Here are some of them.
As I've already suggested, there are often quite large numbers of middle managers in any large corporate organisation. This is because most companies base their operating models on pyramidal organisational structures. The structures are generated through work breakdown models, often based on function or geography. A company might break itself up into several divisions (such as R&D, Product Development, Sales and Marketing, Production & Distribution etc.). Each of these divisions can then be further broken down into smaller units. Sales and Marketing for example, could be divided geographically into regions (such as North America or Europe), and then subsequently decomposed further into country organisations and perhaps finally into sales territories. In this model, significant numbers of middle managers are created as the organisation unfolds layer by layer.
The upshot of all this is that if you are not careful, then you can end up with an alarming number of levels in an organisation. There may also be quite impressive numbers of people who are “managing” things rather than “doing” things. The average number of people who report to each of these supervisors dictates both the number of middle managers and the number of hierarchical layers in the company. Many organisations do not pay attention to this important detail. As a result they can quickly become overwhelmed with barbarian hordes of middle managers swarming around the halls and offices.
Figure 1.3 shows what happens if an organisation unfolds with reporting lines of 1:5, 1:8 and 1:11. In effect, each layer of the organisation will have 5, 8 or 11 people reporting to each manager at each level of the company.
Figure 1.3 The Relationship between Management Span and Organisational Size
If you compare the three models, you will notice that the 1:5 model requires seven levels of management structure to accommodate a mere 19,531 managers and staff. However, the same number of levels would support 299,593 people in the 1:8 ratio. But if you structure your organisation at 1:11, then a staggering 1,948,717 can be accommodated. The number of managers in an organisation is often an unintended side-effect of the reporting spans you choose. For example, even in a medium-sized company of 20,000 people, the spans make a huge difference. In the 1:5 model above, 3,906 managers are required to man such a company, whereas the 1:11 model will only deploy 1,464 supervisors. If it costs $80,000 to employ a manager, then the extra 2,442 managers required in the 1:5 span organisation will add nearly $200m of operating cost to the company. So if you ever wondered why management consultants are always banging on about layers, spans and flatter structures then this is the reason why. One organisation where I worked operated with an average management to staff ratio of 1:5½. Under cover of the 2008 recession, we ran a program which consultants would call “delayering” the company. We tasked each part of the organisation to make structural alterations to their reporting lines so that the management/staff ratio moved towards a target of 1:8. This had a startling impact. We found that we were able to remove nearly 2,500 managerial and clerical posts out of a white collar workforce of 19,800 without causing major disruption to the business. This saved more than £120m of annual operating costs. In comparison, to achieve £120m of profit, the company would have to sell nearly £1.5 billion of equipment and services (which was never going to be easy in the deepest recession in living memory).
“If sufficient number of management layers are superimposed on top of each other, it can be assured that disaster is not left to chance.”
Norman Augustine
Short organisational spans of five or less reports per manager lead to towering management structures comprised of many layers, populated by very large numbers of managers. Furthermore each manager will also have rather less responsibility and rather more time on their hands compared to their counterparts in flatter structures. Should you belong to such a low-span company, then you can probably look forward to a great deal of middle management attention. There is also likely to be heavy demand for lots of new computer systems. Now might be a good time to undertake a quick analysis of the structure of the company to identify the low-span zones. There's a very good chance that these are the areas where most of the pent-up demand for new projects, systems and services are coming from. Conversely, a line manager with fifteen reports is likely to be far too busy to be thinking about trivial things like IT. He or she will be focussed on the important job of keeping their head above the ever rising waters. However, should a heavily loaded manager ever get very passionate about wanting some electronic assistance then there is likely to be a very good reason for it.
“An overburdened, over-stretched executive is the best executive, because he or she doesn't have the time to meddle, to deal in trivia, to bother people.”
Jack Welch
Linkage is a major problem for any IT leader. This is often because many companies still fail to recognise that the most senior IT leader must be a fully paid up member of the top executive team to be effective. He or she is often buried in the management structure of other functions, such as Finance or heaven forbid, maybe even some kind of Shared Services function. This means that the linkage between the rest of the IT organisation and the business will also occur at correspondingly lower levels in the hierarchy. The whole question of the management of IT, unlike other disciplines, seems to have a curious optionality about it. No CEO in their right mind would leave their Finance Director buried several layers down in another function. However, they seem to think it is quite acceptable for this to happen to their IT leader. Some even believe that IT can be led by someone with no experience whatsoever in the discipline. There is also a curious penchant for relatively junior manager with a hobby interest in IT to end up as main points of engagement between business units and the IT function. People seem to end up in these positions irrespective of their seniority, their role or more importantly, their degree of common sense.
Figure 1.4 shows a notional organisation by level. The CEO sits astride the top of the chart, with the real workers at the bottom. The main area of responsibility of each role is identified, together with the types of things that these individuals will be worrying about in normal day-to-day business. The main interactions are represented by the thickness of the arrows.
Figure 1.4 A Well-Connected IT Organisation
In this example, the linkage is established at the top level. In other words, the IT leader is a bona fide member of the executive team. They have a direct reporting relationship with the CEO and the status to match. When the IT leader is seen as a proper member of the management team, it is much easier to generate an agenda where IT is an important enabler for the strategic plans of the company. The thickness of the arrows in the diagram above is very similar, indicating consistent interactions between the IT function and all levels of the organisation. Discussions between the CIO and the SVP of Sales for example, will all be about meaningful topics, such as how they can work together to improve global Sales and Marketing performance.
The second case, shown in Figure 1.5, is unfortunately much more common in our industry. The major links between the business units and the IT function are established at much lower levels in the hierarchy. In this model, the IT leader can also become completely detached from the main business leadership. This is a much more dangerous operating model. It often results in demands for large-scale tactical engagements which in turn spawn large numbers of small-scale projects. In this example, the leader of the Sales organisation does not interact with his IT counterpart, or anyone else in the IT function for that matter. Most of the exchanges are occurring between the UK Sales department and their own local IT support unit. It should come as no surprise, therefore, that any attempts to implement a sales automation system will almost certainly end up as a tactical, UK-centric system focused on capturing and analysing data at a country level. Nobody is talking about improving overall Sales and Marketing performance across the enterprise.
Figure 1.5 A Poorly Connected IT Organisation
The relative lack of interaction between the IT leader and his business counterpart is also very dangerous in other ways. It may for example, encourage the IT organisation to take on a more inward-looking emphasis. This might lead to a progressive lack of alignment and an increasing risk of dislocation from the leadership of the organisation.
To avoid such problems, it is essential that any IT leader achieves good quality interactions with the leaders in the business. He or she should operate an IT division that is well integrated at all levels. Without this, it will not be possible (or at least intensely difficult) to develop any kind of strategic agenda—at least one that will make any large and positive impact on the company. This is bad for IT but even worse for the company. Thoughtfully conceived, well-designed and skilfully executed IT projects enabling process change can automate and change the core business processes themselves to create enormous advantage to the corporation. But you do have to be the right person who is—critically—in the right place in the organisation.
IT leaders often fret about how they should support the company's leaders. Many believe these lofty folk are the most vexatious group to satisfy. Clearly, such interactions will be easier if the IT leader is a full and active member of the management team. Nonetheless the needs of the leadership are often very different to the rest of the user community and the wise IT leader should tread very carefully.
In terms of company leadership candidates, organisations are usually only interested in promoting those with experience, ability and a track record. It therefore takes quite a while for the ambitious Young Turks to climb to the top of the tree. This means that many company leaders today are Old Turks and have a degree of computer literacy that would probably cause a bunch of 16-year-olds to guffaw in disbelief into their social media networks. This is not the time to make ageist comments about baby boomers, but many of your leaders will be handicapped as far as modern technology is concerned. Most grew their careers in times when Information Technology played a much more peripheral role in industry than it does today. Many will favour traditional paper-based methods of communication control, often leaving email and other electronic wonders to their much younger assistants. I recall the first email I received from a CEO I worked for some years back. It simply said (in capital letters):
“PLEASE COME AND SEE ME NOW”
I scrambled straight up to his office expecting to get fired. Instead, the meeting was convivial. Our leader wanted to follow up on a piece of strategy work we had been discussing the previous week. When I asked the Boss why he shouted at me with his email, he just looked at me blankly. He thought I'd be pleased that I was chosen to be the recipient of his very first email.
