The IT Skeptic - Comments for "The uselessness of ITIL process maturity assessment"

I think everybody would agree

skeptic — Wed, 11 Jul 2012 21:41:35 +0000

I think everybody would agree with what you are saying, but just to be pedantic (how unusual) something that helps.and boosts the application of people's energy is exactly the definition of a tool.

Equally pedanticly ITIL is (mostly) not governance and not much of a framework.

ITIL is NOT a tool.

Visitor — Wed, 11 Jul 2012 20:37:46 +0000

Hold on. ITIL is explicitly, by its own definition, NOT a measurement or even a tool. It is a governance framework based on the selection of best practices. People expect ITIL to solve their problems in an automated fashion. Only the hard work of people can accomplish that, and ITIL provides them with a framework to do that. ITIL it isn't a tool - it is a guide for applying energy in the right places at the right time. The energy still needs to be spent, still needs to be measured, and still needs to be refined over time. ITIL is not a "money saver", it is not a "silver bullet", and it is not just "certificates and training".

It is insane when people come out of one or many ITIL training courses and think they're done. That's just the start. Then you have to actually do the heavy-duty analysis and implementation work, the measurement and the continuous improvement. That still has to be done, and ITIL training doesn't eliminate any of that effort. Instead, hopefully that effort, if you keep on track, produces measurable and positive results in a more efficient (but certainly not optimal) way than what would have otherwise happened, and you'll be able to improve it over time. Do you need ITIL to do this? No. Do people fail with ITIL? Absolutely. But ITIL certainly helps the organization that has troubles aligning its service priorities with management distractions and business realities.

Suggestions?

Peter Suba — Mon, 12 Mar 2012 11:56:46 +0000

ITILosaurus,

Not quite sure any more what you are driving at. Most of your comments indicate sensible thinking and a lot of bad experience working within frameworks termed as ITIL. However I don't really see any suggestions as to what to do, rather what things are useless. I am not sure what then to make of them i.e. where an I lead.

Like Skep I find myself agreeing with a lot of statements but feeling like the criticism that comes back is more about how ITIL (terms/concepts) are understood and implemented (often not very well), rather than with the concepts themselves.

Is it a sign that much of ITIL has been picked up and implemented in the real world too many times in a certain way that it now lives its own life and synonymous with less-then perfect practice? I am careful not to use the term "bad practice" as I consider these attempts to leave many organisations in a better state than without trying at all - even if they don't end up with "best practice"...

An ERA is all very well...but getting to it is impossible

ITILosaurus — Fri, 09 Mar 2012 16:52:51 +0000

Very interesting point and in general we agree conceptually in the ERA. If you have that then you can look at how to optimise your processes. We also prefer this as a strategy than Continuous Service Improvement because knowing the process interactions means we can look for ways to apply effective technology to optimize those processes, or 'simply' change those processes.

That being said, an Enterprise Reference Architecture by its very own nature (it is in the word "Enterprise") will be impossible to achieve.

Our companies are spread over multiple geographies, with lines of business that intersect and share. The act of defining the ERA in the first place will consume a significant proportion of our resources (i'm thinking of the outsourcing discussion above) to accurately model and even then will have changed before the model is completed.

Sorry, nice idea. No cigar from the ITILosaurus.

I would love to agree

ITILosaurus — Fri, 09 Mar 2012 16:44:03 +0000

I would love to agree with you, but I find myself agreeing with my esteemed ITILosaurus collective member who commented yesterday.

To pick on MTTR is to pick on one context.

Read the line "Continuous Service Improvement"

Now think about that statement...

We are in this brave new world unable to define a single "Service". We cannot define or maintain the necessary relationships within a CMDB because our infrastructure is tolerant to single faults and thus continuously adapting. (When a link fails, the VLANs using that link are switched to an alternate link. When a VM fails, the applications are switched to an alternate VM). Mostly our users are unaffected and do not even notice the bait and switch.

How can we maintain a relationship model of all those circumstances? We cannot. If we cannot model these Services, how are we to firstly measure them and then continuously improve them?

Should we then look at our platform as a whole? Too big.

Should we break it down into elements? Well that is what Problem Management does isn't it? Looks at the entities that comprise our platform and reports on their reliability, enabling us to have meaningful discussions with our suppliers.

Where does that leave Continuous Service Improvement pray tell?

MTTR is a red herring. Continuous Service Improvement is a waste of time (and money) and is similar in concept (as my fellow ITILosaurus member mentioned) to Total Quality Management (for those of us old enough to remember that consultants wet dream in the late 1980s and early 1990s).

Time is not a great healer it appears, time is a great recycler. What happened to all the TQM consultants? They became ISO9000 consultants. What happened to them? They became Y2K consultants. What happened to them...ITIL...where next? Don't you love this world.

The Outsource Win-Lose Relationship

ITILosaurus — Fri, 09 Mar 2012 16:31:04 +0000

Oh my!!! You have opened the kimono on Outsource contracts. YOU ARE SO RIGHT!!! This is another elephant in the room that no one discusses. It's not appropriate for the ITILosaurus Collective...but perhaps we should discuss it there because it makes us all mad!

CFO's and Accountants (read: Boring) are bonused on reducing the apparent bottom line.

Our "friends" at Outsource company TLA (let's face it, they're either two or three letter acronyms) are bonused on profit.

Our accountants want to get FTEs off their books as quickly as possible.

Our friends want to get us to do the deal as quickly as possible.

There is never the time to spend, or the right resource engagement to accurately document what "we" actually do in all of its splendor. So we miss things and our "friends" bank (straight to it) on us missing things.

The consequence of outsourcing has two detrimental affects on our business. Immediately we end up in Change discussions (read additional cash commitments), AND, every thing slows down. To get something done now requires multiple signatures, interactions, umming and ahhing, risk appraisals, etc etc etc.

In the old days we walked up to one of our staff and asked "do you have the time to do X?". They would say "when do you need it by?" we would agree a timeframe and kerrpow...it would be done.

Now when I walk up to the same person, they are a bottleneck, shackled by contractual barriers and timesheets.

To bring this back to ITIL. ITIL puts us on the path to Outsourcing. Outsourcing is a blight on our collective businesses. (Not commodity outsourcing, operations outsourcing).

ttfn

Tell the truth

Tell the truth — Fri, 09 Mar 2012 03:50:33 +0000

Reminds me of the time I was engaged by a hardware vendor to run an independent TCO Assessment of a company based in Brisbane.

Using the old Gartner TCO Manager for Distributed Computing. This was back in '04 when ITIL wasn't particularly mainstream in Oz.
Anyway the HW vendor wanted to build a case to sell more kit and/or manage the existing kit better, maybe even out-task some work.

The "best practice" part of the assessment involved the below (so you would scoop up most of an ITIL v2 assessment and plenty of V3):
Change Management (Deployment (installs, adds, changes), Retirement and moves, Change management technology, Change management process)
Customer Service (Service desk technology, Service desk process, Marketing and relationship management)
Training (End user training, IS training)
Technology Planning and Process Management
Operational Management (Virus protection, Data management, Performance monitoring and event management, Security, Standards compliance, Repair and maintenance)
Asset Administration (Hardware inventory management, Software inventory management, Lifecycle management, Procurement process, Vendor management)

Anyway, what the "best practice" part showed was that they had "middle of the road" maturity. Very high in things like virus protection, security, not so high in event mgt. But were not hopeless in anything. The cost assessment & customer satisfaction part (the things that really mattered) showed that they were lean, provided a good enough quality of service, no ticking risk timebombs and were respected by the business.

As the independent consultant there were a few bits and pieces they could improve on, but ultimately, the IT shop was doing a good (enough) job and should be left alone to go about their business. So that's what I recommended.

This proprietary approach, despite having a Best Practice nirvana allowed the value context to override the maturity context.

Suffice to say that the HW vendor who paid for my time wasn't impressed with my findings.

ITIL

Iain Wicking — Fri, 09 Mar 2012 01:05:47 +0000

The reason why all of these 'tools' and 'approaches' fail as they only paint part of the picture and a disconnected one at that. Also there are range of methodologies which has resulted in multiple silos in terms of standards, methodologies and their application.

To eliminate all of this we have taken an approach that captures a full Enterprise Reference Architecture, its layers, etc. Also this approach enables the ERA to be viewed from multiple perspectives and has the benefit of linking all the components in an enterprise together in a meaningful way. Change one thing and it cascades and impacts on other areas.

Without a holistic view you work on 'parts' of an enterprise in splendid isolation and generally in a meaningless way.

OFFS Before u slag CSI read

skeptic — Thu, 08 Mar 2012 19:18:30 +0000

OFFS Before u slag CSI read it first. It is exactly about setting a context for improvement and finding definable and measureable goals.

And if the second primary goal for you guys is Mean Time To Restore then I suspect u r lost in the tech. Availability is about far more than that.

Debate is fun, thanks. I find it bizarre to be debating on both sides on this blog...

collaboration

skeptic — Thu, 08 Mar 2012 19:12:42 +0000

Thee are a few tools on the market now which allow parallel workflows of.tickets... or so the hype assures me.

You can and should also collaborate by actually writing something in the ticket history.... but that never happens. Good luck trying to fix a cultural problem with a new tool.

Continuous Improvement

Dougie! — Thu, 08 Mar 2012 16:52:28 +0000

Ahhhh... I have seen and experienced a significant number of organizations that don't understand processes.

Think about this... In an outsourcing environment, the outsource provider is the lowest bidder. (Can you say MINIMALIST) The contracts are based on LOE slots which means its all about bodies. The contracts RARELY have any incentives toward measuring and optimizing processes, measuring effectiveness, or even DOCUMENTING current processes. Many outsourcing companies just won't do it.

So, all in all, you get what you pay for. After all, it is all about cheap and bare minimums and NOTHING about making things better. And, as long as management follows are manages to this, it will only get worse.

I also note that there are alot of Director level management types that are Sales oriented but lack Engineering discipline or operational exposure sufficient to make good decisions. Some of the signs you see right away are products that have no users. Products that are partially implemented but deliver questionable value. Shelfware. PoliticalWare.

These Design by Glossy Directors can be utterly destructive to operations. They throw tools at Operations, then proclaim victory. Only toneverrealize value or even personal integration. In the end, CFOs usually catch wind of the spend- spend - spend Director and they get IXNEYED. Others leave after a few years only to leave a trail of tears over the years.

Not everybody has evolved into providing IT Services. If this is your team, ITIL is probably not going to help you with anything other than provide a common language. And even then, if it doesn't fit your minimalist, body shop approach, you will inherently pick and choose which functions you think you support.

ITIL provides several key elements:

a common Language
a Foundation of functions
a starting point for you to fill in the process blanks

ITIL is a methodology... a Philosophy. Not a technology.

Another part that makes ITIL implementation difficult is that the tools and utilities are designed for a single user. For example, you are assigned a ticket. If someone else needs to work on this, you transfer the ticket or you create secondary or child tickets. 2 people rarely work on the same ticket... And if they do, only one person is able to update that ticket.

The tools are not "Collaborative" or team enabling.There are tools on the horizon that will supercharge your teams through the enablement of information, tools, and collaboration.

Thanks - will go check it out and respond...

ITILosauris — Thu, 08 Mar 2012 14:37:26 +0000

If I or my collective friends have anything relevant to say!

Just to shut down this "continuous service improvement" position...our view is quite simple...our collective represents an industry where if we had no computing we would have no companies and where to be competitive as 'market behavior' changes and compliant with ongoing regulation changes we need to continually change.

So, when Change is the only constant, you never get to the point of being able to continuously improve existing services because you are continually delivering changed services or new services so you never have a baseline to improve from.

(Economists in the room will also note that at some point one will reach a ceiling in terms of ability to continue to improve - capitalism and economic growth or company performance for example. It is impossible to continue to grow an economy at a certain rate, or grow at all past a certain point!).

We also believe that the goal of continuous service improvement is so nebulous as to be valueless.

Improvement (when viewed from an IT perspective) has one of three contexts:
1. Customer Satisfaction or, Perception of Satisfaction (think about it, they are really the same)
2. Mean Time To...[Resolve/Change/Deliver/etc.]
3. Efficiency of...[Resources/Equipment/Technology/Money/etc/]

So, instead of Continuous Service Improvement, should we not be looking to choose one of the contexts and having that as our strategic goal for each change/new program we are engaged in to be as optimized as is possible? (Best Customer Satisfaction... or Lowest Mean Time To..., or Highest Efficiency of...)

These are definable and measurable goals.

So if you agree with the above, then the only conclusion one can make is that Continuous Service Improvement is a non-productive activity made up for those people who can no longer be employed in the last "nebulous ponzi consulting bubble" of Total Quality Management...

;-)

We love your blog by the way and love your perspective. I hope we're not seen as too negative here. Discussion is good. Positive action instead of protectionism from vendors is better...you are helping the former and we thank you for that.

I agree about CMDB. I've

skeptic — Thu, 08 Mar 2012 13:04:00 +0000

I agree about CMDB. I've never had a client mature enough to attempt model driven BSM. And I totally disagree about CSI: it is used to conceive of how anyone professional can operate without improving.

Those are interesting cases. But what about the basics. Please see the last third of this post http://www.itskeptic.org/transformational-technologies-are-small-view and then explain to me how incident, problem, or change are transformed by any technology of your choice.

I feel a Donald Rumsfeld coming along...

ITILosaurus — Thu, 08 Mar 2012 12:34:19 +0000

Firstly - we're ITIL Septic (not skeptic) because we believe ITIL is septic. In fact, worse, we believe that ITIL practitioners and pushers are a cancer on the IT Service Management community, draining much needed IT budget into nebulous self serving valueless activities that do not help the business, the end-users or the IT staff at all (when applied to modern service platforms).

The Donald Rumsfeld is as follows (remember his unknown unknowns - very insightful)...well here is our response to your earlier point but concerning "methods":

There are some basic methods that we must continue to teach/do down the Ages that continue to add value regardless of the changes in ways of working.

There are other methods that are totally irrelevant to new ways of working that add no value at all.

Further, there are methods that if taught as "best practice" or "fundamental" to a way of working will adversely impact new ways of working.

This is where we find ourselves with most of ITILs core tenants:
- CMDB (whether unified or federated)
- Model driven BSM
- Continuous Service Improvement

We're told that folding the sails in a certain way will make us more efficient.

Anybody noticed...we don't use Sails any more!!!

Modern infrastructures are not client-server or mainframe like. They need new methods. The old methods (and technologies designed to underpin those old methods) are irrelevant.

ITIL and its practitioners and pushers continues to espouse the methods for managing client-server.

Wake up world!

quill pens

skeptic — Thu, 08 Mar 2012 11:43:00 +0000

And we don't teach IT users how to use quill pens either. Actually an awful lot of sailors' techniques didn't change when sails went out. My cousin learned to sail in the NZ navy in the 1970s too. He also learned how to operate advanced electronic weaponry. And he learned things both sailing ships and warships have in common: navigation, living on a.ship, survival, sea law , military discipline...

Either both our navies are stupid, or you might be missing the point...

Sailing mainframes

aroos — Thu, 08 Mar 2012 11:33:41 +0000

From 1930 to 1956 this ship http://upload.wikimedia.org/wikipedia/commons/0/0b/Suomen-Joutsen.jpg was a training ship for sailors in Finland. Even after it stopped sailing, it served as a school for sailors. There must have been people in charge of the sailors training like Rob who thought new technology does not change frameworks. Reef the mainframe and haul up your incidents!

Now it is probably just good that I cannot remember any good word for describing those people who thought that teaching people to sail a frigate was a necessary part of sailor's training in the 20th century ;)

Aale

great new skeptical blog

skeptic — Wed, 07 Mar 2012 19:57:00 +0000

Nice blog (BTW, you mis-spelt "skeptic" as "septic").

I agree with all the great content on your blog but not necessarily your premise as to the cause: like many others I think you are shooting the message instead of the flawed messengers. ITIL is not mainframe specific. ITIL works well as a general framework if it is applied intelligently. And it doesn't need a CMDB to work well.

New technologies don't change ITSM things much unless one has a narrow tech view of the world

Notwithstanding the above

ITILosaurus — Wed, 07 Mar 2012 14:06:00 +0000

See our blog: http://itilosaurus.wordpress.com/ for a perspective on the [lack of] value of ITIL maturity, and, moreover the impossibility of the CMDB, ergo BSM and as a direct consequence, any likelihood of continuous service improvement.

Keep doing what you're doing ITSkeptic. One day the vendors will wake up and begin to deliver solutions which enable agile service management instead of protecting ffiefdoms

The dangers of declaring processes

Peter Suba — Sat, 03 Mar 2012 23:12:56 +0000

I hope you don't mind me picking up the thread here.

Your point is exactly why I am frowning when exposed to any discussion around the number of processes in the ITIL (2011) framework. Putting aside the points you have made some time ago around the requirements for a process to be defined as separate (and hence why ITIL might be getting it all wrong from that perspective), I have more practical concerns.

Whilst in the ideal world, there would be highly knowledgeable and experienced people applying a framework in its entirety to a specific IT organisation, which could lead to great results, there are some characteristics of the framework that is used for purposes it was never (or should never have) been invented for.
Namely, the fact that you have a countable set of "things" in the ITIL framework (i.e. processes, books, functions etc) leads people to divide everything according to these numbers.

- They start having assessment by process and cut the scope of the assessments and reports sharply at the edges of processes as if this was reflecting reality
- They have outsourcing contracts scoped around processes
- They define organisational departments in IT around grouping of processes per "book"
- They define improvement processes, process ownership etc etc per process

It starts with somebody wanting to organise things so instead of a 350 line improvement tracker they have a grouped set of actions. They then have a process area assigned to each. Then you have summary lines per process area. And so things follow. Budgets are tight. Management will come back with "choose your highest priority process". Do they have a full understanding of the framework? No. But once you have a grouping, people will get hooked on those groupings.

Which is why, for example, I don't like the fact that in ITIL V3 we have Change, Release, Evaluation, Testing & Validation all separate, for example. I understand why they are listed separate, I understand they focus on different things. But in practice, they are so intertwined that I feel like defining them separate will be leading less experienced people on to dangerous places when they do scoping activities. I think once a framework reaches such recognition and usage as ITIL did, there ought to be some thinking going into unintended consequences of whatever is put into the framework. In other words, defining so many processes might be fine within a community where the "users" of the framework are as knowledgeable as the contributors to the books - but it isn't when you consider that many people will be taking stuff verbatim from the books, especially when they are misinterpreting the message of "adopt and adapt".

Brilliant

Charles T. Betz — Fri, 02 Mar 2012 16:00:43 +0000

James -

"For a maturity level model to have credibility it seems to me that it must be rooted in empirical evidence a) that it represents real world states and b) that the progression between states follows a set order. "

Brilliant.

I'd also like to see empirical evidence supporting any given set of proposed process areas. I'm not aware of any research along those lines. It would have to involve some linguistic or anthropological approach.

Otherwise we wind up with oddities like CMMI-DEV having four (count them) process areas related to "project":

- Integrated Project Management
- Project Monitoring and Control
- Project Planning
- Quantitative Project Management

I don't see how these can be mutually exclusive, which is (I think) a hallmark of any solid framework. How did they derive that particular decomposition (and other other process areas)? What is the basis for it? Why is it optimal as compared to having one larger project management process area encompassing all four?

As always, if someone can point me to some research where these things were done, I'd be appreciative. I keep thinking I must be missing something, that there must be some detailed, researched justifications underpinning CMMI. I'm less interested in research covering where CMMI has been applied, that then says "the following benefits were seen."

The idea that a service system has a relatively small number of stable states echoes my own thinking of late. I'll have to check out Stadia.

Charles T. Betz
http://www.erp4it.com