Product Description

Essential reading for all decision makers (IT-literate or not) who are presented with an ITIL(r) proposal or asked to oversee or own an ITIL project. It explains, in lay-manager's terms, what ITIL is. It reveals what ITIL is good for, what it is bad at, what to expect. It describes how to ensure an ITIL project succeeds, what to require from the project, and how to measure the results. ITIL(r) is a Registered Trade Mark and a Registered Community Trade Mark of the UK Office of Government Commerce ("OGC"). ITIL(r) is registered in the U.S. Patent and Trademark Office.

Product Details

• Amazon Sales Rank: #738545 in Books
• Published on: 2009-04-06
• Binding: Paperback
• 178 pages

Customer Reviews

A skeptical point of view, worth reading, not accepting
The Executive Summary chapter of the book includes the following sentence with which I'm in total agreement: "Every organization needs the processes ITIL describes." The next sentence, however, is where we disagree: "Every organization already has them." This dichotomy really is the basis for my review; I agree with some of the material and disagree with other parts.

I've been in too many organizations that either didn't have Change Management, or didn't have it in a form anywhere close to what ITIL describes. So the comment that "every organization has them," isn't correct. For example, I've seen the named process, but it consisted of using software version control tools. That is not even close to the process ITIL describes.

The fundamental difference between the author's point of view and mine (reflected in this review) is that I don't see "ITIL... (becoming) something of a cult," or "a movement." I don't see ITIL becoming something it isn't. Quite simply, ITIL is documentation of good/best practice for IT. This doesn't lend itself to "cult" or anything else -- it either is good/best practice or it isn't.

If you think about, "implementing ITIL," the book says (and I agree) that is the wrong approach, you don't implement ITIL, you don't "Do ITIL" i.e., start a project and you're done when ITIL is implemented. Instead you "adopt" ITIL processes at pain points within the organization -- with planning, involvement of the people, and clear communication throughout the organization.

Adopting ITIL is as much about people, organization, organizational culture, and partners as it is about putting ITIL process into practice. While the book makes this point, it includes this quotation written by the author from another Web site owned by his company, "Not everyone can afford or wants best practice." While there is footnote attribution, I don't believe the quote should be included in the text the way it is. Instead, I'd like to see the entire concept, including the quote, in a footnote.

The book talks about alternatives to ITIL. ITIL documents existing best/good practice. Are there really alternatives, isn't good or best practice just that? The author says, "COBIT has matured to the point... that presents a credible alternative to ITIL," and that ITIL has, "...many omissions compared to COBIT." Again, the author and I must agree to disagree. Yes, COBIT now includes many processes similar to ITIL, however, the overall goal or focus of COBIT is still fundamentally IT Governance. ITIL isn't COBIT; the two aren't intended to map the same domain space. ITIL and COBIT can work together.

There are too many additional points of disagreement for me to enumerate them all in this review. Consider these two areas: CMDB and the choice between ITIL V2 & V3.

The author is right the CMDB (Configuration Management Database) can't be done. That is one of the problems with ITIL V2, which suggests a monolithic database with all configuration related information. That approach didn't work. It's one of the reasons ITIL V3 talks about a Configuration Management System (CMS), system, not database.

The book appears to suggest that an asset database is sufficient. According to "Owning ITIL," "Incident-Problem-Change works just fine on top of a single asset database." Not in my experience! Without the missing pieces that are part of a CMS, the relationship between the various assets, how the assets are used and combined to form Configuration Items that participate in the delivery of IT Services, proactive problem management becomes impossible, change management can't evaluate the impact of change on the live environment, and incident management can't relate this incident to others.

Owning ITIL includes the following: "Don't leap into ITIL3.... For those organizations that feel they have 'conquered' ITIL2, version 3 is the next logical step." In my experience, the organizations that have "conquered" ITIL 2 were actually operating in modes closer to what we call ITIL V3.

Why? When people talk about ITIL V2 being simpler or easier than V3, they are usually only considering 2 of the 7 books of ITIL V2 (Service Delivery & Service Support) and neglect the necessary guidance in the other 5 ITIL V2 volumes. ITIL V2 focuses on specific ITIL processes and almost silos them in either planning (Service Delivery volume) or operational (Service Support volume) with Security Management as a suggested wrapper. The basic view is relatively a narrow focus on each process.

Services have life cycles. This fact is ignored by V2 and is the foundation of the reorganization/refresh that is V3. ITIL V3 expands information from ITIL V2 core and includes information from the "lesser" ITIL V2 books. In ITIL V3 the process are presented as part of the lifecycle that helps to dispel the "soft silo" notion that is part of V2. In other words, a core part of the approach for ITIL V3 is how all of the processes work together to achieve IT Service Management, as integrals parts of service life cycle.

Another example of the differences between the two versions: The discussion about what constitutes a process, in ITIL V2, is relegated to an appendix titled: Process theory and practice. On the other hand, ITIL V3 includes a complete discussion about processes, process models, and how to design a process including designing the metrics and measurement systems to gauge process success (or thresholds for process improvement).

Other changes in V3 recognized the realities missing from V2. For example, ITIL V2 documents a single function, Service Desk. ITIL v3 includes the Service Desk, and adds Operations Management, Technical Management, and Application Management -- functions that the V2 organizations needed and already had in place.

ITIL V2 included processes for Change, Configuration, and Release Management. ITIL v3 includes them with enhancements and also provided descriptions of the missing process that were used to protect the live environment and assure the change would actually deliver business value. In other words, ITIL V3 documented what was actually happening in the real world and exposed that information to keep the Library current. ITIL V3 didn't invent processes; it reports what organizations were already doing, not theory, but current practice.

To put it another way, ITIL V3 isn't theory or the next "version" per se. ITIL V3 is a refresh of the Library that documents current best/good practice; it's not a new version in the way that Microsoft Office 2007 is new compared to Microsoft Office 2003.

ITIL has never been a predictor of what might be good/best practice; it documents what is current at the time it was written. If you want to own ITIL, don't DO it (a point the author also makes), don't implement it, instead adopt it, top to bottom within the organization. Recognize that ITIL is as much about people and culture as it is about processes or achieving IT Service Management.

One more point, ITIL V3 includes guidance for outsourcing, insourcing, down-sizing, right-sizing, mergers & acquisitions, and more... topics faced by many organizations today, topics not addressed in version 2.

The 104 recommendations sprinkled at the end each chapter are worth consideration, but not complete. The ITIL Project Proposal questions are reasonable starting point, but should be tweaked in the context of "adoption" versus "implementation" as noted above. Other questions should be added to address the current ITIL level of knowledge (or awareness) in the organization, the ITIL awareness (and or adoption) of partners/suppliers, etc.

While you should use multiple projects as part of the adoption process, the message in the book is not clear about this point. Owning ITIL makes that says that ITIL is an approach, not a project. Then there's the chapters "ITIL Project" and "Post Implementation Review" (e.g., you don't implement ITIL as part of a project, so there isn't a "post" -- instead review should be continual as part of the adoption process).

There are multiple points of value in Owning ITIL including: Don't DO ITIL for sake of doing ITIL or just to say your organization is following documented good practice. Do it because there is a sound business case for ITIL adoption. For me, there are too many points that detract from the message. This is where the concept of Owning ITIL should start and focus.

Bottom line: The book author is The IT Skeptic. Read the book to understand a skeptical point of view. Don't accept it as your only guide to make competitive decisions to meet today's situations, challenges or demands.

Finally some honesty on ITIL
I was fortunate enough to find Rob England's work while on twitter @TheITSkeptic. I have been in the IT Service Management business for close to 20 years, both working on a help desk and working for ITIL software and training companies.
I was lured to this book because of the title and after reading Rob's view on many other topics in IT on his blog [...].
After reading it (twice), I realized what I had my hands on. This was a book for anyone just starting to research ITIL all the way to those of us who have been forced to drink the kool aid for a long time.
Rob takes time to look at the industry of ITIL, the cult of ITIL and explain where and how ITIL is a good idea. "If IT ain't broke, don't fix it". Additionally and more importantly unlike other ITIL books, Rob takes head on what's MISSING from ITIL.
The book covers the "aspirational concept" of CMDB, but there is another book from Rob England covering that topic much more. It moves on to talk about other frameworks (YES VIRGINIA YOU HAVE A CHOICE).
One of my favorite sections is the analysis on Vendors and Analysts. A very real light is shed on the purpose of analysts -" exist to create change so that they may interpret it".
How true and how many times are we as consumers lead down this path to only find out that it's a bit late and we may have bitten off more than we can chew.
I would highly recommend this book for EVERY IT and Management person today.
It's not about BEST PRACTICE, it's about REAL PRACTICE, and it gets NO MORE REAL than "Owning ITIL" by Rob England!