List of ITIL V3 roles

Since ITIL does not tabulate all the role definitions anywhere, not even the glossary (except possibly on the ridiculously expensive ITIL Live - who'd know?), once again the IT Skeptic provides a public service in the same way as our cross-reference list of ITIL V3 processes. Here is

the IT Skeptic's Unofficial Unauthorised List of ITIL V3 Roles

[Updated 2009/4/16: added SFIA cross reference and some questions]
[Updated 2009/10/7: added five more roles - thanks JRD! "By far the best list I've found!"]
[Updated 2009/10/23: added comments about the Glossary]
[Updated 2010/7/26: added more roles from SD]
[Updated 2011/08/11: removed SFIA, see comments]

***** FOR ITIL V3 2011 ("3.1") list of roles, see comment below from Matthew Burrows

In the ITIL ref column: SS=Service Strategy (book), SD=Service Design, ST=Service Transition, SO=Service Operation, CSI=Crime Scene Investigation
the numbers refer to sections in the book.


Role ITIL ref
Access Manager SO 6.6.9
Account Manager SS 4.1.3
Applications Analyst/architect SO
Applications Manager/team-leader SO
Availability Manager SD 6.4.7
Build and test environment staff ST
Business Owner SD Appendix G
Business Relationship Manager SS 4.1.3
Capacity Manager SD 6.4.9
Change Advisory Board ST
Change Authority ST
Change Manager ST
CMS/tools Administrator ST
Configuration Analyst ST
Configuration Administrator/Librarian ST
Configuration Control Board ST
Configuration Manager ST
Continuity Manager SD 6.4.8
CSI Manager CSI 6.1.3
CSI Reporting Analyst CSI 6.1.7
Deployment staff ST
Early Life Support staff ST
Emergency Change Advisory Board ST
First line support SO
Incident Manager SO
IT Designer/Architect SD 6.4.4
IT Directorate CSI?, Glossary
IT Facilities Manager SO E9
IT Operations Analyst SO
IT Operations Manager SO
IT Operator SO
IT Planner SD 6.4.3
IT Steering Group Glossary
Knowledge Management process owner ST
Major Incident Team SO
Performance and Risk Evaluation Manager ST
Problem Management team SO
Problem Manager SO
Product Manager SS B2
Release and Deployment Manager ST
Release Packaging and Build Manager ST
Second line support SO
Security Manager SD 6.4.10
Service Asset Manager ST
Service Catalogue Manager SD 6.4.5
Service Design Manager SD 6.4.2
Service Desk Analyst SO
Service Desk Manager SO
Service Desk Supervisor SO
Service Level Manager SD 6.4.6
Service Manager CSI 6.1.2
Service Owner ST 6.1.2, CSI 6.1.4
Service Test Manager ST
Service Transition Manager ST
Service Transition planning and support ST
Shift Leader SO
Super users SO
Supplier Manager SD 6.4.11
Technical Analyst/Architect SO
Technical Manager/team-leader SO
Technical Operator SO
Test Manager ST 4.5.5
Test Support team ST
Third line support SO

....but wait! I only count about 15 or 16 process managers in there and zero process owners.

ITIL tells us that every process has an owner so add another twenty-something owners (depending on who is counting the ITIL processes).

Does every process have a Manager role? ("There may be several Process Managers for one Process... The Process Manager Role is often assigned to the person who carries out the Process Owner Role, but the two Roles may be separate in larger Organisations.") If so there are another ten-or-so manager roles to be added to this list too.

That would bring us to about 90 roles in ITIL V3.

Keep in mind that these are roles not headcount positions. Sometimes they are more just actors (e.g. SS) than formalised roles (e.g. SD) - ITIL does not distinguish. I left out some that were clearly an actor, e.g. "Customer" or "Application Service Provider"


  1. Is the SS Product Manager different from the CSI Service Manager?
  2. Are the ST and CSI "Service Owner" roles the same thing? The books don't cross-reference each other.
  3. Are the ST and CSI "Service Owner" roles the same thing as SS Product Manager?
  4. Why does SD Appendix G (Example Service Catalogue) use the term Service Manager rather than Service Owner? [More on Service Owner]
  5. The glossary definition of "Service Manager" bears no resemblance to CSI Service Manager. SS's Product Manager isn't in the glossary at all. In fact most roles aren't.
  6. Maybe I missed it, but ITIL V3 doesn't appear to have one person owning and accountable for the customer experience. ITIL Service Delivery Manager

Corrections or additions or discussion: please add a comment

If you found this post useful, and you are a Facebook user, please Like this blog :


ITIL2011 roles

I've found 103 roles mentioned in ITIL 2011. It does note that these are not exhaustive. It's also worth mentioning that these are roles and not job titles.

I haven't yet done the SFIA mapping - partly because SFIA V5 is in the final stages of development and I think it would be better to map it to that rather than V4G.

Here's the list, with a reference to which book and the page number that the information starts on:
1. Generic service owner role (SS329, SD257, ST224, SO192, CSI130)
2. Generic process owner role (SS331, SD258, ST226, SO193, CSI131)
3. Generic process manager role (SS331, SD258, ST226, SO193, CSI132)
4. Generic process practitioner role (SS331, SD259, ST226, SO194, CSI132)
5. Strategy management for IT service process owner (SS332)
6. Strategy management for IT service process manager (SS332)
7. Business strategy manager (SS332)
8. IT steering group (SS333)
9. IT director or service management director (SS333)
a. Also called "Director of service management" (SS337)
10. Service portfolio management process owner (SS333)
11. Service portfolio management process manager (SS333)
12. Business relationship manager (SS334)
13. Business relationship management process owner (SS334)
14. Business relationship management process manager (SS334)
15. Financial management for IT services process owner (SS335)
16. Financial management for IT services process manager (SS335)
17. Budget holders (SS335)
18. Demand management process owner (SS335)
19. Demand management process manager (SS335)
20. Chief sourcing officer (SS336)
21. Contract manager (SS337)
22. Business representatives (SS337)
23. Design coordination process owner (SD259)
24. Design coordination process manager (SD259)
25. Service catalogue management process owner (SD260)
26. Service catalogue management process manager (SD260)
27. Service level management process owner (SD260)
28. Service level management process manager (SD260)
29. Availability management process owner (SD262)
30. Availability management process manager (SD262)
31. Capacity management process owner (SD263)
32. Capacity management process manager (SD263)
33. IT service continuity management process owner (SD264)
34. IT service continuity management process manager (SD264)
35. Information security management process owner (SD265)
36. Information security management process manager (SD265)
37. Supplier management process owner (SD266)
38. Supplier management process manager (SD266)
39. IT planner (SD267)
40. IT designer/architect (SD268)
41. Service transition manager (ST227)
42. Transition planning and support process owner (ST227)
43. Transition planning and support process manager (ST227)
44. Transition planning and support practitioner (ST227)
45. Change management process owner (ST227)
46. Change management process manager (ST228)
47. Change initiator (ST228)
48. Change practitioner (ST228)
49. Change authority (ST228)
50. CAB member (ST228)
51. CAB chair (ST229)
52. SACM process owner (ST229)
53. SACM process manager (ST229)
54. Configuration analyst (ST229)
55. Configuration librarian (ST230)
56. Release and deployment management process owner (ST230)
57. Release and deployment management process manager (ST230)
58. Release packaging and build practitioner (ST230)
59. Deployment practitioner (ST231)
60. Early life support practitioner (ST231)
61. Build and test environment manager (ST231)
62. Service validation and testing process owner (ST232)
63. Service validation and testing process manager (ST232)
64. Service validation and testing practitioner (ST232)
65. Change evaluation process owner (ST232)
66. Change evaluation process manager (ST233)
67. Change evaluation process practitioner (ST233)
68. Knowledge management process owner (ST233)
69. Knowledge management process manager (ST233)
70. Knowledge management process practitioner (ST233)
71. Knowledge creator (ST234)
72. Incident management process owner (SO194)
73. Incident management process manager (SO194)
74. First-line analyst (SO194)
75. Second-line analyst (SO195)
76. Third-line analyst (SO195)
77. Problem management process owner (SO195)
78. Problem management process manager (SO195)
79. Problem analyst (SO196)
80. Request fulfilment process owner (SO196)
81. Request fulfilment process manager (SO196)
82. Request fulfilment analyst (SO197)
83. Event management process owner (SO197)
84. Event management process manager (SO197)
85. Access management process owner (SO198)
86. Access management process manager (SO199)
87. Service desk manager (SO200)
88. Service desk supervisor (SO200)
89. Service desk analyst (SO200)
90. Super user (SO200)
91. Technical manager/team leader (SO201)
92. Technical analyst/architect (SO201)
93. Technical operator (SO201)
94. IT operations manager (SO202)
95. Shift leader (SO202)
96. IT operations analyst (SO202)
97. IT operator (SO202)
98. Applications manager/team leader (SO202)
99. Applications analyst/architect (SO203)
100. CSI manager (CSI132)
101. Seven-step improvement process owner (CSI133)
102. Seven-step improvement process manager (CSI133)
103. Reporting analyst (CSI133)

The Principal Agent Problem

Economists have been studying the principal agent problem for years. With the platitudinous Information Technology Indoctrination Library, the principal agent problem becomes a contest of wills between agents, who resist control through the adoption of profoundly boring, amoeba-like bureaucratic methodologies; and principals, who struggle to stay awake long enough to exercise control over the agents they hired.

Under the pretext that IT required persons of superior political ability and business acumen to manage a technically knowledgable workforce, the Change Managers evicted the geeks from their sheltered workbenches--and moved in themselves. We can see these agents of change creating more problems for principals by inventing their own specious language and by creating interminable lists of "process owners" within it. The Change Managers won, and the vanquished must adopt the language of the victors. The dreary, uninspired, droning monotone of ITIL ensures talented workers will select themselves out of the workforce. The remaining mediocrities will need to be managed. It is a brilliant, witty strategy.

The principals who hired the Change Managers must wonder whether they should count themselves among the vanquished; whether their non-technical agents of change are pursuing their own agenda; and whether the Change Managers, who purport to bring to IT a political sophistication, business acumen and service orientation inconceivable to the hapless geeks they displaced, are at bottom managerial squeegee men.

From the perspective of the principal agent problem, the putative superiority of the new trans-technical business and political weltanschauung of the IT managers is unsustainable. In fact it is a transparently and unapologetically self-serving effort among managers to bore the principals who hired them beyond the point of cognitive incapacity. As a strategy among agents, it provides security and protection from principals. There is no empirical evidence that the "theory of the theory" disease, once contracted, leads to greater productivity in IT. Instead, it leads IT management to run roughshod over computer science and research computing, which ought to be kept separate from IT.

in English?

Beyond an intellectual wank, I'm not sure that you said anything of substance at all except "I don't like ITIL". For those of us with less awesome minds, perhaps you would care to translate.

Rob, stop being a Sarah Palin!!

Hey Rob,

Stop using a Sarah Palin tactic where you summarily reject someone's idea by branding them an "intellectual". The freaking problem with IT (and the reason all the b.s. in ITIL won't stop people from getting certified in it) is a lack of deep thinking and analysis. Requires sharp minds and a lot of hard work, and time time to think. Yeah, yeah ... I know you are all way too busy because your freaking pager went off about another big incident and you need to put on your "practitioner" underwear over your sorry ITIL pants and fly off to save the day.

It does not take a lot of brainpower to understand why the Principal-Agent problem is as widely found is bacteria in a kitchen sponge. Let's excuse our friend for using some really dense language, and focus on the substance of his argument. Let's not be lazy. The agency problem is why most services fail, both for customers and service provider. And good design mitigates (can never eliminate) its detrimental effects. The problem is more several in business services such as IT is that there are several degrees of separation between customer outcomes and user experience. And the agency problem appears in every degree. Which is why sometimes the security team has no freaking clue how or why they have murdered convenience of access for the sake of control.

The principal-agent problem appears, again like bacteria in kitchen sponges, in more mundane situations. Oh! Surprised the airline agent was rude to you even though you are a paying customer? Well, so is she because she does see you slapping down dollar bills. In fact she hasn't even seen the service level agreement you signed with the airline. All she sees is a boarding pass in your hand. So why don't you get back in line with everybody else who has got one? That's the agency problem.

Let's be humble here Rob. People, not unlike you, have dedicated their lives studying such problems. They have been subject to extreme scrutiny, before being published, cited, and eventually awarded prizes. Like, umm the Nobel Prize. So please quit the Tea Party and join us. We may be brutally intellectual, but we sure know how to give a hug.


wounded i am

Well I've been insulted a few times on this blog but never so cruelly as to be compared to Palin.

I'm not anti-intellectual. I quite fancy myself as one, and hase always welcomed and relished intellectual debate on this blog. I really couldn't understand a word the guy was saying.

I for one believe ITSM is a vehicle for restoring line of sight to the customer not damaging it, for building a service focus not losing it. Arguments such as yours exhibit a profound lack of understanding for what ITIL is there for (or a willingness to forget). Sure bureaucrats and geeks seize on it as a means for passive aggression but that's bad management not a bad theory. As I have argued before, don't shoot the message.

brutality explained

Brutes are people too, so I know how it feels. But we're actually kindred spirits Rob so you will forgive me. Yes, that was really dense prose, as I called it out myself. But his intention was genuine, if his communication skills were lacking. If place all the burden on the writer, and as readers are absolutely f#$king lazy to make an effort to understand, we'll promote a culture of bland, rehashed, mashed, and deep fried and honey-dipped sound bites that have no nutritional value at all and the only reason that kind of stuff can be palatable to you is because you were raised on it.

When power-wielding bloggers such as yourself shoot down people so quickly, others won't take the risk. Ideas and knowledge are about risk. Let's take the risk of reading densely worded material and not getting it immediately like the sugar rush from a 7-Eleven Big Gulp. Have you really stepped back and placed a critical eye on sweet sugary stuff that gets tweeted and retweeted on a daily basis? I could write an app to measure the glycemic index of some of the Twitter streams.

And buddy, come on, spare me the "a profound lack of understanding for what ITIL is there for ..." will ya? I've just wrapped up on one of world's largest and most trying implementation of service management using ITIL for a bank run by a bunch of ex-GE mafia who'd throw your ass out on the pavement just like that, if every word you said or step you took didn't move the needle for them in terms of customer outcomes. Oh I have the most profound understanding you can imagine of what ITIL is there for (no pun), where it come from, how it started, and how it became what it has become. I've seen what I wish I could 'un-see'. Fascinatingly enough, if you pick up the first ITIL books written (before they added version numbers) you will shed a tear for the ITIL community and exclaim "Oh the humanity of it all".

Don't shoot the message

OK then a willingness to forget what ITIL is for.

It seems to me as far as i can discern through the academic posturing that the "principal-agent" problem is about loss of line of sight to the user, or loss of empathy for the user. And this is being blamed on ITIL, or ITIL is being blamed for failing to prevent it. That's along the same lines as blaming Obama for failing to prevent a recession. The intent of ITIL is to address the problem but there is only so much ITIL can do, no matter how skillfully wielded.

I think the "failures" of ITIL stem from at least three issues:
1) shitty management
2) an expectation that people and culture will change as quickly as process and technology. They won't. It takes years.
3) fierce guerrilla resistance from the IT cowboys who want to remain free on the range, who have no perception of business risk, who think they are above any form of controls, who regard review as a slight on their genius

None of those are an inherent flaw in the ITIL theory. Don't shoot the message.

P.S. Regular followers of this blog know I hardly ever roast a commenter. i think that one deserved it. i welcome feedback from regulars as to whether I overstepped.

P.P.S. One of these days I will have time to properly read ITIL V1 and see if the original texts were really so sacred. All this talk smacks of "the good old days" to me.

Yes, you did

Rob, sorry but I think the comment was interesting and you overreacted.

Also it is too easy to blame "shitty management" and "IT cowboys" for failure. I don't think that is true. World is full of good practices that even less than ideal management & staff can handle. On the other hand, good people will fail if they are using a faulty model.

I just received my 2011 pdf-editions. There I read that "ITIL offers robust, mature and time-tested practices". A few pages later it explains that "Implementing an SKMS enables effective decision support". Googling SKMS brings up as the first hit "Warning don't try ITIL V3's SKMS at work | The IT Skeptic". The third hit is "Skyline Home Page" I googled also SKMS tool, and found only SMS tools. Truly mature and time-tested practice.

ITIL is an inside-out approach to IT service management. It has some value; if your operation is a mess, you have to concentrate on the inside. A lot of IT operations are still struggling with some very basic things. When you get your engine running, you need better models.


Right said Aale

The SKMS is a good example of how badly ITIL has degenerated. I've led a major project within the US military and they have some of the best implementation of knowledge management I can think of. I'm not the only one, but there are many of us who have seen first hand what organizational learning and knowledge transfer is all about. There are actual methods, algorithms, rules, and standards. So it is dishonest of TSO, itSMF International and whoever the hell these days is in charge, to sell books, exams, and a healthy professional life, with the claim of industry best practice. That's just simply dishonest. There is no other way to look at it.

Also, much of ITIL, and I'd say about 90% (I don't really believe ITIL Service Strategy is yet part of ITIL in the popular imagination) has nothing to do with service management. All most all of it is about operations management for an organizational function called "IT" with which the term "service" is loosely associated. How can you call something "service management" when there is really no meaningful and correct guidance on managing a services enterprise? Is the IT community so insulated and isolated from the rest of the world's disciplines like that bushman in Gods Must Be Crazy that even a Coca-Cola bottled tossed from airplane seems captivating and interesting.

And Rob, you can't be like Goldman Sachs and short ITIL.

robust debate

I do like robust debate especially when it is comprehensible (I've re-read that original comment a third time and i still can't decode it. I'll get Aale to translate it next time I see him).

Once I get past your ad hominem attacks on my style and my supposed responsibilities, then the criticisms you make of ITIL are exactly the same as those I make on this blog: SKMS dreamware, inside-out perspective, "best practice" as a stupid statement...

Unlike you I haven't spent so long analysing ITSM and accumulating knowledge that I have lost all perspective of the real world. Down here, outside the Fortune 1000 and the world's second largest military bureaucracy, the basics of ITIL are indeed a revelation to many, and an excellent first step for them. Well, second step: I start with COBIT unless they insist otherwise because they read about ITIL in CIO magazine. We agree ITIL is flawed. I don't agree it is fatally flawed. I also haven't been pulling a bong enough to believe that ITIL is the product of some huge global conspiracy to pervert ITSM. Castle ITIL is riddled with all the normal human failings: avarice, politics and folly. But most of the people I know are acting with the best intentions to advance something useful.

Other than a few specifics, you've given us nothing but drama-queen hyperbole about anguish and horror. How about some concrete arguments why ITIL is so flawed as to be an abomination from your lofty perspective? And don't be slagging off the three points I made as trite. They are fundamental mistakes that I see often, and only the first one is talked about much. I believe the second and third points - change at a human pace and the backlash of the IT cowboys - are not widely discussed or understood. Not widely enough, anyway. Not down here in the real world.

P.S. time you came out Bro0t. there can't be too many argumentative male service management experts working with the US military who are possibly located in Palo Alto (or work for...) and almost certainly have English as a second language (Dutchman, I'm guessing).

love and respect

Love you Skep! Just feeling a little cold and hungry outside Castle Skeptic :-(

Nah ... I'm just kidding man. Come on man. You're my idol Skep. OK no more, what was that, ... 'mad homo nem' attacks ok? I really didn't mean to. I guess I'm a brute with no manners. But I do have thing or to say about what's flawed about ITIL. And why it is not OK to say "Oh for many organizations who don't know shit, the basics are revelation". That's an awful thing to say man. It's like those companies up here in the West shipping sub-standard products including medicine to Africa saying "Well, at least they have food to eat" and "Look at the cars they used to drive". No Skep. Every organization no matter how big or small, advanced or mature (btw, WTF does organizational maturity really mean anyway?) are entitled to simple solid logic, principles and methods, rules and formulae, on which they can build systems, process and value propositions that are fit for their market. That's what knowledge is all about.

And looks like you really haven't worked with large and complex organizations otherwise you won't be hurling those Tea Party grenades. Quoting Mitt Romney: "Corporations are people". Romney is an ass. He is one of the brightest strategy & finance guys Harvard or the Mormon religion ever produced. I bet he can price a derivative or solve simultaneous equations while brushing his teeth. But now he is pandering to the masses by dumbing himself down enough to not seem elitist but just staying a notch above than Sarah Palin on the IQ scale.

And you're joking about COBIT right?! Wait, am I on the wrong blog or something? Where am I?

There's always room in

There's always room in Castle Skep. In fact I hope it is Villa Skep, with open doors and clear windows. And the management gives as good as it gets :) Don't call me stupid and irresponsible and expect a hearty handshake of welcome or the top seat at the table.

Hyper-destructive criticism of ITIL is in fashion right now. The Gartner Hype Curve is following its remorseless path. But ITIL works, is useful, and has great momentum. I maintain that ITIL may be flawed but not fatally. You (and others) have not identified any flaws that have not previously appears on this blog, and you have not shown how any of those flaws justify abandoning ITIL. Nor have you offered any sort of alternate path.

You are correct that I have not worked in large and complex organisations. My largest client has 12000 users. I like it that way - that's why I live in NZ. Yes I'm anti-elitist, for two reasons (1) most of the IT world works in smaller and simpler organisations - we need to reach out to them (2) ITSM is not rocket science: if there really are profound insights to be had in mega-sites, I'm not seeing them emerge. I find the "you couldn't possibly understand" attitude patronising and egotistical unless backed up with real value content that shows the difference. It isn't.

This blog isn't about demented negativity. I try to offer constructive criticism and to recognise what is good. Only one Castle ITIL member ever turned their back on me and the feeling was mutual. The buffoons are gone now and Castle ITIL does useful work. I'm nor about tearing down Castle ITIL, just opening the doors and reforming the Court.

If you have sound arguments why ITIL (and now COBIT) are rubbish, and some better alternatives, you have yet to offer them. We're waiting.

And BTW I learned not to respect anonymity on the Web. I tolerate it when there are grounds, eg whistleblowers, but I'll always think better of those who stand by their opinions. Anonymity was a mistake for me - I encourage others not to make the same.

Management by Power Point vs Knowledge Management

I missed this debate earlier. It certainly has its amusing side - the notion that the US killing machine is numero uno for Knowledge Management & Transfer (unless the bigger, more bureaucratic Chinese killing machine is better) is just brilliant! Even allies of the USKM say that it is inflexible and unable to make decisions unless they're part of the powerpoint slides du jour ( M$ seems to rule in the USKM, which rather makes a point [ a 'power point ] about their technical savvy - after all, how many wars can you loose before you get the permanent label of 'incompetent' ). Sorry, mixed metaphors seem a specialty of this thread - M$ has just lost the tablet war & the USKM has lost more wars than can be listed in the space here.

So, in comparison, ITIL's KM seems pretty top notch - used by real companies, paid by customer's money ( not money extracted by tax payers - though, to be fair, much of ITIL was written with such money ).

The long list of roles that are possible is impressive and I can understand why somebody might think it was invented as an appendix to Kafka's 'The Castle'. However, ITIL makes, as it always has, that it is there to be adopted by adaptation, not installed as a military rule-book.

Genuine knowledge transfer is two way - the grunts [ USKM jargon ] generate, as well as consume, knowledge. Knowledge Management is concerned with learning from experience, throwing away what doesn't work and engaging directly with the real world - none of which apply to the organisation cited as an exemplar of the practice.

The Principal-Agent Problem

How could the introduction of the principal-agent problem from economics be framed in the vocabulary of IT service management? It might be characterized as a "best practice" to "reuse" ideas that have a rich academic history in the study of the modern firm--but this would not do justice to the notion. The reason for introducing it here--without belaboring the point with page upon page of citations from the literature--was to raise a question: how is it that one of the overarching concerns of service management in IT is never identified or mentioned as such in its literature? It is telling that professionals concerned with this question would come here and exclaim, "Aha! I was aware of this problem but didn't know it had a name." Some of this is to be expected: it might be expensive for ITIL admit that its ideas are derivative. Best to say nothing. Also, the literature on the principal-agent problem doesn't always cast managers in the rosiest light.

ITIL does indeed have its strength: it encourages competent mediocrity. It does this in various ways, one of which is to disparage intelligence through its focus on "culture"--whatever that means. The conceit that IT is a more political subject than it was in the old days may be true, but political involvement of middle management may not be appreciated by the owners who hired them. Must I quote your own words back to you? I am pointing out that this belief--that " IT is now a political endeavor beyond the ken of sheltered geeks like you"--is itself a manifestation of the principal-agent problem. You should be focusing on the work that needs to be done, instead of berating sheltered geeks. As a principal, this is how I expect my agents to perform. I'm not paying my managers to harp on whether their staff believes in their hearts that Jesus is their savior: I want the work to get done. From the perspective of the principal-agent problem, I see ITIL-addled managers arrogating to themselves areas of the firm that should be independent of IT.

My hope is that the injection into the discussion of a few terms from an extensive and hitherto ignored literature may raise the level of discourse above ideological debate. So don't be "defensive" about it: follow your own advice to have an "open mind" and consult with everyone else before making a change, instead of "solving your own problems".

closed and sheltered

I'm not defensive. (There's a self-contradictory sentence if ever there was one). I like to think I'm open minded. I'd also claim this blog has challenged more ITIL sacred cows than most. And one challenge this blog has raised before is that ITIL tries to reinvent everything and claim everything as original work, so we agree there.

Now that you have stopped writing for post-graduate humanities and lowered yourself to the vernacular of the university-educated white collar professional, I can actually understand you, thank-you.

I've pillaged a number of other domains from engineering systems theory to product marketing, so forgive me if I hadn't gotten around to economics yet. Nor had many others in ITSM it seems, except probably Ian Clayton who seems to have pillaged everywhere. I look forward to learning more about the principal-agent problem now that you have so tactfully introduced us to it.

You do confuse me a little. You berate ITIL for being closed and sheltered, then you berate me for criticising the technical sector of IT for being closed and sheltered. The pot is black.

The good old days

I can't avoid pointing out that in the good old days of the v1 manager's training at the Civil Service College, when we were more concerned with developing skills than guaranteeing exam passes, we frequently had economists deliver guest sessions. Not only that but we also gave the students the opportunity to engage with accountants, project managers, statisticians and auditors. The end of the course always featured a presentation to two senior managers, one of whom was always from a non IT background. And, as I'm sure I've said elsewhere here, the first session on the course was dedicated to the product-service continuum and an incredibly simplistic introduction to some of Levitt's ideas.

James Finister

The Principal Agent Problem

I knew better than to include the last sentence about defensiveness--that was gratuitous. I apologize.

I don't identify you with ITIL, and I don't consider you cloistered. It is an unarticulated principle of management to understand that hypocrisy may be rational (which is not to say moral), and it may be rational to attempt to get others not to understand this. This cynicism is what I find so distasteful. But I don't believe this applies to you. Perhaps it applies to me. I don't think I'm being hypocritical, but I don't trust what anyone says about themselves, including me.

ITIL is filling a void with another one. The void is real: the disparity between what constitutes engineering in computing and civil engineering is enormous. Alan Kay speaks about the construction of the Empire State Building. It took 3400 people in a little over one year. Where have you seen this in computing? Where civil engineering has standards, deviation from which tends to introduce problem upon problem, IT has--this website. This website is probably the best that the industry has to offer in the way of standards. They're all here, in one form or another, in the comments or in the blog posts. That's not an exaggeration: one could learn the state of the art in this subject just by perusing this site.

IT is an infant attempting to learn a few ostensive definitions. What counts as professional certification, by comparison with civil engineering, is little more than a Fisher-Price toy dashboard. The void is an engineering void that cannot be reduced to a problem of service management.

Also, there is some confusion over the word "enterprise". As Paul Graham pointed out, enterprise technology companies are not really technology companies at all: they're sales companies. The word "enterprise" seems to suggest that it must take over every aspect of computing--anything that happens in the "enterprise" should . This is devastating for areas like research and development, which cannot be subject to the same levels of risk management that apply to service management. Yet I have seen, time and again, IT attempting to overwhelm endeavors that would rightly be considered risky by the standard of sales companies. I've seen this in postgraduate institutions, medical schools and research computing centers.


Oh no you don't. You don't butter me up that easily. ("butter me up" now there's a phrase that takes on new connotations in the modern world).

However I must agree. Having been subjected to engineering school I know what real engineers go through to get accredited. I wrote about this here

(Suzanne will be on my case now, puzzled why I'm not supporting prISM. I think it is the wrong agency, the wrong scope and the wrong name. If it were an IT-wide certification such as a British CITP it would make more sense. Service Management is too narrow a discipline and frankly itSMF don't have the credibility to carry it off.)

Hear hear

Do you hear yourself? Or is the sound of lashing out 'bon mot' too loud. For now I will humbly submit to your moral superiority and reformed public prosecutor self. But take time to understand how and why you crossed the moat. I'm patronizing? That's rich Skep! Real rich.

"ITSM is not rocket science". Here we go again. What's wrong with science. When did "common sense" become the dominant science. Don't you think that's the problem? Have you recently read Availability Management or Configuration Management in ITIL? Anybody with a knowledge of high-school algebra can master that level of analysis. But you and others insist any further advancement of the theory is too much for "smaller and simpler organizations"? Wait, did you say I was patronizing? And you are anti-elitist?!

Go read financial management and availability management in the first books that were written simply as guidance for the UK government and not for 100% pass rates in ITIL foundation. There is detailed guidance, worked out calculations and a level of analysis that is astounding. Today we all we have is MTBF and MTTR. A division and a subtraction. One configuration in series and one in parallel. And of course that availability should be defined from the customers' perspective. I'm fighting for the lost scientific knowledge. And very surprisingly I'm fighting against you.

I believe you have the integrity to come back here and apologize when you acknowledge, how for the sake of commercials interests, ITIL was progressively watered down, filled with slogans and easy-to-digest pithy maxims about "change the culture" and "hire good people" and "processes have inputs and outputs". More people passed exams. Then more people thought they could. So they made sure more did. Suddenly we had recruiters and PR staff who were ITIL-certified. Not that they shouldn't be. But ITIL for everyone" meant "ITIL for no one".

What pisses me off is you know better, but have now assumed a position and public persons that is forcing you to talk like a politician. What was that? " ... just opening the doors and reforming the Court"? Oh please!


I'm neither reformed nor a politician. You're just disappointed because I don't go along with your hysteria and bile. My views have changed little over the five years of this blog. The very first sentence written on this blog was "the time is ripe for a more objective evaluation of ITIL’s merits and caveats". I have changed my mind on a few things and yes i have apologised at times, but I don't see me changing my mind over anything you have presented thus far let alone apologise. One minute ITIL is inside-out (which I agree with) and only paying token attention to service, the next moment the very best arguments you can muster against ITIL are based around a few availability calculations and coverage of configuration? Oh please indeed.

P.S. Please refer me to the amazing financial management coverage in ITIL 1. I'm having trouble finding it. Or in fact any particularly amazing examples of "lost science". Perhaps i have a different library. I'd especially like to hear examples of how ITIL V1 was more service-centric or outside-in than ITIL V3. Of course I only have 33 ITIL V1 books so I may be missing some, or perhaps my versions of the books are too recent to be useful.

Wow. BroOt, are you OK?

Wow. BroOt, are you OK? Where does all this aggression come from? Did Sharon Taylor do something unspeakable to a family member?

I still have not read one item in your objective critiques that Skep hasn't agreed with. Otherwise, it's been all the bizarre Tea Party name calling.

I'm struggling with where a skeptical, real world filtering of ITIL is as dangerous as you claim. I'm not a consultant. I haven't worked with dozens of companies. But I have worked for 4 companies that were improved by using ITSM concepts. Some a little, some a lot.

I'd really like to see where ITIL has caused damage. Damage NOT related to the three issues Skep mentioned. I'm not trying to call you out. I really want to get some insight. That's why we're here, right?

Dan Kane

The right time to implement

So BroOt, let me get this straight.

What you are saying is that Skeptic criticises ITIL but not enough.
You also say that as ITIL books/content is developed it get less and less acceptable for actual implementation, because it is not perfect - and everyone deserves the perfect product only (whatever it is).

I could agree with that in theory - but what I struggle with is understanding how in the world are you going to develop the "perfect" product without the input that wide implementation experiences can provide?

Or are you saying that the progression of the material is not incorporating those experiences well enough?

It seems that your arguments are at odds with each other. If you want a "product", a theory that is developed to high scientific standard to be the shining light and "perfect practice" (I am starting to dread using "best practice" and "good practice" as the V3 books start muddying the waters, although that is not the point here), surely that development will always be ahead of the actual implementations and will come out with well thought through but innovative and new concepts. But in that case, how can you use that as a criticism as well (see your point about SKMS not being an established practice because your google search does not give you much around it)?

At the moment it does seem to me that you are upset about the commercialism of ITIL as a framework, and advocating for a much smaller circle of only-experts-can-know-this approach. Surely there is a balance between spreading what can help organisations (and like it or not, what you call watering down and commercialism helps more organisations benefiting from it compared to their state of operandi before they came across ITIL) and having the highly sophisticated framework that only a few elite can comprehend and so it not actually being used in the real world?

Maybe there is scope to provide a "masterclass" version of ITIL? But wait, isn't it something that the ITIL v3 strucutre already caters for (if someone wants to write it) in their complementary guidance section? Aren't you equating ITIL V3 with the 5 core books? What stopes you from restructuring, for example, the missing bits from ITIL V1 Availability into a masterclass book of "Availability deep dive" to be published under V3 complementary (after resolving the copyright aspects of course)?

How to treat ITIL

Not again

Yes I realize my comments are getting personal and distracting from the point I'm really making. You put down people all the time with your "oh you're so elitist" jabs. As advising large and complex organizations disqualifies them from advising smaller or simpler ones. Your sarcasm and witticisms are a smoke screen. Get someone to count how many times you've used that tactic to wiggle out of a serious argument. I have actually discussed specifics with examples of what's flawed. You should get past my taunts :-)

And yes, you cannot have it both ways. Nobody had heard of you until you became the mysterious skeptic who relentlessly and mockingly attacked the ITIL v3 project and became the Anna Hazare of ITSM world. People lapped it all up and you kept serving because you filled a need, just like FOX News and Murdoch did in the USA. Your stature grew. Now you're complaining? I'm just one of your disciples :-) Want to be like you :-)


Next time we see I'll translate it into Finnish for you ;)


PS I don't fully agree with the comment but I have recognized the problem in the Service Desk context and I did not know it had a name.

Since when?

Wait! You're the guy who became famous for criticizing ITIL for "theory". Fact is, there is very little theory in ITIL except perhaps for Service Strategy. Theory in the ITSM practitioner world is as appreciated as scientific evidence, climate change, and regulation are by the Tea Party. And aren't your three points tiresome by now? How about some hard new ideas versus the same old general self-help bullshit we read in paperback 10-minute MBA books you pick up at the airport?

ITIL is really flawed and nobody wants to point out the Emperor has no clothes? Wait, which side of the moat are you really on? And yes, seeing is believing. When I open the original availability management book (i.e. version 1.0) I was astonished at the level of analysis and rigor in those first edition books. Like you, I had all these dismissed them as old farts clinging on to their "good old days". Then I read the book and I felt anger at the avarice and greed that has taken over ITIL that led to the maligning of truly a great body of work. Version 2.0 was the first abomination. Of course when v3 came out people felt the same. Progressively, as ITIL became popular and more lucrative to vendors and training companies, it was converted into pulp and canned to be shipped worldwide for mass consumption. And now with the 2011 edition, it gets worse.

So don't be a freaking CNN anchor and waste your power and influence (you have a following) and mindless shit like "Oh ... it is people and process stupid!". Some of us know, you know better. And that's inexcusable Rob!

P.S. The agency problem is from divergence of interests between the principal and agent. User is the agent of the customer. Service delivery/support staff are the agents of the service provider. That's why the agency problem is more severe in business services than consumer services.


The phenomenon is most accurately captured by the Russian word Poshlost, which unfortunately is untranslatable into English.

Exhibit A: Are you a low-status techie:

I quote: "My personal bias is that technologists should rule a company. I’m completely in line with Mark Suster when he writes that the startup that’s most worth funding is all technologists. My reasons for this build upon Mark Suster’s in that you don’t have to “translate things into English.” It’s kind of insulting when I hear the phrase “translate things into English.” It puts the blame on the person on the team most equipped to solve the problem. The person, who wants “things translated into English,” is the problem, not the coder."

Exhibit B: The segment on "the noise from the middle" in a recent talk by Alan Kay. URL:

none the wiser

I've read and re-read both your posts and I'm none the wiser as to what you are on about. I am humbled by your superior intellect and vocabulary. Now if you'd care to stoop to speaking in vernacular, perhaps we could then decide whether you actually make any sense.

I suspect you are saying that the process-geeks who displace the techno-geeks when operations finally gets some control over what is happening are not themselves technologists. Which is generally false. Or maybe you are saying that IT managers are not technologists. Whatever. You seem to think this is a bad thing.

You then seem to leap to some connection between what is good for small technology startups and what is good for the rest of us. I can't see the link myself but then as I say I'm having trouble grasping much of what you say. I have a feeling you might think that all conversations in IT including business ones should be conducted in techno-geek. Techno-geek is of course not actually a language so much as a mindset: a mindset where decisions should be made on a limited value set that does not include economics, expediency, human factors or politics; it cares only for technical purity and intellectual machismo. To the extent that techno-geek is a language, it is English obfuscated with acronyms and jargon, in order that the technologists can maintain a closed clique and pretend to superiority. Technologists of this sort are an arrogant bunch of misanthropes who can't see that their own narrow bigoted worldview cripples their ability to function in a normal human (or business) society. And I'm starting to discern through the haze that you might be one of them.

If you check into the real world some time, please come visit.

нехватка сам понимание

Um, isn't this techno-bias simply another expression of the principle-agent problem, whereby the Principle monitors the Agent by asking, "Just feckin' give it to me in English already"?

How do you say, "Lack of self-awareness" in Russian?


Great job. Thanks.

This must be a goldmine for some consultants who can spend ages on writing role descriptions and RACI matrices for all those roles ;)

But seriously. The list proves that the framework is broken. A sensible framework would not produce such bs. Many of those "processes" are actually just activities, possibly within another process or function and do not need owners or managers...


Fantastic work, thank-you, but no SFIA

Hey Matthew, thank-you SO MUCH for doing that. Huge job. Skip the SFIA work. I've been meaning to remove SFIA anyway for two reasons (a) the roles don't all map well to SFIA and (b) I no longer use or recommend SFIA. In fact I wouldn't be the least bit surprised if the SFIA mapping was a violation of terms of use.


I think it's a shame that you don't use SFIA anymore. V5 is currently in development and due to be released soon, and there is some really good stuff in it.
I understand what you are saying about usage restrictions, but in practice this hasn't prevented me from using it with customers as it is them using it internally and me helping them to use it. I have been on the course and am an accredited consultant - I note your comment about the courses being in the UK, but they are now available in Australia and NZ and many other places.
From my voluntary work with itSMF UK, I've been involved in some SFIA activity, and I must say that I think many of the points you raised have been resolved. I sit on the SFIA Council as the itSMF UK representative, and would be happy to raise any additional points in the hope that we can get them resolved and allow wider use of SFIA.
Could you let me know what issues you think remain?
Kind regards

I'm a generalist. I use

I'm a generalist. I use skills frameworks about twice a year and make a few hundred bucks in fees when I do as part of larger engagements. I have no intention of spending thousands certifying in order to quote a few paragraphs in a recommendation doc. SFIA, like ITIL, is not brain surgery. All this you-cant-use-it-until-we-annoint-you bullshit is just a revenue scam. If SFIA really exists to serve the profession it should be in the public domain, pure and simple.

Cheese Roles

Great job Matthew - I am still counting.

Its full of holes - swiss cheese holes...

The problem is - they failed to nail them to activities within the new 'process flows'. For example, who is responsible for running change management - the change process owner or the change process manager?


The meaning of CSI in the ITIL ref column is "Continual Service Improvement" and not "Crime Scene Investigation" as misspelled in the sentence: "In the ITIL ref column: SS=Service Strategy (book), SD=Service Design, ST=Service Transition, SO=Service Operation, CSI=Crime Scene Investigation
the numbers refer to sections in the book."

CSI = Continual Service Improvement

explains it

Well THAT explains a lot! Phew thanks. I've been making such an idiot of myself in client meetings til now
I always wondered why nobody died


Wait a minute, it just might be correct - I've seen many ITSM implementations that just might benefit from a Crime Scene Investigation :).


Of course it is correct. When there is a major screw-up, CSI is called in.

Who killed ITSM?

Cluedo: Death of this ITSM professional was by verbal diarrhea, and I conclude the murderer was (drum roll)... Service Strategy, in section 2.4.1 pages 19-20, Principles of Service Management, and the weapon was a blow to the head with blunt text such as this,

"The aim of service management is to make available capabilities and resources useful to the customer in the highly usable form of services at acceptable levels of quality, cost and risks. Service providers help relax the constraints on customers of ownership and control of specific resources. In addition to the value from utilizing such resources now offered as services, customers are freed to focus on what they consider to be their core competence. The relationship between customers and service providers varies by specialization in ownership and control of resources and the coordination of dependencies between different pools of resources (Figure 2.6)."

followed by repeated blows to the head in the immediately following paragraphs, (yes the next paragraph):

"Customers specialize in business management to achieve one set of outcomes using a set of resources (Pool A). Similarly, service providers specialize in service management with another set (Pool B). Service management coordinates the dependencies between the two side through assurances and utilization. Customers are content with utilization of certain resources (Pool B) unless ownership is a prerequisite for strategic advantage."

Luckily the ITSM professional was dead before he hit the ground as more blunt text blows rained down... "Specialization is a necessary condition for developing organizational capabilities...... "

"Why do you hit your head against the wall for hours?" Response, "Because it feels good when I stop".

Missed a few

By far the best list I've found! I did find a few that were not on your list:

IT Facilities Manager SO E9
Major Incident Team SO
Test Manager ST 4.5.5
Access Manager SO 6.6.9
Emergency Change Advisory Board (ECAB) ST

When just reading the books it isn't obvious how screwed up the roles are, that only becomes apparent when you try and use them.


I'm looking at my copy of the ITIL 2011 Edition, in the Service Operations book, and I can't see a section Section does include mention of a major incident team - but this is not a 'role', it is a 'team'. It says that the major incident team should be under the direct leadership of the incident manager (a role that is missed in chapter 6 - which is supposed to define the roles). So, in my opinion, 'major incident team' should not be in the list of roles, but maybe Incident Manager should be.


Apologies, I've just realised that my latest comment was on a list for the 2007 edition of ITIL. I should have looked at the date, but was confused by another article which mentioned 108 roles in ITIL 2011 edition (they had taken my 103 roles and added the 5 listed by another contributor) - this was wrong, although in checking I did uncover reference to an Incident Manager in the text of one section, and it's not in chapter 6 which is supposed to describe the roles.

My count is 47 roles in ITIL V3.0

Wow - My 'Decipher the ITIL Code' program uncovered 45 named roles in ITIL and 2 implied... so my count was at 47 role looking descriptions - I ignored 'team' and the like. I'm hoping 'edition' 3.1 takes a few of these behind the woodshed and puts them down.... the USMBOK has 7 major roles and a role continuum to explain the minimum and what know-how each needs...

Syndicate content