Oscar Wilde once said that "The cynic knows the price of everything and the value of nothing." I shudder to think what young Oscar would have said about I&O organizations that don’t know what it costs to deliver individual IT services let alone the value they deliver to the business. Just knowing that it costs “x” annually to “run IT” is no longer enough.
This might appear a little random at first but I was reminded of something I wrote two years ago when informed last week of a CIO fired because they couldn't articulate the value their IT team delivered to the business.
So ask yourself, “what value does IT deliver to the business?” Not in generic terms like business process-enablement and technology-supported efficiencies. What does the money we invest in IT each year actually deliver to the business in terms of value? More importantly, which IT services deliver the most value and which deliver little or no value?
Hold on a minute though. Do you actually know what “value” is from a business perspective? I’m not talking about the value I&O believes its IT services deliver; I’m talking about what the business thinks.
Am I moving too fast? Let’s take stock of the status quo.
“I remember when I lost my mind” … oops that’s Gnarls Barkley. I should have started with … I remember when software asset management (SAM) was on my radar as an IT service management (ITSM) practitioner. It was circa 2003, and my then employer was scared to death of the implications of non-compliance. We did some ground work but IMO it somewhat “died a death” when we realized that we had no idea where all the purchase records were – let’s assume they are all compliant now. Since then I have viewed SAM as just being on the to-do list for far too many organizations, never quite making it into the realms of actual “doing.” Sad but true.
Thankfully, however, my first three months at Forrester is changing this opinion – as 30% to 40% of my client inquiries relate to IT asset management (ITAM) and SAM (if you are interested the other 60% to 70% relate to ITIL adoption, process improvement, and ITSM tool selection – there’s a lot of tool replacement going on). SAM is rising from the ashes of its compliance era, in many ways this time “it’s all about the Benjamins.”
In a “spare” hour this afternoon I needed to create a list of the Top 20 ITIL adoption mistakes for a Forrester client. An hour later (I made sure I time boxed myself to avoid scope creep … oh dear, scope creep could be included below too) I had 50. Quite scary really.
Anyway, IMO it’s an interesting list and most likely incomplete. What it is, however, is something that could potentially be used as a tick list for organizations starting out with ITIL or considering a change of IT service management (ITSM) tool. Please take a read and let me know what I missed (or if you think I am making bits up).
Understanding and Vision
1. Believing the ITIL hype or, for my American friends, “drinking the Kool-Aid”. It’s about improving the business not adopting ITIL
2. Not understanding what ITIL is, i.e. that it is only a framework. There is no such thing as ITIL-compliance. Oh and ITIL does not equal ITSM and vice versa
3. Not understanding that it isn’t about “doing ITIL” but rather that it is about “using ITIL”
4. Thinking that either ITIL is a silver bullet or that it is “the only fruit”. What about ISO 20000, COBIT, USMBOK, Six Sigma, and CMMi?
5. Not fully understanding the breadth and depth of the changes it will require across people, process, and technology
6. Not understanding the level of resources (including cost) and commitment needed to adopt it
7. Not understanding the criticality of people to success
A “bonus” blog today (and hence it is quickly constructed) and the subject area will need to be returned to at a later date. The reason for the bonus blog is that I am a little bit excited.
SysAid, a provider of IT help desk and customer service software solutions, has provided me with a subset of the service desk benchmarking information captured through its customers’ use of its software (on an opt-in basis, of course).
To me, this is the sort of stuff that the ITSM community (see my previous blog) is crying out for – information that helps them to understand where they are and what they should aspire to. More information about the SysAid benchmarking is available at http://www.ilient.com/it-performance-benchmark.htm (link is provided for more detail on the definitions for the benchmarks below).
Average Service Requests (SR) closed per Admin (Service Desk Agent)
Important note: If you follow the above link, the assumptions show that the SRs are “incidents.”
Quick comment – I am assuming that this is per day but I am seeking clarification. As with all the slides in this blog, please treat with care in the absence of sample sizes.
In IT service management “circles” there’s a lot of talk about Social Media (with new terms like “Social ITSM”) and Cloud (with debates such as “Is Cloud the death knoll for ITSM and ITIL?”), but what about another aspect of the changing business and IT landscape that doesn’t get enough attention – Mobile?
We all have mobile devices (and I am deliberately stressing “devices” here), I don’t know whether I am a good or bad example having travelled recently with a work laptop and BlackBerry along with personal Android and iPhone devices, and an iPad. I know, how sad. But mobile devices, and their use and management, pose a serious challenge to I&O organizations.
“Enterprise Mobile Technologies: Individual employees are able to put the latest mobile devices and apps to productive business use faster than their employers can. Our data suggests the most highly mobile (and highly paid) employee segments (33% of the information workforce) already embrace these tools to make themselves more productive from work, from home, and from the road. What it means: Companies have little control over who uses these.”
For those of you that put up with my tweeting on Twitter, you will already know that I am obsessed with customer service. Or to be more accurate, I am obsessed with being treated like a customer. While a polite Englishman at heart, I am not prepared to tolerate poor customer service. In the words of David/Bruce Banner, “You won’t like me when I am angry.”
“But what has this to do with ITIL?” I hear you screaming at your screen. Please bear with me as I recount last Saturday night and Sunday morning (thankfully there is no link to the film of the same name).
Last weekend I spent a single night at a “chain” hotel. The customer service upon arrival was excellent, on the back of my loyalty card I received a room upgrade and complimentary soft drinks and chocolate bars in the room. Ah, the world was good and I was “living the dream.” I felt like a valued customer. Fast-forward to the following morning and the picture couldn’t have been more different.
During the night the room had been so hot that it was difficult to sleep. “You should have turned down the heating or opened the window,” I hear you cry. Check and check. The wall-mounted thermostat made no difference. The window, somewhat morbidly, had been screwed shut. I didn’t call down to reception as I couldn’t face a handyman/woman messing around in my room in the middle of the night (if they were actually available).
No, this isn’t about the returning of your ITIL books to ITIL’s makers (just think how much they would cost to post) but more of the reaping of the knowledge and experience held within the ITSM community (ITIL’s creators, publishers, trainers, consultants, software vendors, ITSM practitioners, and ancillary roles such as analysts) for the benefit of all.
This is by no means a new idea. Various conversations have taken place over the years to create lower-level, more granular, and ultimately more practical best practice information that is freely available to ITSM practitioners. Whether it is in the form of blogs, white papers, discussion threads, podcasts, special interest groups, or “free” training and events, such information is invaluable to the IT people “at the coal face” who don’t want to have to “reinvent the wheel” nor to have to read through a set of ITIL books which IMO isn’t really designed for the hectic work lives of ITSM practitioners. Practitioners just don’t have the time even if they have the inclination. They will also struggle to find really practical help and assistance from such a "sea of text."
With the updated version of ITIL imminent (the 29 July 2011), I participated in a BrightTalk webinar on “what next for ITIL.”
My views on this are very clear, that we need to “look back before we look forward.” I touched on some of this in a previous blog, 2011: An ITIL Versioning Odyssey, but think it worthwhile to continue to articulate my views in this area.
Let's start with what I consider to be the biggest issue: the gulf between theory and practice with ITIL.
There is no doubt that ITIL can benefit I&O organizations. There are certainly many I&O organizations encouraging, or even forcing, their people to take ITIL training and qualifications: There are at least 1.5 million people with the certification and there is no sign of this slowing down. Not only are trainers busy, so are ITSM consultants and, of course, industry analysts. But, from an industry analyst perspective, there is a lot wrong with ITIL. This is not just how it ballooned in size from ITIL v2 to ITIL v3, but also how it is adopted in the real world.
So what's going wrong?
If you look at existing ITIL v2 adoption, there is a focus on the reactive elements such as incident management, problem management, change management, and maybe even configuration management and service-level management. How many organizations have moved on to the more proactive elements such as availability management, capacity management, IT financial management, and continual service improvement?
My colleague, Glenn O’Donnell, and I (do I sound like the Queen?) have delivered a Forrester report called “Improving The Ops In DevOps” inspired by the long-bemoaned tension between “change-the-business” (dev) and “run-the-business” (ops) IT teams and their activities, and the need for change.
This tension inflicts a detrimental impact on the business. In fact, most organizations suffer this curse, and stereotypes that reflect this animosity abound. Does this sound familiar? Ops people see dev people as sitting in their ivory towers cranking out code all day and wanting to release applications oblivious to real-world constraints; dev sees ops as cog-turners ensuring that the IT infrastructure doesn’t break under the strain of poorly written code. Chances are that your organization is not this bad. But this exaggeration is indicative of the tension between these two IT “tribes” and their opinions of each other. These stereotypes exist because organizational behaviors do exaggerate genuine conflicts, and both parties must act quickly to change.
Getting DevOps right will address many of the issues enterprises consistently have with IT, such as applications failing to meet both functional and nonfunctional requirements, delivery delays, increased costs, and an inflexibility to change. But is DevOps enough to save I&O from extinction?
I recently spoke with a Forrester I&O client looking for “incident classification best practice.” I knew that I should have had knowledge of this, or at least access to it, but all I had was a loose set of guiding principles that are probably more “common sense” rather than “best practice.” I was happy to talk with the client but wanted to know what I had missed.
Google seemed a great place to start. After all, Googling “ITIL” results in 21 million hits (I do appreciate that not all of these will relate to the IT service management best practice framework though). So I Googled “incident classification best practice” (plus “incident categorization best practice”) and was surprised at the results. Well, the LACK of results. There was no freely available advice or guidance on this subject.
The main reason for my surprise is that, with the wealth of IT service management best (or good) practice out there (especially with ITIL espoused as THE framework of IT service management best practice), this is one area where I definitely think that value could be derived by documenting successes and the pitfalls to avoid.
Given that many organizations adopting ITSM best practice, or ITIL, will start with the service desk and incident management, the creation of a robust incident classification hierarchy is something they will need to do. A similar opportunity also arises when organizations switch between competing ITSM products as part of the well-documented ITSM tool churn. For others it is relevant when the realization sinks in that the existing incident classification hierarchy is cumbersome and ineffective. Incident classification is important, so where is the best practice?