OGC publish a useless Lifecycle Process Model for ITIL V3

ITIL V3 process modelOGC have recently published the long-promised Lifecycle Process Model for ITIL V3. It is pretty much useless in its published state.

The process 'model' is offered as a diagram on the OGC website, devoid of any definitions, commentary or explanation that I can find.

There is no explanation of how to read it, how it came about, what the context is, what compromises were made, what possible confusions to beware of... Nada. Nix. Just a pretty picture in V3 pastel purple.

I'm a graphical person rather than a narrative person. I find diagrams immensely useful, but only with some explanation as to what the author meant. I like the flow of this diagram back and forward across the five books, but I am left more mystified than enlightened as I read it.

The diagram does use hyperlinks, but instead of being to the open free glossary, these links are to the closed, paid-subscription online books.

The diagram is not done to any recognisable process diagramming standard, so how one interprets the shapes and arrows is left entirely up to the reader without explanation. The IT Swami predicts we will soon get into the territory of pundit interpretation.
"When a process input is an outlined arrow it differs from an unoutlined arrow ..."
"What Nostradamus meant by 'from the skies shall come an alarming powerful king' was..."
"When he says 'Blessed are the cheesemakers' it refers to any manufacturers of dairy products..."

There are 25 boxes with the cut-off corner, which often means a process. So are there 25 recognised processes? But some boxes have lots of stuff in them. How is this to be interpreted? i.e. what does it mean when stuff is all parcelled up in one box? Surely "Validation and Testing" and "Knowledge" are not the same process?

What are the weirdly floating texts like "Service Level Package", "Service Design Package" and "Early Life Support"? Are these the output products of some process and if so which one?

The picture gets darker towards the middle then lighter again at the bottom. What does this mean? that Service Transition is the most important book? or just the most opaque? Surely that honour goes to Service Strategy?

Thanks a bunch OGC. This diagram should generate rich pickings for bloggers, conference speakers and consultants alike for a long time to come.

Comments

stupid diagram

Another question about this stupid diagram: WTF are those arrows going between the boxes? outputs?

It looks like they are an activity: "define the market", "negotiate and agree", "design solution", "resolve and restore". How the hell an action can be an output or trainsition between "lifecycle elements" is beyond me when those elements are themselves what ITIL wildly calls "processes" but are more often functions or some other amorphous lump that does stuff.

Every time I look at this supposed description of ITIL it annoys me more, especially when the model we were promised lurks behind the paid doors of TSO.

Why doesnt someone present to these diagrams at a conference?

Skep

What amazes me is that ITIL V3 has more than 375 diagrams, plus those in the Intro to Service Lifecycle which includes this Xmas cracker, I see everyone 'implementing' (sorry adopting) ITIL, and hear folks asking (stupid) questions on Linkedin every week about whether there is a tool out there that helps an ITIL 'process' happen - and there is little or no call for clarity. No folks guess and read what they need to read into a diagram.

Where is the best practice guidance for interpreting ITIL diagrams?

When will one of the authors, or designer of any one of these diagrams, actually submit a presentation at any conference to walk us all through a what they developed? And why, why, why do they insist on asking questions in exams (Expert and Intermediate) about a diagram that is minus an explanation in the book.

Any takers?

Where's Ernest Hemingway When You Need Him?

Yes. Less diagrams. Maybe 95% less.

And the narrative needs work too. Short, sharp declarative sentences. That's it.

ITIL Questionnaire

Hi . I think you mentioned a questionnaire in your review but I could not find it in any of the 4 OGC Books ( namely Service Design , Service Operations , Service Strategy and Service Operations ) . Am I missing something here ? . Kindly let me know where I can find the questionnaire. Thanks and regards . Anjan

sorry

Sorry Anjan not sure what review or survey you are referring to?

Skep is back

Allright! The Skep is back! Too much niceness lately - about time you went for the jugular again. More of it I say.

Optimist...

I do like your criticism. To make it a bit more constructive I would personally add that this PICTURE of ITILv3 is the first contribution to understanding the bigger picture of the 5 books. Yes, we can disagree with some of the choices made. I believe on the other hand that if we don't try to read it as if it where a flowchart, but simply a visual represention of some main elements in the books, it is not that bad. Let's see it as an attempt to provide some light in the dark.

Greetings,

the IT-Optimist

Maarten Bordewijk
Getronics PinkRoccade

two worlds collide...

Quite an old post perhaps but still nice to react on it.

This is a typical case of a technical person trying to understand managmeent literature. Management litereture is not designed to be exact. Its main purpose is to get a nice feeling while reading it without thinking too hard about the content. The sentences should flow and the diagrams should be visually pleasing.

In no way should the content be exact or unambiguous as that would make it easy to criticize. In a way, such literature is not 'falsifiable' or in the sense of Popper not scientific. Perhaps we should simply accept this, then as technical persons use a lot of terms from ITIL in the way that we see fit ourselves. The managers won't know the difference anyway.

Good old times

Erik
Thanks for pointing to this great old discussion.

I suppose you don't have a clue who were discussing here. Technical people trying to understand management literature... LOL

Aale

a contemptuous approach

Perhaps but I wish they would shed some light on the light. This is a half-assed attempt to tick off a task long overdue. ITIL V3 takes a contemptuous approach to the concept of process and it shows (which also shows just how disconnected they are from the desires of the user base). Tossing us a picture without explanation is a poor show however positively you try to look at it.

I know where its father is....

Skep

This picture is the son of figure 10.22 "Integrated lifecycle element flow" found on page 169 of "The Official Introduction to the ITIL Service lifecycle" publication. ITIL Service Lifecycle Management Model. Some minor changes - no supporting text, less shade, more boxy boxes....

If I could upload an image I would - will send it via email....

As for us all guessing how to interpret - I agree - DON'T - we must force them to explain their diagramming standards used THROUGHOUT V3..... perhaps this will be in a companion book or part of a future 'how to read ITIL' Foundation exam...?

in ITIL V3, element = stage = process

Dang, you're right! I never looked closely at those diagrams in the back of the Introduction book for that very reason - that they don't communicate much without commentary.

In the book the diagram 10.22 is called "Integrated lifecycle elements flow". Page 167 says "10.22 shows the high-level integrated flow between lifecycle stages". (N.B. this is the entire explanatory text).

So in ITIL V3, element = stage = process. Is anything NOT a process?

It is a bit rich to relabel it as a "process model".

ITIL process model is impossible

Last year I talked to the guy who was supposed to deliver "the ITIL process model" and told him that was an impossible task: he would never succeed in putting "ITIL" in a process model, when he started from the believe that ITIL V3 contained 27 (or whatever figure) processes. He didn't agree, but until now I haven't been proven wrong ;-)
The illustration at the OGC website has little to do with a process model, at least if you use the ITIL definition of 'process'.
ITIL contains - or claims to contain - processes, procedures, functions, activities and other material.

Using widely accepted definitions, we can easily conclude that most of ITIL's content is about *procedures* and about *activities* that *can* be performed by *functions*. Useful, but not applicable as such - at least not without a vision and an architecture of yourself. This makes ITIL a useful reference model, but definitely not an implementation model - let alone a process model.

It isn't really hard to put the ITIL content in place, using the People/Process/Technology paradigm, the definitions, an ITIL 9000 management system, and some very simple and widely accepted paradigms. But that seems to be left to the market. ITSM consultancy agencies will find themselves a rich playground for several years to come....

Definition of "process"

Jan,

There have been a few discussions of process definition on this blog. I think we both harbor concerns about ITIL's function/process confusion, but I am not sure we have the same definition of process. What material do you look to as authoritative? I'm most familiar with Rummler/Brache & their disciples.

The question of granularity is perhaps central. One could say there is only one process, the service lifecycle. I consider that a value chain (another controversial topic here). My processes would be one level below that overall lifecycle, event-driven, visible to the end customer and generally seen as resulting in value-added end states.

Charles T. Betz
http://www.erp4it.com

ITOCO for process management

Charly - I use the ITOCO model for process management. It is completely similar to other generally accepted definitions of 'process', but it emphasizes the 'control' element more than the others - and that's exactly where things normally go wrong. Read paragraph 8.2 of the ITIL Foundations book - it explains the concept, the model, and the terminology of process management. I'll cut a small text fragment that explains the basics:

=================================
Processes
When arranging activities into processes, we do not use the existing allocation of tasks, nor the
existing departmental divisions. This is a conscious choice. By opting for a process structure, it
often becomes evident that certain activities in the organization are uncoordinated, duplicated,
neglected or unnecessary.
A process is a structured set of activities designed to accomplish a defi ned objective.
Instead, we look at the objective of the process and the relationships with other processes.
A process is a series of activities carried out to convert input into an output, and ultimately
into an outcome. The input is concerned with the resources being used in the process. The
(reported) output describes the immediate results of the process, while the outcome indicates
the long-term results of the process (in terms of meaningful effect). Through control activities,
we can associate the input and output of each of the processes with policies and standards to
provide information about the results to be obtained by the process. Control regulates the input
and the throughput in case the throughput or output parameters are not compliant with these
standards and policies. This produces chains of processes that show the input that goes into the
organization and what the result, and it also monitors points in the chains in order to check the
quality of the products and services provided by the organization.
=================================

This ITIL Foundations book doesn't actually mention the ITOCO model, since ITOCO was not an official element in the ITIL books. And the Foundations book had to be completely in line with the core ITIL books, to be able to be used as an extensive and official guide on the 'formal ITIL'. The ITOCO model itself is explained in the other ITSMF publication on ITSM: the "Introduction to ITSM - based on ITIL V3". Read paragraph 2.1.5 Management of Process and look at Figure 2.7: Process diagram, based on the ITOCO model.

On the Rummler-Brache swim-lanes: I don't use those, since:
1- I believe that processes should be kept clean, i.e. limited to activities, without any reference to organization
2- it often is not simple to relate activities to one-and-just-one role

And since I really believe in simple solutions, I work from a simpler view, based on strict separation of the Process/People/Technology layers, using the ISO 9000 quality system approach (Process/Procedure/Instruction). For our practice, we've built a very simple structure of these elements, and it proves to work time-upon-time, for the smallest and the largest organizations. It uses ITIL and other models as reference models, as we discussed above, but it allows us to apply more and better knowledge than we could find in ITIL alone.
Anyone can come up with systematic approaches like this, just using the best suitable knowledge available to a specific situation, but I prefer to keep it very simple. IT people seem to make the same mistake over and over again: they seem to think that the complexity that has been the main characteristic of IT systems for decades MUST be reflected in the complexity of the management of IT organizations. And they are wrong.

No Owners?

If you keep people and process seperate, how do you then assign any accountability for getting those processes/procedures performed? I believe that you have to have some kind of RACI matrix (or whatever other type of matrix you like) in the processes so that there is a level of responsibility and accountability. So, we have a process....it's "not my job"...it's just a document. Without involving the people, it's shelfware IMO

my 2cents

Liz

9000 relates People and Process

Liz - of course you need owners. And of course you'll need a RACI model. The thing is, that I believe that you FIRST need a separately developed dimension of Processes, to be able to relate them in the optimal way to the People, and then to the Technology. That way you will have made sure what your processes are - independent from the organizational aspect. Once you've got those, you'll be able to apply them all over the IT industry, since the best processes do not vary with the organization - they are really a commodity.

We've done exactly that with our own ISM framework and it is being accepted by more and more organizations in the Netherlands - who now have the very same process model as their neighbours - but most likely with very different procedures and instructions (since they are all unique - aren't they ;-)?

Btw - it is of no interest to 99% of the people what these processes are.... If you follow the ISO 9000 principles you'll see that the first layer where people are involved is the Procedure layer! So we only communicate to people in terms of procedures and instructions. But that's after we've related the activities of the process model to the people in the orgnanization.

If you follow this approach, life gets very very simple. And consultants can concentrate on bringing added value instead of inventing wheels at the cost of their customer.

ITIL is a useful reference model but not an implementation model

I think this is a very powerful concept that I heard when talking to Jan before - where does it originate Jan? "ITIL [is] a useful reference model, but ...not an implementation model" More needs to be made of this, to make clear to people that this is what "framework" means. It is the hidden message of 'adopt and adapt'. I'll blog on this soon...

"reference model" original

Skep - the quote on ITIL being a reference model rather than an "implementable" framework is an original by my 'partner in crime', Wim Hoving. Unlike Charly's rather academic analysis, we use the term 'reference model' simply to point to 'a reference'. And I'm quite sure Wim never read "Art Caston's Proact methodology for enterprise architecture".
ITIL - in our eyes - clearly is a reference, to be used when doing practical things. It contains lots of good advise on how things can be done in certain sectors of the IT management market. I always say that that is not because ITIL invented it, but simply because these wise approaches existed and they were then (after the fact) collected and documented by ITIL, as they had been documented in many other ways before (articles, white papers, presentations, books, consultancy practices) over a long period of time. The fact that ITIL has been branded very strongly and was then adopted heavily by the vendor market, explains to a large extent why so many people now know it. Which doesn't mean that it is "the only" or "the best" source on ITSM - on the contrary. Just compare existing ITIL documentation with the eleven editions of the Dutch annual book on ITSM and you will know - but then again, you must be Dutch to be able to profit from that.
The same goes for the new practical series of ITSMF publications in the "ITSM Global Best Practice" volumes. They will be a rapidly growing source of real-life knowledge, not limited by formal restrictions of 'holy' framework approaches, but bringing us the best we can find in the market. It will allow you to apply the experience and wisdom of others, still using ITIL as a reference model.

Framework, not a model

Models to my mind require some formality, which ITIL lacks.

While I don't know if enterprise architecture can claim credit for the concept of a "reference model," I was first introduced to it through working with Art Caston's Proact methodology for enterprise architecture.

Most modeling is some combination of as-is and to-be. But in the words of the caterpillar, "if you don't know where you are going, any road will do." A reference model is a idealized, green-field, exhaustive target state, at what the OMG would call the "computation independent level." It can be used to assess the gaps in the current state, so that a roadmap can be formulated. Reference models I am familiar with include IBM's IFW for financial services, RUP for software development, and PRM-IT for IT management generally; and the TMF's eTOM for telecommunications. Googling "enterprise architecture reference models" also gave me a link to the US Federal Government's FEA. (Sorry but I don't have time to provide pointers.)

One interesting question is, "what is the difference between a framework and a reference model?" While I don't think there is any generally accepted industry answer, I would propose that a reference model usually would be based upon some formal or at least widely used modeling syntax (metamodel). Frameworks would not have this requirement. Another way to look at it might be to say, "while all reference models are frameworks, not all frameworks have the rigor to be considered a reference model."

In my view, ITIL may be a framework, but it is far from a reference model. Beyond the function/process issues, there is also the lack of a conceptual data model or ontology beyond the simple glossary, something that I think all the other examples I've cited here have. (RUP is the only one I'm unsure of.)

Some recent discussion, not exhaustive, on reference models/architecture at http://groups.google.com/group/the-enterprise-architecture-network/.

Charles T. Betz
http://www.erp4it.com

Assessments and Roadmaps

"It can be used to assess the gaps in the current state, so that a roadmap can be formulated"

Has anyone else noticed that in practice most ITIL assessments do little more than tell you your current state of maturity and lead to a roadmap that says little more than "start doing all the things you aren't doing"

Has anyone come across an approach to ITIL assessments that actually helps to develop a context specific roadmap for an organisation, taking into account the organisation’s size, ambition, culture, leadership, experience etc?

When I was on the customer side of the fence every consultancy I used just came up with a boilerplate set of recommendations. Something that struck me is that none of them ever told me to NOT do something. For instance no one ever said “Don’t implement problem management yet because you aren’t mature enough to do it yet”

"Consultants do say don't"

Hi James,

I agree with your point in a 'majority' of cases - but not in all cases.
Let me make it clear that I am not questioning your view point, while agreeing to it partially, I am digging a bit deeper into that context.

The issue mentioned by you happens, according to me, for two reasons:

- Many professionals see 'being a consultant' as a lucrid career path, without a real backing of Knowledge,skill/expertise and experience.
- Many consultant see consulting engagements (for ex: assessments) as another 'deliverable based' job. Fixed time lines, fixed formats, fixed scope of deliverables. There is no accountability (at least internally) felt and experienced by those professionals for the outcomes.

There are at least three-four cases I was involved, as a consultant as well as at the other side of the fence where the recommendation was NOT do some thing (or at least NOT YET!).

I have advised two clients not to attempt Configuration management and ITSCM as yet ( and similarly some more the same way on CMDB)
There is at least one case where I recommended customers to NOT to go for ISO20000 certification at that point (It is another matter they would have easily got the stamp of certification if they found the "right" auditor - But I sensed the management was interested in improvement of practices).
There are some cases where we advised our clients to implement only performance monitoring based (kind of reactive) availability management and capacity management and NOT attempt any other practices 'described by ITIL'.
There are a couple of consultants from Europe with whom I was associated, who has advised the organization which I was part of - NOT to implement full fledged practices in some areas of ITIL, again not as yet.

So the point is, the issue happens not with the 'real consultants' - who assumes accountability of the customer outcomes (at least at an advisory capacity).
The issues are created when people see consultancy as a 'glamourous' or 'easy' profession where they show their knowledge and dont need to take accountability.

Unfortunately, we are living in a world where Consultancy is shifting into a 'Template driven job'! You can see tool kits and things like "ITIL in a box" are luring clients for easy results. Efficiency of consultants is many time given priority above the effectiveness ("Your competitor can do the same job in 2 days, as they have all templates which he will send us! why do you need 1 week? - This is one real question asked by a real customer to me!. Efficiency matters, but not at the cost of effectiveness.

Just imagine medical Doctors (who are also called 'Consultants')move into a template driven approach.(Some thing like: "I can give you medicine for any disease in one hour!!!")

I hope majority of them has not moved that way, a thought otherwise start giving me shivers....

Vinod
http://www.itserviceview.info

Consultancy Maturity Model

I'm not sure where you are disagreeing with me?

Your post has made me think about the fact the ITIL consultancy market has been around for a long time now, and has evolved into different sectors and can also be argued to be going in different directions in different geographies.

The types of consultancy I had in mind in terms of "unintelligent" assessments are actually a mixture of the established firms who specialise in ITIL who have commoditised their services, the big boys who don't fully understand ITIL (in my experience they actually look down on it zand also are most likely to view it, as you describe it, as a 'deliverable based' job - that's what drove me from the last big consultancy I worked for) and those with an interest in selling a specific solution.

There are a lot of other kinds of consultancy out there. Perhaps they all have their place, being suited to certain kinds of client. I always think clients get the consultancy they deserve ;-)

In agreement - dwelling further.

As I mentioned in my post, I am not disagreeing with your post - I was giving instances where consultants in fact tell customer NOT to do things as well.
Also - I was dwelling on possible reasons - whcih I believe is in agreement with your thoughts as mentioned here.

And yes, you mentioned a third valid reason for such consultancy (which I should add to my list of possible reasons): an interest in selling a specific solution.

Clients get the consultancy they deserve - Hmmm I like the thought, but some time I feel very sorry for clients who are taken for a ride by biggies and those others who commoditise the services.

I know a consultant from a well-known consulting firm (Dont want to name them - though I get a private pleasure, as they are my competitor ;-)) did a gap analysis for a client's ITSM against ISO 20k, give a list of the things they should have in place (Gaps!! - a perfect example case you highlighted) and then send a set of documents to them (Process documents - Ready made!!), which would make them "compliant and ready for certification"!

Vinod
http://www.itserviceview.info

Clients doing it for themselves

I also had a client who bought a set of "ISO certified templates" for SLAs etc from a company that operates in the Antipodes, which might just have been acceptable as a starting point as they stood, but the client then took out all the content but still kept referring to them as the ISO templates and clung to them as if they were a lifejacket.

It never crossed theior mind to quwestion whether the SLAs were a representation of the service their customers were crying out for.

Consultants who say "don't"

Music to my ears, James. Even as a consultant I've become frustrated with the template-driven approach to assessments - I've reviewed and rewritten too many assessment reports where the recommendations are a series of bullets from the questionnaire - listing all the ITIL things the client is not doing.

I'm pleased to say the company I work for has moved away from that kind of assessment and does consider size, leadership, specific business pain-points and so on in the analysis and the recommendations - and we do tell clients to forget certain pet areas for a while. But we don't have an approach as such yet - it relies on exposure to the client environment and judgement by the consultant. A structured approach would have to investigate and make some conclusions on how each ITSM process / sub-process and each service contributes business value (money or risk). In essence, you'd have to do some Service Strategy / SLM for the client. And investigate the skills and capability/adaptability of the staff - talent management, perhaps, to assess the viability of process and control improvements.

Maybe a more formalised approach to assessing process culture (independently of the actual processes used or not), and principles like data management that are often raised on blogs but not so much by ITIL books or vendors, is a pre-requisite to delivering the kind of assessment you're hoping for.

Syndicate content