Archive for the ‘ Change Management ’ Category


Keeping on-schedule with IT Change Management Metrics

Written by admin
November 24th, 2009

There are several Change Management Metrics that can evaluate if the registered change is on-schedule and all of the approvals have been recorded in time for the change to start. Often the best practice for managing the Change Management Process in accordance to ITIL is to maintain a set of metric based reports that the IT Change Owners and Change Managers can easily retrieve using a self-service portal or tool.

Here are several metrics that may assist your organization in building better insight as to if the Change Management Process is moving the change request through smoothly and if there are any bottlenecks along the way.

Change Management Backlog

Pending Action

This measurement is to determine how many changes are pending an action either by the Change Owner, Change Manager, Approving Authority, Business Owner, Customer, or anyone else associated with the Change Request.

Pending Action Calculation: ($current_date – $last_activity_date) > $max_target_days

A suggested $max_target_days should be between 3 to 5 days. An activity could be as simple as updating the Change Request of if the Change is still on schedule.

Pending Approval

Similar to Pending Action, it is a good practice to have a separate metric that notes how many change requests are still pending approval authority before they can continue.

Pending Approval Calculation: ($approved)=false and $status NOT in {“Rejected” | “Cancelled” | “Closed”}

Alternatively a good metric to use is to also have a departmental based report that each department can run to see if they have change requests awaiting approval from their department.

Pending Approval by Department Calculation: ($approved)=false and $status NOT in {“Rejected” | “Cancelled” | “Closed”} and #department isin $current_pending_approval_groups

Change Management Schedule

Changes Scheduled for Implementation this Week

Most organizations try to schedule a weekly meeting to discuss the IT Changes that will be implemented during the current week. This meeting allows for the Change Managers and Change Owners to come together and formally inform each other of the impact and status for each change. This calculation can be used in preparation for the meeting and/or to build a calendar for business and IT users to stay informed.

Scheduled Changes in Current Week (Assumes 7 day week): $current_date + ’7′ > $implementation_date

This second calculation could be use if the department only works a 5 day work week. You would assume that $day_of_week is the day that that work week begins (i.e. Monday = 1, Tuesday = 2, etc)

Scheduled Changes in Current Week (Assumes 5 day work week): $current_date + (’5′ – $day_of_week) > $implementation_date

Hopefully these simple metrics can help you uncover a few bottlenecks in your organization’s change management process. Remember, using metrics based on ITIL concepts are built on a guidline but do not always represent the best way to report progress in your IT organization. Each metric would need to take into account the capability, capacity, and maturity of the Change Management Process at the organization.

The Purpose of Change Management

Written by admin
November 24th, 2009

The purpose of Change Management is to ensure that all methods and processes are standardized across the Information Technology Enterprise.  Utimately through using Change Management, an organization and establish a controlled environment to record, evaluate, authorize, prioritize, plan, test, implement, document, and review changes to the IT Infrastructure.

There are two main goals of change management:

  1. Respond to the business’ goal of reducing downtime while increasing productivity
  2. Respond to IT Requests that will better align the services of IT and the needs of the business

A change can arise because it is a proactive or a reactive measure.  A proactive change is making a change to benefit the business.  This could be deploying a new application, upgrading an operating system, or an enhancement to an existing IT Service.  A reactive change is a change that is used as a means to resolve an error.  This could be a change such as restarting a server, applying a software patch, or replacing a failed hard disk.

The Change Management Process is often managed by a Change Manager and approval for changes are authorized by a Change Advisory Board (CAB).  The size and personnel needed to manage the Change Management process is often scalable and dictated by the size of the organization.  Typically the process is centralized, however, often smaller organization will have a change management process that is informal.  An informal process would be like one that sends a simple email to several other employees and/or is notes jotted down in a notebook.

IT Change Management Example:

Your Web Application Department is part of an IT Division that oversees a Judiciary Branch for a major metropolian city.  The goal of your organization is to keep the Judiciary Branch’s website operational for the public as well as internal intranet users.  At times you will need to restart the Web server to add memory or to add hard disk space as more users use the website.  Change Management can help control who and when a modification is made to that server.  If you use a controlled change management process, the system administration will have to notify all of the business users and IT support staff when they move the server offline.  The Change Management process would also require there to be a paper trail of documentation for what modification was made to the server as well as who made the modifications.  Change Management can really assist even a department from costly unplanned downtime and unavailablity of the servers.