ITIL was "crowd sourcing" is it still?

ITIL V1 was a collaboration of industry experts leveraging their best practices and current organisation to produce a library of "best practices".

Interestingly ITIL was not a dive into how these experts came to these decisions, it was merely a definition of what you should look like if you were following best practice.

Did we miss out?

The benefit of learning how a conclusion was reached is that it allows others to build upon this discovery, you don't say e=mc2 and leave it at that, you need the working, the story of how you proved that this was indeed true.

The problem with ITIL is that we not only don't have the story of how these IT experts determined that these best practices were indeed best, what methods they used to get there, the pitfalls and successes that shaped the final result. We also have no description on how to implement it from a standing start.

There are reasons for this lack of the "how" the main one being that every IT organisation is assumed to be sufficiently different that it would have to be too broad to be useful.

Where does this leave us?

I have written before about where ITIL is heading but I think it's worth reiterating, the IT industry does not need another "this is how you would look if you were perfect" book from a library. We need tools, methods, Etc.

There are many of these out there, LEAN, 6Sigma etc. none of them are perfect, but at least they try to get you to the goal.




Read more...

The Human Element

I was busy writing a little blog post about how process and statistics can, when taken to extremes, actually make life harder...when I stumbled upon this great article by Lucid IT.

My original blog post was going to talk about the following scenario:

After upgrading a server for more memory upon powering the box back up it looks like it won't boot. The memory is removed but still nothing. It turns out that it's the hard drive, which is replaced and everything works.

however....

The change was not completed, and it ran over it's window(or was that an incident), the incident of the hard drive was not logged instantly as it was assumed that the issue was the memory. Did the change cause the HDD failure?

How to categorise this change?

Rarely will a process define the options in such detail, and as described in the article mentioned it really behooves you NOT to write a process that defines every possible outcome.

Leadership and value

Leadership and delegation of responsibilities are vital, a process is inflexible; it's the people who need to be empowered to deal with these unexpected situations.
This may sound a little scary to anyone who has spent years trying to get process in the door of an IT shop, but the bottom line is that process is supposed to be valuable. Rather than spending hours in digging in the weeds to give the perfect catagorisation it may be more valuable to just pick one and move on, a single change will not determine future IT spend after all.

Maybe the IT worker isn't superfluous afterall!

Read more...

Understand the goal before you set it

Thought: When running the race to great service: Experience counts.

When running a marathon or cycling "a century" for the first time, one usually does some serious practice. Over a period of months, you get an idea of your ability. When the inevitable question, "What time are you shooting for?" arises, the answer is suitably vague to avoid later embarrassment and also because it’s only possible set very general expectations.

Experienced professional athletes have completely different perspectives on goals. They have perfected their technique over time; they understand their fitness levels and where they are in the season, enabling them to decide to hold something back for the world championships or leave nothing in the tank at the last meet of the season. They will have a specific target time and race position.

In an organization embarking on an ITSM program for the first time, we shouldn't have the same goals as an experienced practitioner; we should have vague targets that will tighten up over time.

Single focus or multi-discipline?

The runner analogy is simple but unfortunately the IT management world is not: The practice of an IT manager is more akin to a decathlete; as a multi-discipline leader we must decide where we will get the most bang for our buck. But there are only so many hours in the day and so much money in the bucket, so where is it best to spend our valuable resources?

Start with the obvious questions:

How good is good enough? Do we really want to be world-class in a particular field?

These are questions only you can answer. As with most answers, they are usually more accurate with better more reliable information to base them on:

Do you have this information? How can you get it? Where will it come from? Is this the first step?

To get back to our analogy, even the novice runner practices, gets baseline data to build from, and understands basic but amorphous goals to aim for.

Putting this Thought into practice:

1. The first thing to do when starting an ITIL adoption is determine where you are starting from.
2. If you can't really determine that baseline DON'T PANIC, maybe that is a good first goal, it will be cheap with demonstrable results.
3. Once you have a baseline try to determine where you want to improve, (speak to your customers)
4. Now you have your starting capabilities and your chosen disciplines in priority you can work on your practice schedule and set some vague goals.
5. Practice makes perfect, as you move from beginner to amateur to professional you can and will get better; eventually you can start thinking about being world class (if you want).
   

Parting Thought

Only when you are world-class can you think about your position in the race, until then you are competing against yourself to your own goals – your first goal is to make sure your goals are the right ones.

Read more...

Has ITIL been oversold?

This Blog post by Michael Jagdeo has the following statement:

"The more I speak with industry experts, the more I realize that ITIL is getting a bad name. It’s gotten to the point where some people can’t even mention ITIL, even when they are implementing ITIL best practices!"

Ouch, I hope this is not going to be the standard industry response, I know ITIL has been around too long to be considered a fad, but still this is a concern.

I have been part of a few bad "deployments" of ITIL, and anyone who reads this blog will know I am no huge fan of simply following the dogma (or the ITIL books) without thinking hard about why (hence supportTHOUGHT).

I still believe ITIL has a future. There are issues with ITIL but this post is not about that, I would like to hear some non-sales success stories, I think it's about time we as managers told tales of delivery and value, if the only place for success stories are from consultants and software vendors the credibility gap will only grow.

Thoughts?


Read more...

The right amount of maturity

Youth is wasted on the young.-George Bernard Shaw

I was reminded of this fact today as I overheard a couple of young people calling each other "immature".

Immaturity is an insult, and certainly it's portrayed as a negative in most "maturity assessments", but how much maturity is good for you?


I have no answer to this, as a constant theme in this blog: you need to answer this for yourself, but this should provide a couple of thoughts:

People get more inflexible with time and so does a mature business process, this is great for providing consistent quality, but the world is not remaining constant, your mature process can become elderly very quickly.

Keep this in mind: one person's mature is another person's "past it", to remain youthful and vigorous a little risk can be a good thing!

The IT Skeptic has a longer post about this, also maybe not perfect but thoughtful none the less.


Read more...

Head in the Clouds? 8 things to keep in mind.

I can still remember the first time I saw a cloud on a diagram of a computer system, it was a long time ago and it looked something like this:


I asked a few questions at the time: Whats in the cloud? surely we need to know how the traffic is routed around?

I was told not to worry about it, that the cloud was only a cloud to us; to the network provider it was a well understood network diagram, they could at any point tell what was going where, but that we really didn't need to know.

The SLA was our iron clad agreement that we would have bandwidth and redundancy we had asked for. That the amorphous entity we were using was managed to our expectations.

The problem with SLAs is that they are an agreement not a guarantee, which we found out to our cost.

Today the cloud is the hot new thing... here are some principals for engaging your business in a cloud.

1) The cloud should only be a cloud from the outside, if the people running the cloud cannot describe it in more detail there are issues.

2) You need to really understand your requirements before doing business with any cloud.

3) SLAs are agreements not guarantees, if the cloud fails to meet their side of the agreement make sure you are still in business.

4) For SLAs to work well you need to be able to monitor them. It's likely the cloud can monitor the service they believe they are providing to you, can you do the same?

5) If you backup one cloud with another, it will behoove you to deconstruct both clouds to determine single points of failure, don't end up backing up one cloud with itself.

6) The benefit of the cloud is that it can change as needed, make sure the due diligence you do when first engaging in the cloud is repeated on a regular basis.

7) The cloud will meet more well understood structures at some point: networks, even USPS(!) ensure you have the right expectations from these services too.

8) The final rule is a truism: If something seems too good to be true it probably is, clouds are not miracles, don't commit until you COMPLETELY understand how it works and how you can use it.

This post may have come off negative in regards to cloud computing, I have tried to not comment on the capabilities of cloud computing, which I feel is still being defined, but rather try to encourage the thoughtful decision not to put too many eggs in too few baskets.

Read more...

Cycle Hype

Just read this post, an interesting read.

I recommend it.

My take: know why you are doing what you are doing, if it's ITIL, LEAN, anything, don't believe everything you read and question how and why.

Be cynical of new management trends, if they seem like magic how on earth will you be able to explain them to everyone?

Read more...

ITIL V3, LEAN and Consultation

A week ago I made a quick post related to the fact that ITIL should already be LEAN, and this got me thinking about the evolution of ITIL and whether it has taken a wrong turn.

In the early days of IT management there was no standard way of running IT, everyone did it differently but some did it with more success, it was these successful methods that formed the foundation of ITIL.

ITIL V2 built upon these into a wildly successful framework that has become the de-facto IT operations standard.

ITIL V3 is an update to V2, It was written by experienced ITIL professionals - ones with intimate knowledge of the holes in V2 and where it needs to be extended.

This is a valuable place to get some insight, however, ITIL was a success because it looked outside itself to see where others were running their IT organization using better practice; it took the worlds best IT organizations and showed us how they worked.

There are organizations that have taken non-ITIL paths to success, LEAN, 6Sigma etc; what have they learned? are we embracing innovation and evolution?

The challenge for V3 is the success of V2

The innovation in IT management is not only in the adoption of ITIL but will also come from elsewhere, ITIL needs to be open to success OUTSIDE the ITIL framework and bring this into the fold.

"Best practice" is an endless quest, ITIL needs to ensure that it embraces developments in the Service (and IT) managmement field, that it dosen't get caught in a cycle of perfecting the processes it built in the 1980s while the industry moves on.




Read more...

Introducing the Service desk

In the latest DITY the following issues/concerns with a new service desk has been noted:

Users felt they were losing connection to the technical resources they were used to dealing with.
IT staff felt they were losing connection to the users they had built up relationships with.

I believe these are legitimate concerns of most organisations when implementing a service desk, however the deployment of the service desk is usually done for a reason, in this case we don't know the full rundown of reasons to implement the service desk, but it's noted:

"Our technical groups were looking forward to the new Service Desk as a way to reduce interruptions to their daily work."

The solution presented to this lack of trust is "the 5 minute rule": basically to bypass the service desk and speak to the 2nd level engineer, with a little encouragement to log a ticket first. As long as the conversation dosen't last longer than 5 minutes.

I have the following issues:

1) Though it may be nice to always have an engineer on the end of the phone, if this was the desired situation why bother with a service desk.
2) This 5 minute rule has no ending, this does not seem to be a transition phase but a permanent process.
3) The 5 minute rule was put in place because both sides do not trust the new desk, bypassing it is not going to help build trust.
4) it's likely that the engineers will be just as disrupted as they were before.

Solutions.

This is an organizational change issue, without knowing the organization in question it's tough to be specific, but here are a few possibilities:

1) get all parties in a room and explain why this is being done.
2) find another avenue to maintain relationships, form working teams or process champions, there are more enjoyable and productive relationships than user/engineer available to us all.
3) provide great escalation and reporting to make sure the user experience is not being adversely impacted (at least more than expected).

I believe it is a mistake to build a process with a built-in bypass, people always take the path of least resistance.

Change is difficult for everyone, we need to address that fear rather than enforcing it.

Thoughts?




Read more...

ITIL adoption is not plain sailing

Large (IT) organizations are often likened to supertankers, slow moving, hard to turn - hardly agile. I am not sure this analogy really reflects the true nature of the complexities of leading multi-faceted groups...

I prefer to liken my organizations to a flotilla of ships sailing in a single direction, a single boat is fairly agile and can adapt to the changing environment fairly quickly.

When viewed from high above this mass is all moving in a single direction, changing course though is hard, it requires much co-ordination and effort, a hundred hands on tillers, plenty of shouting.

Its hard to captain this collection of small teams, though they are all moving well under their own power it takes serious effort for the entire flotilla to change course. The other danger is that some outliers will sail off in their own direction, maybe in the same direction the whole group is going but not in sync, making communication hard.

Post ITIL adoption.

There are different ways to picture an organization after ITIL adoption, but I like to relate it to a navy fleet, a smaller number of larger ships. These ships are still relatively agile but are easier to keep on the same page, they have an identifiable command structure and most importantly they speak the same language and communicate often.

This fleet can even have small boats using their agility to take risks, but they are acknowledged as such, the risk is managed and the can be reeled in if necessary.

This to me is one of the real benefits of and ITIL adoption, its not the shiny new tools, it's not even really ITIL per se, its the fact that the organization has a language to communicate with, that effort is expended bringing teams together under one direction, it's the hard decisions that are required to be made to get there.

The above tasks are not easy, they take effort and dedication, but when the next storm of technology, economy or opportunity appears on the horizon would you rather be captaining the flotilla or the fleet?

Read more...

Is ITSM just IT management at this point

Yesterday on twitter I asked the question: "is ITIL and ITSM just good IT management" and I got the response :@RobertEStroud: RT @supportthought: Is ITIL and ITSM just good IT management" No much more involved - look to COBIT for a start #itsm

Which I agree with, but I think the fact that I am a novice in the short form of twitter didn't really help me get my point across, which wasn't intended to be about the span of ITIL.

What I meant to ask was: Isn't managing IT as a service the de facto way of running IT now, does anyone really run it as a bunch of computers? Hasn't that ship sailed?

I actually don't know the answer to this, hence the question I suppose, I reside in the US and even though we are reported to be late adopters I still don't meet anyone who isn't running IT as a service.(or at least trying/intending)

I would be interested to know if anyone has any comments about this, I have a feeling that all this focus on getting everyone to look at IT as a service may be wasted, they buy the idea and really just want a practical way to do it.


Read more...

ITIL and LEAN

A nice post here on IT and LEAN.

I have a few comments around LEAN and ITSM, I think they will take a full post... however as a taster:


I think that LEAN as espoused by Chris Curran in his post is a useful tool and becoming a LEAN organisation is something I can understand having benefits, but here is my question:

Shouldn't ITIL already be LEAN? if these really are the "best practices" shouldn't that encompass organisations that have gone LEAN?

I understand LEAN is a culture not a bunch of tools, ITSM should be to a certain extent too, do we really need to LEAN our ITIL?

Thoughts?


Read more...

More comments to my Previous post

I do not think the "Helpdesk" or ITSM tool space lacks innovation, but it is hard for smaller organisations to compete with the large vendors.

The speed at which they gobble up the niche players to add to their offerings is making entry into the market hard.

I have hopes that the CMDBf standard may actually allow more niche tools to compete on a level playing field, we shall see.

Every year though when I go to conferences I see new software offerings that I had not previously heard of, I think the market is working fine and innovation seems to be alive and well, whether having a "standard" like ITIL to work from has helped these tool creators, or hindered their creativity I cannot answer.



Read more...

Compatible

Response to Service Sphere's blog entry

ITIL compatible is a fairly general description, ITIL certified, either Pink or other is pretty much standard for any "helpdesk" software, if you were writing helpdesk software why wouldn't you?

However I would question how hard it is to be compatible, most of the big vendors' software is so flexible you could customize it into anything.



I too have seen great (and well loved) software leave the forefront, but I don't think that was due to the ITIL Borg, but rather the (big 4 vendor) empire striking back.




PS yes I know that last movie reference was a stretch :)



Read more...

ROI, CBA and how to analyze value

Thought: How is my business going to benefit from an ITSM program?

My answer to this would be that companies that take on a systematic evaluation of how to run their IT dept will see improvements in service, will be able to focus resources in the areas that the customers care about, will be able to really understand the quality of service that is being delivered.

Before we get into the question at hand, I would like to give a little context and definitions:

Investopedia:

Return On Investment (ROI) is a performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. To calculate ROI, the benefit (return) of an investment is divided by the cost of the investment; the result is expressed as a percentage or a ratio. The return on investment formula:

Wikipedia:

Cost-benefit analysis is a term that refers to a process that, whether explicitly or implicitly, weighs the total expected costs against the total expected benefits of one or more actions in order to choose the best or most profitable option. The formal process is often referred to as either CBA (Cost-Benefit Analysis) or BCA (Benefit-Cost Analysis).

So we have two similar and popular methods of determining if a project is worthwhile, or which of a variety of flavours of project are most worthwhile. Neither of these two methods in their basic form can help us determine the value of a ITSM program as defined above until we can actually assign a monetary value to the service improvements.

Typical methods.

The methods I have seen to "justify" an ITSM project are:

1) Reduction in outage time/number of outages (MTTR/MTBF)
This choice seems easy, implement good incident and problem management processes and we should reduce MTTR etc. the issue here is most organisations setting off on an ITSM journey don't have the cost of these outages, and the ITSM program is probably the solution to that. Catch-22.

2) Reduction in costs due to efficiencies.
This is really headcount reduction but could be software licencing due to CMDB implementation, again it's very hard to understand the real savings associated with good ITSM practices.

3) Service improvement/time to market
This is a true goal for most ITSM initiatives, but how do we quantify this let alone monetize it?


So there we have it, ITSM a great goal but hard to justify, and even if we "wing it" and make some numbers up we risk missing, or just faking the results.

So I am left with this question: how can we determine and demonstrate the benefit of an ITSM adoption, in terms that mean something to most businesses (IE cash).


Read more...

SAME

In my previous post I mentioned that I was looking for more information on how to manage IT in a model that is a little less complex....

I have been poring over the SAME document created by Jan Van Bon and Wim Hoving, and I have to say I think it's excellent.

This model seems to capture the realities of managing IT in a simple and easy to understand fashion, though I haven't put this into practice I can see the potential for forming a logical structure around the complex IT organisations and running decisions through the model to see where they fit best.

One of the only negatives I would mention about this piece is the comment that "Information support" is merely a supporting activity akin to HR or Finance, and though I agree with this, I think that provision needs to be made in the model for businesses where IT is the product, where delivery of information is the profit center.

This is only a taster of the full SAME model - I assume this and more will be covered in the full version.

In an ITSkeptic comment recently Jan said:

there's plenty more where this came from. It just hasn't all been published yet, and some of the published material is copyrighted so I can't simply provide it publicly. Most of it is all over the books my team produced with a huge team of experts, in the ITSM Library, a series of books previously published for the itSMF. I'm currently writing 'the ultimate book' on this subject, and a team of authors is writing a series of books on detailed topics, all in the same (SAME) architecture. These titles will be published by Van Haren Publishing, independently from any formal body.

There's one publicly available article I wrote for CEPIS/UPGRADE, titled "This is NOT Governance".
More relevant articles can be found on my company's website, but since that is all in Dutch, apart from one other article on the Process Management Matrix (PMM): here is a shortcut to an English translation of that article. It will tell you how to avoid one of the most common pitfalls when introducing process management ("failing to remove the responsibility from the previously responsible line manager, when introducing new process managers").

I look forward to the "ultimate book" on this subject.

Read more...

How Complex does this need to be?

So.... ITIL has 5 main books covering 27ish "processes", CobiT has 34 processes some of which overlap providing a governance structure of what should be being done, with ITIL explaining (somewhat) how. ISO 20000 details more standards that completely overlap with ITIL and CobiT. LINK

None of these three really cover project management, and nowhere that I can see is there a real prescription for how to manage IT technology or Organisational structure.

It is somewhat of a theme on this blog that this stuff can't be this difficult... is running an IT department really this complex?

What are we really trying to achieve?

All the frameworks call it different stuff but basically we do the following:

1. Plan our future
   
2. Design stuff to get us there
3. Build what was designed
4. Support what was built
5. Report on our success and improve. (I may consider this part of support but it matters little)

Now when I read through all of the 34 processes that are detailed in CobiT I actually agree that they are all valuable, so this post isn't really a comment that CobiT or ITIL are wrong.

Maybe it does have to be this complex, maybe this complexity is real, and what we need is more professionalism in the field of IT management to control all these moving parts.

I would be interested in hearing any opinions and in the mean time I will be out there looking for the dummies guide to building a world class IT organisation, let me know if you have written one.



Read more...

Public domain

Most professions are governed by a set of best practices that are not only well known but in many cases the law of the land, Doctors, Lawyers and Engineers do not sell or hide the rules that constitute the foundation of how they do their job.

A new medical procedure is peer reviewed and though the technology and the procedure are patentable one does not have to license the information to demonstrate, practice or write about the procedure.

A rising tide lifts all ships, and a rising quality of work in most professions is shared.

The recent discussion on the ITSkeptic website brings the ownership of ITIL into sharp focus, all the content though seemingly freely given to the OGC by vendors, consultants and organisations is not public domain. The training materials derived from the ITIL published materials is licenced.

Now, I am no expert in what it takes to create or manage ITIL or how the APMG or the OGC do business, but it would seem to me that the wider the information can be spread the better. I understand there needs to be controls around the quality of any "standard" but does this have to come with such a heavy hand?

In my opinion ITIL should be "by the people for the people", it would seem to already be "by the people" we just need it back. (preferably at cost)



Read more...