The OGC ITIL V3 Change Log's greatest hits
If you are thinking the ITIL V3 2nd Edition or Refreshrefresh - or whatever it is called - is just about adding a few missing semicolons and spelling Ivor Macfarlane's name right, think again. Even if they get talked out of this plan to rewrite (read: dumb down) the whole of Service Strategy ("oooh ITIL is HARD - why can't it be easy like TV?"), take a look at some of the errors to be fixed in the books. Remember, paid authors for each book from major corporations, hundreds of reviewers, professional commercial publisher with professional editors... and we get:
| 83,85 | Each of the ITIL books refers to "Purpose, Goals and Objectives" for processes, but the ITIL Glossary does not clearly distinguish the meanings of these terms. Purpose and Goal are not defined. The definition of Objective says that it is a "Defined purpose or aim...". There should be a set of three definitions that clearly distinguish these terms Throughout the 5 core books the sections 'Purpose/goal/objective' are inconsistent in whether all three are stated. |
|
| 81 | SO | Figure 4.4 there is not an option for a no response to decision-diamond "Workaround?" in the process flowchart diagram. |
| 122 | ST | In 4.3.4.3 control of the DML is clearly by SACM - a change from v2, where this was RM. ("The Official Study Guide" contradicts this, as it says the software is under the control of "Change and Release Management" [sic]. ) |
| 127 | The design of a service seems to be an implied overarching process in the Service Design book, but it is not defined anywhere. [Skep's note: one of the few process docs we have, Figure 10.22 of the Official Introduction, also here, seems to imply that "Design solution" is an activity of Service Catalogue Management, but it is hard to tell as the diagram seems to show atcivities as outputs] | |
| 145 | The terms Business Relationship Manager, Product Manager (a.k.a. Service Manager) and Service Owner are used at different stages of the life cycle. They seem to refer to one or two closely linked roles that have not been well distinguished and whose interactions have not been well defined. The term Service Manager is used only in the CSI book. It looks as though the authors did not coordinate on these terms or roles. They should be rationalized, and any distinctions or interactions should be clarified, and Glossary entries update. [See also Skep's attempt to understand ITIL roles] | |
| 149, 170 | SS | The term Service Model is not defined. This is a key part of Service Strategy, but is also not defined there. |
| 155 | ST | 4.2 Change Mgmt does not have a section for 'Challenges, CSFs and Risks', unlike the other processes (c.f. 4.3.9 and 4.4.9) |
| 162 | SS | The concept of Value Capture is not well explained. It is mentioned in 4.3 and 4.3.2.3. However, in 3.5.1 it is only explained in terms of an example where value is NOT captured. This concept is particularly tricky for type I and type II providers. |
| 37 | SD | ITSCM and Availability Management make no reference to Recovery Time Objective or Recovery Point Objective (which are of great significance when designing for service continuity and availability) - but these are listed in the glossary and mentioned briefly in Service Operation under backup and recovery. |
| 36 | SD | A change to the Goal of ITSCM was accepted during the public QA process, but didn't get into the published version. Like v2, the Goal still omits any mention of risk reduction, although the process description does stress this |
| 53 | Missing Integrated Service Model | |
| 73 | SO | Proactive Problem Management has disappeared |
| 196 | SS | Kano model is mentioned but no explanation ... page 205 Kanban system - there is no explanation in the book |
| 206 | CSI | An exam question hinges on what is the first step of the CSI model. there are two versions: a 6-step one on pages 15 and 30 and a four-step one on page 163 (not to be confused of course with the "7-step PROCESS" which has eight steps, the second one being numbered "1", on page 32) |
| 213 | ST | In 4.2.6.4 the table of the seven Rs is inconsistent with the Official Introduction p81 and the Managers Bridge sample exam. The 5th R shows "What RESOURCES are required" where the other two sources show "What resources are REQUIRED". |
| 214 | ST | Inconsistency about level of Change assessment. 4.2.6.4 p54 under 'risk categorization' talks about determining the level of assessment (similar to v2 'minor changes' not requiring a CAB). However, after this, it is implicit (and explicit in The Official Introduction p82) that "the" CAB must assess all Normal Changes. This needs to be sorted out, as the change model for minor changes was a key concept for "the efficient and prompt handling of changes". |
| 215 | ST | Fig 4.5 p57 shows the CAB as the level-3 Change Authority. This contradicts the last paragraph on p59, which stresses that the CAB is an advisory body only, and also that a "Change Management authorization plan" (which is not described) should name the authorizers. |
| 222 | ST | Table 5.3 on p166 breaks a cardinal rule of a RACI matrix, that only one person/role can be Accountable for any activity. |
| 266 | SS | The Glossary defines a Service Package as including a [single] SLP and one or more core services and supporting services. 5.5.4.3 says that SP(s) (the first use of this term) come with one OR MORE SLPs. The Glossary has an SLP as a defined level of Utility and Warranty for an SP. The SLPs are 'associated with' (how?) ... a CSP. The Glossary has a CSP as a detailed description of a Core Service, but 5.5.4.3 describes it as a SP ... shared by 2 or more SLPs, and that attributes of the SLPs can be subsumed into the CSP. |
| 270 | There is a widespread lack of consistency of definitions of what are and are not processes, their goals, objectives, purpose and aims, and in the definitions of terminology. This applies across the main books, the Official Intro, the KEGs, Little ITIL and Passing Your ITIL Foundation Exam. This makes it difficult as a trainer to know what version to teach, as an examinee what the required right answer is; and as a supplier to be able to describe how we try to align with ITIL. Is it possible to have an agreed, consistent source? By example, there are 5 different definitions of 'Market Space', 3 different definitions of 'Service Portfolio' and 5 variations of the Goals/Objective/Purpose of Service Design. [can't you just hear their voice rising to a shriek at the end?] | |
| 295 | SD | 4.6.4.2 notes that the security policies should be widely available to all customers and users. This is fine for an internal provider (type I or II) but may be totally unacceptable for an outsourcer (type III). It is difficult to see how any outsourcer could claim alignment with ITIL in this area |
I think I've checked all of these but let me know if they're wrong. I'm only about halfway through the Log and these are just a few personal favourites - I'll add more doozies later. Contributions welcome of really BIG-implication errors and omissions not just typos or sentences that don't make sense or minor inconsistencies, else we'll have the full 300.
I bet the ITIL authors never thought that casually defined descriptions such as the six-step-CSI model or the "Seven Rs of whatever" would ever become exam questions. That's why I don't get too worked up about errors that aren't going to cause confusion: I feel that ITIL was never written to be taken as seriously as it is.
Some of the Change Log entries are of course vexatious or dumb, such as 142 which wants to reinvent Standard Change, or this one, 195, which really takes the prize for runaway political correctness:
Concern over figure 6.6 (page 136) in Service Operation. The diagram has a hexagram as its centre - there is some concern how this will be received globally, particularly in the Middle East. Consider changing this.
The Semitic implications of Application Management are clearly offensive. The best way to solve that will be to change all models so that there are only five aspects to be inter-related: perhaps anything involving six things in a circle is offensive because of the implication that it MIGHT be joined by a hexagram.
Furthermore, as an atheist I am deeply offended by orthogonal lines with their Christian connotation (e.g. figure 3.4 in CSI which clearly depicts a Crusader's crucifix). I insist that no diagram depict lines intersecting at a right angle, especially in situations where the horizontal might be shorter than the vertical and/or offset above the vertical midway point.
Made in New Zealand 
Comments
Crowd sourcing ITIL
Why not set up a 'Wikipedia' for ITIL. Everybody could add content and we wouldn't need to pay for authors or editors. After a few weeks it would converge into 'crowd sourced best practice'
Only kidding!
rob.
You mean this one:
http://wiki.en.it-processmaps.com/index.php/Main_Page
half a dozen failed attempts
No he doesn't. There's half a dozen failed attempts at publicly created versions of ITIL. It doesn't work: there's not enough people, there's nothing in it for them to motivate them, and there is no review and editorial function to ensure a consistent and high quality result.
I think COBIT5 could be different, given the enthusiasm for ISACA members to contribute volunteer effort, and the amount of energy and people and cash and credibility ISACA will be able to inject to make it happen. Or maybe they'll run into the great tarpit of apathy that all these things bog down in. You just have to look at Wikipedia ITIL.
ITIL Idiom #67 - "...service stinks"
The change log is the tip of the iceberg.
I have assembled over 1100 'decipher statements' in my online library for ITIL. Not typos, but miss-steps in Version2 and Version 3. (Next week I'll be making those available as part of the next version of the best practice online library service). I hope that in the New Testament edition of ITIL they promise they write the glossary AFTER they refresh the books!
The ITIL V3 glossary gives us key terms a misrepresented 'Agency Principle', the 'British Standards Institute' (but no ANSI), a strange definition for COBIT, 'configuration structure' (presumably this is what the book terms a configuration model?), control perspective, 'customer portfolio' (explained as a list of customer - not their investments), client and customer (different definitions), ISO20000 (explained as aligned WITH ITIL!), ITIL (described as a set of best practice guidance), a hacking of Porter's 'Value Chain'.... and so on...
At least the V3 glossary effort removed a few V2 classics, including 'allies', 'customer interrogation' and 'informed customer'.
Anyway, I was also struck and pleased by the commitment by OGC to hunt down and remove any 'idioms'. Here's a taster - CSI page 7, Section 1.4 Usage, and I quote...
"CSI is not an emergency project kicked off when someone in authority yells that the service stinks".
Some other idioms... 'chokepoints', 'the holdup problem', 'tool trap', 'firefighter trap'..
Some interesting statements (wonder how these translate to Tibetan or Korean):
'staff must rotate', 'staff must be minimally certified', 'adequate scarce resources'
Oh one more, checkout 'factors of service availability (active, passive, divers and homogeneous redundancy)' in Strategy and see if you can find it as part of the Availability Management discussion in Service Design...
And a classic from the Design book:
"Architectures and designs should be kept, clear, concise, simple and relevant. All too often, designs and architectures are complex and theoretical and do not relate to the 'real world' ". Have you seen some of the diagrams in this book... page 83 is a doozy.
Not a quick fix....
idiomatic entry
One more idiomatic entry is identified in Issue 134:
SS 2.4.4.1, the issue asks 'what in household terms is a furnace?' Many countries don't burn bulk hydrocarbon fuels round the clock in the basement. "Furnace" might cause puzzlement in the sensitive Middle East followed by delight on hearing of the explanation.
Business relationship management
Has anybody noticed this, it is not in Change Log.
Glossary says:
Business Relationship Management
(Service Strategy) The Process or Function responsible for maintaining a Relationship with the Business. Business
Relationship Management usually includes:
■ Managing personal Relationships with Business managers
■ Providing input to Service Portfolio Management
■ Ensuring that the IT Service Provider is satisfying the Business needs of the Customers
This Process has strong links with Service Level Management.
SS book has Figure B1 in Appendix B2 where a box called Business relationsip Management appears. That's it.
Aale
BRM is analogous with Sales Manager
Aale
SS book also implies BRM is same as account manager or sales manager... again not in glossary. I'm fairly confident most of what needs to be fixed is not in the Change Log...