Deep Creek Center home.

Tag: project management

PM and ITIL

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?

Integrating ITIL with project management

One of the many issues facing organizations trying to get substantial traction with ITIL initiatives is the incorrect perception that ITIL is “for operations.” I can’t begin to count the number of developers and project managers who have openly asked in one of my Foundations classes “this isn’t for projects, right?” Well, yes, of course it’s for projects, since projects are how we perform most activities in IT; design, development, service improvement projects, new service initiatives, and the list goes on.

In many cases, the ITIL community is firmly responsible for this misconception. Asked to describe their ITIL adoption and good practices, they inevitably point to Service Desks, Incident and Problem Management processes, and occasionally Change Management or a CMS tool implementation (often without an underlying CM process to drive its use or efficacy).

With ITIL v3, we have a chance to fundamentally reset everyone’s expectations of ITIL. We now acknowledge the whole Service Lifecycle, beginning with Strategy. It’s reasonably easy to see the parallels of the activities of Service Strategy and Service Portfolio Management with a PMO; look at business cases, assess ROI and VOI, and approve and charter projects. Likewise, Service Design and Transition provide clear processes and guidance for managing the tactical aspects of capturing functional, nonfunctional, and usability requirements (think utility and warranty), performing service and measurement design, developing or acquiring applications, infrastructure, and metrics management tools, coordinating testing and validation, and overseeing transition planning and execution and operations uptake. These are the fundamental parts of planning and executing any good IT project, and would look very familiar to a PMP. By the way, these models work brilliantly in agile development models as well as more traditional waterfall approaches (which don’t work, but that’s a different post).

The biggest risk we have for successful ITIL adoption is that very often senior IT management really has no idea what ITIL really is. They think in terms of the most basic Service Operation processes, the Service Desk function, or maybe Change Management, but generally have absolutely no idea how ITIL helps to bridge the yawning cultural chasm in many organizations between Development and Operations. When we teach that Management Commitment is a mandatory critical success factor for ITIL implementation, it begins with basic understanding and clarity of vision across the Service Lifecycle.