Evolutionary Change Management

The ITIL V3 framework describes processes to transition services from development to implementation and then ongoing support. Change management is a key function that helps to drive all of the other processes within service transition across the entire organization.

Changes can happen at the following levels:

1. Strategic changes (proactive)

2. Service changes (proactive/reactive)

3. Operational changes (reactive)

Change management is a dynamic process that will have to evolve with the changing needs of the business, the organizational size, and the project outcomes. In this article, I will try to address some of the key challenges that are faced in any organization today with regard to change management and some tactics that can be used for choosing the right strategies for overcoming these challenges. The main theme of this article is to stress the importance of keeping change management scalable and lean at every stage of the organizational improvement process.

The scope of this article is limited to service changes and operational changes. Viewed from this perspective, a change can be defined as any modification made to service assets, including resources and capabilities. Resources and capabilities may be thought of as critical configuration items (CIs) of an organization. CIs are generally managed in a configuration management system (CMS). Therefore, by extension, a change is a modification to CIs and is tightly coupled with the CMS.

As the organization matures in terms of the number of CIs, the CMS will also grow proportionately in terms of both quantity and complexity.

At any stage in the organizational maturity process, service managers must evaluate the complexity of the CMS, the quantity and types of CIs, regulatory requirements (such as HIPAA, SOX, etc.), and the change models before any strategies are adopted for improvement. If the CI is not too complex and change processes are too verbose, then the change processes will overburden the system in terms of both cost and time. Similarly, if the CIs are complex and the change processes are inadequate, then there will be loopholes that can lead to undesirable impacts such as increased cost, poor quality, and lost time.

Simply put, it is important to achieve a balance between the change management process and the CI complexity while also ensuring that the processes adopted are scalable in the future. It is also important to choose the right kinds of CMS and change tools depending on the complexity of the project.

I will discuss a couple of tradeoffs change management teams usually face and suggest solutions for tackling these tradeoffs.

Complexity of CIs Versus Complexity of the Change Management Process

There is a “chicken-or-the-egg” problem when it comes to whether you should decide the scope of change management and then strategize the CI identification process to be recorded in the CMS, or decide the scope of the CI identification and then strategize the change management process.

One way to solve this puzzle is to compare the complexity of CIs and the complexity of changes to decide on an appropriate strategy. In the following example, the size of CIs have been categorized into small and large. 

For example, take a look at the third row above. Regardless of the size of the organization, what really matters is the complexity of the CI. If there are only a couple of servers and printers in an organization, it is fair enough to categorize the complexity of CI as simple. Because there are limited servers, any changes to these servers can have a major impact on the business. For instance, a downtime of twenty-four hours making any changes to the server configuration will result in countless dollars of lost business value. In this case, it is fair to categorize the complexity of change as complex. And let us assume that the CMS in this organization is still immature. Given these parameters, the best strategy to adopt at this point in time is to decide on a change management process and then decide the CI complexity. So, we might decide that strict controls and authorizations are required even if it is a minor configuration change. Based on this, we might track the CI metadata appropriately. At a later point, if we add hundreds of servers to the same organization, then change complexity will become simple and CI complexity will become complex. We might consider the option in the seventh row to decide a strategy for CI complexity and then tweak the change management process accordingly.

Size of an Organization Versus Maturity of the CMS

The maturity of a CMS plays an important role in the adoption of change models. It isn’t necessarily true that if an organization is large, then their CMS is mature. Similarly, it’s also possible that a very small company may have a highly advanced CMS. The table below displays the different possible scenarios and the change strategy to adopt.

If the CMS of an organization is mature and up to date, then changes can be controlled more easily by adopting lean models. But if the CMS isn’t mature, then we may have to adopt complex change models to overcome the limitations of the CMS.

Therefore, the complexity of change model is inversely proportional to the maturity of the CMS.

In general, if the CMS is not yet implemented or isn’t mature, it is beneficial to adopt stricter or advanced change models. As the CMS matures, the change models can be made more lean over a period of time.

For example: If an organization hasn’t yet invested in a configuration management database or the database isn’t mature, then it would be beneficial to adopt tools such as spreadsheets or templates for controlling any changes. Once the CMS matures, the change models can become lean as a result of decreased micromanagement of the change process.

Size of an Organization Versus Regulatory Requirements

Investments in a configuration management database and change management tools are directly proportionate to the regulatory requirements of the business. A small startup might be an IT auditing firm that needs to abide by the SOX guidelines. Similarly, a large organization may not have any regulatory requirements. Therefore, the management team must be careful when choosing the right investment.

The table below displays different scenarios:

It has been my experience that commercial tools provide better features, especially when there are regulatory requirements that are best met with tools that have both good security and compliance features.

Incidents Versus Complexity of the Change Management Process

Incidents that are attributable to changes are an important key performance indicator, which is used to evaluate the quality of the change management process. Generally, the number of production incidents attributable to changes is directly proportional to the complexity of the change management process.

Because operational changes are reactive in nature, the complexity of the change management process should be decided based on the number of production incidents, as shown below:

A Hybrid Approach

In many organizations, a hybrid approach might be suitable, wherein a mix of the above strategies can be adopted for better payoffs. For instance, a company might have four business units out of which one may have to comply with regulatory requirements. In this case, a mix of open source and proprietary tools can be adopted.

Conclusion

In my opinion, adopting an evolutionary approach to change management will result in better results in terms of cost, quality, and time. Implementing change management as described in the ITIL V3 framework with the right balance of strong processes will help your organization achieve success.