The economy is in the doldrums, budgets are shrinking and management wants more accomplished. Not a good job-security recipe to say the least. In the middle of this quagmire there are still some fundamental principles that hold true. The change management process is critical at this time, more than ever, because studies have shown that 78%-80% of network availability problems stem from human error.

Whether you dispute the exact figure, we know that a large percentage of the incidents that IT must address could have been avoided with better planning and communication both within and between IT teams as well as with the business. These errors give risk to unplanned work that is typically urgent and comes at the expense of planned work, chiefly projects. In these lean times we can’t afford to be doing unnecessary work.

The goal of change management is to balance the risks of making a given change against the risks of not making that change. To put it another way, the change management process is about the risk of a change resulting in a bad outcome weighed against potential harm to the business from not making the change. This risk management can be very challenging to say the least.

Essentially, the change management process involves the management of a request for change (RFC) through review, impact assessment, planning, implementation and then post implementation review.

To clarify, let’s analyze each of these steps:

The review of RFCs by a formally appointed change manager allows for the much needed filtering and prioritization of changes. IT organizations are suffering from limited resources and decisions need to be made about what should, or should not, be done and when. Part of the filtering is based on an understanding of the potential impacts of a RFC—both good and bad. The importance of the services must also be understood and can be assessed by interviewing the business, reviewing formal business impact analyses, and so forth.

Also important is to understand the relationships between various configuration items (hardware, software, documentation, people, etc.) that are associated with a change. This data can be drawn from the configuration management database (CMDB), what ITIL v3 terms the “Configuration Management System” (CMS).

These relationships help the change manager understand any dependencies that may exist and help with assessing impact to the business. All too often changes are made and connecting systems crash because the group doing the change didn’t know that certain dependencies existed.

Assuming the RFC is approved to proceed and not outright rejected, the next step for the change manager is to select the appropriate workflow based on impacts and urgency. A given change management workflow is known as a “change model”. If there is low risk then a relatively light model known as the “standard change model” can be used wherein the change is essentially just recorded. This is important because people must always be able to quickly answer the question, “What changed?”

As the potential level of impact increases, so does the level of management and scrutiny in each change model. As mentioned, a standard change may just require recording whereas a more substantial change may require the assemblage of a team, the use of specific application development techniques, various testing protocols, review with the business at each phase, etc. What is in each model is something an organization needs to define.

The ITIL books identify five models: standard, minor, significant, major and emergency. In theory, the intent is to best match the combination of IT service, urgency and impact to the right model. An organization can have as many models as needed to trade off flexibility and risk management. However, if there are too many models and the selection of the right model is confusing then that defeats the purpose and can lead to errors, audit findings, etc.

The economy is in the doldrums, budgets are shrinking and management wants more accomplished. Not a good job-security recipe to say the least. In the middle of this quagmire there are still some fundamental principles that hold true. The change management process is critical at this time, more than ever, because studies have shown that 78%-80% of network availability problems stem from human error.

Whether you dispute the exact figure, we know that a large percentage of the incidents that IT must address could have been avoided with better planning and communication both within and between IT teams as well as with the business. These errors give risk to unplanned work that is typically urgent and comes at the expense of planned work, chiefly projects. In these lean times we can’t afford to be doing unnecessary work.

The goal of change management is to balance the risks of making a given change against the risks of not making that change. To put it another way, the change management process is about the risk of a change resulting in a bad outcome weighed against potential harm to the business from not making the change. This risk management can be very challenging to say the least.

Essentially, the change management process involves the management of a request for change (RFC) through review, impact assessment, planning, implementation and then post implementation review.

To clarify, let’s analyze each of these steps:

The review of RFCs by a formally appointed change manager allows for the much needed filtering and prioritization of changes. IT organizations are suffering from limited resources and decisions need to be made about what should, or should not, be done and when. Part of the filtering is based on an understanding of the potential impacts of a RFC—both good and bad. The importance of the services must also be understood and can be assessed by interviewing the business, reviewing formal business impact analyses, and so forth.

Also important is to understand the relationships between various configuration items (hardware, software, documentation, people, etc.) that are associated with a change. This data can be drawn from the configuration management database (CMDB), what ITIL v3 terms the “Configuration Management System” (CMS).

These relationships help the change manager understand any dependencies that may exist and help with assessing impact to the business. All too often changes are made and connecting systems crash because the group doing the change didn’t know that certain dependencies existed.

Assuming the RFC is approved to proceed and not outright rejected, the next step for the change manager is to select the appropriate workflow based on impacts and urgency. A given change management workflow is known as a “change model”. If there is low risk then a relatively light model known as the “standard change model” can be used wherein the change is essentially just recorded. This is important because people must always be able to quickly answer the question, “What changed?”

As the potential level of impact increases, so does the level of management and scrutiny in each change model. As mentioned, a standard change may just require recording whereas a more substantial change may require the assemblage of a team, the use of specific application development techniques, various testing protocols, review with the business at each phase, etc. What is in each model is something an organization needs to define.

The ITIL books identify five models: standard, minor, significant, major and emergency. In theory, the intent is to best match the combination of IT service, urgency and impact to the right model. An organization can have as many models as needed to trade off flexibility and risk management. However, if there are too many models and the selection of the right model is confusing then that defeats the purpose and can lead to errors, audit findings, etc.

The economy is in the doldrums, budgets are shrinking and management wants more accomplished. Not a good job-security recipe to say the least. In the middle of this quagmire there are still some fundamental principles that hold true. The change management process is critical at this time, more than ever, because studies have shown that 78%-80% of network availability problems stem from human error.

Whether you dispute the exact figure, we know that a large percentage of the incidents that IT must address could have been avoided with better planning and communication both within and between IT teams as well as with the business. These errors give risk to unplanned work that is typically urgent and comes at the expense of planned work, chiefly projects. In these lean times we can’t afford to be doing unnecessary work.

The goal of change management is to balance the risks of making a given change against the risks of not making that change. To put it another way, the change management process is about the risk of a change resulting in a bad outcome weighed against potential harm to the business from not making the change. This risk management can be very challenging to say the least.

Essentially, the change management process involves the management of a request for change (RFC) through review, impact assessment, planning, implementation and then post implementation review.

To clarify, let’s analyze each of these steps:

The review of RFCs by a formally appointed change manager allows for the much needed filtering and prioritization of changes. IT organizations are suffering from limited resources and decisions need to be made about what should, or should not, be done and when. Part of the filtering is based on an understanding of the potential impacts of a RFC—both good and bad. The importance of the services must also be understood and can be assessed by interviewing the business, reviewing formal business impact analyses, and so forth.

Also important is to understand the relationships between various configuration items (hardware, software, documentation, people, etc.) that are associated with a change. This data can be drawn from the configuration management database (CMDB), what ITIL v3 terms the “Configuration Management System” (CMS).

These relationships help the change manager understand any dependencies that may exist and help with assessing impact to the business. All too often changes are made and connecting systems crash because the group doing the change didn’t know that certain dependencies existed.

Assuming the RFC is approved to proceed and not outright rejected, the next step for the change manager is to select the appropriate workflow based on impacts and urgency. A given change management workflow is known as a “change model”. If there is low risk then a relatively light model known as the “standard change model” can be used wherein the change is essentially just recorded. This is important because people must always be able to quickly answer the question, “What changed?”

As the potential level of impact increases, so does the level of management and scrutiny in each change model. As mentioned, a standard change may just require recording whereas a more substantial change may require the assemblage of a team, the use of specific application development techniques, various testing protocols, review with the business at each phase, etc. What is in each model is something an organization needs to define.

The ITIL books identify five models: standard, minor, significant, major and emergency. In theory, the intent is to best match the combination of IT service, urgency and impact to the right model. An organization can have as many models as needed to trade off flexibility and risk management. However, if there are too many models and the selection of the right model is confusing then that defeats the purpose and can lead to errors, audit findings, etc.

Once a change is planned and is being built, its actual implementation needs to be scheduled. A confusing part of ITIL is the relationship between change and release and deployment management. Change is the governing risk management process. Release and deployment is concerned about the actual implementation.

ITIL v2, however, used to make it sound like the use of release was optional. The truth is that aspects of release were always used and the real question is, “What is the best method to get this change into production safely so that operational systems are not disrupted and the business can make best use of it?” Answering that question and following the release policy can help guide how best to deploy a change, or collection of changes.

Changes are reviewed at two points: immediately following when they were scheduled to be implemented and also after 90 days. The first review is operational in nature and serves to identify if the change went in as planned and to communicate such to the organization.

The second review is to determine if the change was ultimately successful or not and if it caused incidents or problems. If it caused the latter then the reasons need to be understood and steps taken to both correct any deficiencies in production systems as well as how changes are built in the future.

An effective and efficient change management process is critical today for organizations who must avoid needless work. Rather than work on incidents that arise from errors, we need resources working on what matters and change management can help make that a reality.

Additional Guidance

There are a number of resources available to help organizations design and implement a change management process:

• British Educational Communications and Technology Agency (BECTA) – Framework for ICT Technical Support (FITS)
  http://www.becta.org.uk/tsas/
• ITIL’s Service Transition Volume
  http://www.itil.co.uk/
• Microsoft Operations Framework v4.0
  http://www.microsoft.com/mof
• Pepperweed Process Model
  http://www.pepperweedprocessmodel.com/

George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.