Unfortunately, you attended a V3 Foundations Course. As a certified IT Service Manager, I am no fan of the "improvements" of V3. V2 was, and still is, best practice. The guidance of the V3 framework is flawed at best.
My advice as an experienced practitioner for the past 5+ years internationally, is to stick to V2. This is where you'll find the value.
Additionally, if your instructor could not explain the relationship (not overlaps) between ITIL and Project Management, I'd argue that she may not be all that experienced. The distinctions are clear for those who have actually worked to integrate the Service Management concepts into the typical IT organization.
You may recall some time ago I noted that I was going to get ITIL Foundation-level certified. Well, after a few delays, the deed is done, and I'm back from immersion in the fundamentals of the IT Infrastructure Library. Since it was held in Dallas, I also got immersed in that massive wind and rain extravaganza that eventually flooded the middle of the nation last week.
While there are many different providers of the ITIL Version 3 Foundation Certification Course such as BMC, HP, Learning Tree and others, the particular class I attended was offered by the ITSM Academy.
I was both delighted and relieved to discover that our instructor, Joy Yoder, has a lot of practical experience in service management. Besides being an excellent instructor, Joy was able to use her background to keep the class interesting with plenty of practical context and references.
The foundation-level certification class provides an in-depth guided tour of:
- ITIL objectives and its approach to Service Management
- How ITIL is structured, the processes it includes, and the key concepts
- Lots of ITIL-specific definitions and terminology
- A glimpse into how ITIL relates to other IT standards and methodologies
It concludes with a 1-hour, 40-question formal certification test. I should point out that the foundation course and its certification exam is still at the 'awareness' level; there are several follow-on practitioner courses that delve deeper into the methodology for those who are responsible for implementing ITIL.
The foundation level is a good for stakeholders who must govern or facilitate the processes and need to be able to speak the language. For those seriously interested but need more education before making a decision, it is a great mechanism to assess whether ITIL is even right for your organization, and if so, to what extent.
While I went in to this course with a pretty solid grounding on general ITIL structure and concepts, this 3-day tour does a good job of thoroughly exploring conceptual nooks and crannies of ITIL, far beyond the overview you get from a one-hour webcast or and industry article. For me, it did a lot to separate the facts from any preconceptions or suppositions that only casual exposure inevitably creates. Joy was also able to give us some deeper explanation well beyond the slide deck when needed.
So, what did I come away with? First of all, before I complain or counterpoint, let me start by saying that from the vantage point of what ITIL sets out to accomplish — establish an approach for IT Service Management, it does so in a largely detailed and practical manner. I have some minor grief with how it redefines or ignores some common business terms (pet peeve), and others that it simply makes up that are of questionable benefit (really now, if you are going to discuss Deming's PDCA improvement model, then why not DMAIC from Six Sigma as well?
Nope — let's make up our own 7-step model instead…). There are few areas where I have to wonder why they even bother to go into them, as they cannot be treated in enough depth to be meaningful.
In my humble opinion, there are also some balance issues; an entire guide dedicated to continual service improvement? Component level asset documentation and information management is a big deal. Service Desk — lots of focus.
Yet, applications and their management are barely recognized. Software is the most common tangible deliverable that customers interact with, the core of most services and the primary reason that the other components even exist, and one of the more costly aspects of service development and delivery; why is there so little discussion or guidance about establishing mechanisms for how to assess, optimize and manage them?
Most of all, the class served to further reinforce my concerns over the significant overlaps that exist in V.3 with other proven and widely accepted methodologies. The overlap itself wouldn't be so bad except for the lack of recognition or accommodation. For example, both Service Strategy and Continual Service Improvement concepts pretty much ignore product, program and portfolio management approaches. But the biggie is project management.
I have a better appreciation for how much real work it is going to be to integrate ITIL into an environment that has already established a project-oriented culture. The irony is, because of the overlap, it is probably impossible to fully implement both PMI and ITIL standards in a single environment, yet both disciplines are required; "Projects — 'ya can't live with 'em, can't live without 'em!"
The ITIL Lifecycle goes from (Service) Strategy to Design to Transition to Operation and Continual Improvement. Conspicuously absent is Development. It reminds me of the infamous Sydney Harris cartoon from The New Yorker, where in the middle of a long equation written on a blackboard is the statement, "then a miracle occurs"…
So, while design considerations, deployment and release management are covered, ITIL is mute on the topic of actually creating or changing the service. Why? Ah, because that's the domain of project management. The implementing organization is on their own when it comes to service development, but instead of leaving an area with a big sign that says, "insert PM methodology here", and providing conceptual hooks where the accepted scope of project management can be logically fit within the ITIL framework, it steps all over a good deal of common real estate.
How does one treat areas such as design and deployment, which both disciplines cover, using different approaches and lexicon? For example, is any organization willing to forego the term 'Project' in IT, and replace it with 'Change Request'?
Is everyone going to toss their project charters, functional and technical requirements docs and replace them with a Service Design Package, SLR or SAC? I didn't see 'project manager' mentioned anywhere in ITIL roles and responsibilities, yet it is critical to fulfilling the service management lifecycle. How do they interface with the Change Manager?
How about the Program Manager? Are they one and the same? These are all details that will have to be addressed when reconciling competing views on IT management. What a shame — it was a missed opportunity for the respective leading governing bodies for these disciplines to collaborate with each other and find alignment.
Bear in mind that project management can't be ignored and won't go away; it is an accepted business practice that transcends just IT in many organizations, it has more tenure, and ITSM won't work without it. I fear that by ignoring the role project management plays in the service lifecycle, ITIL has doomed itself to be partially adopted in bits and slivers, which will obviously limit its effectiveness. We see it already, with organizations saying, "We're implementing Problem and Incident management".I like ITIL — it has a lot of good things going for it and brings much needed focus on IT services. These critical operational functions lack the relative glamour of big exciting projects yet suck up most of the resources, so it is good for ITSM to get some time in the spotlight as well. But, at the end of the day, these two have to dance gracefully together to really wow the audience.