Posted October 25th, 2010 by Roman Jouravlev
…We’ve discussed it many times with my colleagues and students but somehow there hasn’t been an occasion to write the whole picture down. So here it is – seeming to bу quite contradictory to what ITIL says and in some particular aspects even heterodox.
The service lifecycle
While evolving from version 2 to version 3 ITIL has renamed groups of processes, sometimes without any changes to the content of those groups. The cycle formed via this transformation looks quite reasonable until one comes to details of the processes. He or she would find many questionable areas not only relating a process itself but also in regard to its role in the phase and in the whole cycle.
First of all, naming all five parts of the model as lifecycle phases ITIL confuses anyone who had ever looked in a vocabulary for what phase means. Service strategy and continual service improvement are not phases, are they? These elements of the model are vitally important but this fact doesn’t make them phases of the cycle. So when I say service lifecycle I mean three phases that form it:
- service design and delivery
- service transition and control
- service operation and support
Personally I wouldn’t form the cycle this way but let’s consider the grouping as given – just because the books exist and the processes are packed the way they are. Having them packed this way we can only write proper notes on each package. I’m sure that processes in each group are capable to achieve common goals. There are three clear goals for each group and they are a bit different from those stated in the books.
Service design & delivery
This process group jointly ensures:
- New/changed services design – translation of customer’s service level requirements to service design package.
- Ongoing quality management for services in operation. (This function of SLM is somehow moved to CSI book in ITIL but the duty is applicable for other processes as well. These activities are partly covered – or better to say mentioned – in Service operation book (4.6)).
- Relationship management – meaning relations with customers/business upwards and with suppliers/subcontractors downwards.
Note: In other models some of the processes migrated from this group to another but in ITIL they just hide some important duties over “design” title.
Service transition & control
These processes are responsible for:
- transition of new/changed services from design to operation – often in cooperation with development (considered as a black box in ITIL).
- safe and effective modification of services in operation (operational changes that need a degree of control though not related with design).
- control of the state of permanently changing service infrastructure
Note: These goal statements don’t cover knowledge management process but in this case I would insist that it is because the process is in a wrong place, not because the goals are incomplete.
Service operation & support
Well, processes in this book are still mostly regard support but nevertheless with a little help of so-called “common operational activities” they try to do the following:
- ensure normal operation of the services in accordance with their design
- restore normal operation when it appears to fail
- prevent/decrease possibility of service failures via improvements in operational environment.
Note: some processes described in service operation book don’t seem to be processes at all. I mean event management which is clearly a function (if we do insist it is a process, the need for consistency makes us to recognize Service desk as a process as well) and access management.
The last note needs to clarify the distinction between processes and functions a little. I’m sure that these terms are mixed up in ITIL. It may sound strange but the reason they are mixed up is the improved standardized structure of the books.
Goal/purpose/objective
All processes in ITIL are described following the same structure. In fact it means they are described using the same titles and sub-titles but it is a great improvement beside to what we had in version 2. But common structure brings common errors or ambiguities if possess ones.
Every process has something entitled “goal/purpose/objective”. I consider it as a source of confusion:
- Goal is an inalienable attribute of every process – by definition of process. Process is a set of activities directed to a specific goal.
- Purpose is a functional intension of something and relates to the utility of a subject. Function is a set of assets realizing specific purpose.
Trying to define both goal and purpose for a process one steps into a trap. Check chapters 4.n.1 in any ITIL book to see how authors have managed to overcome it.
I have mentioned this fundamental distinction (which is quite obvious and widely discussed) just to show why I’m sure that both event management and access management are functions providing specific functionality to various processes in exactly the same manner that other functions do.
Fit for life
All these comments are not vitally important to real-life service management practice. But as a trainer I have to look for a consistent big picture for service management system and ITIL doesn’t always provide one. So what do you think? Do you find ITIL service lifecycle complete and consistent? If not – what would you change and why?
Geoff Harmer
(25/10/2010)
A very interesting viewpoint, Roman.
My two cents:
In my view, it is probably safer to consider processes as "hosted" in a lifecycle phase, rather than accepting that is the only place the process takes place. In particular, Knowledge Management applies in all phases of a lifecycle. There is a diagram in the Official Introduction to the ITIL Service Lifecycle that makes this spread across the lifecycle clear. See p. 150 fig 10.2.
Regarding Goal/purpose/objective. I have always adopted a view following the V2 approach of starting with a process mission statement:
Start with a mission, break that into goals and break the goals into objectives. As you do this the amount of detail increases.
Analaogy:
A famous USA mission was "a man on the moon by 1970"; the goals were "get a man into space", "get 2 men into space", "get 3 men into space", "get a spacecraft to the moon" and so on. The first goal needed a set of objectives: e.g. "build a powerful rocket", "build a spacecraft, "build a life support system", build a re-entry system etc.
When ITIL V3 started using purpose, I saw that as meaning mission. So I order them Purpose/goal/objective. and tell my delegates it is really Mission/goals/objectives.
Geoff
Roman Jouravlev
(25/10/2010)
Thank you, Geoff!
regarding G/P/O confusion: that's exactly what I've meant telling about traps. No matter who has better interpretation of that. What matters is that we have to interpret such an important and need-to-be-clear part of ITIL. I'm quite sure that author of the structure had some third meaning in mind while inventing that title...
...And of course a translation problem is also involved here.
Aale Roos
(25/10/2010)
Good article Roman. World needs heretics.
It is amazing that a service lifecycle model, which is not a lifecycle and does not include business relationship management and/or sales can be so popular.
Just a detail. I have been saying that event management is an activity of the Monitoring & Control function(s).
Roman Jouravlev
(25/10/2010)
Thank you, Aale!
...and what do you think about Access Mgt? I'm sure it is a part of what MOF used to call "Security Administration". Nice and important thing but why call it a process?
Anonymous
(25/10/2010)
I agree with the sentiments expressed - though as you say Roman different people will have different interprertations and in my view therein lies the conundrum - it should not be so unclear as to require the need for interpretation!
When I was developing couursware for the the full set of ITIL V3 courses the P/G/O was one if the more obvious areas of inconsistency as it seemed like each set of authors was left to define what that meant and therefore how they should be stated - as soon as I saw that, I knew I was in for a challenge to make the courseware consistent. Maybe if they had an overall editor who understood the publishing business it might have been different - not so sure that was case based on the result.
I am also not so sure it will be any better in the upcoming updates
John Worthington
(25/10/2010)
I like and agree with your view of Strategy & CSI as not really 'phases' in a life cycle, and I tend to tell students that the 'processes' described in ITIL are in the books where they are most active and/or contribute to the lifecycle 'phase' and not that they are restricted to a particular point in time....
as for goal/purpose/objective, while I like the specificity you illustrate I usually just leave it at "the goal of the process is to.." particularly at the foundation level.
As for Event Management, why raise another tirade about process vs function? What's so wrong about Event Management as the process, Operation Control as the Function, enabled by monitoring automation?
Jan van Bon
(25/10/2010)
This discussion touches upon one of the core flaws in ITIL, or better: one of the core misunderstandings that tend to happen when people use ITIL.
ITIL indeed is not a lifecycle. Just take a vocabulary, and anyone can see that ....
ITIL does NOT describe processes - it's a set of best practices, and it says so.
ITIL follows the worldwide accepted definition of process. But show me the process in chapters like Security Management, or Capacity Management.... Stop expecting to find processes in ITIL.
@Roman: "not vitally important to real-life service management practice"... I totally disagree. They're vital! If you do not know your processes, then how would you ever be able to manage your activities in an effective and efficient way? Your processes are directly related to your true nature. Only organizations with different businesses will have different processes.
Asset management is a function. Security management is also a function. Just like Capacity management and many others. There are many functions described inITIL best practices. It's vital to make the distinction, if you ever want to be able to construct a smart organization.
Read the article I published on Functions & Processes in 2008, in "ITSM Global Best Practices - Volume I".
You can download the article here at the ITSM Portal.
Roman Jouravlev
(25/10/2010)
Thank you, Jan!
...what I mean by saying "not vitally important" is the following:
You can call your processes "functions" and call your function "processes", or split some of them and combine another, or totally redefine any terms... until you understand your reasons and until your own model - conservative or the most extravagant - fits your goals and helps you to manage properly. Self-invented good bike can be better then properly copied knockoff based on good practice.
Most of ITIL flaws and ambiguities ar just ITIL's. We don't have to depend on them, they've nothing to do with us if we don't want them to. So I consider this column mostly as a way to share some points I often have to deal with as a trainer. It is not a holy war, really.
Jan van Bon
(25/10/2010)
Indeed - this is just about making sense.
Unfortunately ITIL is a hype, which means that too many people just follow every book to the letter, and compete their fellow 'expert' by trying to be better at the understanding of the holy book. We've seen this with many hypes, and it always leads to the same result: high cost, low effect.
On the 'personalization' of 'the model': I don't think 'any' model will work. There are several paradigms that are used all over the world and that have proven their effectiveness. It would not be wise to ignore these. Yet, many managers ignore the most basic paradigms around, and follow ITIL gurus instead.
Anonymous
(27/10/2010)
Jan, It is about making sense, and if by hype you mean using ITIL for the purpose of saying you are ITIL complant, without actually getting any value out of it, then it is a "hype" for those who use it that way. I don't think you are saying that it is all hype.
As a neophye user of ITIL good practices, the more I read, and the more we (the college) use, the more application of those practices I see, and the better I see them fit together. I keep having "aha!" moments when we are wrestling with an issue and I suddenlty see what ITIL provides to address that type of issue, and how that fits between the pieces we arleady have. ITIL says frequently that there is no one set way to do things, and that each organzation has to adjust the practices to what works for that organizaton. For us, using that apporach, IITILis proving its value on an ongoing basis.
Anonymous
(09/11/2010)
Great post Roman, good points and good resulting inputs. Personally, I think V3 took ITSM a good few steps forward, i.e. tried to map to a lifecycle and typical organisational structures, and develop/add topical 'processes'. It was always going to be contentious though, but had to be done.
I agree ambiguities remain (and some added!). It must be tough being a trainer facing the skeptics and the new & confused! As a veteran ITSM'er I can handle the ambiguity, as I agree with the detail (mostly) and realise the groupings (processes, functions, phases, org'n) is open to interpretation & situation ... but I do believe on the whole it's got it right.
The risk is that people will undermine and potentially kill ITIL as it breaks tricky territory, as opposed to contribute to clarifying and fixing anomalies at forums like this and via the ITIL 3.1 rework (which I do believe needs a better CSI cycle time!).
So, here's my four-pence worth -
1. Lifecycles - Works mostly, more so if you realise you start with Strategy and end with CSI, but both are continual at an organisational level, whereas the others are services centric. The wheel diagram works for me, as does the 'stripey' diagram for showing processes across lifecycles.
2. Process vs Function - Organisations regularly form teams (functions) around tricky processes, so it can be confused. Events and Access usually need many functions though (L1, L2 & L3). Service Desk debate dead a while, it's definitely a function serving IM, KM etc.
3. Purpose/Goals/Objectives - Did my head in at the time, so thanks Geoff for straightening me up there. I love simple examples.
4. Transition junk-yard? - New grumble on this posting. Gotta be focus of V4. V3 left this jumbled, with evaluation vs validation/testing (Eh?!), and Planning & Support left unsure of it's place vs Project management disciplines. I don't blame OGC for this, the industry is struggling with it also.
I do agree ITIL (incl OGC & APM) needs to step up it's game even more, but it's more the wider executive (and operational) confusion on 'complimentary' frameworks and how they work together, i.e. COBIT, Prince/PMI, Lean, SFIA, etc..
Good debate, happy to hear similar or counter-views.
- Dave Caldwell
Anonymous
(18/11/2010)
Picking up on one minor - but important - point among the many above. The Purpose/Goals/Objective issue has annoyed the hell out of me since it should have been such a simple thing to get right & consistent, but I have been assured by the authoring team in a public forum at last week's itSMF conference that in the new edition due out next year every "process" has a section headed Purpose and Objectives (no more goals) and that each contains entries that are as the label describes.
Post new comment
Comments