Confused change management in ITIL V3
I believe ITIL has aspirations beyond its station. ITIL is an operational framework for IT production environments. So long as it knows its place and sticks to it, all is well. But every now and then it gets an inflated view of its own importance and starts poking into the development aspects of IT, or worse still the strategic ones. This is an example of the latter, where the book is confused between operational and strategic aspects of change. The forums are littered with confused postings. Sometimes a RFC is something that fixes a problem or is an operational tweak, at other times it is something raised by an end user, e.g. a request for application enhancement or a whole new application. The two are totally different things.
Charles Betz set this thinking off with this comment
the ITIL concept of Change "can't be done" and is so far removed from my operational reality as to be baffling.
I've worked in education, retail, consulting, and banking, in organizations with a combined annual spend of $3.5 billion on IT. I have NEVER seen a CAB do cost/benefit analysis. That front end to the IT service lifecycle is variously called project portfolio management, project initiation, customer relationship management, demand management, and other terms. I have NEVER seen it called "Change Management."
Nor are the senior executives responsible for authorizing those investments ever assembled together in anything called a CAB or something similar. There is always an IT executive committee reviewing the major investments, but that's just part of their job, and the overlap between that group and the operational CAB is small.
Am I generalizing from too small an experience basis? Let me tell you a story. I presented at the 2006 ITSMF Upper Midwest (U.S.) regional, to a very full room of about 100 people, on an enterprise architecture approach to understanding ITSM. I posed the question to them:
"Do you see Change Management as
" 1) a holistic process for initiating all changes to IT services, including cost/benefit analysis and approval of major change initiatives even pre-project? Or
" 2) a primarily operational process with a 1-4 week lead time, focused on specific configuration changes to managed environments, for the purpose of communication and coordination?"
100% of the people chose #2. And there was a lot of muttering as people digested this. Some didn't even seem to realize that ITIL calls for #1.
Admittedly at one national EAC conference I asked the same and got a small minority indicating that they lean more towards #1.
In a very small organisation it can (in fact should) be 1 and 2 merged together - the organisation is too small to distinguish them: there is only organisational change with IT as one flavour of that. But for the kind of sites we are talking about on this blog, there is a massive distinction between organisational change and administrative IT production change and the two should not be muddied. The latter is the responsibility of IT, the former is not. They both have the word change in the title and a vaguely similar process, but beyond that they are owned and operated pretty much independently: organisational change invokes IT operational change when the time comes to do the IT bit. See my model of change.
In fact there are three levels to this. Does IT operational change handle a change from when a user thinks of it? ...or does IT operational change handle a change from when development starts to think about changing the code? ...or from when the change is ready for testing and production handover?
ITIL V3 could have done either of two things to clarify this:
(1) grow to properly cover more than production operations by presenting a cohesive model of organisational change, properly integrated with and feeding Demand Management, which would also need to be an organisational not IT-centric process
(2) pull its head in to only cover production operations.
ITIL V3 did neither - it toyed with a larger land-grab without executing it properly. The Service Transition book should concentrate on IT operations and leave the higher-level organisational stuff to others. If ITIL is seriously going to address project-level and business-level change, it should do so distinctly in a separate book.