4 February 2008

Project Management and ITIL Release Management

PM Hut has an article on the difference between project management and ITIL release management.

The key difference seems to be that projects are finite and releases go on forever. Apart from that good system management shares a lot with project management.

Early this decade I spent some time as a systems analyst. The team I was in managed escalated service issues, releases and administration processes such as the budget and user access.

It was an interesting and high performing team and I learned quite a bit about good system management processes from them. The team approached the management of ther systems in a very planned and structured way that left space to deal with crises when they came up.

Principles from project management were applied to everything they did. Let me run through a few examples;

  • Releases were planned many months in advance, withy resources and funds allocated and work prioritised.
  • Stakeholders were engaged and planned changes were communicated broadly. The communicatons were planned and monitorred.
  • Risks and issues were actively managed.
  • The potential benefits were carefully assessed before budgets were allocated.
  • Changes to business requirements (ie enhancements) were managed in a controlled fashion.

Additionally, individual releases can be 'project managed' even to the stage of benefits realisation. The two frameworks go together well.

Do any ITIL practitioners have a view on this?


    1. Well, ITIL and PM are the two favorite subjects over here, and the concepts are starting to become more and more compatible.

      What prevented us from getting to this conclusion was the fact that in Brazil we are facing ITIL as a way out from the support crises we face.

      If we think in terms of service support and service delivery, we are using service support as a contour solution and will really treat the problem (service delivery) later.

      This way of thinking makes us tend to think about release management only when it involves a change to correct an error, and the systems improvements are being treated separated using whatever method we prefer.

      According to ITIL, a change is a change and only one can have access to the CMDB, but it will take some time to make everybody agree.

    2. Anonymous8:35 am

      That's kind of like analyzing the difference between PM and QA - you can't - they're apples to oranges.

    3. Project Management is about Build, Release Management is about Delivery. PMs should be in control of resources required to build a solution, but Release Management manages the infrastructure (environments) and deployment processes that guarantee repeatable, no-risk delivery of the solution's artefacts into a run-time environment (QA, UAT, LIVE etc...). Release Management audits the change history of Release-Unit Builds (Packages of functionally related components) just as Software Config. Mgt. manages the version history of source-files. It then audits the environment content in terms of Release-Units deployed, and declares the overall Build for the Release under development (Eg. M3.5.1_build#11 - which is a consolidation of the various Release-Unit builds comprising the delivery).

      Further to this, Release Management is integrated into Service Management, and issues a Forward Schedule of Releases (showing which Service-Applications are changing and when), and Release Notices for individual Releases that manifest the Business Content (RFCs, Incidents, Back-log defects and Project Outputs), and the Technical Content (Release Units), as well as knowledge transfer (updates for Known Problems and Workarounds), Release highlights, Delivery Timelines, outages, service-degradation etc...

      Projects are only one way a service can change, BAU fixes (incidents), Emergency Incidents, Back-log defects can all be delivered effectively via Release Management and its supporting infrastructure of code-streams, environments and deployment resources.

    4. Thanks for sharing that Dave.