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.
See http://erp4it.typepad.com/erp4it/2006/05/whats_a_change_.html
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.
Made in New Zealand 
Comments
In its defense
In its defense, ST does say in 4.2.2
ITIL V3 Framework
The V3 Framework is excellent. Unfortunately, the people who created it don't appreciate the potential. They created a great framework and then took all of the V2 Operational stuff and used it as supporting detail. V3 concepts can be applied across the enterprise but the authors of V3 continue to focus on operations.
Service Management
Funny you should say that: see USMBOK or my new book due out for Christmas. Neither work is IT-oriented but both are about Service Management.
The constant refrain that IT
The constant refrain that IT and business MUST be aligned seems to be responsible for much of this; "alignment" doesn't mean that every move IT makes must be justified from a strategic standpoint. If the business side asks "What are we doing to ensure our IT department is strategically aligned?" and IT can say, "Well, we can use ITIL v3 to make strategic change decisions..." then everyone is ostensibly satisfied, even if that's not really what ITIL is for. "Operational" shouldn't be a codeword for "unimportant and easily ignorable," but it's not as sexy as strategy, unfortunately, which even the ITIL writers have picked up on. A tight focus on ensuring that operational change procedures are managed efficiently is no bad thing.
breaks down with Change
I think that - for once - this isn't about "alignment". The separation between strategic/aligned/business actiivty and backroom/operational/IT activity breaks down with Change. Change is the connection between them. They are not aligned, i.e. pointing in the same direction. they are linked, integrated. Organisational change is what drives a lot of IT change (although IT also generates a lot itself). Which is fine so long as ITIL sticks to running the backend operational IT change. But as soon as it talks about user RFCs and service portfolio and demand, suddenly it is poking its nose into organisational change. You can't separate out IT service change from business change. They are one and the same. So Service Strategy swaggered into the boardroom, but Service Transition stayed firmly rooted in the IT Change Manager's office, and confusion reigned.
There are four types of change
In support of your discussion...
There are four types of maintenance (change) applicable to products and services as defined within the USMBOK (@Page 184):
- perfective (new functionality)
- adaptive (forced compatibility)
- preventative (proactively avoid and issue)
- corrective (post issue or failure)
Each are subject to prior justification, which naturally includes cost. A MAJOR initiator of maintenance is Problem Management, where almost everything required to review and approve the change is prepared, including the action plan and expected results. Another MAJOR instigator is the product or Service Manager, or whatever name is assigned to the individual responsible for the Service Plan, which dictates the functionality of the service.
The type of change (reason) is one element of the overall classification scheme. This is often missing from guidance in many of the popular frameworks. Other elements more commonly found include area of change (hardware, software, organizational), and of course the degree of risk. ITIL is correct in reminding us that the governance associated with a reviewing and approving a change should be proportional to the level of risk. It should also reflect the required knowledge and affected or involved communities.
The change practice should be used for all changes. The procedure used should be 'proportional' and include the degree of risk and the resource commitment to effect.
A key metric to successfully managing change is being able to compare estimated with actual cost.
Again - are we discovering that ITIL offers useful but incomplete guidance?
more than production change but less than organisational change
are we discovering that ITIL offers useful but incomplete guidance? indeed.
What your discussion doesn't address is where change kicks in. the four categories you describe sound to me like they apply to IT production cnahges. they don't sound like a good model for business organisational change.
I don't believe ITIL's description of change is adequate to manage organisational change requests: new product, new IT application, office move, merger, change of branding... and yet it tries to be more than just IT production change. And it explicitly does not manage projects or project portfolio, but it does attempt to manage service portfolio. And so on and so on. ITIL V3 is caught partway between IT and the business, more than production change but less than organisational change.
Organizational change drivers... and types
Although my wording may have been slanted to non-organizational change - and towards products and services, the types of maintenance do indeed include any organizational, process, documentation or similar change required.
The driver for the change can be anything. Lets go back to the service for a moment and consider the need of a service (product) manager who must react to new/customer market needs in a market they currently exist. The resulting strategy (service plan) might require a change in the support structure, new service branding, and a complete rewrite of how costs are recovered (new billing and invoicing procedures), oh lets add in new governance. perhaps it was all driven by a new government regulation - who knows.
The 4 types are designed to handle this type of change. I'll be writing on this in more detail in an upcoming book ' Service Change Management'.