Just in case you all think it has gone rather quiet here after the recent flurry of action I should point out that I'm currently away on my V3 Manager's Bridge Course and looking forward to the prospect of becoming a v3 Expert. Well on paper at least. I'm glad to say my fellow course members seem equally realistic about what the course is actually giving them. It would be hugely unrealistic to expect the course to deliver expertise.
I'll blog more on the sate of ITIL training in the next few weeks. For now I'm off to take a mock exam.
Wednesday, 24 February 2010
Saturday, 20 February 2010
Brandon Lane CIO - Episode 2
Taking Stock
Episode 1
"It could be worse"
It seemed to newly appointed CIO Brandon Lane that he was the only person who knew how bad the news really was.
Only a couple of hours ago his deputy, Sally, had greeted the news of his sudden change of role with those same words, and now it was Yssabel, his wife, saying them.
"It will mean more money won't it, and a bigger team and budget to manage, and you like a challenge, you turned around the audit team"
It really was worrying that Yssabel and Sally appeared to be working from the same script. For a moment the thought crossed his mind that Hans might have briefed them both in advance. Only the fact that he knew they both equally detested Hans kept the thought at bay.
"It isn't the same at all as taking over the audit team. It was easy to get rid of the unqualified tick and turn auditors and bring in people who were already qualified or who really wanted the qualifications. All the team understand what we need to achieve and how to get there In IT all the teams hate each other. In IT nobody knows if anybody is really an expert or just making it up. For years Henry was considered untouchable because everyone thought he was the only person who knew how the PRISM system worked, then when it failed it turned out he didn't have a clue either."
Yssabel pouted. Brandon had to admit she was good at pouting.
"Anyway" she said, pointedly "You've got all those wonderful audit reports the sainted Sally has produced. Surely they must give you an idea of what needs to be done? You are always saying how wonderful they are"
"Well that is part of the problem. The excuse for getting rid of Jaques, apart from the slightly dubious files found on his laptop, is that he hasn't actioned any of the critical audit recommendations Sally has made in the last two years."
There was something about the way Yssabel snorted and dragged her heel across the floor that reminded Brandon of a bull about to charge.
"Oh well, that will be OK then. Sally can help you sort it out"
"Sally is going to be busy enough doing my old job, as well as her own.
"Oh, isn't that a shame."
Having made her point Yssabel softened.
"So go on then, what are you going to do? I know you well enough to know you've been thinking it through since the moment Hans told you, and you've probably had a plan in your head for the last two hours."
He smiled, and took the chance to pour himself a glass of wine. He would have slumped down in a comfortable chair but they were all occupied by the dogs, and he was feeling guilty about shouting at them when they'd jumped up to greet him coming through the door. That was the trouble with dogs. The poor things got shouted at because they happened to be there at the wrong time doing what they thought was the right thing to do. A bit like IT, he mused, everybody in IT thought they were an expert doing a great job and couldn't understand why no one else could see it. Very briefly he thought that the next few months might be easier had some one thought to have Dimitri 'done' before he'd developed his aggressive territorial habits.
"OK, yes, I have some ideas." He couldn't quite shake the image of Dimitri being taken to the vets, but he carried on.
"I need to get the balance right between telling them what they need to do, and them working it out for themselves. I need to shield the techies from the business, and the other way about as well. So I'm going to set up a proper service management team. There are a few things out there that might help. Sally builds all the computer audits around something called COBIT, but it isn't very sexy"
Brandon noticed Yssabel computing the spin to be put on his use of the of the words 'Sally' and 'sexy' in the same sentence even with negative connotations and decided against mentioning her again.
"There's something called ITIL as well. Gartner like it, and if Gartner like it Hans likes it. If Gartner and Hans like it I like it. So ITIL it is."
"So let me guess what you are going to do." Yssabel paused.
"First of all you are going to cook me a wonderful dinner, and then you are going to call in a team of consultants to tell you how to do ITIL in exactly the way you want them to do it."
Episode 1
"It could be worse"
It seemed to newly appointed CIO Brandon Lane that he was the only person who knew how bad the news really was.
Only a couple of hours ago his deputy, Sally, had greeted the news of his sudden change of role with those same words, and now it was Yssabel, his wife, saying them.
"It will mean more money won't it, and a bigger team and budget to manage, and you like a challenge, you turned around the audit team"
It really was worrying that Yssabel and Sally appeared to be working from the same script. For a moment the thought crossed his mind that Hans might have briefed them both in advance. Only the fact that he knew they both equally detested Hans kept the thought at bay.
"It isn't the same at all as taking over the audit team. It was easy to get rid of the unqualified tick and turn auditors and bring in people who were already qualified or who really wanted the qualifications. All the team understand what we need to achieve and how to get there In IT all the teams hate each other. In IT nobody knows if anybody is really an expert or just making it up. For years Henry was considered untouchable because everyone thought he was the only person who knew how the PRISM system worked, then when it failed it turned out he didn't have a clue either."
Yssabel pouted. Brandon had to admit she was good at pouting.
"Anyway" she said, pointedly "You've got all those wonderful audit reports the sainted Sally has produced. Surely they must give you an idea of what needs to be done? You are always saying how wonderful they are"
"Well that is part of the problem. The excuse for getting rid of Jaques, apart from the slightly dubious files found on his laptop, is that he hasn't actioned any of the critical audit recommendations Sally has made in the last two years."
There was something about the way Yssabel snorted and dragged her heel across the floor that reminded Brandon of a bull about to charge.
"Oh well, that will be OK then. Sally can help you sort it out"
"Sally is going to be busy enough doing my old job, as well as her own.
"Oh, isn't that a shame."
Having made her point Yssabel softened.
"So go on then, what are you going to do? I know you well enough to know you've been thinking it through since the moment Hans told you, and you've probably had a plan in your head for the last two hours."
He smiled, and took the chance to pour himself a glass of wine. He would have slumped down in a comfortable chair but they were all occupied by the dogs, and he was feeling guilty about shouting at them when they'd jumped up to greet him coming through the door. That was the trouble with dogs. The poor things got shouted at because they happened to be there at the wrong time doing what they thought was the right thing to do. A bit like IT, he mused, everybody in IT thought they were an expert doing a great job and couldn't understand why no one else could see it. Very briefly he thought that the next few months might be easier had some one thought to have Dimitri 'done' before he'd developed his aggressive territorial habits.
"OK, yes, I have some ideas." He couldn't quite shake the image of Dimitri being taken to the vets, but he carried on.
"I need to get the balance right between telling them what they need to do, and them working it out for themselves. I need to shield the techies from the business, and the other way about as well. So I'm going to set up a proper service management team. There are a few things out there that might help. Sally builds all the computer audits around something called COBIT, but it isn't very sexy"
Brandon noticed Yssabel computing the spin to be put on his use of the of the words 'Sally' and 'sexy' in the same sentence even with negative connotations and decided against mentioning her again.
"There's something called ITIL as well. Gartner like it, and if Gartner like it Hans likes it. If Gartner and Hans like it I like it. So ITIL it is."
"So let me guess what you are going to do." Yssabel paused.
"First of all you are going to cook me a wonderful dinner, and then you are going to call in a team of consultants to tell you how to do ITIL in exactly the way you want them to do it."
Thursday, 18 February 2010
CoreITSM 101: The Kano Model
Last week's lesson was that if you do not get the basics right it doesn't matter about anything or everything else.
That is an important lesson because many ITIL/ITSM programmes focus on the more exciting prospects when putting together a business case. Twelve months into the programme it can then look like a disaster because the deliverables don't match the promises - even though the programme has actually been a success.
To see why this is let us look at t a little bit of theory. In tune with the whole ethos of CoreITSM I'm going to try and keep this a simple as I can.
This is the Kano model.
You can go away and look it up at the end of this lesson, at which point you'll realise just how much I'm simplifying things. But for now I'm focussing on what is important. OK.
The Must Do Basics
Right, using the Kano model as a tool, think about the concept of basic requirements. That's the bottom curve. These are the things that if you aren't doing right the business are going to notice and complain about.
So start doing them right and everybody will live happily ever after!
Except that isn't the case because doing them right will not have a long term impact on your happiness, or, more importantly, that of your customers.
At the end of year one people will be telling you what a great job you've done getting request fulfilment down to an acceptable number of days. User and customer satisfaction might even go up a a few percentage points.
At the end of year two people will be "like, so what."
After all you are only delivering the service they always expected. Last year they noticed the improvement, but this year they won't notice you delivering the dull old specified service. Not only that, but even if you pull out all the stops, say you get a new user account down form 8 hours to 6 hours, does anyone care if 8 hours is good enough? And you'll have to pull out all the steps, because in year one you will have delivered all the quick wins....won't you?
So what do you do? Well you can move on to address another area of service where you aren't yet delivering the basics. That is always a smart move and there probably will be another basic area to move on to because the chances are high that the pain those long request fulfilment times were causing was masking the pain of something else you've not been doing right.
The Desired Performance
That straight line running straight through the middle of the graph is labelled performance. Start doing them better and the customer will be less unhappy, carry on doing them well and the benefit doesn't stop once you've met the customer expectation. Reducing year on year IT costs for instance, or better still enabling the business to reduce year on year costs. The first couple of years you manage to do it the customer will start to rethink their opinion of IT, the third and fourth years you do it IT will be held up as a shining example.
Excitement
Here is the good news. There are some things that, once you are delivering the specified service, put a broad smile on the customers face. There's more, these are things that if you aren't doing now the business won't ne that bothered about it. This is the top curve labelled excitement. Here is the bad news, and it is two parts. The first is that until you are delivering the basic service the business won't care how well you are doing in these areas. The second is that things that fall into this category can be hard to come by in the IT services world. This is real Apple territory.
What we might be able to do though, is hit a few points on this line. Winning an award for instance, or getting a senior manager an invite to be a key note speaker at a major industry event.Chose your moment to exploit these.
Indifference
There are aspects of a service that customers and users don't care about any way. Whether we do them or not neither pleases nor displeases them. Often in IT we make the mistake of thinking the customer cares about something when it is really only important to us. Establishing a CMDB? Who cares outside of IT? The business do care, of course, about the benefits that a CMDB can deliver, but often we mistake the means for the end, and then wonder why the customer doesn't find it a compelling business case. This is the region of indifference within the circle.
The Inverse
I really don't know how to break the news to you, but there are some things we do in IT that the business positively don't like! That's the line running from top left down to bottom right labelled inverse. Things like engineers turning up in sweaty clothes, or treating users as idiots. Just stop doing those things now.
So What Do We Do Now?
Go away and check which of the Kano categories the planned benefits of your ITSM programme fall into. The best way of doing this, of course, is to speak to your users and customers using a simple triple question approach:
1. If we fell short of the availability target would you be:
A. Happy
B. Neutral
C. Unhappy
2. If we met the availability target would you be:
A. Happy
B. Neutral
C. Unhappy
3. If we exceeded the availability target would you be
A. Happy
B. Neutral
C. Unhappy
If the answers are C, B and B than Availability is a Basic requirement of the service.
That is an important lesson because many ITIL/ITSM programmes focus on the more exciting prospects when putting together a business case. Twelve months into the programme it can then look like a disaster because the deliverables don't match the promises - even though the programme has actually been a success.
To see why this is let us look at t a little bit of theory. In tune with the whole ethos of CoreITSM I'm going to try and keep this a simple as I can.
This is the Kano model.
You can go away and look it up at the end of this lesson, at which point you'll realise just how much I'm simplifying things. But for now I'm focussing on what is important. OK.
The Must Do Basics
Right, using the Kano model as a tool, think about the concept of basic requirements. That's the bottom curve. These are the things that if you aren't doing right the business are going to notice and complain about.
So start doing them right and everybody will live happily ever after!
Except that isn't the case because doing them right will not have a long term impact on your happiness, or, more importantly, that of your customers.
At the end of year one people will be telling you what a great job you've done getting request fulfilment down to an acceptable number of days. User and customer satisfaction might even go up a a few percentage points.
At the end of year two people will be "like, so what."
After all you are only delivering the service they always expected. Last year they noticed the improvement, but this year they won't notice you delivering the dull old specified service. Not only that, but even if you pull out all the stops, say you get a new user account down form 8 hours to 6 hours, does anyone care if 8 hours is good enough? And you'll have to pull out all the steps, because in year one you will have delivered all the quick wins....won't you?
So what do you do? Well you can move on to address another area of service where you aren't yet delivering the basics. That is always a smart move and there probably will be another basic area to move on to because the chances are high that the pain those long request fulfilment times were causing was masking the pain of something else you've not been doing right.
The Desired Performance
That straight line running straight through the middle of the graph is labelled performance. Start doing them better and the customer will be less unhappy, carry on doing them well and the benefit doesn't stop once you've met the customer expectation. Reducing year on year IT costs for instance, or better still enabling the business to reduce year on year costs. The first couple of years you manage to do it the customer will start to rethink their opinion of IT, the third and fourth years you do it IT will be held up as a shining example.
Excitement
Here is the good news. There are some things that, once you are delivering the specified service, put a broad smile on the customers face. There's more, these are things that if you aren't doing now the business won't ne that bothered about it. This is the top curve labelled excitement. Here is the bad news, and it is two parts. The first is that until you are delivering the basic service the business won't care how well you are doing in these areas. The second is that things that fall into this category can be hard to come by in the IT services world. This is real Apple territory.
What we might be able to do though, is hit a few points on this line. Winning an award for instance, or getting a senior manager an invite to be a key note speaker at a major industry event.Chose your moment to exploit these.
Indifference
There are aspects of a service that customers and users don't care about any way. Whether we do them or not neither pleases nor displeases them. Often in IT we make the mistake of thinking the customer cares about something when it is really only important to us. Establishing a CMDB? Who cares outside of IT? The business do care, of course, about the benefits that a CMDB can deliver, but often we mistake the means for the end, and then wonder why the customer doesn't find it a compelling business case. This is the region of indifference within the circle.
The Inverse
I really don't know how to break the news to you, but there are some things we do in IT that the business positively don't like! That's the line running from top left down to bottom right labelled inverse. Things like engineers turning up in sweaty clothes, or treating users as idiots. Just stop doing those things now.
So What Do We Do Now?
Go away and check which of the Kano categories the planned benefits of your ITSM programme fall into. The best way of doing this, of course, is to speak to your users and customers using a simple triple question approach:
1. If we fell short of the availability target would you be:
A. Happy
B. Neutral
C. Unhappy
2. If we met the availability target would you be:
A. Happy
B. Neutral
C. Unhappy
3. If we exceeded the availability target would you be
A. Happy
B. Neutral
C. Unhappy
If the answers are C, B and B than Availability is a Basic requirement of the service.
Build your business case around an undestanding of what success will mean to the business, not what it means to IT.
Sunday, 14 February 2010
ISO 38500 Survey
I mentioned in a recent post that a survey was planned to look at ISO 38500.
Here it is
A survey is now open to 6th March to assess the market for ISO 38500 If you can, please identify that you came across the survey from this blog.
Here it is
A survey is now open to 6th March to assess the market for ISO 38500 If you can, please identify that you came across the survey from this blog.
Thick Skinned and Ugly
"Historians often hide from us the real path of history behind their errors, different opinions and false tales"
I have a good friend who is a doctor and a psychiatrist. She knows very little about the world of business which makes her observations on the world of management quite refreshing. To put it another way, she tends to see through the b******t and posturing. When we meet up it is usually to go to a lecture on one of the subjects we share an interest in, be it psychiatry, psychology, philosophy or pseudo-science.
Last year we got a last minute chance to hear Malcolm Gladwell speak.
It was, I guess from talking to others, a typical Malcolm Gladwell experience. An adoring audience. A wholly scripted speech that was so well rehearsed it appeared off the cuff, a gripping storyline and a lovely little moral. In this case "However well prepared you are don't be over confident because something might happen that will trip you up." It was a fun, entertaining and rather expensive fifty minutes. It was worth it though to get such a deep insight into the....no hold on this is where my friend looks at me and says "That was s**t" , despite the fact she has a mega crush on him.
The same story, the same facts about the Battle of Chancellorsville could be used to tell any number of other neat stories. You could even make a case that Hooker lost the battle because he wan't confident enough , not forgetting that you could cherry pick another battle to support another view.
Having heard the story what can I do with it? How should I change my behaviour to get any benefit from it? How do I reconcile it with other Gladwell anecdotes?
You have to hand it to Gladwell though, he speaks with confidence and whilst you are listening to him it all makes perfect sense. If you get the chance go and hear him speak.
Don't wait for a chance to go and hear the next speaker I want to talk about. Instead do everything in your power to go and hear him speak, and take as many people as you can along with you. In fact if you can arrange a speaking event for him.
Ben Goldacre is a doctor and a science journalist. He writes a science column for the Guardian newspaper, and in 2008 published the brilliant book Bad Science.
This genuinely is a book that if taken seriously could save lives. It attacks the self serving, scientifically unfounded and deliberately distorted thinking that prevents effective health care strategies from being delivered and leads to many deaths.
He is passionate about the need for evidence based medicine. You can hear him speak here about the importance of meta analysis
The Pictorial History of The Rhinoceros
For many years the best known drawing of the rhinoceros was a woodcut by Durer made in 1515. It was based on a description of a rhinoceros that lived, briefly, at Lisbon zoo. It was the last rhinoceros seen in Europe until the arrival of Clara in 1741 and throughout that period Durer's woodcut was considered the most authoritative depiction of a rhinoceros.
So it is a pity he gave it a horn on top of the withers, scaly legs and dragon like armour amongst other fanciful embellishments.
What seems likely is that Durer added his own interpretation of the description, and those following afterwards would not have noticed what his imagination added because it still appeared to match the description. It was armoured, and it did have two horns, for instance.
Not only that but a 1752 edition of a catalogue of Roman coins appears to depict a Roman rhinoceros looking just like Durer's. So did Durer's embellishments come from knowing what the Roman's thought rhinos looked like, or was the authority of Durer's drawing such that it influenced the person drawing the Roman coin to see details that were not there?
Why did Durer's drawing endure? Perhaps for no better reason that that people found this image of the rhinoceros attractive and it resembled what they wanted a rhinoceros to look like.
The Dangers of Second-hand Knowledge
If we hear an attractive story from someone like Gladwell, or are shown a compelling picture like Durer's woodcut we are inclined to believe it and loath to let go of it. In the ITSM world there are people who never bother to ask if the story is true, if the conclusion is sound, or if the diagram makes sense. Then they go and repeat the story and copy the diagram and tell everybody who will listen, and some who won't, that "This is the truth about ITSM"
How do they know it is the truth? They read it on a PowerPoint slide.
Rather like the strange link between the woodcut and the coin you sometimes even have a distorted version of your own ideas and diagrams ,that you'd discarded as dated ten years ago, placed in front of you, quite innocently, as somebody else's original new great idea.
We love to have complex realities reduced to simple stories, but that doesn't make those stories either true, or useful.
And here I confess that the quote with which I started this post is extremely second hand. It comes not from some revisionist historian late in the last century, but from Sebastiano Errizo writing in 1559.
For that quote, and more on the story of Durer's Rhino, I am indebted to and recommend The Rhinoceros of The Pope
Thursday, 11 February 2010
Brandon Lane CIO - Episode 1
The New Job
Brandon Lane sat back in his chair and closed his eyes before speaking.
"Sally, it is a great report. I wouldn't say it outside of this room because I have a great department all round, but your computer audit team rocks."
Sally smiled. She'd worked with Brandon too long as her CIA to know that there wasn't a 'but' coming along the rail road track towards her with the head light on and the brakes screeching.
"But how can I sell this to the board?"
He smiled at her, and waited. They both knew he had asked the question knowing she had already thought about the answer. She waited a few seconds before answering
"I know. It is only a week since the gateway review gave the CoproLITE project the OK, and the CFO is on the steering committee."
He opened his eyes and moved forward, resting his chin on his hands. He didn't say anything, but his body language made it clear he expected her to continue.
"So how can we publish an audit report that says the project looks doomed to fail? Maybe we can still make it work. It isn't like Dimitri doesn't know what we've said in it. My team have tried to keep him on board from day one."
Dimitri was the Head of Development. Neither Sally nor Brandon under estimated him. He was a clever guy. Rather, as Brandon would put it when he knew it would never get back to Dimitri, he was a clever guy surrounded by idiots, but he wouldn't admit it. That is Dimitri wouldn't admit he was surrounded by idiots. He was very good at telling people how clever he was.
"I know, and for once I don't blame him. Everyone is to blame. If only Jacques had knocked a few heads together..."
Sally finished the sentence for him.
"...but that isn't Jaques' style."
Brandon sighed, as an auditor it was something he did a lot of.
"How did he get to be CIO? What does he actually do? Was it you who told me that in the mornings he sneaks in to his office trying to avoid anyone talking to him? I like the guy, but..."
Brandon's phone rang. He went very quiet and very serious before saying
"That was the top floor. I'll be right back. Don't go away."
As he left his corner office and walked through his team's space he couldn't help feeling a glow of pride. In four years he had turned the Internal Audit department around. Now it was staffed by professionally trained auditors whose audits reports were driven by business imperatives. The jewel in his crown was Sally's computer audit team.
Taking the elevator up to the 11th floor he was expecting the other Cs, the "Real Cs" as Ysabelle, his wife called them, to have got wind of the CoproLITE report. It didn't make for pretty reading, and it didn't take any prisoners. Despite his regard for Sally he was still thinking about how he could water it down to make it acceptable.
Brandon and Hans, the CEO, had history. It wasn't good. It was the sort of history Harold and William the Conqueror had. It is fair to say they didn't see eye to eye.
So it wasn't a surprise when Hans threw the Coprolite report at him as he walked through the door. Fortunately Brandon had instinctively ducked.
What was a surprise was Hans telling him that Jaques had been escorted from the building ten minutes earlier, and they now had a new CIO.
Back in his office on the 7th floor Brandon broke the news to Sally.
"Can I be the first to congratulate the new, and I hope, in the nicest possible way, acting, Chief Internal Auditor on her new appointment?"
Sally's jaw dropped.
"They haven't sacked you have they?"
"No, it is much worse than that.
They've made me CIO."
....to be continued.
Brandon Lane sat back in his chair and closed his eyes before speaking.
"Sally, it is a great report. I wouldn't say it outside of this room because I have a great department all round, but your computer audit team rocks."
Sally smiled. She'd worked with Brandon too long as her CIA to know that there wasn't a 'but' coming along the rail road track towards her with the head light on and the brakes screeching.
"But how can I sell this to the board?"
He smiled at her, and waited. They both knew he had asked the question knowing she had already thought about the answer. She waited a few seconds before answering
"I know. It is only a week since the gateway review gave the CoproLITE project the OK, and the CFO is on the steering committee."
He opened his eyes and moved forward, resting his chin on his hands. He didn't say anything, but his body language made it clear he expected her to continue.
"So how can we publish an audit report that says the project looks doomed to fail? Maybe we can still make it work. It isn't like Dimitri doesn't know what we've said in it. My team have tried to keep him on board from day one."
Dimitri was the Head of Development. Neither Sally nor Brandon under estimated him. He was a clever guy. Rather, as Brandon would put it when he knew it would never get back to Dimitri, he was a clever guy surrounded by idiots, but he wouldn't admit it. That is Dimitri wouldn't admit he was surrounded by idiots. He was very good at telling people how clever he was.
"I know, and for once I don't blame him. Everyone is to blame. If only Jacques had knocked a few heads together..."
Sally finished the sentence for him.
"...but that isn't Jaques' style."
Brandon sighed, as an auditor it was something he did a lot of.
"How did he get to be CIO? What does he actually do? Was it you who told me that in the mornings he sneaks in to his office trying to avoid anyone talking to him? I like the guy, but..."
Brandon's phone rang. He went very quiet and very serious before saying
"That was the top floor. I'll be right back. Don't go away."
As he left his corner office and walked through his team's space he couldn't help feeling a glow of pride. In four years he had turned the Internal Audit department around. Now it was staffed by professionally trained auditors whose audits reports were driven by business imperatives. The jewel in his crown was Sally's computer audit team.
Taking the elevator up to the 11th floor he was expecting the other Cs, the "Real Cs" as Ysabelle, his wife called them, to have got wind of the CoproLITE report. It didn't make for pretty reading, and it didn't take any prisoners. Despite his regard for Sally he was still thinking about how he could water it down to make it acceptable.
Brandon and Hans, the CEO, had history. It wasn't good. It was the sort of history Harold and William the Conqueror had. It is fair to say they didn't see eye to eye.
So it wasn't a surprise when Hans threw the Coprolite report at him as he walked through the door. Fortunately Brandon had instinctively ducked.
What was a surprise was Hans telling him that Jaques had been escorted from the building ten minutes earlier, and they now had a new CIO.
Back in his office on the 7th floor Brandon broke the news to Sally.
"Can I be the first to congratulate the new, and I hope, in the nicest possible way, acting, Chief Internal Auditor on her new appointment?"
Sally's jaw dropped.
"They haven't sacked you have they?"
"No, it is much worse than that.
They've made me CIO."
....to be continued.
Tuesday, 9 February 2010
An Aviation Variation
A few days ago I posted about how a Le Mans racing team copes with a wheel falling off.
Here is a variation from the world of aviation with a surprising twist.
The landing gear on many airliners is unsafe for landing on soft grass in an emergency because it DOESN'T break
New Scientist blog
Whilst we are talking about aircraft there is a gem of an idea buried halfway down this article, along with a link to a great video of a 777 landing in a crosswind.
Test pilots don't just check what happens if something breaks - they also check what happens if something breaks and the pilot does the wrong thing in response!
You know, the way we check what happens if a dual power supply fails and the engineer takes out the wrong one to repair and then design a procedure to stop it happening for real.
Here is a variation from the world of aviation with a surprising twist.
The landing gear on many airliners is unsafe for landing on soft grass in an emergency because it DOESN'T break
New Scientist blog
Whilst we are talking about aircraft there is a gem of an idea buried halfway down this article, along with a link to a great video of a 777 landing in a crosswind.
Test pilots don't just check what happens if something breaks - they also check what happens if something breaks and the pilot does the wrong thing in response!
You know, the way we check what happens if a dual power supply fails and the engineer takes out the wrong one to repair and then design a procedure to stop it happening for real.
CoreITSM 101: The Basics
How have we managed to turn something so essentially simple as ITSM into a multi million pound industry?
Why have we over complicated it, and in doing so lost sight of the basic truths that lie at the core of it?
There was a spoof chat show on British TV, the Mrs Merton Show. Think of it as a low key predecessor of Ali G. The most famous moment in the show's history was when "Mrs Merton" asked Debbie McGee, wife of an ageing but famous British TV magician "What first attracted you to the millionaire Paul Daniels?"
So what has made us turn ITSM into a multi million pound industry? Hmm, perhaps it could be we all want a share of those millions. Heck I can't complain, it has provided me with a decent living for years. After all the market is never wrong, is it?
Don't you lie awake at night, though, thinking that you are missing something simple and obvious? Don't you occasionally cut yourself when shaving because you've been distracted by the thought that giving your ITIL project a punning name is not enough to make it successful? Oh and trust me on this, all the good names were used a long time ago, and if you think it is funny, it probably isn't.
Worry no more, though. Over the next few weeks I'll be blogging on some of those basics that we so easily overlook.
Today's Lesson - Why We Have a Job
Here is an extreme example, but unfortunately true, of how out of touch IT staff can be. I was running a workshop at short notice for a client. They were a small UK government agency with a clear remit and a reasonably high profile. The sort of agency you will find mentioned in a newspaper story on a regular basis. This is a consultant's dream because before you even walk through the door you can learn an awful lot about the client's culture, what they want to achieve and all that good stuff.
On this occasion it was just as well I'd done my homework because it soon became apparent that the IT team had no idea at all about what their users did for a living. We are talking being unable to name their Chief Executive, or being unable to pick out their mission statement from a list on a slide. It was a short list, it was the only one on it.
Why was I running the workshop? They were being threatened with being outsourced and wanted help to defend their position. What did they think their greatest strength was compared to the wolves at the door?
Give yourself five bonus CoreITSM CPE credits if you guessed that they thought it was their knowledge of their own organisation.
Simples, huh!
Now before you give yourself another pat on the back, and for double or nothing points, what lesson do you think I'm going to draw from this?
I'm going to tell you how important it is to think about yourself as part of the business, right? I'm going to tell you to forget about Business IT Alignment (BITA) because that is so yesterday compared to actually being an indivisible part of the business, right?
Can you hear that sound? That is the sound of those five bonus CPE points flying back into my pocket. Better luck next time.
Here is the lesson.
Had those guys had the nous to listen to their users, and discussed with their boss what the users' bosses were saying, they would have found out that their understanding of the business was not the issue. In fact the customer knew full well that because of European employment law they would probably be stuck with the same staff regardless of who won the contract.
The two things that mattered to the business were:
*Since this is a CoreITSM course, not an ITIL v3 one this translates as "it does what it should do"
Why have we over complicated it, and in doing so lost sight of the basic truths that lie at the core of it?
There was a spoof chat show on British TV, the Mrs Merton Show. Think of it as a low key predecessor of Ali G. The most famous moment in the show's history was when "Mrs Merton" asked Debbie McGee, wife of an ageing but famous British TV magician "What first attracted you to the millionaire Paul Daniels?"
So what has made us turn ITSM into a multi million pound industry? Hmm, perhaps it could be we all want a share of those millions. Heck I can't complain, it has provided me with a decent living for years. After all the market is never wrong, is it?
Don't you lie awake at night, though, thinking that you are missing something simple and obvious? Don't you occasionally cut yourself when shaving because you've been distracted by the thought that giving your ITIL project a punning name is not enough to make it successful? Oh and trust me on this, all the good names were used a long time ago, and if you think it is funny, it probably isn't.
Worry no more, though. Over the next few weeks I'll be blogging on some of those basics that we so easily overlook.
Today's Lesson - Why We Have a Job
Here is an extreme example, but unfortunately true, of how out of touch IT staff can be. I was running a workshop at short notice for a client. They were a small UK government agency with a clear remit and a reasonably high profile. The sort of agency you will find mentioned in a newspaper story on a regular basis. This is a consultant's dream because before you even walk through the door you can learn an awful lot about the client's culture, what they want to achieve and all that good stuff.
On this occasion it was just as well I'd done my homework because it soon became apparent that the IT team had no idea at all about what their users did for a living. We are talking being unable to name their Chief Executive, or being unable to pick out their mission statement from a list on a slide. It was a short list, it was the only one on it.
Why was I running the workshop? They were being threatened with being outsourced and wanted help to defend their position. What did they think their greatest strength was compared to the wolves at the door?
Give yourself five bonus CoreITSM CPE credits if you guessed that they thought it was their knowledge of their own organisation.
Simples, huh!
Now before you give yourself another pat on the back, and for double or nothing points, what lesson do you think I'm going to draw from this?
I'm going to tell you how important it is to think about yourself as part of the business, right? I'm going to tell you to forget about Business IT Alignment (BITA) because that is so yesterday compared to actually being an indivisible part of the business, right?
Can you hear that sound? That is the sound of those five bonus CPE points flying back into my pocket. Better luck next time.
Here is the lesson.
Had those guys had the nous to listen to their users, and discussed with their boss what the users' bosses were saying, they would have found out that their understanding of the business was not the issue. In fact the customer knew full well that because of European employment law they would probably be stuck with the same staff regardless of who won the contract.
The two things that mattered to the business were:
- They got an IT service that actually worked
- They got Value for Money (VfM)
You didn't need to understand what the agency did to know that fifteen days to process a new user request was unacceptable, or that every time a major upgrade failed senior management despaired. You didn't need to know about the business to understand that they were fed up of every IT project getting the costs wrong and asking for more money.
Having an ITIL v3 Service Strategy would not have kept that IT department in house. Sorry to break that news to you.
What the business needed was for IT to get the basics right
Controversial?
Possibly so, but with a move towards SaaS and cloud computing who actually cares what your IT provider knows about your business? The majority of IT should be a commodity service, just like the electricity supply and the telephone system. That is where we are headed. I'll talk about the value added in a later post.
You know I feel uncomfortable about taking those points away from you. I would love to say getting close to the customer and user is really really vital. If nothing else if they had been close to the business that IT department would have known that basic utility* and warranty* was what was important, and would have understood that their "delivery wasn't good enough."
So you can have the points back if you can correctly identify what film and musical stage show that last quote is from.
So you can have the points back if you can correctly identify what film and musical stage show that last quote is from.
Homework
The next two posts in this series will build on this one by looking at the Kano model to assess ITSM maturity, and defining the basic requirements for a service desk in a contract. Look out for them over the next couple of weeks.
*Since this is a CoreITSM course, not an ITIL v3 one this translates as "it does what it should do"
Monday, 8 February 2010
You Couldn't Make it Up....
...OK, I guess you could, and the ITskeptic did.
You can get it from Lulu as well.
One of Rob's most ridiculously funny conceits was the vanity driven membership schemes BAPTISM and EgoITSM "especallly suited to those too tight or disreputable for BAPITSM."
And now we have prISM.
I guess Rob wasn't so far from the truth after all. Funny that.
Is ITIL a Cargo Cult?
The Halo Effect
One of the must read management books on my list of all time greats is Phil Rosenzweig's 'The Halo Effect'
In some ways you could describe it as an anti-management book in that it debunks the claims made by most of the best selling management books to know the secrets of long term management success. "Good to Great" is still a wonderful inspiring read, but have you ever asked yourself "What happened next?" in the organizations it praises? Do we still associate Fannie Mae with greatness?
Rosenzweig likens much management thinking to what that great thinker Richard Feynman called Cargo Cult Science.
Cargo Cults
During WW2 islanders in the southwest Pacific saw troops form both sides of the conflict descend on their islands, build airstrips, install radio stations and call down aircraft to deliver supplies.
When the troops moved on the islanders built non functioning copies of the airstrips and the equipment they had seen in use, and they copied the behaviour of the troops in the belief that they too would be able to call down goods from the gods or their own ancestors.
Although the intervention of the interlopers changed their behaviour they were actually confirming a view the islanders already held - that they would be rewarded if they behaved in the right way. In fact they thought the troops were usurping the benefits that were actually meant for them.
Is ITIL a Cargo Cult on an Island Near You?
ITIL qualifies as a cargo cult if::
Looking at it from an islander's perspective why did the rewards come for the troops and not for them?
Maybe it was because before the troops came to the island they had already developed the capabilities and tools and lines of communication needed to build the supply chain..
A couple of links
Chokey the Chimp on Crap Factoids
The ITskeptic on ITIL as a cult
P.S. I'm sure I've seen another post somewhere suggesting the link between ITIL and a cargo cult, but the only sites I can find are about cargo cult agile, not ITIL. If anyone comes across a link that pre dates this one can you let me know.
One of the must read management books on my list of all time greats is Phil Rosenzweig's 'The Halo Effect'
In some ways you could describe it as an anti-management book in that it debunks the claims made by most of the best selling management books to know the secrets of long term management success. "Good to Great" is still a wonderful inspiring read, but have you ever asked yourself "What happened next?" in the organizations it praises? Do we still associate Fannie Mae with greatness?
Rosenzweig likens much management thinking to what that great thinker Richard Feynman called Cargo Cult Science.
Cargo Cults
During WW2 islanders in the southwest Pacific saw troops form both sides of the conflict descend on their islands, build airstrips, install radio stations and call down aircraft to deliver supplies.
When the troops moved on the islanders built non functioning copies of the airstrips and the equipment they had seen in use, and they copied the behaviour of the troops in the belief that they too would be able to call down goods from the gods or their own ancestors.
Although the intervention of the interlopers changed their behaviour they were actually confirming a view the islanders already held - that they would be rewarded if they behaved in the right way. In fact they thought the troops were usurping the benefits that were actually meant for them.
An intelligent reader, such as yourself, can probably see where I'm going with this...
Is ITIL a Cargo Cult on an Island Near You?
ITIL qualifies as a cargo cult if::
- There are people who genuinely get benefit from an ITIL approach
- The behaviour of those people appears alien to the islanders
- The islanders copy the form of ITIL, but not the substance
- The islanders' behaviour remains consistent with their old belief that they deserve rewards
Do People Get Benefit From ITIL?
Yes.
Forget the crazy claims about absurd ROI that are fodder for Chokey the Chimp.
Here are just some of the ways ITIL has benefited organizations that I know of from personal experience:
- Reduction in actual headcount - not just notional savings of people hours
- 75% in the time to fulfil requests
- SLAs that the business believe in
- Improved NFRs resulting in services designed to meet the customer need
- Contracts rewritten to define the service, not the underlying technology
- Changes rejected before work has started on building them, not the day before release
I know, normally I sound more cynical than sceptical about ITIL, but that doesn't mean I don't believe in ITIL's underlying value.
I could also mention the benefits it has brought to individuals, such as increased confidence to talk to the customer, higher salaries and greater job satisfaction, but I'm going to save that for a post about ITSM training.
Are These People Crazy?
Leaving aside the rather worrying tendencies of some people to go overboard in their belief that ITIL holds the answers to all questions I think there is much in the behaviour and attitudes of those who deliver benefit based on ITIL that is distinctively different., and can seem crazy to outsiders.
- They seek out bad news
- They use metrics and targets
- They talk to customers and users
- They admit what they don't know
- They look for best practice outside of their own IT department
- They believe that the mechanisms of ITSM matter
- They don't believe the answers are to be found in technology
- They use a distinctive language and argue about what words really mean
- They believe IT staff should have non technical training
- They adapt ITIL where the guidance is currently insufficient
- They seek help when they need it
They do all these things and more
Do People Copy the Form but not the Substance?
You bet they do.
These are the people who seek out ready to use templates for SLAs. These are the people who want metrics to prove their success, not so they can see where they need to do better. These are the people who call in external consultants to tell them what they are already doing is fine. These are the people who argue endlessly over the semantics of an ITIL term without ever trying to understand what the authors actually meant by it. These are the people who think that putting in a service management tool will solve all their problems. These, above all, are the people who believe they can leave out vital great chunks of ITIL in the name of adapting and adopting it.
These are the people who think renaming the Help Desk as a Service Desk was actually important
I could go on.
Is This Consistent with their Old Behaviour and Believes?
I'm afraid that it is. These are the islander who will always latch onto a fad and copy it. These are the people who will exploit any idea if it promises to bring them rewards. These are the people who believe that they are delivering a good service and the customer should be grateful.
Why Did The Gods Deliver The Goods?
Maybe it was because before the troops came to the island they had already developed the capabilities and tools and lines of communication needed to build the supply chain..
Maybe they simply knew what they were doing.
A couple of links
Chokey the Chimp on Crap Factoids
The ITskeptic on ITIL as a cult
P.S. I'm sure I've seen another post somewhere suggesting the link between ITIL and a cargo cult, but the only sites I can find are about cargo cult agile, not ITIL. If anyone comes across a link that pre dates this one can you let me know.
Thursday, 4 February 2010
When brands like Toyota lose their shine
It would be a cheap trick to use Toyota to push up hits on my blog wouldn't it?
So as I throw my copies of "Toyota Culture" and other Toyota inspired management books in to the recycling bin, and reflect on the fact that the wife chose a bad week to order a new Toyota IQ, I'll try and think of a brand "like Toyota" instead.
You know, big on process and CSI.
A brand that has moved rapidly in to new geographies and launched a plethora of new products.
A brand that is in danger of putting short term gains ahead of the long term market.
Yes, you've guessed it.
I'm thinking
Is ITIL the next Toyota?
So as I throw my copies of "Toyota Culture" and other Toyota inspired management books in to the recycling bin, and reflect on the fact that the wife chose a bad week to order a new Toyota IQ, I'll try and think of a brand "like Toyota" instead.
You know, big on process and CSI.
A brand that has moved rapidly in to new geographies and launched a plethora of new products.
A brand that is in danger of putting short term gains ahead of the long term market.
Yes, you've guessed it.
I'm thinking
Is ITIL the next Toyota?
Wednesday, 3 February 2010
Is ISO/IEC 38500 The Cinderella at the IT Governance Ball?
I like ISO 38500. I like it very much indeed.
Which is why I find it so hard to understand why it has been met with such deafening silence in the UK.
Which is why I find it so hard to understand why it has been met with such deafening silence in the UK.
- Is it because COBIT is already so well established?
- Is it because people are not aware that it exists?
- Is it because people are unsure how to respond to it?
A survey is now open to 6th March to assess the market for ISO 38500 If you can, please identify that you came across the survey from this blog.
Why do I like it so much?
I honestly believe that the standard has a lot to offer organisations, especially those that have not already been driven down the governance route in reaction to external requirements.
I believe that whilst we often talk about ITSM addressing the concerns of the corner office the truth is we rarely actively engage senior business management in delivering IT. Good IT Governance, with a focus on the interests of stakeholders can make a real difference to the relationship between IT and the business.
The benefits of good governance obviously extend beyond ITSM, it is also a sign of effective portfolio, programme and project management.
What is so great about ISO 38500 is that it can get people, and I include the business, not just IT, to realise just what their responsibilities are for ensuring IT is effective and efficient in supporting the organization. And the standard is, of course, very clear that the responsibility for IT rests at director level.
I'll end this post with a specific example of how I've seen an idea inspired by the standard make a difference even in an organisation that has yet to decide whether to adopt it wholesale.
They thought they had good project reviews, they had even adopted the concept of gateway reviews that were led by the business, but what they discovered when they compared their approach to the standard was they were only judging each project by its own internal criteria.
In effect they were only assessing if the project was on track and within budget. What looking at the standard made them realise was that they were not asking if the project was still aligned to corporate objectives, and that compromises being made within the projects were contrary to the Principles of the standard.
For instance short cuts were being taken over the acquisition of change related hardware and services that threatened to contravene the financial limits for needing to re-tender the entire project.
Tuesday, 2 February 2010
So what is ITIL?
What is ITIL?
I don't mean in an ITIL 101 type sense.
I don't mean in the glib way a consultant would sum it up on a .PPT slide.
I don't even mean what does ITIL claim to be.
I mean what is ITIL in reality.
I'm not an ITIL v3 expert so I cannot give you a text book answer. Instead here is my own interpretation.
To begin with - what ITIL isn't.
It isn't a standard
Yeah, we all know this. Those of us involved with developing ISO/IEC 20000 can tell you how different it would be if it was. But hey, since we have ISO 20000 so we don't need ITIL to be one
It isn't Proven Good/Best Practice
Perhaps this is less obvious.Once upon a time it was true. V1 was very much based on what good mainframe shops did as a matter of course. There are still bits of ITIL v3 where this is true. In some areas though you are either getting blue sky thinking without any evidence to support the ITIL position, or you are getting ideas that are dated and basic. Which are which? Hmm not obviously signposted is it?
It isn't Proscriptive
Well it would have to tell you if it was, but it doesn't tell you which bits of it you HAVE to do to provide an adequate service to your customers.
It isn't a Menu from which you can Make Choices
I actually think this is the most dangerous misconception there is about ITIL, compounded by the failure to identify the things you must do to be successful. In reality there is a tendency to drop the difficult but essential bits. That's why ISO 20000 doesn't give you the option to do that. You can chose to miss out a stage of ITIL's change management process, but if you do there is a high probability your change management process will be fatally flawed.
So What Is It?
Good question. It is neither fish nor fowl., and that I think is a major flaw.
A Compass?
Someone described it the other day as being a guide or a compass. I find that quite an attractive analogy, but one of the key things about a compass is you always know which way it is pointing. I don't think there is a clear North in ITIL.
A Philosophy?
Ivor Macfarlane used to say something along the lines of "The IT Infrastructure Libary is a set of books, but ITIL is a philosophy."
I find that quite an attractive view as well, and ten years ago it is the view that would probably have got my vote. But ten years ago the ITIL community was relatively small , relatively homogeneous and relatively self organising. Most of the people involved had an implicit understanding of that philosophy. Times have changed though, and that is no longer true. We can no longer liver with a disparity between the books and what we really mean
A Statement of Facts?
This is a view that has only really struck in recent weeks. I suspect it is in part my reaction to the view that you can chose the elements of ITIL to adopt, and that you change the meaning of what ITIL says to suit yourself.
It doesn't matter what I say or think, an incident is still different from a problem. A change is a change, whether I like it or not, and I firmly believe there is only one overall change management process that can work. Marginal costing has a very precise meaning in accountancy. What makes something a contract isn't whether we call it a contract instead of an SLA.
Is ITIL a Map?
Slowly I'm coming to the conclusion that what ITIL is closest to being is a map of the ITSM world. There might be some areas of that world that we don't want to venture in to, but they are still there whether we chose to believe in them or not. There is a way of holding ITIL up against the real world that helps make sense of the real world, but we have to learn what the symbols on the map mean.
Being like a map isn't the same as actually being a map though, and most maps interpret the world through a political lens and can only be based on what we currently know allied to some more or less reasoned supposition.
What I am certain of though is that it ITIL is not to continue getting people lost in the ITSM world there needs to be absolute clarity about what ITIL actually is.
I don't mean in an ITIL 101 type sense.
I don't mean in the glib way a consultant would sum it up on a .PPT slide.
I don't even mean what does ITIL claim to be.
I mean what is ITIL in reality.
I'm not an ITIL v3 expert so I cannot give you a text book answer. Instead here is my own interpretation.
To begin with - what ITIL isn't.
It isn't a standard
Yeah, we all know this. Those of us involved with developing ISO/IEC 20000 can tell you how different it would be if it was. But hey, since we have ISO 20000 so we don't need ITIL to be one
It isn't Proven Good/Best Practice
Perhaps this is less obvious.Once upon a time it was true. V1 was very much based on what good mainframe shops did as a matter of course. There are still bits of ITIL v3 where this is true. In some areas though you are either getting blue sky thinking without any evidence to support the ITIL position, or you are getting ideas that are dated and basic. Which are which? Hmm not obviously signposted is it?
It isn't Proscriptive
Well it would have to tell you if it was, but it doesn't tell you which bits of it you HAVE to do to provide an adequate service to your customers.
It isn't a Menu from which you can Make Choices
I actually think this is the most dangerous misconception there is about ITIL, compounded by the failure to identify the things you must do to be successful. In reality there is a tendency to drop the difficult but essential bits. That's why ISO 20000 doesn't give you the option to do that. You can chose to miss out a stage of ITIL's change management process, but if you do there is a high probability your change management process will be fatally flawed.
So What Is It?
Good question. It is neither fish nor fowl., and that I think is a major flaw.
A Compass?
Someone described it the other day as being a guide or a compass. I find that quite an attractive analogy, but one of the key things about a compass is you always know which way it is pointing. I don't think there is a clear North in ITIL.
A Philosophy?
Ivor Macfarlane used to say something along the lines of "The IT Infrastructure Libary is a set of books, but ITIL is a philosophy."
I find that quite an attractive view as well, and ten years ago it is the view that would probably have got my vote. But ten years ago the ITIL community was relatively small , relatively homogeneous and relatively self organising. Most of the people involved had an implicit understanding of that philosophy. Times have changed though, and that is no longer true. We can no longer liver with a disparity between the books and what we really mean
A Statement of Facts?
This is a view that has only really struck in recent weeks. I suspect it is in part my reaction to the view that you can chose the elements of ITIL to adopt, and that you change the meaning of what ITIL says to suit yourself.
It doesn't matter what I say or think, an incident is still different from a problem. A change is a change, whether I like it or not, and I firmly believe there is only one overall change management process that can work. Marginal costing has a very precise meaning in accountancy. What makes something a contract isn't whether we call it a contract instead of an SLA.
Is ITIL a Map?
Slowly I'm coming to the conclusion that what ITIL is closest to being is a map of the ITSM world. There might be some areas of that world that we don't want to venture in to, but they are still there whether we chose to believe in them or not. There is a way of holding ITIL up against the real world that helps make sense of the real world, but we have to learn what the symbols on the map mean.
Being like a map isn't the same as actually being a map though, and most maps interpret the world through a political lens and can only be based on what we currently know allied to some more or less reasoned supposition.
What I am certain of though is that it ITIL is not to continue getting people lost in the ITSM world there needs to be absolute clarity about what ITIL actually is.
Monday, 1 February 2010
The Rise of the Instant ITIL Expert
Back in November I presented a session at the itSMF UK's conference on getting the right people involved in your ITSM initiative. One of the key themes was how do you tell the heroes from the villains within your organisation.
There seem to be a lot of self styled ITIL gurus around these days and it can be equally difficult to identify who to trust, so here is my personal opinion about just some of the types to be wary of.
The Retrospective ITIL Expert
This one claims that they've been using ITIL for years, but when pushed you discover they've only recently been qualified and appear to know little about the history of ITIL or what it is really trying to achieve. Of course they'll then tell you that ITIL is only common sense and their practical experience trumps ITIL
ITIL by the v3 Book
This one argues everything against the specific wording of ITIL v3 and appears to be oblivious to the fact that just about anybody who was involved with v3 will cheerfully, in private at least, admit it has flaws and omissions. They rarely seem to be aware that ITIL existed before v3 or that rather like another well known book you can usually find an out of context quote to suit whatever position you chose to take.
The Flawed Theorist
Theory is good, ITSM deserves a better underlying theoretical model than it currently has. The theorist, however, is only interested in their own theory. That almost nobody else agrees with it is not an indication that the theory night be flawed but of the stupidity of everybody else in the ITIL world. The rest of us are not capable of appreciating the intellectual superiority of their idea. More often than not their great new theory rests on the type of misunderstanding the Foundation exam was introduced to counter. When pressed to prove their theory they will retort it is up to the rest of us to prove them wrong.
The Expert in ITIL and nothing but ITIL
A close relative of the believer in ITIL by the book. These days they are often to be found in the training community. Their entire knowledge of subjects comes from what they know of ITIL.They appear unaware that much of the content and language of ITIL is a sub set of other specialisms. Mostly harmless.
The Wannabe
The wannabe was once forced to attend a workshop as part of an ITIL initiative. At the time they were quite happy to tell everyone what a waste of time it all was, but hey now they are an expert, especially if it means being able to get a job in consulting or training.
The Confidence Trickster
Nothing phases this one, they have absolute confidence in their own expertise and are only too glad to share it if you attend their training courses or reply to them off list. They often award themselves some grandiose but meaningless title . It doesn't matter if you are a newbie making an innocent mistake or a true guru passing on a hard learnt lesson, the confidence trickster will treat you with equal contempt. What they are not so great at it is showing any evidence that they've actually applied ITIL any where or have any real insight.
The Good Guys
As I said in my original presentation the odd thing is that there is a superficial resemblance between the heroes and the villains so why don't we remind ourselves of what you should be looking for in an ITIL expert.
Retrospection
It really is helpful if they can see their pre-ITIL life through an ITSM lens. That includes recognising the things they would have done differently had they known about ITIL at the the time, or even the things they would have done differently in the gap between knowing about ITIL and really understanding ITIL. They'll also be able to identify the things they did right that echo what ITIL says.
V3 Knowledge
The real expert will understand what has changed in V3 and how it relates to the history of ITIL. Of course they will also know about COBIT and ISO/IEC 20000. They will be able to give you a cogent account of how v3 could be improved but won't lose sight of the benefits of the changes. Not only that but they'll be able to add real value because of their practical knowledge of integrating ITSM throughout various life cycles.
Theory
A real expert understands the need for an element of theory, but will also know how to apply and adopt that theory.
Breadth and Depth of Expertise
You don't want an advisor who only knows about a small part of the ITIL world, you want someone who can offer input across the full breadth of ITIL. But you also want some depth and a good sign of that is a previous relevant specialism.
Ambition
True experts are always willing to learn and to improve. They are confident about what they achieved on their last assignment, but are already thinking about what they will do differently next time.
Confidence
The true ITIL expert does have a certain arrogance, but it is based on demonstrable success. If they hold a strong view they will explain why.
There seem to be a lot of self styled ITIL gurus around these days and it can be equally difficult to identify who to trust, so here is my personal opinion about just some of the types to be wary of.
The Retrospective ITIL Expert
This one claims that they've been using ITIL for years, but when pushed you discover they've only recently been qualified and appear to know little about the history of ITIL or what it is really trying to achieve. Of course they'll then tell you that ITIL is only common sense and their practical experience trumps ITIL
ITIL by the v3 Book
This one argues everything against the specific wording of ITIL v3 and appears to be oblivious to the fact that just about anybody who was involved with v3 will cheerfully, in private at least, admit it has flaws and omissions. They rarely seem to be aware that ITIL existed before v3 or that rather like another well known book you can usually find an out of context quote to suit whatever position you chose to take.
The Flawed Theorist
Theory is good, ITSM deserves a better underlying theoretical model than it currently has. The theorist, however, is only interested in their own theory. That almost nobody else agrees with it is not an indication that the theory night be flawed but of the stupidity of everybody else in the ITIL world. The rest of us are not capable of appreciating the intellectual superiority of their idea. More often than not their great new theory rests on the type of misunderstanding the Foundation exam was introduced to counter. When pressed to prove their theory they will retort it is up to the rest of us to prove them wrong.
The Expert in ITIL and nothing but ITIL
A close relative of the believer in ITIL by the book. These days they are often to be found in the training community. Their entire knowledge of subjects comes from what they know of ITIL.They appear unaware that much of the content and language of ITIL is a sub set of other specialisms. Mostly harmless.
The Wannabe
The wannabe was once forced to attend a workshop as part of an ITIL initiative. At the time they were quite happy to tell everyone what a waste of time it all was, but hey now they are an expert, especially if it means being able to get a job in consulting or training.
The Confidence Trickster
Nothing phases this one, they have absolute confidence in their own expertise and are only too glad to share it if you attend their training courses or reply to them off list. They often award themselves some grandiose but meaningless title . It doesn't matter if you are a newbie making an innocent mistake or a true guru passing on a hard learnt lesson, the confidence trickster will treat you with equal contempt. What they are not so great at it is showing any evidence that they've actually applied ITIL any where or have any real insight.
The Good Guys
As I said in my original presentation the odd thing is that there is a superficial resemblance between the heroes and the villains so why don't we remind ourselves of what you should be looking for in an ITIL expert.
Retrospection
It really is helpful if they can see their pre-ITIL life through an ITSM lens. That includes recognising the things they would have done differently had they known about ITIL at the the time, or even the things they would have done differently in the gap between knowing about ITIL and really understanding ITIL. They'll also be able to identify the things they did right that echo what ITIL says.
V3 Knowledge
The real expert will understand what has changed in V3 and how it relates to the history of ITIL. Of course they will also know about COBIT and ISO/IEC 20000. They will be able to give you a cogent account of how v3 could be improved but won't lose sight of the benefits of the changes. Not only that but they'll be able to add real value because of their practical knowledge of integrating ITSM throughout various life cycles.
Theory
A real expert understands the need for an element of theory, but will also know how to apply and adopt that theory.
Breadth and Depth of Expertise
You don't want an advisor who only knows about a small part of the ITIL world, you want someone who can offer input across the full breadth of ITIL. But you also want some depth and a good sign of that is a previous relevant specialism.
Ambition
True experts are always willing to learn and to improve. They are confident about what they achieved on their last assignment, but are already thinking about what they will do differently next time.
Confidence
The true ITIL expert does have a certain arrogance, but it is based on demonstrable success. If they hold a strong view they will explain why.
When a wheel falls off
The Power of the Analogy
Every year I make the pilgrimage to Le Mans for the famous 24 hour race.
Being me I can't help thinking about the parallels with service management and the lessons we can learn from the teams.
Before I continue a word about analogies. It strikes me from time to time that there are people in the IT industry who do not see the parallels between what IT does and what other specialisms do. I guess it doesn't matter that they don't get some analogies, after all when we are teaching, for instance, the use of an analogy is only one way to get a point across and you need to appeal to different mindsets. When it does matter though is when what another specialism does is directly analogous to what we do in IT and has valuable lessons for us to learn about the right way of doing things.To disregard how the engineering community carry out Root Cause Analysis, for instance would be both supremely arrogant and irresponsible.
Recognising we have lessons to learn from outside IT is a major driver for making improvements. Here is one interesting story:
I'm afraid my insights based on Le Mans aren't going to be quite as vital as that.
Lesson Number 1: Things will go wrong
At the start of Le Mans several million pounds worth of cars are lined up on the grid. For every team this is THE race of the year. Winners of Le Mans, both drivers and cars, go down in motor racing history. Every single person involved with those teams is committed to....well winning the race or your class would be great but the 250,000 spectators at the track (Yes you read that number right) all know that just getting to the finishing line 24 hours later is a massive achievement.. The current record for distance covered during the race is 3,235 miles. That works out at an average of 135mph, though the highest speed actually recorded for a car at Le Mans in 248mph.
So, things break, or get broken.
And the teams expect that, so even though they have spent a lot of time and money trying to make sure things won't break they also plan for what will happen when they do break. That means:
They design things to break
It is much better to have a minor component break in a known way than to have a major component blow up. So you sacrifice one component and the car limps back to the pits. Did I mention that if anyone but the driver touches the car whilst it is on the 8.5 mile long circuit the car gets disqualified? Don't worry about the guy in the photo at the start of this post, he is actually in the start of the pit lane, though that isn't where he was at the start of the crash. How did it get like that? I'm afraid one of the Aston Martin cars hit it and slammed it in to a wall. That wheel at a crazy angle is an example of what I'm talking about, the suspension has sheared off at points deliberately weakened to protect the main structure of the car.
They design things to be fixed
End of the race for the 26 car above? Not yet. The crash happened about 7.30pm, by 2am the car was back on the road. Remember this isn't a little shunt on the high street, this is a crash that saw the car slam into a concrete wall at high speed. How did they do it?
Here's a picture I took in the pits before the race. Can you spot what is missing?
Every component is designed to be removable, and the mechanics train on how to move and replace them.
People Are in the Right Place
The pit lane at Le Mans is a dangerous place, and those garages where they have to do any major mechanical work are about the same size as a large domestic garage. You can't have hundreds of people milling around. The team management are normally on the pit wall keeping an eye on the telemetry. The drivers who aren't in the car are asleep in a motor home, and the bosses, the sponsors and the guests are in the hospitality suite above the garage.
And Finally...
You can do a surprising amount with gaffer tape and a hacksaw, but a final top tip is some of the teams swear by using a certain brand of fizzy cola to clean the flies off the windscreen - but make sure you wash it off well and don't try it on a computer.
And for those who just like the cars...
Here's a slide show of the rest of my photos from the 2009 race
A new beginning
Don't you just hate blogs that suddenly dry up for no apparent reason?
Like this one. No sooner had it received the ITskeptics seal of approval than it all went very quiet here.
At least that is how it must seem.
In reality the number of draft posts has been growing steadily, but for various reasons I've not wanted to publish them. The main reason has probably been that many of them are related to an area where my own thinking is developing rapidly. So what is it?
No it isn't the Cloud or SaaS.
Well not exactly, it is the more generic topic of commodity computing, and how we apply service management best practice to it.
Like this one. No sooner had it received the ITskeptics seal of approval than it all went very quiet here.
At least that is how it must seem.
In reality the number of draft posts has been growing steadily, but for various reasons I've not wanted to publish them. The main reason has probably been that many of them are related to an area where my own thinking is developing rapidly. So what is it?
No it isn't the Cloud or SaaS.
Well not exactly, it is the more generic topic of commodity computing, and how we apply service management best practice to it.
Subscribe to:
Posts (Atom)
Posts
