The ITIL glossary needs a defibrillator

In an earlier post I highlighted the fact that ITIL-speak is not aligned with customer terminology.  Now I want to take this a bit further and say that ITIL-speak isn’t even aligned with common IT speak.

IT has a natural language of its own that varies slightly from organization to organization.  To a certain extent, ITIL has tried to go against this in the name of standardization.  Adoption of a global terminology standard benefits the industry as a whole, but does it benefit an individual organization which has already settled on terminology that is understood clearly within the organization?  Naturally, it is very difficult to get people to adopt new terminology in place of a lexicon that has become established over many years, so there are major cultural change issues involved in throwing out something that works for the sake of standardizing with the outside world.  People will not get behind such an initiative because they will not see any value in it – only disruption – which is a fair point.  Standards that don’t bring real benefits to the individual organization fail to take hold.

• IT Manager: "We're calling it X instead of Y now"
• Techie: “Why is that word better than this one?”
• IT Manager: “Because it’s the standard”
• Techie: “Not in this organization it isn’t!”

Indeed, the ITIL glossary is far too cumbersome, with the ITIL V3 Glossary running up a total of 58 pages, there will be few people on the planet who have digested and assumed the entire ITIL dictionary.  Thus, we can never expect mainstream adoption whilst the effort required is so great.  Perhaps terminology should be chopped up into chunks and associated with different processes or maturity levels so that it can be adopted in a focused manner.  After all, there would be little benefit in force-feeding your IT department terminology that applies to processes which are outside the ITSM roadmap.  Once again we find ourselves back in the position of looking things in terms of what is of practical value to us, right now.

 "Mr ITIL, tear down this wall."

To simplify ITIL terminology, each process should have a surrounding cluster of terminology, indicating the standard terminology that is commonly used in the strategic and day-to-day management of that process, including the ITIL, IT and business/customer terminology – and how one maps to another so that it actually helps develop understanding and communication in real life.  This would allow organizations to select a standard set of terminology, but one that fits the context of their own business.

• Customer: “I’ve got a problem with my printer”
• Service Desk Analyst: “Actually, Sir - I think you mean you’re having an Incident.  It will be a Problem when we create a Problem record in our ITSM tool.”
• Customer: “@&#? #$*!”

Organizations that think a change in dialect is going to fix IT won’t make much progress.  It’s about adopting the ideas behind the words, not just the words themselves.

Why anybody who attends a meeting with no agenda should be shot

As promised in my You might be an email junkie if... post, I've finally got round to an attack on corporate inconvenience #2 - meetings!

Many of you will be familiar with the problem.  If you don't think there is a problem, then maybe you ARE the problem.  Everybody sits somewhere on the 'love-meetings-hate-meetings' spectrum.  I personally dislike meetings.  Some people justify their existence with meetings, turning a 2 minute face-to-face into an expensive, hour long pow-wow with a dozen slightly confused people.

Why I don't like meetings

• Decision by committee is rarely productive.  People have roles and responsibilities for a reason.
• No agenda means no direction, too many tangents and a lot of yawning.
• Granularity.  Obsession with working out all of the minutiae in the meeting.  A 30 minute meeting become a 3 hour meeting.
• Value for money.  Multiply the number of attendees by a ballpark hourly rate by the number of hours spent in the meeting to calculate cost.  Would you show the figure to your boss?
• Failure to set action points makes the whole thing worthless.
• Opportunity cost.  What could you be doing if you weren't in that meeting?
• Mobile devices.  Ban them.  If you need to have a meeting, the spirit should be present, not just the body.

Someone once emailed Chuck Norris about a mandatory CMMI meeting. Chuck Norris emailed a blank reply with no subject and one attachment… a roundhouse kick to the face.

Solutions

• Ask if a meeting is really the answer to the problem?  Many problems can be solved by individual face-to-face interactions.
• Refuse to attend meetings with no agenda (emergency CAB meetings and a few others excepted as these have an implied agenda). Commit to using the 'decline' button more.
• The staff or systems which manage room bookings should reject bookings without an accompanying agenda. No agenda = no meeting.
• Use a money clock to easily identify cost and maintain focus.
• Assign actions - clearly.
• Take minutes, distribute and use them.
• Ask if the meeting was worth it.
• Management should run spot checks - examining the agenda, attendee list, minutes, action points, costs and results.  5 minutes every month can keep meetings from regularly spiralling out of control.

Of course, because life is never simple, there are always exceptions.

IT S.W.O.T. Analysis

(Click to enlarge)

More ITIL-Bashing - Institutionalised IT-speak

ITIL-bashing seems to be reaching fever-pitch, so I’m going to throw in a personal gripe – ITIL-speak.  Terminology is one of the few prescriptive elements of ITIL, and although it is useful to have a common lexicon to aid communication, this only helps communication within IT - not between IT and the business users.  IT bods have real problems translating IT-speak, which is riddled with TLAs and long-winded geekery, into language that the business understands.

"Quit your ITIL jibber-jabber!"

I'll give you an example:

Service Request

ITIL-Speak:

• Service Request (ITILv3):    [Service Operation] A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

Customer-Speak:

• I need something new from you

Incident

ITIL-Speak:

• Incident: [Service Operation] An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example Failure of one disk from a mirror set.

Customer-Speak:

• There's something wrong with the thing I have.

However...
Despite the trend for ITIL-bashing, I find myself stepping in to defend it.  Yes, there are problems, but it is the best we have got at the moment.  It doesn't need to die, only to evolve.  I still believe that an expert-moderated ITIL wiki would provide the best platform for ITIL to realise its potential.  When will that be?  That will be the day the ITIL consulting industry dies.

Availability Management: Get rid of the 'nines' and bring in the $$$s.

Availability management is at the core of customer satisfaction.  Without availability, no service is delivered and there is no service revenue.  However, due to the continuous changes in patterns of service consumption, the bottom-line business impact of service downtime ('unavailability' is not a word) will vary from one instance to the next, according to the volume of demand that has not been met, and the value of that demand - after all, not all customers are equal.

IT organizations need to define how service availability translates into revenue.  Availability has become a critical business metric that IT can use to improve service provision and drive increased revenue, particularly for ‘clicks-and-mortar’ e-commerce organizations where downtime equals lots of lost revenue.  Although availability management isn’t the most glamorous corner of IT, from the user perspective it is a key influence on customer satisfaction and thus business success.  If a service is not available, revenue will be lost, the brand will sustain damage and customers will look for other service providers.  Your competitors are only a mouse-click away, so customer loyalty is lost far more easily than ever before.

Why availability is a problem
Many IT organizations are still device-oriented departments, fixated with system uptime as the key availability metric.  These have a grand total of zero relevance to the business. For IT, a ‘five nines’ availability metric (99.999% uptime) may be seen as quite an achievement (about 5 minutes downtime a year), but if that 5 minutes of downtime falls right in the middle of the busiest business period of the year, the direct impact (lost revenue) and indirect impact (brand damage and customer attrition) is likely to be job-threatening.  IT managers who let this happen will have to answer tough questions on why IT wasn’t ready.  IT managers need to understand that downtime is not random, nor does it have a uniform cost every time it strikes.

The Nines - Crap film, crap IT metric

Work from the top down
In the ITIL 3 process map, Availability Management quite rightly sits in the Service Design Processes group, indicating that it is a critical part of the process of designing a service.  Designing high availability into a service is a good start, but there is always a threat of downtime during the operation of the service coming from external factors.  Downtime is always caused by a change of some sort - either a haphazard change applied by the service provider which has impacted the service in an unforeseen manner, or a change in the pattern of service consumption that has resulted in an overload.  Thus, the business needs to be aware of IT changes so they can veto badly timed changes, and IT needs to be made aware of marketing activity that will drive spikes in demand so that they can plan for capacity to meet demand.

Take a holistic approach to ITSM and avoid a world of pain

The Incremental Approach to ITIL

Many organizations want to improve on the cost, quality and agility of their IT service provision by implementing ITIL best practices, but this often seems like a daunting prospect.  As is often the case, the burning question is – how do we start?

You can’t boil the ocean.  Tackling 10 processes simultaneously is prohibitively complex and almost certainly doomed to failure, so the default roadmap to ITIL nirvana is to slice it up process-by-process, selecting the most urgent process (or couple of processes) for improvement first and finding a tool to that supports.  This strategy makes good sense in principle and outputs a rather smart roadmap chopped up into manageable, bite-size chunks. However, there are two major pitfalls with this process-based approach:

• It draws organizations into a web of integrations and upgrade problems as an incremental approach to procurement is assumed by default.
• It ignores the fact that it isn’t 100% of a single process that would bring the most immediate value, but selected elements of multiple processes – to create a ‘thread’ of value across ITIL.

Turn to page one of your ITIL roadmap and the focus may be on applying service desk automation or a solid change management process, but are you giving consideration to the last item in the roadmap?  Vendor evaluation tends to work on a very narrow “what we need now” basis.  If you need a service desk tool, you need a service desk tool, so go out and buy one that fits your needs.  Makes sense so far.  But turn to page two in the roadmap and change management is the next priority.  Does your service desk vendor supply an adequate change management tool?  No?  Then you’re looking at another vendor evaluation cycle.

The vendor evaluation cycle

Integrating two incident and change management tools may not involve a great deal of effort, but each time an additional module is added in line with the roadmap, the cost of integration is multiplied and the pitfalls of integration become all too apparent.  Each stage in the roadmap will be affected by delays, costs and risks.  Implementation is delayed by vendor evaluation.  Integration is often complex and requires expensive consultant time.  Risk of failure is high.

Oops! You failed to plan and fell into the Incremental ITIL trap.

The Holistic Approach

Individual ITIL processes don’t exist in a vacuum.  The greatest value to be gained from the ITIL framework comes from the interconnected nature of the processes.  Much of this comes from the sharing of data across processes (e.g. CMDB).  Implement one process in full and there is no data sharing.  Implement elements of Incident, Problem, Change, Release and Config and you’re leveraging that data five times over.

By slicing ITIL horizontally and tackling the must-have elements, irrespective of which ITIL guidelines they are associated with, you can create a thread of value that spans across ITIL and takes advantage of this leveraging.  Instead of taking a short-term view and putting 100% of your resources into an ‘ideal world’ Incident Management strategy, there is more to be gained by distributing efforts and tackling the must-haves for quick wins, wherever they might lie. This ‘long thin thread’ forms a solid starting platform from which you can get quick results, demonstrate the value of ITIL in action, justify further investment and develop your roadmap in a safe, stable manner.

At a lower level, there are strategies for ensuring a smooth roll-out of your ITIL roadmap.  For example, look at the information you will need to capture to run process.  By standardizing the information stored at an early stage you can avoid administrative issues later on.  A broader view of the specific data requirements can help avoid later projects to realign.  It’s a lesson that organizations often learn in hindsight and one of the areas where a consultant can really help out.

Holistic ITIL gets the "Pareto Middle-Distance Stare of Approval"

Planning is, as ever, critical to enabling this holistic path to value.  Work out what you need now, but also look at what you want in the long term from your ITSM strategy.  Having a 3-5 year view may not be of great use to you now, but it can certainly help avoid some of the many pitfalls in the future.  Factor this into your vendor selection and you stand a better chance of supporting your long term goals without getting stuck in a quagmire of integrations projects, upgrade paths and administration overheads.  Evaluating toolsets against how they can support your extended roadmap is the key to avoiding many of these problems in the future.  How many vendors do you need to work with to enable your plan?  Fewer vendors means fewer of the issues that plague enterprise IT solutions initiatives.  Selecting a vendor with comprehensive support for ITIL processes can mean that you don’t get the best-fit for each one, but it’s unlikely that your ITSM needs vary more than 20% from any other organization in the same industry vertical and gaining 80% of the value from 6 processes is better than 99% from just one.

Remember, ITIL is a means to an end.  Don’t just focus on applying ITIL.  Go for breadth, instead of depth, to leverage process overlap and interconnectivity.  Focus on the parts of ITIL that are of value to you and prioritize them in terms of value to the business as a whole.  In these days of economic flux, IT needs to be seen as an asset to the business.

Cloud Nonsense - A Collection of Cloud Computing Faff

The trend for bad cloud metaphors has been going on for some time now.  Thankfully it seems to be running out of steam and the wave of cloudmania has hopefully broken.

Bad Cloud Metaphors

• Storm warning for cloud computing 
• Lightning Talk: Crunchy Cloud Computing (???!)
• The Fog over the Grimpen Mire: Cloud Computing and the Law
• Cloud computing - Storm clouds or is it smooth flying? 
• Above the Clouds: A Berkely View of Cloud Computing 
• Cloud Computing: Overcast and Spreading Gradually 
• Cloud computing faces an overcast future before skies will clear 
• Partly Cloudy - Blue-Sky Thinking About Cloud Computing 
• The Dark Side of the Cloud 
• If the Clouds Burst 
• Clearing The Air On Cloud 
• Cloud computing promises a rainbow of benefits
• Not Every Cloud has a Silver Lining
• Lightning strikes Dublin cloud computing

 "Don't you dare associate me with this nonsense!"

Winner of the Cloud Nonsense Award 2011

Cloud computing can cause rain and land the poor villager in jail

This is a direct quote:

"Cloud computing is unreliable in a storm; if it rains, the data might get washed away. Information stored in mobile phones leaches into the phone’s battery and stays there even if the SIM is destroyed. Whatever you say hangs in the air around you for an hour, and can be sucked into recording machines and played back."

Priceless.