ITIL's biggest hole: where is the meta-lifecycle?
Writing a presentation today, I was reminded again of the biggest hole in the ITIL content, even ITIL3. ITIL3 now describes the lifecycle of a service, and does an excellent job of it. But where is the guidance on how to implement the ITIL process machinery to manage that service through its lifecycle? Where is the lifecycle of the lifecycle, as it were - the meta-lifecycle?
ITIL2 had the very good Planning to Implement Service Management which was a start - sort of an orientation course before one set out. But nobody has done a Route Guide on the Road to ITIL or a Phased Approach to ITIL Maturity.
ITIL3 only makes the need more pressing. ITIL3 has - quite rightly - raised the bar. As I discussed in the latest Skeptical Informer newsletter, ITIL3 looks a long way away for someone just starting their ITIL journey, and the core books only really describe the destination.
The complementary guidance books are a handy catch-all answer for any defiiciency in ITIL3, but a guidebook along the path to ITIL maturity is a stand-out candidate for the first book off the block. If I didn't already have one book long overdue and assorted other projects on the boil, I'd have a crack at it myself.
The cynic in me wonders if this gap is too big a revenue generator to all the consulting firms for OGC to ever rectify it.
Made in New Zealand 
Comments
ITIL is a reference framework not an implementation framework
In another thread, I said:
JvB has hit the nail on the head for me: ITIL is a reference framework not an implementation framework. ITIL students go away puzzled as to how they are actually going to use this, or if they can see that then how are they going to get from here to there. For pity's sake someone make yourself rich and us all happy by writing the book.
It's not about implementing ITIL!
G'day Skeptic,
There is no need to have a detailed approach for implementing ITIL for a number of reasons.
Firstly, every business is unique based on their internal and external operating environments. This presents different sets of risks and costs to the boards of management which may be mitigated and reduced through the targeted implementation of certain aspects of ITIL - but only where the outcome of the implementation directly targets the identified business risks and costs.
Secondly, the budget available for mitigating and reducing the identified risks and costs to the business is based on the level of risk and costs the business is able to withstand and still retain competative advantage in their particular industry. The budget will determine just how much of ITIL can be implemented.
Armed with this information - the business needs to evaluate the available options to determine the best bang for the bucks. This would mean that an approach to implement ITIL at one organisation will never fit another organisation - hence it's not about implementing ITIL - but more about solving business problems with tools such as ITIL.
The priorities and budget of one organisation may determine that Change Management needs to be addressed in order to reduce the back-log of changes due to inefficient change processes. Whereas another organisation may determine that a single point of contact through a Service Desk needs to be implemented to reduce the disruption brought about by all users having direct access to everyone in the IT department with all manner of requests and issues.
I cannot see how a detailed approach to the implementation ITIL (V2 or V3) can be of value to more than just one organisation - if at all any.
Well... I do not agree entirely
It is true that every business is in some sense unique. But the differences between IT provisioning for one company and another are not that big and therefore the 80-20 rule applies. Whatever IT organization, whatever business environment, you'll need some change management. And there only a limited amount of designs possible for that specific process.
It is true that ITIL is a tool. And I will agree that you shouldn't implement a tool without a good business case or business reason. Depending on the Business needs it is expected of an IT organization to be organized in such a way that they provide the greatest amount of added value. There are not that many different ways to organize a successful IT Service Provider and ITIL provides good guidance in this respect.
An implementation approach for an IT Service Provider based on ITIL (doesn't matter which version, that is mostly semantics) will have added value, because most IT organizations are really bad in transforming from a reactive cost center to a pro active value center. And I have seen many IT departments and they are in the core all the same.
Hmm, let's check the math
Let's assume for a moment you are correct; there are a limited number of archetypes in IT. Everything else is an irrelevant variation on a theme. Further assume that number is small. Say, five unique archetypes.
Now if the premise further assumes that each archetype warrants a uniquely different process, Change Mgt for example, that means we need 5 methods to implement each Change Mgt variation. Not too daunting so far.
But wait, what about the rest of the processes? If we stick with the familiar v2 processes we get (5^10) almost 10 million implementation variations. Think we can fit that in a foundation course?
You may argue that certain processes will come in sets; they have natural affinities. Or they have may overlapping and common constructs. Perhaps. But we've also ignored the variations on how the processes *interconnect or interplay* - another source of complexity. Not too mention variations in organizational structures, operating models and, well, you get the picture. And if we throw in the the v3 processes we have ... well, I can't count that high.
Even if the number of archetypes is two (big and small) the number of variations is still very, very large. Too large to codify. And I've left out the real source of complexity: How do we know each variation is correct?
(Yes, for purposes of clarity I've simplified the math.)
(Note: this is a simplified subcomponent of a larger line of logic that explains, among other things, why even small organizations never reach equilibrium, why ERP has such persistent problems, why benchmarks are misleading and why idealized end-states never happen. Maybe I'll put it out here if anyone is interested.)
call an ambulance
This line of thinking is getting way out of hand. It ignores one of the basic requirements of a useful discussion: an agreed language. ITIL V2 contained a lot of elements that were called "processes" - but weren't, according to ITIL's own definition. So, if you drill down the ITIL text, you will indeed find a VERY limited set of 'real processes'.
ITIL V3 is in no way different, although it showed one tiny glimpse of awareness, when one of the authors wrote "Capacity Management actually deserves to be called a function and not a process", or something with that meaning....
If you give the ITIL books to a member of the BPM Forum, you might do him a favor and call an ambulance at the same time ;-)
Now, you may fight over the best way to do Change management, but I'm pretty sure each of us will do a test before deployment. And each of us will do the review at the very end. And we plan before we invest in the development or in procurement (I hope). We may differ a bit in the level of detail here and there, but the ITIL documentation on Change mgt is rather robust - at the end of its evolution. The same goes for a couple of other processes.
The *difference* where you can do the math comes in when we discuss functions instead of processes. Functions are influenced by local conditions, by infrastructure, by money, by skills, etcetera. There are many variations to the theme there. But not in the basic processes.
Before we are lost in math, let's first start to learn how to read. And when we do that, let's agree on a common language, so we understand eachother.
jan
Clarity
Are you saying:
1 - ITIL's Change Management process works for *all* IT shops?
2 - This same process cannot be improved upon?
As I said in another
As I said in another comment, there are two markets here:
the big and/or sophisticated sites that need some degree of customisation (read: expensive consulting), and the vast unwashed masses who just want to get something in to control the current unsatisfactory situation.
The second (and much larger group) group would be happy with a standard OOTB Change process, at least to start with.
That is my point
Although you can argue the number of permutations in car design, as clearly has been put forward above, as well as the number of permutations in the design of a good working IT service organization, fundamental there are only a few points to start. Keeping the car analogy:
The majority of cars have four wheels: I know only one car which had three wheels as the factory setting (the Robin). Of course you could argue that there are also vehicles with two (we call them motorcycles or, lacking an engine, a bike) or more then 4 (mostly found on some kind of truck).
Most cars will have their engine in the front of the car (unless it is an expensive sports car or an old Skoda). They have a round steering wheel.
They come with stick shift or with an automatic gearbox.
They have a seat for the driver and at least one more for a passenger.
They come in 3, 4 or 5 doors version.
An on these basic models you can then create endless amount of different versions, customized to all the wishes customers has. As long as they are willing to pay for it.
All IT organizations will have some sort of Change Management and those processes will not differ extremely as Jan has pointed out above. All IT organizations will have some sort of error control and call management, which can be called Incident Management. And all IT organizations will have at least one user to have a dialog with on service levels expected. In that respect ITIL describes in general terms an IT organization. To stay within the analogy: it describes a car, not a specific car and not a car that meets all the requirements of all the users, but a full working car none of the less. And not necessary a good car: a car without imagination or design.
As far as I am concerned, and in line with my earlier post on Greiners model, you need to transform an IT organization along the lines of ITIL first before you can start to improve, modify and bring the IT organization in line with the business strategy. The number of choices in the first stage are limited and for the majority of the IT organizations enough to start with,
BPM Skeptic
BPM is often touted on this board as the outside beacon of authority but let's be real, the BPM community also struggles with defining processes. I sat in a recent session with two well known BPM luminaries who had an updated version of process - only this time, they assured me, they got it right.
Not that they weren't very talented gentlemen. You've probably read a few of their books. But BPM has already forgotten its predecessors: COBOL, CIM and BPR. All were designed for higher orders of computerized logic; all failed to solve the value creation paradox, sub-optimization problem, enhance collaboration or employee learning. Long on talk, short on results.
Sigh. So here we are again, talking as if BPM already solved the process problem. Most of the arguments read like an L. Ron Hubbard book. I'm still waiting for the evidence. On the other hand, one of the most well known businesses to embrace BPM went out of business not too long ago.
I'll take the stance that ITILv3 showed proper humility. It outlined some basic process fundamentals (which the "third-wave" of BPM is already revising) and then got out of the way.
But I'm always open to breakthrough ideas. How would you define process?
Why implementations go wrong
The poor use of the term process is also a major factor in failed ITIL implementations - trying to enhance capability using the same sort of project based approach that you use to implement a workflow based process is in my experience doomed to fail.
People also spend a lot of time trying to over complicate the theory, rather than just addressing the basics that they need to fix.
Semantics make ITIL implementations go wrong
I find it difficult to imagine that an ITIL implementation will fail when there is a poor use of the term process or function. Discussions on the difference between a process or a function might be interesting to some, but when it comes to implementing it makes more sense to talk about the goal and results of a Service Provider. What is the output of a process or function (or role or team or...) and how does this contribute to the overall performance? Getting understanding on those definitions is useful. And I agree with Jan that a common language is desired. ITIL gives some good definitions and some bad examples of using them (like the definition of Incident for example in relation to Event).
We tend to focus to much on how things should be done instead of focusing on what needs to be achieved by the IT department. And then again there are not that many different options available. The people to ask are the customers, the business. And they really do not care if the capacity of the network is kept in check by a process or a function. It still needs to be done.
To come back to the Math reply. You can look at the individual processes and start calculating (BTW there are also several different kind of changes, that will make more variations possible). The question I would like to ask: what makes a good car? There are several good Engine options, different set of tyres, steering, etc. The amount of possibilities are endless. How many options are there for the car itself? Not that many. It depends if you want to have a family car or a sports car or maybe a pick up truck. Depending on the role of the car the set of options may differ, but the amount of the good choices to make are limited. And how well the decision making has been can be seen in the customers approval or disapproval. That shows what works.
Implementing an IT Service Provider based on ITIL is like building a car, there are decisions to be made and these depend on what is expected that the customer will approve of, but there are only a few variations in approach possible.
As long as its black.
"What makes a good car?" is the right question but I don't see how the number of good choices are limited. If so, the typical automobile manufacturer wouldn't offer an average of 50 models.
A car is not only about fundamental transportation. It's also about prestige, reliability, cost (high or low), eco-friendliness, fuel conservation, heritage, and many others. Every choice is the sum of an equation of constraints. One person's good choice is another's poor choice.
I have a colleague, a COO for a Fortune 50, who never drives his 6-figure Italian sports car past the mailbox (in all fairness, it is a large property). Another has pledged to drive only bio-diesels. I strive to keep these two chaps from ever meeting.
So too, in services, there a myriad of outcomes to serve and constraints within which to adapt. The permutations are vast. ITIL's Change Management process, as robust as it may be, does not work in all scenarios. And small numbers, when mixed with exponents, become very large, very quickly.
As in services, only the customer can answer the question, "What makes a good car?" When the provider answers the question then he's imposed his own artificial constraints - not the customer's. A strategy with a limited shelf life.
As Henry Ford said of the Model-T, "Any customer can have a car painted any colour that he wants so long as it is black".
The cars might differ but production remains the same
Isn't it strange that the people who seem to struggle to understand ITIL often seems to be those who don't understand the anakogies with other industries and their customers' other experiences? I find analogies very powerful.
Lets look at this car one. It is true that there are a vast range of cars available in the market place, with considerable segmentation. To me this would seem to be analogous to the services we provide to our customers - and it is important to remember that when some one buys a car they are also making value judgments based on perceptal issues such as branding, mot just the technical specification.
If you look deeper into the automotive industry you discover that the apparant diversity in the market place is achieved with a remarkable amount of reuse, not just within one companies' range but across different companies. The apparant differentiation is achieved by altering the areas which cost least to develop.
The really relevant point though is that the vast majority of cars are manufactured on production lines that are designed and operated in the same way around the world, regardless of the car companies target market sector. The latest trend is towards multipurpose production lines that can have different models going down them in a dynamically controlled product mix. A good example is the line at Halewood which produces both the Freelander 2 and the Jaguar X-type, with only the body shops being seperate.
So perhaps it doesn't matter that IT shops have diverse customers, services and geographies once process can still fit - but with two cautionary notes. The first is that procedual (as oppossed to process) might need to be made to fit a specific organisation - for instance by introducing multiple CABS, and secondly that the ITIL change process is, in mind, not sufficently well documented to allow for any formal verification that it is indeed the "universal" change process.
Isn't this the same sort of
Isn't this the same sort of logic used by non-IT execs when they say, "Its just a room full of computers. Hire a bunch of computer people, click 'Next->Next->Finish' and its up and running. Everyone has the same common stuff. What's so hard?"
Back in the 1970s, Ford and GM viewed industry production processes as all the same. They'd been building cars for 60 years, for goodness sake. Production processes were quite robust. Toyota and Honda viewed their production processes as strategic assets. Detroit thought they were either confused or naive.
While there may be common elements (chasis, for example), automotive production processes are *very* different. In many cases, it is proprietary and competitive differentiators. Even within a company (e.g GM and the Saturn line).
Toyota may use the same supplier materials and other reusable common elements, but the production processes are *very* different from the Halewood line. The layman may see a similar multi-purpose production line with reusable components, but Toyota sees distinctive capabilities; even in the fundamental break/fix and change processes. They periodically shut down all production plants in order to re-tool (continual improvement) these ever evolving production processes.
Again, IT may have common hardware and software with similar needs for repair and change. But there are many permutations from which to choose. And, to succeed over the long term, they must echo the strategic themes of the organization. Take Google, for example. Even today they have no use for ITIL Incident and Change Management. Their versions of these production processes are *very* different because IT understands the strategic imperatives are better served. The ITIL versions would makes things worse. Or MySpace, or startups, or sports leagues, or partnerships, and so on.
Thought of the day: I wonder how many of ITIL consultancies are running ITIL production processes within their own IT organizations. ;-)
Interesting points
You make some interesting points, and I'm not in a postition to comment on all of them.
Lets just deal with the automotive one to start with, since the consultancy I have just left does several tens of millions pounds worth of business in that area. I think the issue is more subtle. There is a consensus that the Toyota way is right, but companies who try and adopt it generally seem to fail because they leave out an element, or somehting goes wrong in the cultural translation. Trust me most of the major automotive companies want to emulate Toyota, but don't get the holisitc message. Incidentally the Halewood production has been evolving very succesfully, it was orignally put in to build Fiestas ( a Ford compact)
I learnt an awful lot about IT processes from my early experience in a secure government IT shop. We didn't do ITIL, because ITIL didn't exist then, but when it came to changes we, amongst other things:
- Made sure we understood both the risks and benefits
- Engaged all stakeholders
- Tried to understand the impact of an individual change on the overall system
- Always had back out plans
- Always tested both the change and the implemenation of the change
- Seperated approval to proceed with change build from approval to implement the change
- Made sure there was a very clear segregation of duty between the change promoter or builder and the person authorising the change
- Reviewed the change after implementation
Looks a bit like ITIL, doesn't it? ;-)
Adapt and adopt
Yes, ITIL's change managment process is not something that fits everywhere.
I liked the comment that I read somewhere that noticed that 'one size fits everybody' actually means 'one size fits nobody'. If you are all things to all men then you are shallow.
What I value about ITIL's change management process (and much of the rest of ITIL) is not the process itself, but the thinking behind it. A change management process must be useful, easy to use, it must have a good audit trail, it must prevent too frequent or unnnecessary change and so forth. The principle that a change is a move from one well defined state to another well defined state is absolutely right.
In short, it is the philosophy of pragmatism that lies behind ITIL that is of ultimate value, not the specifics.
Ford was right too, as another poster has observed. What is important is that something works. That it is aesthetically pleasing is nice too, but secondary.
I remember the story of somebody who defected from the Soviet Union. A year or so later he was back. People were surprised and asked him why he went back. He said that he couldn't cope with the need to decide, every day, which of fifty different types of soap he wanted. He went to a shop to buy soap, soap was what he wanted, that was it - not a complex multiple choice job of deciding which particular soap suited him.
I sympathise completely. ( my wife doesn't, but that is another story...)
Differing view
The Ford quote was a bit of a snare trap in order to make my point.
Believe it or not, prior to Ford, cars were available in many colors. They were of very high quality and manufacturing processes were well established. Their versions of Change and Incident management were robust and well accepted across the industry. They were perfectly pragmatic.
However, it was also accepted that cars luxuries for the rich; something to be carefully made and bought for pleasure. Ford found a new strategic imperative: low cost cars for the unwashed multitudes. Everyone said he'd be out of business in six months.
The only way this new imperative could be accomplished was by upending the "robust" processes; both in methods and systemic design. Black was the only color for only one reason: any other color took *too long to dry*.
You see, the only way he could pull it off was with speed. He sacrificed process attributes such as stability and variation for speed. The processes thus became too fast for any other color. This could never have happened with a bottoms-up approach. Christensen calls this The Innovator's Dilemma.
And I see this today in the IT industry. An ITIL consultant will promote a process design that ignores the strategic imperatives. All in the name of pragmatism, of course. In most cases he will be fine. But in many cases he will be wrong.
Nanny knows best
And I see this today in the IT industry. An ITIL consultant will promote a process design that ignores the strategic imperatives. All in the name of pragmatism, of course. In most cases he will be fine. But in many cases he will be wrong.
------------------
I was marking some Service Support exam answers last week. I had an unusually excellent set of students who'd all been in seniour management positions for some time.
I found one of their answers very amusing. They were asked to give an opinion on what might be causing a certain symptom and why the symptom might be worrying. Then, later in the question, they were asked to make suggestions on what could be done.
What was funny was that none of them, in the suggestions area, mentioned checking to see if their hypothesis was actually correct and that there really was a problem, nor did they include any suggestions about asking the end users about it to find out what sort of fix was required.
In real life I know that all of them would have done that, but, in the context of an exam they imagined that there must be a 'right answer', and they saw that as taking action, not being consultative.
Similarly, as you say, about consultants. It isn't always their fault. I had one customer who insisted that business customers must never be consulted about anything because it would only confuse them - after you've argued that this is a bad idea a few times, what should you do? Should you decline the engagement because you know it won't work? Or should you see what you can do with the pig's ear you've been given, knowing that the result will be nothing remotely like a silk purse?
It didn't hurt Henry :-D
It didn't hurt Henry :-D
Actually there are two markets here:
the big and/or sophisticated sites that need some degree of customisation (read: expensive consulting), and the vast unwashed masses who just want to get something in to control the current unsatisfactory situation.
The second group would be happy with a black ITIL.
Category Mistake
My view is that IT organisations want to work with processes and workflows because that is what they are comfortable with. They therefore try and shoehorn service management into the same sort of solution space, hence the temptation to treat ITIL as a project (which can work sometimes but often doesn't)
I have seen an organisation spend months trying to agree an SLA process map whilst their customers have sat their aghast because what they needed was a competent service manager who listened to their concerns, kept their promises and spoke their language. Meanwhile as the customer got angrier the IT department continued to believe that they were "doing ITIL"
Agreed
Well said. I recently overheard a presentation where the distinguished speaker opined "there are no ITIL projects, only improvement projects. ITIL is simply a lever."
The tighter ITIL cranks on the prescriptive bolts, the less room it leaves for self optimization and emergence. A theme explicitly called out in Sharon Taylor's forward and well understood by the Skeptic. Of course, there is a trade off. Too little tightness on the bolts and emergence becomes wobbliness. We'll see which side it lands on.
Looking for ITIL V3 Process Maps
I have been asked by an author for ITIL V3 Process Maps. Can anyone help me find them? They were a key deliverable in the ITIL V3 scoping document: 'a complete integrated process model' and were due to be out before the 5 core titles. I'm probably not looking properly but to save me time can anyone direct me to where they are?
vapour ware
I believe these were supposed to be part of the ITIL 3 deliverables, as defined for Spring to Autumn 2006 delivery at
http://www.itsmf.com/images/news/scope_web.pdf
IIRC, and I might well be wrong, the contract to produce them went to HP.
Work in progress
But nobody has done a Route Guide on the Road to ITIL or a Phased Approach to ITIL Maturity.
At the spanish itSMF there exists a workgroup that is working on a project methodology to face ITIL implementations, and they will present the results in the next Symposium in November.
Besides, the problem is the ITIL completely lacks of a maturity model, so it is impossible to do this phased approach using the best practices published right now, so you need complimentary guidance from COBIT, CMMI-SVC or whatever you want to use to create your own maturity model.
Another interesting approach is the fact that current standards provide you with maturity models *for process* but I haven't seen a Maturity Model *for services* (and I think this is really needed!)
Regards!
Antonio
ISO20000 provides maturity assessment
Great point about maturity of services.
What hasn't come up much is that ISO20000 pprovides an standard assessment model for maturity. It will also soon provide a compliance standard for vendor's products
Yup it's compliance not maturity
You guys are right. I was tired, in a hurry.... what can I say. Yup it's compliance not maturity. Sorry folks, do not adjust your set.
Still another one...
What about my second question regarding product compliance standards?
product compliance
I'll check my facts later - gotta go to another 12 hour work day - but I believe section 3 or 4 of the standard, still under preparation, includes product compliance
What is your source for claiming product compliance in 20000?
Skep - WHAT!!!!
Did you just say that you know or suspect or have heard a nearby whisper that the next generation of ISO 20000 will address 'product compliance'!!!?? Please tell me I'm dreaming. If WG25 is taking on product compliance I am going back to my landscaping business...... We need an ISO:9000 derivative to keep everyone at the funny farm in check.....
ISO SPICE & 15504
I'd be very interested to know more about any plans for ISO 20K; particularly regarding product compliance. I have not seen anything in that regard. I am aware that ISO has dropped the word 'software' out of the 15504 standard; it is now a 'process assessment' standard and work is being completed for ITSM based on ITIL V3 (that is my belief).
ISO 15504 also 'harmonizing' (see the SEI website) CMM, CMMI, etc. What I've been looking for is the 'official' V3 assessment guidance which I believe will be based on 15504.
Perhaps now that APMG is charging for 'complimentary guidance' we'll see some self assessment tools based on 15504 for V3 along the lines of what CobiT's doing?
Would be nice to get a clearer picture of what we can expect. If it includes product compliance (CMDB interoperability anyone?) that sounds like a pretty big bombshell.
Giving the big gorillas that kind of lever doesn't sound like a good thing to me, but an official statement on assessment --- with a maturity model that can enable incremental adoption --- would be very nice.
By the way, OGC did recently release a new book "Building an ITIL based Service Management Department.
John M. Worthington
MyServiceMonitor, LLC
Consider it rumour - cannot confirm
Consider it rumour - I cannot find anything to confirm. I may have imagined it :-D
Not so - ISO20000 is all about PASS/FAIL as a MINIMUM standard
Skep
You could not be further from the light! A standard is all about PASS/FAIL an d NOTHING to do with maturity. Thats what assessments are for - yes, but an ISO 20000 certification effort is an AUDIT - very different. It contains many 'SHALL'. Pray tell me how you build a temperature scale (maturity level) around SHALL. If it were possible then I would have passed my UK driving test first time! As my use of teh rear view mirror was abnou a 3.5 on the assessment scale. Evidently it needed to be a 5!
Can't imagine!!
Wow Mr. Skeptic... Didn't expect to see you telling such a thing!
ISO 20.000 does not talk about *levels*. It has "musts" and "shoulds", but nothing more.
It does not provide maturity levels, neither how to assess them.
As far as I know, you can only see this in COBIT and CMMI-SVC...
Regards!
Antonio
Really?? Now I'm skeptical...
1. Where is the criteria (or other supporting provisions) in the standard that specifies levels of maturity?
2. The standard addresses organizations and their people. How can this be stretched to include products?
Not yet it doesn't
No, the current version of the standard doesn't have a maturity model, but a draft Part Four of the standard does exist, which will provide a maturity model of some form. Currently it is based on SPICE.
Just use this
https://akss.dau.mil/ifc/
What could be simplier?
Please don't create another Meta Lifecycle
I don't necessarily think ITIL needs to publish a "meta lifecycle" edition because companies should adopt process improvement in whatever format they find effective. ITIL is no different than any wide scale impactful change that is is IT related. It has very similar attributes to ERP roll-outs, Indentity Management projects and all other "big" projects. For ITIL to publish a specific book would assume they can ignore the expansive amount of existing IP on change acceptance and implementation.
I got a interesting comment from Aiden Lawes at a itSMF conference in Singapore. "ITIL cannot be implemented". As already mentioned here, it is a basic guideline or framework for a set of process and not enough detail to implement.
My favourite way to promote "adoption" is using the principles of "continuous improvement". Something SixSigma based can work well, as long as you do not take the zealots approach to execution. You can use ITIL as input into the target process design part of SixSigman. At least it has built in the concept of solving a business problem and not just a broad based implementation. Success is all about Business Alignment. You need to implement only the parts of ITIL that are going to give the result you need.
You can see some more thoughts on this at my blog
Meta-lifecycle of servicve - not one but many!
Skeptic
Have you had the chance to check out the SMBOK publication yet? I feel the answer to your service meta lifecycle quandary is there. The service lifecycle it documents pre-dates ITIL V3 by a street and leverages the product, application and systems lifecycle models. There are 9 mini-lifecycles that co-operate to push service requests through the service lifecycle. ITIL V3 fails to explain what drives a service lifecycle (in the SMBOK model the common item is the humble service request), nor does it document how it actually progresses. The SMBOK details this. Also, it is impractical to pin 'processes' at specific points through the lifecycle. The simple fact is that the point at which they make contact with the service lifecycle changes depending on the actual contents of the service request.
These points are documented using the governance framework.
All of this is meticulously stated in the SMBOK. Did you ever get the access code to work? If not send me an email and I will make sure you get access. The reaction so far here in the US has been fantastic.
SMBOK - does anyone use it?
If SMBOK is so good, then how come the book is out of print, and no-one seems to use it outside a small US clique?
ITIL V3 is here to stay, and the rest of the known world outside of the US seem to be taking to it.
So lets bury SMBOK once and for all.
the beat of the cultish drums
I hear the beat of the cultish drums again: "There is only one true BOK and that BOK is ITIL. Hear ye all the truth and bury your false BOKs."
There are many paths to the top of the mountain. itSMF itself is responsible for two: ITIL and ITSM Library. Then there are SMBOK, ISM/FSM, FITS ...
Get your white hood off and get off my lawn.
MOF
...and if I may add: MOF v4 (recently published: http://www.microsoft.com/mof). The MOF Team Model is still a very useful and open standard for implementing a role/team structure for all other ITSM initiatives. Don't be fooled by the "M" in its name: it is universally applicable. See the Global Best Practices book for guidance!
Maarten Bordewijk
Getronics PinkRoccade
Scared of a wider conversation or competition?
Have you read the SMBOK? Do you view SMBOK as an ITIL 'competitor'? If so, then I will suggest this is exactly the mindset we need to sweep away. ITIL can only get better through more open dialog and perhaps a competitor or two!
SMBOK and many other similar sources of good ideas are not designed to be 'competitive'. take for example the latest publication from Jan van Bon - ITSM Global Best Practices - an amazing effort to compile thoughts on how to 'do' service management. Just published, this book ads 620 pages of interesting concepts and ideas to the 675 in SMBOK. Add other books such as those written by Gronroos on Service Management & Marketing and you"ll discover a whole wealth of invaluable resources.
These publications, like ITIL, are attempts to contribute to the conversation we are all party to on service management. SMBOK attempts to understand what is out there and how to codify service management and good references as it relates to service provider organizations, services and key roles. It presents links to a vast source of pre-existing materials using a common framework and language. This is contrary to the traditional closed, exclusive approach of ITIL, and as clearly represented in your blog entry.
The SMBOK is popular because it is openly extensible, invites professional opinion and input, and actually includes ITIL as well as any other book or set of books that speak to service management. SMBOK is universal in its approach in that it is written to service management principles already in place within most businesses. It is largely IT agnostic. There in lies some excitement - a service management body of knowledge that spans both the IT and business 'perspectives' - and is in customer/business compatible language.
Why not allow open discussion on what service management is, what it is not, as well as the best and good practices to help folks achieve some degree of professionalism and success at service management? We need INCLUSIVE strategies not exclusive and many sources of knowledge from which we can all learn and mature.
As for it being out of print - thats true - sold out, it also needed a more mature and experienced publishing strategy and publisher. Small US clique - thats also true in part - not so much a clique as early adopters who are open to good sources of help and who are prepared to take it forward.
As for burying - lets leave that to customer opinion. Like ITIL, I suspect you"ll find out very soon the SMBOK, or rather is latest incarnation, is here to stay.... many feel thats a good thing...
brutal business reality
No I haven't had time yet. I asked about meta-lifecycle for ITIL not competitive lifecycles :-D I'm not sure you have addressed my question. it's not about how to drive a service lifecycle, it is about how to take a planned staged approach to getting to service management, to implementing the lifecycle.
Whether the SMBOK is better than ITIL or not is a moot point until it gains the sort of industry uptake that ITIL has. Sorry, brutal business reality. DEC made fabulous computers but lost out to IBM who made dull solid boxes. The Mac won't say die but Windows still reigns supreme. Wordperfect was a stunning wordprocessing package buried by Word. Ingres lost to Oracle. Lotus 1-2-3 was a terrific.... Palm-OS... Betamax...
Brutality is the common denominator for ITIL and SMBOK
It sure is a brutal business and results reign supreme here in the US. Fair comment about the behemoth ITIL but its long overdue in delivering results that the executive level counts as tangible. It is doable but does require tender loving care and the hand of someone who is prepared to mingle outside know-how with the books. Now lets get back to your other point. You are right - I failed to answer the crux of your question - an implementation approach.
Well the process led approach is now dead so it should be - its as subtle as a nuclear hand grenade thrown into the IT operational areas and folks find that out all too quickly. None of our clients got much out of that anyway. The most successful mined for problems, used non-ITIL problem management methods (such as Six Sigma or LEAN) to define the problem and relate them to desired results, thus stating impact that meant something, then queued a few of these up, rumbled around in the worldwide good practice box (that includes methods in SMBOK) to make minor adjustments to their practices, to get some brownie points in the bank.
After banking some goodwill they then took a line of business, selected a service and customer using that service, identified a few situations that were common, and increased visibility of all traffic by adding that context to the incident, change and service level management areas.
Any implementation will require mapping of what the SMBOK calls 'vital business activities' (the fundamental working pieces inside business processes), and what ITIL unfortunately still calls VBFs. If you have no other way of finding these you can simply require folks at the service/help desk area to make sure they ask the infamously simple question "what is it you are trying to do you can't do", to relate the request to the VBA, and to chase down impact.
The clue to what VBAs are out there and their relative importance and impact is in a 'business impact analysis (BIA)' effort.
Good though it is, little of this approach is in the old Implementing ITSM book.... and there lies ITIl's problem - a lot of good common sense collected into one place and well presented, but no way of connecting the horse to the cart.... connecting all the huffing and puffing to business benefit. ITIL as an implementation STILL demands a $10,000 per IT headcount investment in year one.... we still lack a promisary note of benefit that is linked to a plan to get there.
ITSM can be done. We have found that a promise of 5-10% 'savings' through increased productivity (carefully defined) for a cost/investment of 25% of those savings is a starting point for promises..... I feel a blog coming on...
LEAN or Anorexic?
Well the process led approach is now dead so it should be - its as subtle as a nuclear hand grenade thrown into the IT operational areas and folks find that out all too quickly. None of our clients got much out of that anyway. The most successful mined for problems, used non-ITIL problem management methods (such as Six Sigma or LEAN) to define the problem and relate them to desired results, thus stating impact that meant something, then queued a few of these up, rumbled around in the worldwide good practice box (that includes methods in SMBOK) to make minor adjustments to their practices, to get some brownie points in the bank.
--------
Results are indeed important:
http://thinkingproblemmanagement.blogspot.com/2008/03/titsup-new-heathro...
I wonder why BAA decided on LEAN for their Heathrow Terminal 5 project.
A thing of beauty. Certain
A thing of beauty. Certain to become a case study.
Paul Colby, the British Airways CIO, incorrectly describes Lean as "...standardising processes in order to reduce costs and time waste and improve efficiency". Lean is not about standardization or some idealized technology-driven end state.
But worse is the implied perception of the organization as an efficient factory rather than as a service provider. The writer, Ronald Bartels, hits the nail on the head: an airport terminal is not a manufacturing line. Services do not equal manufacturing.
"Once the first incidents started happening there was a cascading effect making the incidents accumulatively larger." By adopting a manufacturing mindset, the launch inevitably fell prey to the bugbear of manufacturers (and IT shops) everywhere: The bullwhip effect.
Its like watching a remake of an old movie. You know how it ends.
Old fashioned manufacturing
But a modern efficent lean factory would be designed to deal with the bullwhip effect, the great shift in manufacturing philosophy over the last twenty years has, arguably, been to move away from a steady state steady flow model to a demand driven model.
The flaw in the T5 model was to do with presuming everything would be alright on the night, and skimping on key elements such as staff training and inviolving the workforce in process design. A properly understood lean model would probably have been more successful, but what we are seeign at T5 is the result of a typical misunderstanding of what lean should mean in reality,
They are related
The presumption that everything would cut over neatly was a deliberate choice; it didn't happen by accident. I suspect someone questioned the approach but was overruled. So this means that the confidence levels were high for some reason. I'll posit that the overconfidence was yet another symptom of the manufacturing mindset. Let me explain:
For linear structures outside the laboratory, the bullwhip effect can't be eliminated, only dampened. As you point out, modern manufacturers have gone to great lengths to deal with the operational causes.
But they continue to struggle with the behavioral causes.
When the model for a service provider is "an efficient factory", the behavioral aspects are inevitably underweighted. Roles and responsibilities, for example, are defined for operational optimization (demand flow and such). But in such a model, the behavioral causes of instability show that managers do not adequately account for the time delays in making decisions, and they tend to underweight their ability to meet demand. Hence the behavioral explanation highlight the manager's inability to control systems with lagged, indirect and nonlinear feedbacks. Further, behavioral causes have been identified based on coordination risk, the uncertainty about the actions of other decision makers, and shown to trigger the instability found at Heathrow.
In other words, the bullwhip effect persists even with stable and visible demand. I suspect Heathrow not only understood the demand very well, but had great visibility into the demand after the cutover. I'll wager the demand was exactly what they expected.
But neither training nor communication by themselves eliminate the behavioral causes triggering the bullwhip effect. Allowing participants to have extra hands-on experience does not improve performance, and neither does allowing teams to communicate without prior training. All of which, I'll speculate, were performed and contributed to the overconfidence and the decision to cut over.
However, when training is combined with the opportunity to share knowledge and coordinate through communication, performance improves. System-wide training appears to be more effective than role-specific training, addressing both individual decision biases and simultaneous coordination among multiple participants. But, in a manufacturing model, these capabilities appear to make the organization less efficient. They break the manufacturing line with non-linear structures. So they come into conflict with the manufacturing archetypes and, predictably, suffer from neglect.
Risks and testing
There must be a term for the tendency of managment to misunderstand risk.
More than once I have had the feeling that they think that as soon as you put a probability against a risk that they no longer need to bother about it - and here I think is a good example of a project being driven by a best of all possible worlds view, with no realisation of the relationship betweent the different risks involved and a belief that all their toast would land butter side up, every single time.
This I suspect led to mistakes in how they tested the system, partly because I suspect they never tested the whole system as a single entity (including all the staff involved) and also I suspect they "tested for success", not to see what would actually make the system fail.
What seems hard to fathom is that they didn't even seem to have any contingency arrangements in place.
Ludicity
"There must be a term for the tendency of managment to misunderstand risk."
It is called platonicity. Although, there are specific forms. Its called the Ludic Fallacy (as Taleb coined it) when smart people do it.
For example:
- When wall street puts the world at risk with generalized methods for measuring sub-prime loan risk
- When researchers like ITPI apply linear regression to human behavior (a nonlinear system).
- When IT theorists say, "these models are all we have" instead of "I don't know."
- When IT managers are blinded by a one-size-fits-all model, process, org chart or tool.
buzzterm of the day
It's called the Ludic Fallacy by Taleb, circa 2007, so let's be careful not to put it out there as Received Wisdom.
Interesting quote by Taleb here:
"...economics bothers me so much as a discipline, to the point of causing allergic reactions when I encounter some academic economists'"
Interesting point of view. It's pretty clear that some of the criticisms here are originating from a point well outside of the social sciences mainstream; the Taleb quote nicely crystallizes that. I'm certainly not going to kowtow every time his name is brought up as a bludgeon in these debates.
I'll be addressing the ITPI debate further when I am done with some pressing family matters.
Charles T. Betz
http://www.erp4it.com
Nope
I don't think the Ludic Fallacy is what is in play here. I do remember the black swan concept from my undergraduate philosophy days.
I can iamgine a platonic dialogue about risk.
You shouldn't rely so much
You shouldn't rely so much on Wikipedia.
It was the 2007 bestselling book, The Black Swan, that introduced the term to the mainstream. But its been around longer than 2007. You can find it in previous book and essays; not in Wikipedia. Nor is the idea new. Its been around since at least 18th-century, its just gone by different names like "the black swan problem." Hence the title of his latest book. Does that qualify as received wisdom?
And the quote you found so interesting is taken out of context. It is an attempt at humor in order to make a point - a joke intended to provoke. It is an airplane travel story that ends with him sitting (with admiration) next to one of the most brilliant social scientists of modern times. Ironically, you reinforce his point by falling into a confirmation bias by self-selecting a quote out of context.
Not so humorous, of course, is attacking ideas by attacking the person. Let's stick to the ideas.
Not a term of art
You can split hairs about the date it was coined, but the point is that it is not a generally recognized term of art or philosophy, and throwing it gratuitously into the debate makes bystanders feel like they "live under a rock," i.e. out of touch and unqualified to debate.
By the way, quite a catchall of social dysfunctions attributable to the Ludic Fallacy you have there. Don't you think equating ITPI with the current credit mess is a bit over the top?
Glad to see you aren't writing off the social sciences wholesale. We'll return to that in a bit. Are you saying that applying linear regression to human behavior is rarely done?
On another topic, I would be interested in anyone's opinion on this survey, run by a noted Agile Methods practitioner:
http://www.ambysoft.com/surveys/dataManagementAugust2006.html
Charles T. Betz
http://www.erp4it.com
Very reasonable research.
Very reasonable research. The data was taken for what it was and the conclusions did not overreach.
I particularly liked this caveat:
"This survey suffers from the fundamental bias that all surveys suffer from: it doesn't capture the opinions of people who aren't willing to fill out a survey."
Poetry.
Term of art? So we are back
Term of art? So we are back to attacking things other than the idea. Some would argue ERP4IT is not a term of art. But that argument is equally silly since “term of art” is wholly subjective and based on this proclivity for confirmation bias rather than evidence.
I will succumb to my own confirmation bias and point out that "Ludic Fallacy" is quite topical on Wall Street (to describe the sub prime mess and such), the UN (to describe the lead up to the Iraq war), the IMF and a whole community of statisticians seeking to evolve their profession. Philosophers have generally ignored it because, well, it’s a very old idea going back to John Stuart Mills. IT managers can certainly benefit from a little of this knowledge.
I'm not against the social sciences; only science done improperly. I'm not against skeptical bias; I'm against bias for confirmation. I'm not against research; I'm against being a sucker.
For example, I’m not saying linear regression is rarely done on human behavior. I’m saying it is often misused, as in the case of ITPI's analysis:
Regression is a process which tests if variation in a dependent variable can be predicted through knowledge of the independent variables. Methods vary depending based on the relationship (e.g. stochastic or deterministic). This relates to the nature of social science as compared to physical science. For example, you can compute the velocity of an object given known conditions.
This is not the case with systems based on human behavior. Change management, for example, is affected by many human variables. Worse, independent variables, such as other processes (e.g. Incident management), or skill/experience/staffing levels, workload, complexity of tasks, time of day, day of week, business cycles, and so on, are seldom in equilibrium. The degree to which these variables impact performance will always remain imprecise; “predictions” will not hold up well.
For linear regression to work, certain assumptions must be met.
- Linearity: assumes the variables in question have a constant proportionality in the relationship. When driving speed doubles, the distance needed to brake increases fourfold. It is not a linear relationship. It is curvilinear. The same with Change Management. For example, performance enacting 5 daily RFCs will differ from a day with 50000 RFCs, and not in a linear way. Linear regression does not work unless the variables are transformed with nonlinear techniques.
- No Multi-collinearity : Causation in human behavior is very often complex. Performance of Change Management can be affected by things having nothing to do with the CM process (e.g. Incident Management). Linear regression works well when the impact of one independent variable has on the dependent variable, controlling for the presence of the other independent variables. This is fine as long as the independent variables are not strongly correlated to one another. If they are related (positively or negatively), then the results breakdown. It is difficult to sort out the effects of the independent variables on the dependent variable. If the problem is solved by deleting the independent variable, then the result is a seriously biased.
- Statistical inference: A regression represents a hypothesis of how some performance can be explained. Therefore, the model requires testing in order to determine whether or not its predictive ability is significantly better that what would have been obtained by chance or guessing (without knowledge of the independent variables). Where's ITPI's tests? Moreover, where is it's hypothesis?
- Normal Distribution - The use of regression assumes a normal distribution in all the variables. If the data is not normally distributed, you cannot make the statistical tests assumed in the model. ITSM variables appear to lend themselves to power distribution laws rather than Gaussian distribution. I’d love for either you or ITPI to explain otherwise.
And there are others like heteroskedasticity or ensuring the absence of autocorrelation or path dependence, and so on... I'd explain but this debate is getting rather boring.
This may sound complicated, but its not. But it does take hard work.
Interesting!!
>>I'd explain but this debate is getting rather boring.
Hey visitor!! This seemed to be really interesting. May be its boring for you, but not for me because you are adding some science and maths here. Please could you explain?
:-) Thanks!
Antonio
sure
If there is a specific area you have a question on, feel free to send a message to visitingskeptic@gmail.com. I don't want to weigh down the thread too badly.
Concession
It occurs to me, a bit too late, this isn’t really about a critical analysis of ITPI’s research. This is about wanting something to be true; needing it to be true.
It’s similar to the phenomenon of those who need a certain candidate to win the presidency. Critical thinking left town a long time ago. Once the mind is made up, no amount of logic can effect change. Facts are subject to the interpretation of desire.
At the very least, there have been serious doubts placed at the feet of the ITPI research. Here’s my concession: If after all this you still believe the research is valid, go for it. Promote it, proselytize it, hand it to your boss, give it to your co-workers. I won’t object.
Unless I’m in the room.
Detailed ITPI response
Regression is a process which tests if variation in a dependent variable can be predicted through knowledge of the independent variables.
Methods vary depending based on the relationship (e.g. stochastic or deterministic). This relates to the nature of social science as compared to physical science. For example, you can compute the velocity of an object given known conditions.
This is not the case with systems based on human behavior. Change management, for example, is affected by many human variables. Worse, independent variables, such as other processes (e.g. Incident management), or skill/experience/staffing levels, workload, complexity of tasks, time of day, day of week, business cycles, and so on, are seldom in equilibrium. The degree to which these variables impact performance will always remain imprecise; “predictions” will not hold up well.
This is exactly the point of research, to attempt to sort through such multiplicities of factors (they surveyed on 57 variables) and determine “what really matters.” Variables suspected of not being in “equilibrium” need to be controlled for. This is all part and parcel of the method.
Your critique could be applied generally to all uses of regression, and in fact all attempts to discern causality, in complex domains.
I don’t know why you are reluctant to admit this, other than the fact that it aligns you rather firmly with strict positivist views of science that tend to be disdainful of all social sciences (including psychology, economics, management theory, and operations research).
For linear regression to work, certain assumptions must be met.
- Linearity: assumes the variables in question have a constant proportionality in the relationship. When driving speed doubles, the distance needed to brake increases fourfold. It is not a linear relationship. It is curvilinear.
I have confidence that ITPI's statisticians understand these basic issues, which are covered in introductory statistical courses.
The same with Change Management. For example, performance enacting 5 daily RFCs will differ from a day with 50000 RFCs, and not in a linear way.
What do you mean by “performance”? Changes not rolled back? Business value derived from the changes? What is your source for this assertion? Do you have a data set showing 50000 RFCs a day?
BTW, the largest organizations I have encountered, with IT budgets in the low billions US, might process on the order of ~10000 RFCs a month. You’re proposing an example two orders of magnitude larger. Have you worked in IT shops with budgets in the hundreds of billions? I do not think there are any IT organizations that large.
Linear regression does not work unless the variables are transformed with nonlinear techniques.
We have not yet established that the correlations are nonlinear.
Causation in human behavior is very often complex.
Of course. But are you saying understanding human behavior is impossible? That would be a philosophical statement, not an empirical one.
Performance of Change Management can be affected by things having nothing to do with the CM process (e.g. Incident Management). Linear regression works well when the impact of one independent variable has on the dependent variable, controlling for the presence of the other independent variables. This is fine as long as the independent variables are not strongly correlated to one another. If they are related (positively or negatively), then the results breakdown. It is difficult to sort out the effects of the independent variables on the dependent variable. If the problem is solved by deleting the independent variable, then the result is a seriously biased.
I question how thoroughly you have read the ITPI material. If you want to frame a critique here, you need to address their use of factor analysis, “a data reduction technique used to represent multiple observed random variables in terms of fewer derived or synthetic random variables called factors” (p.50); and their use of stepwise linear regression, in which “variables are automatically added or removed from the set to eventually develop the set of predictive variables that best accounts for the greatest variance in the dependent variable” (p. 55).
Statistical inference: A regression represents a hypothesis of how some performance can be explained.
Regression per se does not seek to explain or hypothesize. It simply identifies relationships. It is up to the social scientist to hypothesize explanations for the relationships.
Therefore, the model requires testing in order to determine whether or not its predictive ability is significantly better that what would have been obtained by chance or guessing (without knowledge of the independent variables). Where's ITPI's tests? Moreover, where is it's hypothesis?
The tests are clearly embedded in the method. They didn’t assert prediction unless the correlation was statistically significant. The null hypothesis is that “nothing matters,” that none of the practices make any difference. Therefore, ITPI’s hypothesis would seem to be that “something matters.” This is so obvious and trivial that yes, they probably assumed that the intelligent and charitable reader would infer it.
In personal correspondence, ITPI director Kurt Milne states:
“the formal hypothesis – (which we don’t write up in the report) is something like:
• “H: There exists a subset of change, config and release practices that impact IT operating performance to a greater extent than other change, config and release practices.
• “H0: There does not exist a subset of change, config and release practices that impact IT operating performance to a greater extent than other change, config and release practices. Any difference in performance is a matter of chance.
“When we do the analysis – it is definitely geared toward testing a hypothesis. We follow an analysis plan that we write before we collect data (to avoid exploratory research) to run the tests. We just don’t write all that up – because our target audience (IT decision maker) doesn’t want or need all the rigor of that documentation.”
Having now obtained some of this supporting evidence, it appears to me that ITPI has credible statisticians in their employ, using standard and accepted practices which account for the issues you raise here.
Normal Distribution - The use of regression assumes a normal distribution in all the variables. If the data is not normally distributed, you cannot make the statistical tests assumed in the model.
Milne also states:
“… we did run standard distribution tests and the stats guys were confident that we have a good distribution on independent variables.”
ITSM variables appear to lend themselves to power distribution laws rather than Gaussian distribution. I’d love for either you or ITPI to explain otherwise.
A categorical statement about “ITSM variables” is dubious. There are probably several dozen major data entities in the ITSM space at a conceptual level, each with potentially hundreds of individual attributes, representing all the various metric domains (categorical, ordinal, cardinal, real), and each variable described by a distinct distribution (assuming one could accumulate the data).
For example, duration of incidents might be a normal distribution, while financial impact of incidents probably does follow power law (relatively few incidents contribute to the majority of loss, certainly true in my experience). Chris Verhoef has done excellent work on IT portfolios, rigorously demonstrating that they actually follow lifetime distributions (neither normal nor power law.) See “Quantitative IT Portfolio Management,” Science of Computer Programming 45 (2002), 1-96.
ITPI’s statisticians, per Milne, have observed this empirically: “Some (like derived “top half count” are very normalized. Others have various distributions – one tailed, two tailed etc. My stats guys assured me that the regression analysis works with different shapes – if independent variables are normal.”
And there are others like heteroskedasticity or ensuring the absence of autocorrelation or path dependence, and so on... I'd explain but this debate is getting rather boring.
There are many terms and concepts one might pull out of statistical texts, and yes, describing them is tedious when any interested reader can easily look them up. The question is, does ITPI have access to professional statisticians who understand these issues? You seem to be making a poorly substantiated claim that their efforts are amateurish.
By Visitor (not verified) at Sat, 2008-04-12 16:03 reply
Concession
It occurs to me, a bit too late, this isn’t really about a critical analysis of ITPI’s research. This is about wanting something to be true; needing it to be true.
It’s similar to the phenomenon of those who need a certain candidate to win the presidency. Critical thinking left town a long time ago. Once the mind is made up, no amount of logic can effect change. Facts are subject to the interpretation of desire.
At the very least, there have been serious doubts placed at the feet of the ITPI research. Here’s my concession: If after all this you still believe the research is valid, go for it. Promote it, proselytize it, hand it to your boss, give it to your co-workers. I won’t object.
Unless I’m in the room.
By Visitor (not verified) at Sat, 2008-04-12 16:50 reply
You've not succeeded in raising serious doubts. And your parting shot is ad-hominem, obviously. Let me propose a counter-interpretation: you have some personal interest running counter to ITPI, perhaps because you work for a competing organization, or due to industry alliances. This would also explain your anonymity.
Alternative explanation #2: you jumped to ill considered conclusions regarding ITPI, and after actually obtaining their research and studying it, you have begun to realize the depth of your error and the difficulty of sustaining your case.
I think, pace Occam, either is a simpler explanation than psychoanalyzing me.
For myself, I admit no interest (beyond collegial) in the success or failure of ITPI, and I deny any emotional attachment. As an end consumer of the ITIL/ITSM intellectual enterprise, my primary concern is “what are the terms of the debate”? If mainstream operations research and statistical theory is insufficient to understand IT Service Management, then we are truly at sea with no compass.
Even Taleb admits that linear regression is appropriate in psychological survey research (page 245, The Black Swan), and the ITPI survey research is not far removed. I for one am not ready to abandon well established methods just because of the existence of black swans.
Charles T. Betz
http://www.erp4it.com
Well... it has a name
it is called Cognitive Dissonance.. people want it to be true. :-)
Perhaps a varient on it?
I've often used cognitive dissonance as a concept in my lecturing days, and another useful related concept is that of change blindness. I'm not quite sure though that it conveys the precise thinking pattern amongst senior management that I'm thinking of, though I am sure that it is an important contributing factor.
I suspect coginitve dissonance cuts in quite late in the day, when managers try to hold on to a low risk world view despite the existence of contrary eveidence of things going wrong. The root of the problemn seems to start much earlier, when managers "switch off" when it comes to risk and not to understand what they are being told.
Denial?
Denial?
close, but no free lunch
Again, sort of, but not quite. Thanks by the way to everyone contributing to this line of thought.
Denial is clearly a symptom of the behaviour I'm thinking about, but is it an explanation?
Let me posit an idea. Most of us with a sceptical predisposition...no hold it, maybe that is the answer....I believe some research has been done on how teenagers assess risk. The answer. of course, is not very well, which comes as no surpise to me as the stepfather of three of them. Teenagers will tend to favour the high risk option even when presented with the evidence, because in the nicest possibly sense they are narcistic, and think the stats don't apply to them because they are special, but most grow out of it. Perhaps senior managers don't? Is the answer that a senior manager thinks "This is risky for everybody else, but not for me"
Meanwhile I will suggest a solution to a client whilst kjeeping my fingers croissed behind my back bedcause I know in the horrid real world my advice will only work if the planets align.
Have you noticed no one has
Have you noticed no one has ever seen Taleb or The ITSkeptic in the same room at the same time? Their skeptical styles bear a remarkable similarity. :-)
Very few people have seen the IT Skeptic and ANYONE else
Very few people have seen the IT Skeptic and ANYONE else in a room together. You get your chance in Holland at the end of this month
Risk vs Lifecycle Longevity
Many executives base their decisions on length of tenure, and what is the likelyhood of their decisions and actions coming back to haunt them in that time.(Their own risk management)
In my experience, you need to leave the executive meeting without any degree of uncertainty as to the consequence of accepting to make no decision with risk, and who ultimately owns it. At least a do nothing decision will invoke alternative contingencies.
I personally have not heard of the Ludic Fallacy by Taleb, but then I live under a rock in the real world. Poor decisions by IT executives come back to a poorly communicated issue/problem/objective/saving or a totally non-IT agenda on behalf of the executive. Isn't this Ludic Fallacy just an extended spin on the old term FUD (Fear , Uncertainty and Doubt)? IT Management have dealt with this for at least the past 20 odd years.
You're right. It's a recent
You're right. It's a recent examination of an old problem. How do we deal with FUD without ignoring it or fooling ourselves and then expressing surprise at the consequences.
Greiner's model needs updating?
Reading the comments made on the implementation of ITIL3 made me think first of the nature of ITIL: it is a collection of best practices on IT Service Management. Not a academic model or theoretical framework (although, after reading the Service Strategy book, that has changed a bit). Since the ITIL books are only just published it is no wonder that there is no practical experience with the implementation of ITIL3. Therefor we will have to wait till there are experiences on how to do and not to do implementing ITIL3. Then we can create a Meta-life cycle on implementing ITIL3.
The problem with CMM (I have not read the SMBOK, so I can't judge this) is that it is very academic and internal (i.c IT department) focused. It is very constructed, as if growing in maturity is some sort of a project and that it can all be planned. Since that is not the case, the CMM models are only useful to help identify maturity elements and so determine where you are in the development of the IT organization.
In the Service Strategy book Larry Greiner's model of Organizational Growth and Development is introduced in the chapter with implementation guidance. This model describes the more organic growth of an organization as short burst of revolution followed by long periods of evolution. The revolutions are the response on a crisis that needs to be dealt with (or otherwise the company will be out of business). In the Service Strategy book the 5 stages are described, including the crisis leading to the revolution. This model is useful as a basic Meta model for ITIL implementations (out of curiosity, why would an ITIL implementation be a cycle? That is not very sensible). Unfortunate the authors have failed to read Greiner's later comments that his original model was mainly meant for a manufacturing organization and is less (or not) suitable for service organizations. We would have to adapt Greiner's model to the IT Service organization, maybe using Nolan's original 5 stage maturity model for Data management. The ITIL guidance for instance can be used as a response in the crisis between technology driven IT organizations and added value expecting customers.
Very insightful comments.
Very insightful comments. Nice points but I’m not familiar with Nolan’s 5-stage model. Nolan’s original 1973 model consisted of four stages following an S-shaped curve. He later (1979) added two stages, data administration and maturity, for his current 6-stage model. Is this the model you are referring to?
If so, I can understand the appeal. Nolan’s model is elegant and his logic nicely constructed. Unfortunately, despite years of attempts, empirical evidence for Nolan’s model has been poor and, at best, inconclusive. There is no real-world evidence to make it valid as a model. See empirical studies by Benbasat, Dexter, et al., or King and Kraemer, or Saaksjarv. Please correct me if that has changed.
I don’t think Greiner’s model is anywhere near the final answer but, in practice, it has held up well. If you take a second read, you'll see the ITIL authors slightly modified the original model in order to address some of Greiner's caveats.
These archetypes continue to show up in IT service organizations. General Motors IT organization, for example, is a modern day service organization adopting a stage-5 services org model: See “GM's matrix reloads: how an org chart can inspire internal competition, drive process efficiencies and make a business more competitive.” At the Chicago launch, Merrill Lynch gave a presentation on their move to a stage-4/stage-5 IT services org.
That’s the interesting thing about ITILv3. Despite some of the snipes on this board, the authors cast a wide net in culling from post-2006 industry practice. They were careful not to offer guidance that were not endorsed in modern praxis, no matter how elegant. The Operation authors, for example, pulled approaches from within multi-vendor shops such as General Motors. I know the strategy authors culled from a large number of CIOs and CTOs from small, medium and large IT shops. Each of the case examples, interestingly enough, is a true story. I understand they had a financial management guru from Harvard business school proof the financial management chapter.
removed a chain of comments
I have removed a chain of comments here that stemmed from an inappropriate comment now regretted by its author.
In general once you make a post it is out there, but in exceptional circumstances I will take it down. In this case the post refered to a private conversation and (according to the other party) misrepresented it. I think it best to remove that.
CMMI-SVC
CMMI-SVC apparently will have a staged representation, which might start to answer your question.
See https://bscw.sei.cmu.edu/pub/bscw.cgi/0/424939 for the "public workspace" and
https://bscw.sei.cmu.edu/pub/bscw.cgi/d537712/CMMI-SVC%20baseline%20for%...
for the draft itself.
However, like many others, I never bought into the idea of a linear march through the original CMM levels as optimal; I always found them too academic and arbitrary. I prefer the view that there are multiple "routes to value." There are many paths to the top of the mountain. This is why there is now a Continuous representation for CMMI as well as Staged.
Now, what would be interesting to me is the specific functional dependencies between finer grained capabilities, such as the fact that one can't support dependency-based risk analysis (in the service of Change Management) without comparable maturity in Configuration Management. But that level of detailed dependency understanding has not been apparent to me in the staged CMMI representations; there's been a bit too much "take it on faith."
Charles T. Betz
http://www.erp4it.com
CMMI-SVC could be the solution but...
Charlie, you are right with the commend about CMMI-SVC, but the development of CMMI-SVC was suddenly stopped by the DoD sponsor on April, 26 so right now the standard is in draft, published and revised by the CMMI Expert Reviewers team, but no answer from the NDIA.
A stagged maturity model for ITSM is something really interesting, and even it would allow for a phased or layered ISO 20.000 certification (something that is becoming a point of interest in the GT25 meetings)
Regards!
Antonio Valle
http://gobiernotic.blogspot.com