I have been thinking about Carol’s and IT Skeptic’s comments about PM (and have read the thread he pointed me to, and an awful lot more) and I still think this comes down to a simpler notion. We have a yawning, enormous gap in most IT organizations between Design and Operations, in many cases cast in stone through outsourcing deals to different entities with no aligned targets or shared accountability. This creates the hot potato issue with which so many of us are familiar, and which really drives my interest in service transition, and particularly in placing Early Life Support (ELS) firmly in the hands of Release and Deployment Management. It is in fact the job of PM to manage the SUCCESSFUL transition of their project deliverables (which we’ll assume to be a new or changed service) into the live environment, and to support it until

1) The service is accepted by the customer AND
2) The service is meeting its designated service levels (this implies successful event mgmt, operational monitoring and reporting, and other operational readiness capabilities that really should be flushed out more as part of testing and validation activities).

Project Management (and Software Development Lifecycle Mgmt, but that’s another article) need to be able to coordinate service design and transition activities, and I would liken it to the approach ITIL takes with functions. PM necessarily coordinates across all the activities in service design and transition…based on the scope of their project. Process team leads perform activities across multiple projects in support of process goals and objectives (which should map to project goals around, for example, functional and non-functional (or warranty!) requirements).

The actual ITIL books don’t in fact describe exactly how to run projects (and rightfully leave this for the complementary guidance), but like a similar discussion currently on one of the LinkedIn threads about how ITIL leaves appropriate space for governance models (can anyone say CObIT), it really does so for PM as well, leaving flexibility needed to encompass large programs and small projects alike, while still providing a core set of building blocks needed to build a good service.

I’d like to hear from all of you…where do you see the big gaps, and what are your recommendations for addressing them? If you were writing ITIL 4.0, what would you add/remove/change to improve the efficacy of the guidance?