Questioning the tenets of ITIL
A nice lady from BMC asked me on twitter "which ITIL tenets do you question?". I think a number of tenets of ITIL are open to question, even if I have formed my own conclusions for some of them.
So as a starter list, I came up with these ITIL tenets that are open to question, that are not necessarily the foregone conclusion some ITIListas seem to think they are:
- risk management is not a distinct discipline ("process") of ITSM
- project management is not part of service management
- centralising information in a SKMS and/or CMS is a worthy goal
- one goal of ITSM is stability of the operational environment - change is an exception.
- Service Delivery owns the customer relationship, and Acquire/Build is a service provider to Service Delivery
- that which cannot be measured cannot be managed
- customer satisfaction can be accurately measured
- the Production environment can be secured
- the Production environment can be controlled
- incidents have a root cause
Got any more for us?
Made in New Zealand 
Comments
Absolutely. Try this for
Absolutely. Try this for size:
- Analysing trends of incidents which HAVE happened, somehow enables you to mystically prophesy incidents which have NOT happened.
This is the magical mysticism of proactive problem management.
Someone show me a valid trend analysis technique which somehow predicts future problems and doesn't cross over into the realms of capacity management or availability management and I'll eat my words but the "Proactive Problem Management" referred to in the ITIL v3 books is mystical, utter nonsense.
Let's not mention that when looking for the description of how to implement 'Proactive Problem Management', Service Operation points to the CSI book and the CSI book points straight back to Service Operation. A nice circular set of references for a process which is never detailed, doesn't exist and has outcomes akin to black magic.
Predicting
You are absolutely right about the circular references and you are also right that a lot of so called proactive work is actually capacity and availability plannning.
On the other hand I would not say that predicting future incidents from past incidents is so mystical. Linear models often work for a while. A typical situation might be that there is a growing trend on incidents when your customer base is adopting some new tool or technology. You might notice that the users of ZZZ cause 1 incident per 10 users/month and that the number of ZZZ related incident is growing. If there are 1000 new users of ZZZ every month it is quiter easy to predict that the number of ZZZ incidents will drown your support unless you can find the reason(s) and fix them.
Aale
The problem with that, it's
The problem with that, it's that's one feasible scenario under which it might be possible to predict a potential impact.
This doesn't translate into constantly being able to use trend analysis to predict incidents which have not yet occurred. The only value you can gain from trend analysis is when you project against capacity limits based upon the information that capacity management is giving you.
Any idea that you can somehow predict the future by generic trend analysis techniques of previous incidents seems to me to be nothing more than mystical nonsense. Trends are largely useless unless they're going to cross a critical point which you've established based upon your understanding of the infrastructure's limits.
If your aim is to use Problem Management to reduce incident numbers, trending is pointless. Root cause analysis of your highest impact problems is how you reduce calls to your Service Desk. And the definition of "highest impact" should clearly factor in the number of calls your Service Desk is receiving for each problem.
my list
Agree with most, have to think about a few, nothing that I vehemently disagree with.
Some additions (these are things i question):
1. Requests for Change drive Projects and/or Releases
2. As Cary notes - Asset and Configuration Management can be combined into one practice. Such irony - org I was in pulled them apart after ITIL v3 crammed them together. ITIL went straight backwards on that one.
3. Applications are never Services ("too technical"). At the very least, the vernacular of the enterprise in question should be respected, and there is no industry consensus.
4. Data Management is an afterthought. (even though it is PO2 of COBIT)
5. "Service Design...is different from ... enterprise architecture." (p 203 Service Strategy). What are we paying these expensive architects for, if not to grapple with the highest order, most abstract questions?
6. The Configuration Management System contains records of "configurations."
7. The Configuration Management System "architecture" (figure 4.8 of Service Transition).
8. The Configuration Management System can be discussed without using the term "data quality."
9. Functions are processes. (How many Capacities did you do today?)
10. And the biggest fallacy of all - not explicitly stated, but there by implication - one can optimize a complex IT service creation and delivery system by optimizing its various functions individually.
Charles T. Betz
http://www.erp4it.com
Amen, brother! Too much that
Amen, brother! Too much that sounds good and feels bad.
My main issue with ITIL and
My main issue with ITIL and all the other "good practices" lies in this "align with the business" thing. You know, all this "setting expectations", "defining service levels", ... Let's be honest, aligning with the business really means doing it good enough. No one really focusses on excellence anymore. And people do want to be proud of what they do. There are so many guys who would do things so much better without SLA.
To take a non IT example, if most of the trains are between 15 and 29 mn late these days, it's because the SLA is "less than 30 minutes delay". That really is a drop in quality of service, but as long as it has no business impact, noone cares and that really pisses me off.
The Four Things a Service Business Must Get Right
Good enough, may be just that - for the business.
They may view quality vs. costs. This is Skeptic's ETF issue again.
Frances Frei wrote a nice article in HBR April 2008.
Frei advises aligning four key elements of your business:
• What your service offering consists of
• How you fund the excellence you want to provide
• How you manage employees to deliver quality service
• What you do to help customers enhance—not erode—service
Required reading for IT?
Seems to me that SLAs are commitments, contracts.
If they are written wrong, renegotiate.
Strassman wrote, "Define a systems architecture not only in technical terms, but also how it will distribute political control over information, because all economic benefits arise from use and not from design."
ETF
ETF is indeed an issue ( excessive technical fastidiousness). The finest most ethical professional with nothing but the best interests of the company at heart can overspend on time and technology to build a "better" solution.
Sometimes I grow weary of explaining that "because we should" is not a business case and just because it is a good idea doesn't mke it the best use of scarce resources.
How do some people get so divorced from understanding what money actually means and what business is actually for?
All employees need checks and balances, policy and controls.
SLAs are a tool
I have to disagree with SLAs being a negative thing, although I raised the same issue years ago back in the start of this blog - as a question not an assertion. It's all around how you use the SLA: it should be a minimum acceptable level, above which you may excel all you want, not a bar to aim for.
Without a clear definition of what is and is not acceptable, it is all totally subjective:
Users will whine at any reduction in service even if it is a small one after years of improvement, or a brief one in a generally excellent delivery.
The world is paved with Dilberts and Wallys. Don't give me that crap about every person is a butterfly waiting to be set free: for every professional there is a seat-warmer. Sometimes you have to nail the bastards to an objective accountability. I had the recent horrific experience of dealing with a unionised government service desk - I'm still getting over it.
every person is a butterfly waiting to be set free
Check out this survey of dysfunctional behaviours amongst developers (thanks Charles Betz). Ops shouldn't get smug - I see not reason to think it is any different. People are people, and all this naive crap about trusting staff to do the right thing (Agile, DevOps, "no SLAs", "admin tasks not changes"...) is a recipe for disaster. I'm convinced it is a whine from those who don't want to have to do jobs properly, with rigour, controls, and full reporting and record-keeping.
SLAs: No, Priortization: Yes
pfranck,
I agree that SLAs have limited value, and, especially for internal support, tend to create an adversarial relationship where one did not previously exist. Where I do think the "align with the business thing" can provide significant benefits around priortization of work There is simply too much work for the techs to accomplish in a given week, so what should they work on and what should they hold off until the important stuff is done? Most of us, when clear priorities are lacking, will work on the thing that provides the most personal/professional satisfaction. You said it yourself, "people want to be proud of what they do." That doesn't, however, often lend itself to doing what needs to be done.
Turn the question around
I have been thinking about the opposite of that question: What in ITIL is right? There must be something right as it has stood the test of time, over 30 years is a long time for a best practice model. Here's my list:
1 Define and list services and show that they are not the same thing as the work IT people are doing.
2 Create a customer service interface which is independent from technological domains
3 Separate the temporary fix and permanent fix
4 Create a logical model of the infrastructure and name all components
5 Control changes to production environment
6 Plan for small and large catastrophes
All these were already in Version 1. The 30 years have done the same thing to ITIL that they have done to many of us; more fat, less muscle.
Aale
Soviet style planning
ITIL introduces two demand management processes but does not recognize any market economy activities like marketing or sales. The formal Soviet Union planned production in 5-year cycles. Their problem was that production and demand did not meet. ITIL Service Lifecycle argues that IT services can be planned years ahead and any problems with demand&supply differences can be handled with vigorous demand management.
Aale
Including asset management with SACM
Suddenly, with V3, ITIL included some of the long-traditional ITAM processes with SACM. Poorly.
Why?
Assets have a different lifecyle from configuration as Charles Betz regularly points out.
As does the selection of standard models - infrastructure models.
IT asset management is not a an operations function. It is a central ownership and stewardship administration function. In the military they call it Logistics or Supply - and have whole separate organizations from operations for it. In civilian life they call it materials management, and have whole separate organizations for it. But, ITIL decided it had to include it as configuration management?
In Van Haren's IT Financial Management book (p. 69), "From a deeper analysis, it is clear that ITIL describes mainly configuration management; no specific processes or practices are described in detail to manage assets from the financial perspective."
Nor from a contractual basis. Or several other ownership / stewardship processes.
Since ITAM is much more closely tied to governance and stewardship than it is operational configuration management, putting forth the horrible SACM as IT asset management has created more problems because, now, IT practitioners push back on the ideas of running IT with transparency of costs and good business practices - using ITIL as their reasoning. Further isolating IT from the rest of the business. A very bad result if IT wants to gain respect and trust from the rest of the business - and not get outsourced.
Ass backwards
cary
IMHO ITIL V3 lumped asset management into configuration (albeit in naming of the title only) as a territorial/mindset grab. As you and Chaz point out - what an organization defines as an asset (financial bent) and a configuration item (ICT bent) will likely always differ. They may however reference the same resource (oops ITIL repositioned that age old word but...), for differing reasons.
ITIL is still learning about config. Its still a work in progress in my mind and I'm not sure we will be around when its finally complete enough to catch up with what tools do 'out the box' today. Unfortunately, its a 'shiny object' to some IT folks, like a Soduku puzzle challenge. I wonder how these 'experts' go about explaining that both an asset management and configuration management system - are 'zero cost' operations - self funding....?
11. For users, the only
11. For users, the only route into IT is via the Service Desk.
service desk is not CRM
good catch. i've seen various naive statements implying that senior execs needing a new $10M service or major changes to same would call the service desk and invoke the Project service catalog item.
Gotta have a CRM function of some sort, and it ain't the service desk.
Charles T. Betz
http://www.erp4it.com