Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the IT Galaxy and Beyond
Don't Panic



Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL® IT Governance and Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.


The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronym’s like ITIL, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."

Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams


Troy On Twitter

Recent Entries



Other Blogs


Tuesday, August 23, 2011

Practitioner Radio Episode 12 - Demand Management

Not Understanding and Managing Demand results in IT delivering services that do not meet business / customer needs!

Join Chris and I as we dive into Demand Management and discuss how it is the Front Door of Value Generation.

Practitioner Radio Episode 12 - Demand Management from ServiceSphere on Vimeo.

Show Notes:

  • Demand Quote: Al Capone: I am like any other man, all I do is supply a demand
  • All providers have to manage demand and supply
  • Service Desk: Erlang Calculators / Managing Service Desk Demand
  • Predicted Demand / Non Predicted Demand (History vs Transactional demand)
  • Demand Mgmt requires constant monitoring
  • Prince2 & PMBOK & Demand
  • Project Management vs Portfolio Management (Service / Project)
  • Demand feeds Portfolio Management
  • Merger’s & Acquisitions and Demand Management
  • The role of Architecture in Demand Management
  • The role of Business Relationship Mangers Role and Demand Management
  • Demand Management integrations with the Service Life Cycle
  • The Service Catalog and Demand Management
  • Normalizing Custom Services from SLA’s into the Service Catalog (shaping demand)
  • Shaping Demand (Service Desk & Hosting Examples)
  • Demand influences through price
  • Show Back versus Charge Back (tool for moderating demand)
  • Demand Management Tenants: (Receive, understand, predict) & (influence, shape)
  • Three Types of SLA’s (Historic, Expected, Psychological)
  • Quantified Self – Using Technology to monitor yourself
  • Demand Management & 1st line Support
  • 4 Entry points in ITIL for Demand Management
  • Is A Password a Service Request or Incident?

Thunder Bolt Tip: IT like any service provider is responsible for planning and managing their supply based on demand. Demand Management is in part about receiving and influencing demand based on their clients best interests not their own.

Troy’s & Chris’s Thoughts What Are Yours?

“Ability will never catch up for the demand for it” ~Confucius

To subscribe to Pink’s Podcasts on iTunes


(0) Comments
Posted by Troy DuMoulin on 08/23 at 03:45 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Monday, August 15, 2011

The Primary Roles of Release & Deployment Management

Knowing Who The Actors Are Makes The Storyline Easier To Follow

The primary objective of IT as a trusted service provider and business partner is to manage and optimize the Value Chain of Demand -> Plan -> Build -> Run.

For the most part we understand and execute the various stand alone aspects of this value chain with some degree of success. However it is in the hand-offs between these primary phases that many of our current challenges occurs. For example:

  • Not understanding Demand causes IT to deliver services that do not meet business needs
  • Having limited to no input from Demand into Plan is a recipe for not getting the service design specifications correct
  • Not understanding the Plan or design specifications causes confusion in the identification of acceptance criteria for the build, testing and promote to production tasks
  • Having non-aligned, poorly designed, insufficiently tested and ill coordinated service elements being introduced to the Run / Production environment gives everyone a massive headache

Sound Familiar?

Since we cannot boil the ocean tackling all of our challenges at once this article will focus on the hand off from Build to Run. The ITIL Framework has a full set of processes that help manage Service Transition however from a practical aspect I want to focus this article on Release & Deployment Management with its Primary integration to Change Management.

To set the stage for this discussion the following steps represent the primary steps of the Release & Deployment process flow.

  1. (Change Mgmt.) Conceptual Approval to build, buy or lease based on the approved design requirements
  2. (Release & Deploy) Plan for the release by establishing the right level of “People, Process, Product, Partner and Performance” requirements and production acceptance criteria
  3. (Release & Deploy) Build the Release guided by the Design & Plan requirements
  4. (Release & Deploy) Test that the Release meets the expected Design & Plan requirements
  5. (Change Mgmt.) Based on Release’s attestation that all production acceptance criteria have been met Approve the promotion to production
  6. (Release & Deploy) Deploy the release based on the agreed schedule coordinated by Change Mgmt.
  7. (Change Mgmt.) & (Release & Deploy) Review & Close if successful

Disclaimer: Now before you get worked up about this not being entirely accurate to ITIL remember this is simple high level conceptual flow of steps that we need to establish before we start talking about the roles in Release and Change Management. Also many of you may argue that Change only comes into play on the “Approval to Promote”. My answer to that is what you are talking about is only Change Control not full Change Management and that in practice not theory your Conceptual Change Approvals may occur in different processes (Project Mgmt. / Software Development / Supplier Sourcing) but are still part of your overall “Change Mgmt. System” (for more information on these subjects see the following articles)

ITIL Implementation Roadmap (Change Management) – Part 4
Change Management from Havoc to Control - Forward Schedule of Change

Finally the two Enablers to Make Release & Deployment work before we speak about resources are:

  1. A documented and agreed set of processes, policies and clear description of roles and their responsibilities to overcome the issue of opinion and perception (its not shared truth until its written down and agreed to by all parties)
  2. A set of production acceptance criteria and deliverables that have been pre-identified by the various interested stakeholder groups that are grouped by release type and each step in the Release & Deployment Process

ITIL 2011e New Addition Promo: Take a look at the new 2011 edition of the ITIL Service Transition book for a good list of release acceptance criteria by process phase. The author’s did a nice job of augmenting the guidance around this process and of providing a good shopping list of production acceptance criteria for your consideration.

Note: For more information on these two topics check out the following articles & Podcasts:

ITIL Implementation Roadmap (Release Management) – Part 8—Keeping It From Blowing Up On Landing
Practitioner Radio Episode 5 - Release and Deployment

Release & Deployment Roles

Troy’s Personal View: Release and Deploy are two separate phases of the Release lifecycle with very different objectives. Release is concerned that a release conforms to and completes an agreed set of pre-production requirements to ensure that the Release meets the design requirements and is ready to be moved into production in a manner that will not disrupt current service delivery in an non expected manner. Deployment is focused on the packaging and move of the release into the production environment based on the instructions and requirements pre-defined by the release plan.

So with these assumptions in mind lets consider the following roles: (Not Necessarily As Described By ITIL)

The Release Builder: This is the term that I like to use for the folks in IT that actually do all the Plan and Build activities of a release. This could be a Network administrator introducing a new switch, an application developer coding a new piece of software, a server admin provisioning a new physical or virtual server and even a Project Manager who is in a sense a Macro builder coordinating the activities of many others. It is the Release Builder or a group of them that are actually doing all the work in various streams of pre-production type technical processes triggered by customer demand. The Release Builder is and always has been the role that does the lion’s share of work. Release Management is focused on ensuring that the various builders from different internal and external groups follow a set of pre-determined Release activities. Who does the Deploy tasks however is often a question each organization must consider. In some cases this could be done by the Release Builder, in others due to a legal requirement to ensure “Separation of Duties” the people developing the release cannot be the same folks that deploy it into production.

The Release Manager/Coordinator: Since releases can and do originate from many different groups both internal and external to your organization it is important that each pre-production group wishing to introduce a release into the production environment follow the same process, policies and guidelines for Planning, Building and Testing a release. The role of the Release Manager is to work with the Release Builder in determining what level of Risk and Complexity the release represents and then to communicate to the Release Builder what the Release Acceptance requirements and deliverables are for each stage of the release. These requirements are then executed and performed by the Release Builder and validated by the Release Manager. So in summary the Release Manager is a governance or quality oversight role that ensures that the right level or due diligence & requirements are applied to each release based on an accepted process and a proactively developed set of acceptance criteria that are applied based on the release risk and complexity.

The Release Tester: While the release is Planned and Built by the Release Builder it is good practice to have the testing done by a separate role from the builder due to the obvious conflict of interest. ITIL rightly separates Testing & Validation as a separate process that can potentially be part of each of the Release process phases. However, for the sake of this article we will focus on the Test phase following Build. The Release Manager will work with the Release Tester in much the same way as they do with the builder in that they will ensure and validate that the right level of testing is done based on the pre-defined testing requirements for the release prior to its promotion to production. The functional role of the Release Tester can often be found in various parts of an organization. Sometimes testing is done by a dedicated testing or quality assurance group. At other times the testing role is given to another function such as a production support group or another non involved developer. The primary consideration is that the tester be separate and distinct from the builder.

The Change Manager / Change Advisory Board (CAB): Following the completion of the Testing tasks the Release moves forward to receive authorization by Change Management to be promoted / deployed to production. This is done according to the Change Approval requirements defined in that process by your organization. Major changes may required Executive Approval + CAB, Medium changes by a CAB and Minor by Change Manager. In the case of a Standard or Pre-Approved change it is assumed that the Standard Change process also has incorporated the required release assurance tasks. The role of Change Management is to approve and coordinate while the role of Release & Deployment is to assure and deploy. So picture a CAB meeting where a certain change is being reviewed for approval to promote. The Change Manager / CAB will look to the Release Manager to attest to the fact that all Release Plan, Build, Test tasks have been completed by the builders and testers to the appropriate level predetermined by the Plan stage. In short Change is about approval/coordination and Release is about assure/deploy. Many organizations without a Release and Deployment process place all of this burden on Change Management and overwhelm the process with both goals way to late in the release cycle.

The Release Deployer: Following the approval by Change Management to promote the release to production someone actually has to carry our the deployment tasks and move the release to production. Who does the deployment tasks can vary based on service and technology domain. In some organizations there is a specific group that will schedule, bundled and deploy releases for major applications. In other cases the Release Builder may deploy the Switch or Server to production following the Change approval to promote. How and by whom Releases are Deployed into your production environment by both internal or external groups is a key decision and policy point that must be defined as part of your Release & Deployment Management process. In reality the Release Deployment roles will most likely follow several different approaches within the same organization.

Now that the cast has been defined and the stage is set for you to tackle Release & Deployment Management it is time to define who will take on each of these critical roles required to ensure production stability while introducing change.

Troy’s Thoughts What Are Yours?

“Out of intense complexities intense simplicities emerge.” ~Winston Churchill


(8) Comments
Posted by Troy DuMoulin on 08/15 at 12:46 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Page 1 of 1 pages