Understanding Effective Change Management

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.