In my recent blog on the top 50 ITIL adoption mistakes many related to the people-side of changing the IT service management (ITSM) and IT delivery status quo. In many ways, people are the ultimate barrier (or success factor) to effective ITIL adoption or to other aspects of an IT infrastructure and operations (I&O) organization successfully meeting business demands for IT services.
We often get the technology and process elements of what we do in I&O right, but the people-side of things can be a different matter. Paul Wilkinson of GamingWorks has been a champion for addressing the ABC (attitude, behavior, and culture) of ICT for many years and he shares his (and his colleagues) thoughts with us below.
So what goes wrong?
As more and more organizations adopt ITSM frameworks such as ITIL, it often seems that ITIL or the framework is the goal itself, rather than being a means to an end – that is trying to improve the delivery of IT services from a business perspective.
Paul states that, in his experience, 70% of ITIL-adoption initiatives fail to deliver on their promises, i.e., realizing the value that the I&O organization (and business) had hoped for; with 50% of failures caused by resistance. However, we (the people) tend to blame the framework or the technology. But it often has nothing to do with ITIL – the root cause is commonly the way in which we (mis) apply and (mis) use the framework. That these failures are often down to people issues.
IT infrastructure and operations (I&O) people have long bemoaned their service desk or IT service management (ITSM) tools. It’s a fact of life, well ITSM-life anyway, and analysts will often pepper conversations with clients (and anyone else that will listen to them) with comments such as “that on average an organization will change ITSM tool every five years.” Some analysts quote longer, others quote less. In many ways, whether it is three, five, or seven years is unimportant. It is the fact that organizations are changing tools that is.
In a soon to be published joint Forrester and itSMF USA survey and report my colleague, Glenn O’Donnell, offers up an interesting service desk tool statistic: that, with the exception of SaaS tools, approximately 30% of responders are unhappy with their service desk tool.
Of course, one could argue that this is a little “glass half empty” (that I’m an analyst trying to line the pockets of ITSM-tool vendors) and that the “full glass” view is one where 70% of responders are happy with their service desk tools.
Yes, I could take this view, but I would be doing the ITSM Community a disservice. The big question for me is “why is SaaS only at 4% dissatisfaction?”
A while ago, in fact too long ago (but not in a galaxy far, far away), I wrote a blog called Giving Back To The IT Service Management Community where I surmised that IT service management (ITSM) practitioners need help beyond the ITIL books and associated training. They need real-world help; whether this is by way of guidance, quick-start templates to prevent the “reinvention of the wheel,” benchmarks, or by other means. And that, while some members of the ITSM community already offer help, what practitioners really need is to be offered targeted and focused help. A response that is practitioner “pull” rather than helper “push.”
In short, I proposed that we need to do at least five things (as a community) to help:
Recognize that we are a community and a community that often struggles with the same issues (particularly with ITIL adoption).
Offer up our time to help out others (and often ourselves).
Identify where our efforts need to be applied (for example with the creation of a set of standard (core) ITSM metrics and benchmarks).
Deliver on our promises to the ITSM community.
Never stop trying to improve our collective ITSM capabilities and the quality of delivered IT and business services.
Is it a blog? Is it a musing (that’s not “amusing”)? Or is it just a cheap attempt to pick the brains of others smarter than myself? Does it matter? Can I do anything other than ask questions?
My point (or at least my line of thinking while I plan a couple of ITIL-related Forrester reports) is that we spend a lot of time talking about what to do (or more likely what not to do) when "adopting ITIL," but how often do we talk about whether we have been successful in applying the concepts of ITIL, the processes, and the enabling technology for business benefit?
Maybe it is because we quote the mantra that “ITIL is a journey” and we can’t see a point in time where we can stop and reflect on our achievements (or lack of)? Maybe we segue too quickly from the ITIL-technology adoption project into the firefighting realities of real-world IT service management? Whatever the potential barriers to taking stock, where is that statement that describes what we have achieved and our relative level of success?
Looking at this logically (fatal mistake, I know), assuming (potentially a big assumption) that there was a business case for the “ITIL adoption project” where is the post implementation review (PIR)? Where can we look to see the realization of business benefits (I deliberately didn’t say “IT benefits” BTW)? I’m trying not to be cynical but, even if we forget the formalities of a PIR, how many I&O organizations can quantify the benefits achieved through ITIL adoption? More importantly what has been achieved relative to the potential for achievement? Where did we get to in our desired-future-state?
Help mummy, that horrible man is talking about finance again.
I jest, but I very nearly titled this blog “Warning: This Blog Is About IT Financial Management And ITIL.” Sorry, but this is how I feel sometimes when I talk about the financial side of IT management, IT service management, and ITIL adoption.
But remember, accountants are supposedly boring not scary. The really scary thing is that IT infrastructure and operations (I&O) organizations have survived for so long without really appreciating what it costs to deliver their IT services.
There is no denying that I&O organizations have always “done finance” in some shape or form. There is not a single business function, IT or otherwise, in any organization that can escape the need for some semblance of financial management and the scrutiny from the formal finance department. So my question to I&O execs is not “Are you doing IT financial management?” but rather “How mature is your IT financial management?”
The changing business and IT landscapes are bringing an end to a somewhat slapdash approach to managing I&O’s finances and investment and usher in the need to extend IT financial management to encapsulate the concept of value. Read on, Macduff.
Why haven’t I&O execs focused on maturing their IT financial management practices?
Earlier this week, I attended the Hornbill User Group (or "HUG" as it is affectionately known) to listen to Malcolm Fry, IT service management (ITSM) legend and author of "ITIL Lite," talk about ITSM metrics in the context of ITIL 2011.
There is no doubt that metrics have long been a topic of interest, concern, and debate for ITSM practitioners (I wrote a piece a few years ago that is still the most popular item on my old blog site by a huge margin), and IMO I&O organizations struggle with the area due to a number of reasons:
I&O is not entirely sure what it is doing (in terms of metrics) and why.
We often measure what is easy to measure rather than what we should measure.
I&O can easily fall into the trap of focusing on IT metrics rather than business-focused metrics.
I&O organizations often have too many metrics as opposed to a select few (often led by the abundance of reports and metrics provided by the ITSM tool or tools of choice).
There is no structure or context between metrics (these can be stuck in silos rather than being “end-to-end”).
Metrics are commonly viewed as an output in their own right rather than as an input into business conversations about services or improvement activity.
I need to make this brief; the failure of the lump of plastic that used to be my BlackBerry has made me very time-poor today …
It has been an interesting year for RIM and for the BlackBerry. RIM has seen the erosion of its corporate mobile-email dominance (as employees prefer the usability of iPhones and Android devices), its brand was adversely affected by the BlackBerry Messaging Service being "the weapon of choice" for the thugs involved in the London riots, its tablet play has limped into the iPad's market, and now we have the prolonged service outage ... Sorry service OUTAGES.
The extent of the outage has been and continues to be shocking (there is no way it should have been this severe). But to me, in my capacity as an analyst, and observer and advisor on IT service management best practice, the real issue here is how RIM has handled the situation.
In managing the outage, RIM has acted like an old-fashioned technology vendor rather than a modern-day service provider; while we talk about BlackBerry devices we are really buying into the BlackBerry service. And we expect that service to be consistently delivered relative to service promises and our expectations thereof.
While we would prefer there not to be an interruption to service, most of us appreciate that "stuff" happens. When there is a service-affecting issue, we have a set of minimum requirements as customers that need to be catered for:
Firstly, we want early notification and a speedy resolution or a work around. As a minimum, that the service provider is visibly seen to be applying significant and varied efforts to the resolution of the issue. We want to see that the service provider cares.
Secondly, we want our expectations to be managed. Communications should keep us informed and be honest about when we should expect service resumption.
The IT infrastructure and operations (I&O) organization is no different from any other business function. It employs a multitude of assets to create corporate value. Traditionally, however, I&O’s ability to manage its IT assets has been weak, from both a financial control and an IT asset life-cycle (ITALM) perspective.
Far too often, an I&O organization lacks the necessary controls to avoid IT wastage or remain compliant with software licensing or regulatory requirements. Thankfully (or unfortunately), to date most I&O organizations have been able to get by. But the-times-they-are-a-changing, as do-more-with-less efficiency mandates are prioritized, vendor software audits increase, and the business places greater focus on what IT costs and the value that internal IT delivers. Something has got to give and I&O leaders can step up their game and respond to these internal and external pressures by improving asset management processes to ensure that IT assets are leveraged to maximize the value generated for their parent business.
The IT Infrastructure & Operations (I&O) community has long been awash with management buzzwords and phrases such as "think outside the box," “bare metal,” “IT-to-business alignment,” “ivory tower,” “NextGen,” “people, process, and technology,” “innovation,” "what does good look like?" and “resonate.” More recently we have had to endure such gems as “cloudwashing,” “hash tag abuse,” “virtual sprawl,” and “cloudenomics” (please take a deep breath, don’t let them wind you up).
Another longstanding “buzzphrase” (no, I didn’t make this word up) is that I&O organizations need to “run IT as a business.” I imagine that most of us have used it (I plead “guilty” milord), at least in conversation, but do we really know what it means or what we need to do for I&O to achieve a business-like state?
Firstly, the “run IT as a business” mantra is wrong – well, partially. I&O organizations must indeed adopt practices to run as a business function, but not necessarily as a full business in itself.
One of the most prevalent areas in need of attention is that of the ITIL-espoused discipline of IT financial management. In that business-success not only stems from having a great product (or service) coupled with great customer service, there also needs to be an understanding of the cost of provision, the cost drivers, and the margins involved. Not having this understanding can only expose I&O’s lack of business acumen and capabilities, and make it difficult to compete in the new IT delivery landscape.