I attended a training/consulting firm presentation recently on ITIL v3, one of many I anticipate I'll be sitting through. A couple of random thoughts:
The presenter stated that the lifecycle focus of v3 should help those involved in the software development lifecycle to "feel included" in ITIL. My response: do they *want* to feel included? This is how the ITIL v3 advocate risks being heard:
"Hi, I'm here with my ITIL v3 volumes, please involve me at the front end of your project so I can raise a bunch of concerns having little to do with the core functional value proposition of your system. I'm a certified Service Strategist, but have no background in architecture or the software development lifecycle. I'm holding a book called Service Design, which is all about non-functional requirements and has little to say about the actual purpose of the system. I myself have never actually designed a production application (in fact, I will dismiss the concept of "application" and use the term "service;" you'll have to educate yourself on exactly what I mean, because even I am not completely consistent on the distinction).
"Nevertheless, I am going to tell you how to achieve business-IT integration. Architecture is a low level concern (if it were important, it would have been a major section in ITIL v3). I am more strategic than that, so the fact that I've paid no dues in actually building systems or interacting with functional business users is irrelevant. I have a checklist as long as your arm, but don't worry, I've been to ITIL Training, so I know what I'm doing. Let's get to work."
Unfair? Perhaps. But when I see the credentials of the ITIL experts now carrying the v3 flag, I see a lot of folks who have consulted on help desk operations, incident/problem management, and at best led discussions regarding availability and continuity with business partners. With a few notable exceptions, I'm not seeing folks who've designed systems or cut production code; I'm not seeing delivery project managers; I'm not seeing architects. I'm not seeing folks who have slogged through weeks of wearying requirements interviews and re-iterations. So, why should the SDLC professionals want to be included in the v3 initiative? When none of their friends are at the party? When the majority of ITSMF meeting attendees are operations folks?
Please understand, I support the concept of the service lifecycle. It is essentially the IT value chain. Achieving end to end traceability of services through the demand pipeline would be a very good thing. It's just that the people who control the front end of the demand pipeline may find the idea of being "included" in ITIL a bit backwards. There's plenty of literature and best practice on that side of the house. ITIL and its related training infrastructure will have a long row to hoe in making headway.
This is not just about people reading the v3 books. This is about significant percentages of people in Program Offices choosing to spend their training dollars on ITIL certification, instead of PMI certfication. This is about people choosing to attend the ITSMF, instead of a Gartner or CIO Magazine conference. I realize it's not all zero-sum, but in order for anyone to say the first two ITIL volumes in particular have succeeded, their related training and certification offerings must be in demand, and these offerings (yet to be announced by many ITIL v3 vendors) are entering a competitive market, both on the supply and demand side.
ITIL v3 vendors used to recruiting people with experience in infrastructure engineering and operational process improvement will need to recruit trainers and advocates with much more background in IT vendor and sourcing management, IT portfolio management, architecture, and solutions delivery. And such people will need to be convinced that ITIL is a worthy vehicle. This process is only starting and there is no guarantee as to how it will play out...
Couple specifics:
They are trying to have it both ways on demand management. They are positioning it as the front end of the service lifecycle, but also keeping it coupled to Capacity Management. This puts Capacity Management in an awkward position, because demand management in this more comprehensive sense also includes human resource planning in the context of project portfolio management. How many Capacity Management organizations that you know do that?
Knowledge management (KM) has been established as a process area. This may give a shot in the arm to this notoriously moribund discipline. (See here, here and here.) However, the presenter explicitly called for re-usable and queryable knowledge. This to my mind starts to evoke metadata management more than KM. They are calling for a "Service Management Knowledge System" to do this. Clearly if I were to go out and look for something in this area I would be looking to the likes of Troux or Adaptive, or perhaps the IT portfolio management vendors. I wouldn't be looking to the established Service Management vendors. (The reference system in my architecture would be the IT Data Mart.) It's a step in the right direction that they have disambiguated this from the CMDB; I called for this in my book. Of course, when you start getting into products like these, you start dealing with complex metamodels and reporting requirements. See the OMG's Meta-Object Facility. (The word "metadata" has been cropping up a LOT in various ITIL forums lately. As applied to ITSM, you heard it here first...)
All for now,
Charlie
