Eating the ITIL elephant one leg at a time

It is ridiculously common for advice about ITSM to talk about which ITIL process to do first, or what order to do the processes in. Even the official books Planning to implement Service Management and ITIL Lite are built on the premise that an ITSM initiative is assembled from the ITIL processes. Wrong wrong wrong.

Take as a random example Change Management Can Be Key to Winning Business Backing for ITIL by Ann All.

It was Ian Clayton who pointed this article out on twitter as "another post about what ITIL process to start with is like choosing which truck to run in front of".

Ann started out well with

I think many organizations take a big-bang approach to ITIL instead of first focusing on what business problems they are trying to solve or business goals they are trying to achieve, questions that should help them determine...

and then fell at the last hurdle

... which processes to implement first.

Processes aren't lego blocks. You don't stack them to build ITSM.

Put another way, you don't eat an elephant one leg at a time, you eat it one steak at a time. And one mouthful at a time within the meal.

As my Tipu Method will explain soon when the details are published (under Creative Commons license):

We should understand what are our business goals for service, and derive from those goals what are the required outcomes from service delivery, then focus on improvements that deliver those required outcomes … and nothing else.
One way to improve focus is to work on smaller units than a whole practice. Tipu decomposes the service management practices into smaller, more achievable units of work, called “mahi”. The approach goes like this:

    The value we are asked (or propose) to produce is A.
    Therefore the organisational goals or Objectives are B.
    Therefore the improvement Outcomes required are C.
    Therefore the programme Outputs to be produced are D.
    These outputs come from processes practices E F and G.
    Specifically they come from the following bits of those practices H thru Z

By breaking it down into only the bits that compose a solution to deliver to a customer-focused business value, rather than working on a whole practice for its own sake, we are starting on the outside and drilling in, focusing on demonstrable value.

Comments

is one elephant going to be enough?

Wonderful article, excellent approach of turning the saw upside-down, Rob.
You are of course talking about a holistic ITSM mindset and strategy,and Ann is probably coming from the legacy Service Support story, strugling on how to tacle the donkey. Which became an elephant in the meantime :)

Of course you know you are wrong!

Most ITIL initiatives are driven from the board, otherwise how do they get funded?

And by the way, it not only the board behind the ITIL initiative, its also the Auditors - you know, the trusted advisers!

A basic requirement of any good financial audit is a check on general controls, which of course includes "change management". Heaven help you if there are few change requests that are not signed. This must be reported to the board, its significant (at least the book says so)!

Trusted advisers cannot be wrong, so find a solution to take away this audit finding. Enough said, let me phone a vendor. Oh, change management! What is really needed is a good configuration management system to record all of these changes, especially if they can automate and record the authorisation of changes requests.

Problem solved. IT management have got the silver bullet the vendor promised, the auditors are happy, and so too is the board. A classic win-win for all!

Rob, have you got it wrong! There is a very good reason why most ITIL implementations only address Change and Configuration Management, a very good place to start!

Marvellous at the mahi

Nice piece Rob, hard to disagree with any of that.

ITIL claims to provide 'a cohesive set of best practice', I think it's probably closer to an organised set of good practices frankly, but essentially it's addressing your E-Z.

To me the biggest mistake is not focusing on process priorities - because any good process improvement consultant will focus on the activities from which value is derived anyway - but in failing to define the value in the first place.

If you can see that the business value is in fewer incidents and in those that happen being resolved more quickly, then planning improvements in incident, event, problem management are natural primary focuses and - helpfully - make nice names for work packages. This doesn't mean you're going to 'do that process' in actual delivery, you're [hopefully] going to look at those elements from which the organisation will benefit (hopefully the value definition).

A previous client engaged me to deliver a capability assessment, Change Management and then whatever "service delivery processes" I deemed priorities. Of course I did what they asked and built a process roadmap, but whilst the work packages took on ITIL process names my delivery focused on building value activities and removing blockages within the IT organisation, and relating them to a business problem they'd actually written down. This involved elements of pretty much every ITIL process.

The client fell in when they began to notice how different elements were having 'disproportionately beneficial' impacts elsewhere, and how there was greater control around the way they did things but that it didn't feel like they'd been through wholesale change. The business fell in when they realised they'd not had a single major incident in a year.

Their defined business value was increased availability. They knew a lack of control in their changes were causing immense difficulty. They knew they didn't know how to manage incidents. They knew what there was of their knowledge base was littered with 'reboot server'. The good practices defined in ITIL changed their world, in the form of processes, but not necessarily built that way.

I guess like you I'm concerned that the ITIL baby isn't thrown out with the bathwater because people do insist on approaching it as an out-of-the-book magic bullet. And I know you're 'selling' TIPU, but I think the mahi are there in ITIL - alas the people who recognise they need it don't understand it. And that's true of way too many consultants too.

I've discussed with Ian before that I feel ITSM and USM have different focuses and it's perfectly reasonable for ITIL to focus on IT departments because they need sorting out and that's what it's there for. What's weaker from ITIL is the defining value side, Ian's key point, and even more so how to define business value in terms of IT services.

Even so, as a set of practices - good, largely - it's marvellous at the mahi.

Rich

PS. Those that sell processes on the back of tools should be shot at dawn.

WOW!! Never have I had to read aloud so much!!

Good Post Rob, I have to admit, I did have to read a few of the responses out loud so they made more sense.

All in all leading people through the alphabet is the challenge. Often a client starts with wanting to 'Implement ITIL'. As you correctly point out the next step for a consultant (be they internal or external) is to start with A, and move through the rest of the alphabet (Mahi) as outlined above.

My question though, is how many consultants have the capability to lead their clients down this path? And how do you do it in such a subtle way that you don't invoke and empower passive resistance?

As we all know eating the elephant a bite at a time is the right way to go about doing things, the only challenge is eating an elephant is overwhelming for many an organisation.

Cheers

Andrew

One request at a time!

Rob

At last - a verbal wave is happening that makes sense. As I've said for years "PUT DOWN THE IMPLEMENT". Agree agree agree. implementing anything, unless its a tool to support what you have already worked out as your customer centric service management approach, is at best guessing, at worse a total waste of the businesses money.

Think and act 'outside-in' - yes I said it. Thats me Mr. OI. Buy coffee and doughnuts, go on a 'service safari' and observe your customers in their natural habitat. Lure them to you with the doughnuts (I find this works best), then ask them what they do. record every word and then convene doughnut session #2, back at IT. Find a whiteboard or big wall and start to stick paper up there describing each action the customer performs to get what they want done, done.

Then, add the interaction with systems and It folks and what work it drives within IT. You will find you are mapping the journey of a service request through IT. Amazing. THEN and only then, when you have worked out whats actually happening and why, you add the 'support processes', which include things like incident, change, and applications.

This is service management - next generation service management. get used to it - its here. No more reengineering. No more process improvement. Wrong approach. Fails the customer. Exposed by the disinfecting sunlight of this economy and common sense....

I like driving in my car

Hi Ian,

Hmm. My journey to work consists of 'get in car', 'drive this route', 'get out of car' - isn't journey just a flash name for 'process'? If there's a quicker route that burns less petrol, I should probably take it.

I might prefer the scenic route of course and would happily pay the extra time and money - but if the other half is paying the petrol I might be required to change my ways. Imagine if I was a customer of IT thinking that way!

Perhaps the answer's more complex than 'ask the customer' (allow my poetic licence in reducing OI to that statement!), although clearly understanding customer need is a key element. Business strategy might be a bigger factor though, affordability another, and the right answer might just be 'customer, do it differently'.

And the reality is seen in the developments in security in recent years. Few people really appreciate the risks so it's unlikely to form part of that 'what do you do' conversation - and how do you respond if the collective view is that passwords should be no more than 4 characters and never expire? How many business processes need Blackberrys you can wipe remotely?

This is an example of the part of ITSM that isn't purely OI, in my view. In the same way that legal will shape the way the business operates as well as responds to its needs, IT will shape the market for its services as well as respond to it. It might not yet do that maturely, and of course it needs to understand its value and its customers' requirements, but we should allow more room for IT to lead as well as respond.

I like your thinking and enjoy what you write, I do sometimes wonder if your approach positions IT as well with the business as the theory implies. But I'm with you in the spirit of your comment. 'Process improvement' in isolation might actually be making things worse.

Rich

Yikes

And I've just realised I used the term 'process improvement consultant'. Yikes, please strike that from the record!

Saying the Same thing from a different frame

Ian,

Not sure if what Rob is saying is radically different to your point above, in particular A & B.

The value we are asked (or propose) to produce is A.
Therefore the organisational goals or Objectives are B.

The approach may only differ. A third take on OI (which I like) and Tipu (which is refreshing) is why not get the business and IT collaborating together on the organisations Challenge?

Break down the Us and Them, scenario.

Cheers

Andrew

Bravo!

You use ITSM to help solve business problems; "implementing" an ITSM framework only benefits low rent consultants & tool vendors.

Not just seen but felt

Thanks Rob. The view you express is certainly one I share. By focussing on the value solution, we can choose which practice (ITIL being just one set of guidance) or combination of practices that will deliver the result needed.

Not using that which is fit for the purpose of the organisation or the context in which it operates will miss the objective(s) each time. Process only focus is like developing a design without considering the way it is going to be used and felt by all stakeholders. Almost reminds me of Paris fashion week, it might be pretty, or even stunning but not a practical fit or anywhere to wear it but on the catwalk!

Syndicate content