There are few areas of IT that generate as much confusion as change management. Most IT organisations today have a plethora of tools with many different IT domains that are misidentified as change management tools. Getting it right requires a serious commitment to the creation of an enterprise wide change management process. Unfortunately, many IT organisations have immature processes and policies in place, according to Gartner analyst, Kris Brittain.
This is often due to a lack of clear metrics. Brittain said metrics are needed to provide a baseline for a process, determine the effect of process improvements, identify areas where the process may be ineffectual or broken and assess and prioritise improvements that could make the process more effective or efficient. However, it is important to understand how documented and reported metrics will be leveraged from a management perspective.
Brittain said senior management need to communicate and evaluate how change management metrics map critical success factors (CSFs) and key performance indicators (KPIs).
“It is essential for these metrics to be linked to business goals and objectives and serve as a definition of success,” he said. “Too often organisations rush to a variety of metrics without linking them to overall goals and CSFs. There is an old adage – if it is not measured and monitored then it is not managed.”
To help IT organisations find true meaning in change management strategies, Computerworld has created this special feature. It outlines strategies to refine Information Technology Infrastructure Library (ITIL) change management definitions and turn them into a practical policy that can be automated via a tool.This includes best-practice guidelines for IT change management metrics as well as how to identify the right change management tool for your organisation.
Gartner recommends three key steps for best practice metrics. The first is to establish and track metrics that align with business strategy and ITCM process policy goals. The second is to be ready to change KPIs and metrics as business needs evolve and the ITCM process matures. Finally, communicate and publish results of ITCM initiatives throughout the IT organisation on a consistent basis.
Brittain said metrics used in the ITCM policy guide need to be defined. Following, are some of the more common change metrics tracked by IT organisations.
Percentage requests for change (RFCs) of emergency– Obviously, the definition of emergency can influence this measurement but generally it refers to a change request to repair a failure or imminent failure. Typically, this is an incident that affects production and can cause outages or significant degradation in the business.
Brittain said in most cases this request is executed with limited documentation and is outside the standard change schedule time. “Throughout the industry this metric appears to be by far the one that is most tracked,” he said. “Although reducing emergency change activity is important, the remaining metrics combined offer the richest understanding of ITCM performance.”
Percentage of successful, failed and rejected RFCs – The definition of this isn’t always straight forward. For example, failed could mean that change resulted in a service outage or didn’t deliver to RFC specifications. Gartner said organisations should develop this definition with an understanding that it may shift in time, as the change maturity improves.
Percentage of compliant/authorised and noncompliant/unauthorised RFCs – This metric is focused on whether an individual change adhered to process policy procedures. RFC activity would be defined as compliant based on a variety of process policy classifications, categories and types. If a change was executed outside the defined change process procedure then it would be unauthorised or noncompliant. Gartner said this metric is useful for regulatory requirements, as well as general ITCM policy adherence.
Number of RFCs – This metric is the basic capture of RFCs that have completed the RFC life cycle over a given period. Typically, change managers track this on a monthly basis.
Percentage of changes discussed at the CAB (change advisory board) – The CAB is a cross-functional group set up to evaluate change requests for business needs, priorities, cost/benefits and potential effects to other systems or processes. Typically, the CAB will make recommendations for implementation, further analysis, deferment or cancellation.
Percentage of changes grouped into releases – This is an emerging measurement attracting a lot of interest as more IT organisations develop standardised release management procedures. A portion of change activity – once evaluated – will be handed off to address build, test and deploy governance. This metric is looking for the ability to coordinate changes into a given release, and to reduce the need for more releases.
Selecting the right change management tool
The best strategy for successful tool acquisition is to document the ITCM process and policy. A well-developed process and strong policy will provide the foundation for tool selection requirements. Brittain said organisations should leverage their documented change workflow to illuminate critical tool functional requirements and integration points. “Prior to submitting an RFP, the IT organisation should test the policy and workflow documentation in a manual setting to confirm the viability of the process and policy to be used as functional requirements for tool selection,” he said. “Emphasise the reporting capability. Most organisations pay little attention to this in the RFP analysis, only to find the reporting tool inadequate once they’re into production.”
The adoption of a single corporate change management process policy demands investment in a tool that manages the governance for all IT change activity in the IT production environment. “What is abundantly clear is that one tool won’t address all aspects of the change life cycle, so multiple tools are required,” Britain said.
An ITCM policy is designed to govern repeatable methods and procedures for efficient and effective handling of all changes to the IT production environment. Therefore, tool functionality governs documentation, review, approval, coordination, scheduling, monitoring and reporting of requests for change. Change activity should be automated, therefore, the tool must have proven integration capabilities.
Out of the box, Brittain said the ITCM module should have an established integration with the vendor’s IT service desk. “More advanced integrations are required for global enterprises managing complex environments,” he said. “Early advancements in the automation of change have begun to materialise via integration hooks between ITCM tools and virtualization management tools, providing the ability to automate auditable and documented implementations of a virtual state.”