Is HR ITSM's Greatest Corporate Enemy?

It was one of those late night conversations with 'T' an ex-service manager colleague when the question came up.

He'd become an ex-colleague thanks to the collusion of the office bully and an out of touch HR department. The sad thing was that any ITSM professional would have realised the miracles he had been working up to that time in a very challenging environment.

Before you shed to much of a tear for him he soon  found his niche in a more humane organisation, so six months on I was chatting to him in his new role as a very successful IT Director, shortly before he was head-hunted for a new CIO role.

Meanwhile the office bully continued to convince everyone she was indispensable, right up to her early retirement, since when I'm pleased to say things have improved substantially in that particular organisation.

Up until that point I'd always thought of Finance, suppliers, and the IT department themselves as the barriers to world class ITSM. The more I thought about it though the more I thought T had a point. OK, his was an extreme, though not unique case, but there are lots of ways that HR nibble away at the effectiveness of the ITSM team. Now to be fair the blame doesn't necessarily always lie with HR per se, so much as the CIO's failure to articulate the actualities of ITSM.

Let's begin at the beginning with recruitment.

Do a quick Google on ITIL jobs.

Here's one I've just come across.

"Service Delivery Manager required to work within a leading IT Outsourcer. Working with bid and costing teams the Delivery manager will be responsible for Design and delivering large complex solutions.
Chairing meetings to discuss requirements and effective strategies to manage service proposals and to represent the company to win complex bids. Managing current relationships and developing new relationships with customers to represent the business. Working with ITIL Service Management to work effectively and efficiently within ISEB standards."

"Candidates must be able to demonstrate actual hands on Service Delivery in operating infrastructure services, ie:- a complete end to desk top, server infrastructure, to compliment the ITIL accreditation's.
Experience of leading on major high-touch bids
Demonstrable Service Management leadership expertise
ISEB Service Management Manager Certified (Red Badge)
Knowledge of Information Technology Management and functions
Customer and business orientation, with sound commercial and financial awareness
Has effective working relationships with customer's senior management as well as internal relationships

To start ASAP"

To begin with WTF does any SDM job have the words "To start ASAP" in it?

Think on that. 

Possibilities I can think of include:

• The last SDM gave up in disgust
• A month before go live they have suddenly realised they need a SDM
• They expect a masked man to ride into town and perform miracles
• They believe an SDM should be judged on immediate results

I'm sorry, but everyone of those flashes up "Warning Will Robinson"  to me.

Then look at those responsibilities. Is the SDM really going to have design responsibilities, or are they, as usual, going to have to make a purse out of a sow's ear. What control will they actually have over the delivery of the service? Is their job actually going to be to make endless excuses for other people's mistakes after the event?

ISEB standards? Can some one tell me what ISEB standards there are? This is an advert written in the ITL equivalent of Franglais. 

I'm glad they want someone to 'compliment' the ITIL accreditations, we need more people to say that ITIL accreditations are wonderful.  I'm sure you all know the peanut joke. Sorry that was underhand.

Then just look at the overall job requirements. Isn't that rather like saying a janitor should know how to mop a floor.

Look at it from the SDM's perspective - does anything make this job sound attractive?

The Triumph of the Airheads: And the Retreat from Commonsense

Yes I've suggested all these links before, and yes you've ignored them, but I still think they would be good for you. Buy them as presents for your HR Director.

HR are the vampires of the organisation, that is why they avoid holding a mirror up to themselves. 

Think about it, HR can make two basic mistakes. They can fail to recruit the right person, or they can recruit the wrong person. Is there any mechanism to catch either of those mistakes, because trust me if they recruit the wrong person they won't take the blame.

I spoke at the 2009 itSMF Conference on one of the very basic mistakes HR make. Their ideal candidate is like the average candidate, only more so. They want some one who is more than averagely punctual, more than averagely presentable, more than averagely...average. 

I'm sorry, but to on my ITSM team I want people who are exceptional. I want people who are different. Who are prepared to challenge the conventions that got the IT department into their current situation. I want people who understand that world class ITSM isn't achieved by trying to run before you can walk....I want born ITSM professionals, and above everything else I want people who care.

This is probably a good point to totally castigate recruitment agencies who don't know enough about ITSM to either set salary expectations or to carry out an initial filtration of candidates. For goodness sake, I've seen agencies requesting credentials that don't even exist yet.

OK, you've joined an organisation. Let's have a look at their job design. No, better not really. They are just a collection of buzz words. SDMs achieve success by their influencing skills. They fight wars and campaigns, not battles.

What about the criteria for success in the role? Have you noticed these are never contingent? Nobody ever say "Of course if the project delivers a c**p solution we won't hold you responsible for customer satisfaction."

Training. Dear HR Director, there is a reason why there are ITSM specific training schemes. And the ITSM team understand their value a lot more than you do...

OK, I could go on, but I hope I've made my point.

Brandon Lane CIO - Episode 6

Richard Gets a Wake Up Call

Brandon Lane, the once and future CIO, surveyed his new office.

During his dramatic makeover of it on Sunday he had been faced with two choices. One was to use it to impose his authority and the other was to use it to signal a different way of working. He'd gone with the second choice, though now he was beginning to wonder. It was dawning on him that IT people don't do subtle.

The other thing that was worrying him was his experience of home life. He knew that however much Ysabelle rearranged the rooms there was always one optimal place to sit, and she would claim it before anyone else realised where it was. Looking around his office he tried to guess which was the best seat in the house. Was it best to face the door, or to be hidden from anyone entering the room so you could judge their reactions? What was the optimal distance to be from the coffee machine? Where were the power sockets? Which was the most comfortable chair?

Conversely, he wondered, where was the best place to put someone if you wanted to make them feel uncomfortable.

He didn't have long to wait to answer that question before Richard, the Service Desk manager came in.

"You wanted to see me?" Richard ejaculated as he sat down in the chair Brandon had just identified as the most comfortable.

"Nice of you to drop by. Do take a seat. How are things on the desk"

"I think they are OK, as a manager I try not to get involved in the day to day issues. Of course it would help if we had a new service management tool. Jacques was going to let me develop our own. I've put a paper together, I'll send it to you"

"Richard, remind me, what is the tool you are currently using?"

"It's XXXXXX. Rubbish. It doesn't let me do any of the analysis I want to do."

"I'm sure. Now just remind me of the last IT customer satisfaction survey results...no actually don't bother I read it this morning . Ah, here it is, let me quote 'They never get back to you when they say they will', 'Rude', 'treated me like an idiot', 'Explained how a system I'd designed worked in words of one syllable, and got it entirely wrong'. I could go on, but tell me, does your paper outline how a new tool would solve these issues?"

"Well that is users for you. Never happy. They don't realise how difficult our job is."

"What worries me Richard is this. Do you realise how difficult their jobs are?"

"A new tool would let us..."

"Richard. Richard. Richard. You pick up the phone. You find out what is upsetting the person on the phone, and when they put the phone down you leave them with the feeling that they don't need to worry. How is a new tool going to help you achieve that? How difficult can it be anyway? By the way how are the issues with  the changes to the MFD IP addresses coming along?"

"Is there an issue? No one has told me yet."

"Richard, you are the Help Desk Manager. It is your job to know, and to make sure that other people know what is going on as well. Get out there and sort it."

"But what about your team meeting, it starts in ten minutes."

"Yes it does, but I think it would be a better use of your time to get back to the desk and sort things out."

There was an awkward pause.

" Now Richard. Now would be a good time to go and sort it out"

Lessons From Beyond the Clouds

My Adventures in the world of thin client computing


We sometimes forget that IT strategy should be driven by business imperatives, and that those business imperatives don't change just because the technology does.

So when we start to look at Cloud and SaaS from  an ITSM perspective we should always keep those business imperatives in mind. It also helps to remind ourselves that the problems the business want the cloud to solve are existing ones.

One of the most interesting projects I've been involved in recently replaced all the client's desktop computers with thin client devices, accessing all applications over a combination of an intranet and the internet and a mixture of internal and external hosting. The thin clients and the infrastructure were all provided  as part of an outsourcing deal.

It was a fascinating experience with novel technology and as you might expect there were major hiccups along the way. What struck me time after time though  was that the challenges and issues from an ITSM perspective were all old familiar friends, but seen in a new light. As the French say

Plus ca change, plus c'est la meme chose

Let us begin with what the business were trying to do, and this was very much a business led change. 


They wanted:

• Reduced and predictable running costs and total lifetime cost
• Scalability 
• A stable platform to enable rapid roll out of new services 

A longer term requirement was to enable their internal services to be made available to other partners and directly to their customers.

Lots of implications obviously follow from these high level objectives. Not all of them were perhaps realised at the time, and others were over emphasised during the roll out of the project at the cost of reducing the overall benefit delivered. Other objectives were also added on during the life of the project, such as integration with the business's green policy.

What about the service management perspective?

Many of these will already be familiar to you, I'm sure.

Service Transition

A major issue, as with so many projects, was that the project team made decisions with a significant impact on the  quality of service that could not be delivered without seeking the approval of the service management team, 

Testing

Many supposedly key aspects of the service were contractually specified as requirements for service acceptance and as targets for the service once it had gone live, but no effort was made to design and build tests during the project stage. Had an attempt been made to develop tests, and integrate them with UAT then someone might have noticed that many of the targets and service levels were nonsensical or ambiguous .

Targets

What do I mean by the targets being nonsensical? Pay attention because this is extremely important. I mean they were:

• Impossible to measure. I mean logically impossible, not just difficult
• Not relevant to the actual quality of service
• Not measuring what people wanted them to be measuring
• Not within the control of the supplier(s) to deliver

In many case these flaws could be traced back to targets being inherited from previous contracts and SLAs. Although the thin client solution highlighted their short-comings the truth is they were never good measures to begin with.

Those that were impossible to measure were often ones that were not relevant to the new architecture. For instance those measuring performance at a component level that no longer existed, or which were now hidden inside the cloud.

Often these were also measures that even if they could be measured couldn't be consistently mapped on to the customer or user experience. As an example because of  the way the system was designed to dynamically reconfigure itself it could run perfectly well one day with two portal servers unavailable, but the next day just one portal server failing could bring the entire service to a halt.

A far to common failing of targets is the seemingly universal flaw in logic which goes like this:

"I want to measure X. I can measure Y. Therefore Y must tell me about X"

How stupid is that, but we do it all the time. Do you measure average call waiting time on your ACD system? What is it that you actually want to know, measure and achieve? 

Write them down. Now.

Yes, I am looking at you, write down what you actually WANT to know.

Some suggestions:

"Do customers ring off because they get frustrated with waiting?"

"Does the call queuing system work effectively?"

"Do I need more staff on the help desk?"
"Do my users have reasonable expectations of the service?"

"How long does it take from a user first ringing the service desk until they speak to someone who can help?"

"How many customers are unhappy about how long they've had to wait for their call to be answered?"

"How many times does a customer call the desk before their call is answered?"

Now ask yourself if average time to answer recorded by an ACD system answers any of those questions.

A classic I came across on this particular project was that it was two years before the service desk provider let slip that they only counted waiting time after the caller had listened to the "Welcome" message. Their target was to pick up calls within 20 seconds. The welcome message typically lasted 45 seconds. Go figure.

And if you want a service delivered over the internet you can't hold your application supplier responsible for the poor transaction response time experienced by a user living on a canal boat moored in a cutting.  It didn;'t stop the user complaining though.

Contracts

Something I've never understood about ITIL, especially considering OGC's wider role, is that it has never addressed that in the UK most IT services are dependent on outsourcing, and contracts are therefore key.

Where do I begin? Well to follow on from the previous section too many contracts are written with what went wrong the last time in mind, which might be wholly irrelevant today. 

Secondly far too often the parties agree on the words, but not on the meaning of the words, and again I'm afraid that ITIL does not address this. We can all agree that a service change should go to the CAB, but that is of little use if we don't agree what we mean by a change to the service.

Language and the Dramadriehoek

Pardon my Dutch. Customers, users, the retained organisation and different suppliers are rather like the Americans and the British. They are divided by a common language, which unfortunately they insist on talking to each other. Those of you, who unlike me, have mastered another language will know the peril of the "familiar friend" that expression you can easily translate into another language, but then has a wholly different meaning. 

Mail me for the sick joke that I could insert here but won't. It was told me by a Collector* in HMR&C**. 

The great challenge for ITIL and ISO 20k has to be understanding how you map supplier terminology onto customer and user terminology throughout the value network.

The Retained Organisation

Another opportunity to spit over you whilst attempting to say "dramadriehoek" The ITIL missing link is the role of the retained organisation/intelligent customer.  You need to understand what role you expect the retained organisation to fill, and  you need to realise that it will change over time. The RO should not be man marking the supplier and providing support when they make mistakes. THe RO should be setting the framework for supplier/customer/user interaction.

Service Credits and SLAs

Welcome to a basic lesson in economics. If I set myself up to deliver service A, and you apply constraints C which have I implications on how I can D Deliver the service...

...You get ACID, which is never good.

Punishing your supplier financially only works in a narrow subset of situations. Forget the sunk cost fallacy, what matters is how you can move forward.

Forget the mistakes of your past... what is it that matters now?

----------

* A very very senior British Customs Officer

** If you want  a good night out go to a Burns Night with  the British customs.The man himself was a "Gauger" A well known founder of itSMF was once found lying in a hedge after one such event. I know it was a good night because after five years I finally understood every word the Scottish CFO at the Passport Office said to me. Pity I didn't understand him earlier when he was teaching me accountancy.

ServiceSphere ITSM Weekly Podcast

I'm loathe to include these links, because you could argue the words were twisted from my mouth. Let us get this absolutely  straight, Focus is not a swear word, even if it is beeped out.

Go ahead and enjoy

ITSM Weekly the Podcast week 15

Week 16

10 Reasons Why Your Customers Are Like Poodles

Yesterday was a lovely sunny morning here in Warwickshire, so I thought the dogs would be looking forward to a walk by the river. Unfortunately I could only find one of them. Daisy, the toy poodle, had once again snuck under the supposedly poodle proof netting and escaped to see our neighbours. She was sat on their sofa being hand fed biscuits and watching re-runs of soaps on TV. It didn't matter how much I yelled "walkies" or Milly barked, Daisy wasn't moving.

Milly the elderly dalmatian and I had a nice peaceful walk, and the local rabbits were allowed to frolic without being chased by 2.5kg of kinetic energy personified.

Being me, I twittered about this.

Being an ITSM peep @glennodonnell co-author of The CMDB Imperative twittered back:

Sounds like the poodle found a better customer experience at the neighbor's house! 

What eventually enticed her back was providing a better experience for a different customer. As soon as I began cooking bacon for the two legged members of the Finister family she was back in our house like a flash.

As Glen said when I published the good news of the prodigal poodle's return:

See what happens when you improve the customer experience? The customer returns. There is an ITSM lesson here!

I think there is more than one ITSM lesson to be learnt, and here are 10 of them:

1. However hard you try and fence your customers in they will still be curious about what is on the other side of the fence.
2. The more you try and fence them in the more convinced they will become that what is on the other side is worth finding out about.
3. The customer will make the effort to find out what other suppliers are offering
4. The first time you'll find this out is when you see the customer cosying up to their new supplier.
5. You won't get the customer back by just offering more of the same.
6. Just because one  incumbent customer is happy with your service it doesn't mean others will be.
7. Make a direct plea to them to come back and you face a dialogue ending rejection
8. Openly providing an enhanced service to another customer can attract old customers back, even, he said in full on cynic mode, if the enhanced service isn't immediately available to the returnee. Think loyalty cards, for example.
9. Customers defect for short term gain, they don't know they are supposed to care about total quality of service. 
10. Don't relax. Always keep your ears and eyes open to what the customer is up to.

If you can hear a noise in the background, that's Daisy howling because she's spotted a sausage left on the BBQ.

CoreITSM 101: ITSM Audits

To be truthful this probably isn't really a 101 subject, but I'm posting it here because 'audit' is a term you'll find used with casual abandon by those in the ITSM world who don't really understand what it is all about.

Not all audits are equal, and neither are all auditors 

In fact let us begin with the different types of auditor, because that has a massive bearing on the type of audit that can be carried out and the value that can be derived from it. 

In the ITSM world  the auditors you are most likely to meet include:

• The independent quality auditor assessing management systems against an ISO standard
• The consultant undertaking a supposedly independent audit  prior to and after an ITIL implementation
• A 'tick and turn' internal auditor following a check list
• A systems based internal auditor who will assess whether the system of  management control is effective and/or whether  Value For Money (VFM) is being achieved
• A technical IT internal auditor who will be able to test and assess assess technical controls in detail

 Hopefully I don't need to dwell on the outmoded "tick and turn auditor" I still have nightmares about when the manager of a major government data center rang me up to complain that two of my trainee auditors were insisting he lifted the floor panels so they could check the voids for dust and debris, even though he had explained to them it was a solid floor.

If you read some of the ITSM literature you could be forgiven for thinking that ITSM audits are mostly undertaken by the teams responsible for each process. In reality this rarely happens, though, with several caveats, there are arguments in favour of it as one aspect of the overall audit process. 

So, what about the types of audits these guys and gals undertake?

The last time I checked I was a member of three BSI/ISO committees, so obviously I think ISO standards are a "good thing"  If you aren't British you might want to read '1066 & All That' to get the joke. The point is that these audits do exactly what it says on the can.  They do not look outside of their very specific remit, and that remit is the basic requirement of a management system. So if your IT supplier makes great play of being  ISO/IEC 20000 certified be sure you understand what that really means. it does not tell you anything about the actual quality of the service they are capable of delivering. What it does tell you is they haven't just cherry picked the 'easy' ITIL processes of incident and change management. It is a great starting point, but that is what it is, nothing more.

In another lifetime, before marriage, step-children, dogs, cats and degus I spent a lot of my time doing audits as part of consultancy assignments. Typically we would use a pseudo CMMI approach, because clients can understand the message

"You are here, but really it would be great if you here. Don't worry, it is OK if you only get to here, because we can rationalise it for you"

I'm actually a great fan of maturity models, and I think COBIT has done a good job of integrating them into the ITSM world. I believe, however, that most ITSM maturity models and assessments are flawed though, not least because they never explicitly address how we balance the maturity of an individual process against overall maturity. Being really really good at incident management is really really great, but it doesn't make you a mature service management organisation if you are not terribly good at request management. The classic example we see of this is people claiming to be at a high maturity level for change management but not for release management, service level management, capacity...or any of the other capabilities and processes that are essential to delivering world class change management.

Dare I suggest that the he people doing these audits want to sell you things. Then when they've finished selling you things they want to sell your success. So how much do you trust their audits? 

Now in contrast ITSM could do a lot worse than invest time and effort in cultivating your friendly systems based auditor. They will ask what it is you are trying to achieve, validate that outcome, and then assess whether you are are doing the right things to achieve it.  The only downside is they won't know what technology is capable of achieving...which is where your technically capable auditor comes on the scene. You can possibly sub divide this type of auditor into the one trick pony, who knows a lot about, say, security, and the technology auditor who also keeps a foot in the business world. Both have a valid role to play. 

So what about this concept that ITIL seems so fond of, the self audit approach? First of all let me be very pedantic and make two points. The first is that this is not 'Internal Audit'  Internal Audit  is a corporate governance function and, secondly, what Internal Audit has that the IT team doesn't is independence.

Leaving that aside though I believe there is considerable value in an internal team trying to take an objective view of their own performance.  After all no auditor will ask any question that management shouldn't have already asked themselves. However I think they need help to make it effective. So cultivate a friendship with the audit team, and ask them about Control Risk Self Assessment. Involve your stakeholders in the process, and above everything else make sure you focus on your ability to consistently deliver desired outcomes. 

Just because it has never gone wrong in the past doesn't mean it will always go right in the future

Layers of Reality

I was lucky enough to meet Mark Toomey, author of  Waltzing With The Elephant,whilst he was in the UK last week, to discuss ISO 38500 . It is significant that we met at the offices of a major management consultancy firm who can see real value in getting ISO 38500 in front of the Board.

Equally significant I suspect is that the Rob England, the ITskeptic seems to have finally cottoned on to what I've been telling him about the standard for ages. It is the Board's responsibility not the CIO's.

We are talking about getting the best business outcomes from investment in IT, we are talking about controlling the environment in which ITSM operates, not about the internal management of ITSM. Hence we constantly distinguish "Governance of IT" from "IT Governance"

I'm looking forward to a really exciting debate at Pink11, and hopefully at this year's itSMF UK conference as well. Because trust me, there are issues that need debating.

Lots of discussions we have within the IT world are really interesting for us IT geeks, but not meaningful in a wider context. Take agile development for an example. Yes there are lots of pros and cons, but what I care about is does it help deliver business centric solutions that are timely and cost effective over the whole life cycle of the service.

Or lets look at ITIL. Nothing in ITIL matters unless it produces a positive business result.  Do you want time to digest that?

In positing the IT governance layer encapsulated in ISO 38500 we are saying that good governance of IT adds value to the business. I suspect you are either slapping your forehead in annoyance because I've just stated something blindingly obvious, or you are cursing me because you see the standard as yet another barrier to achieving what you believe IT should be doing and which will add additional layers of bureaucracy.

CoreITSM 101: Reporting

I think it was Horace who said 'I labour to be brief but become obscure"

How apt for this post. Firstly recognise that any reports we produce are an attempt to distil reality that is doomed to failure and secondly many reports lose their meaning in translation  from IT terminology to business speak, or BS as some of us call it. In fact as far as the business is concerned are reports might as well be latine scripta sunt in. And of  course what  Horace actually wrote was

"Brevis esse laboro, obscurus fio" 

At this point you might nod sagely and recall Churchill saying

"There are lies, damned lies, and statistics."  

Shame on you though if you think that means statistics are stuff and nonsense. If you knew your Churchill you would know the great value he placed on statistical information. It is no coincidence that operational research grew up as a discipline during WW2.

I spent a lot of my early career producing New Scotland Yard's crime statistics so I could bore you to death for hours but let me keep it very simple :

• Bad reports are worthless

• Good reports are priceless

What is a good report?Again, very simple: It tells you something you did not not know before reading it.

Now if I want to fill a conference session I'll speak about reporting . Whatever advice I give, l know that what most of the audience actually want is a standard  list of the metrics they should produce .

Which means they haven't listened to a word I've said.

There is no golden list. What you need to report on is driven  by context. A report that might hav been vital last year might be just so much noise this year.

I hate doing this, but sometimes I have to. Let me give you some guidance that will help you realise you aren't producing useful reports. If it makes you feel better these are all lessons I've learnt the hard way .

• If you don't produce the figures one month, does anyone notice or care ?
• Do managers just pin your graphs up to decorate their offices ?
• Can you tell a story about what the figures are telling you?
  You should be able to write at least three sentences:
• what the figures mean
• should we worry about what the figures mean
• what should we do in response to the figures

Of course of you are on top of your game you will have:

• Looked at individual figures in the context of what other figured are telling you.
• Identified in advance the thresholds for when action is required, and those thresholds will enable you to avoid failure, not respond to it
• Thought through the actions people need to take.

So today's homework: go away and assess the reports you currently produce against these criteria.

Tumbleweed

You might have noticed it has been kind of quiet around here. Not so behind the scenes where a lot has been going on. There are plenty of articles in draft waiting to be published, including the latest instalment of Brandon Lane and Core ITSM 101 on reporting.

I've also been having some very interesting conversations about the governance of IT and ISO 38500.

So watch this space.