Killing CAB, Part 3: Change Models

In this third and final installment in the Killing CAB series, I’ll be talking about Change Models – perhaps the most widely overlooked method of streamlining IT Change Management.

It’s only a model

(If you landed here, consider going to the first article in the Killing CAB series.)

Many IT people hate ‘traditional IT Change Management’ because so much of what we do is done again and again. We deploy applications, patch PCs, and adjust server capacity. We do these things all the time, and yet we treat them as normal changes because they carry risk. 

To make matters worse, it never ceases to amaze me how many different methods companies have for performing very similar changes in daily operation. In reality, CAB must review such RFCs simply because the approach needs to be validated to ensure outcomes are achieved, and risks are managed.

But, logically, we all recognize the repetitive nature of these types of changes, but fail to see the risk presented by the lack of standardized approaches.

They can’t really be standard changes, because the particulars are different and have different tolerance for risk. Adding a network switch in the customer-facing data center versus in a largely unoccupied sales office, for instance. While the activity is basically the same, the risk level and concerns are very different.

Change models are an approach to these repetitive-but-unique types of change. They take into account how the same activity in different situations may require different handling. The model itself brings these kinds of differences to light, and ensure each is handled according to the approved plan.

Change models streamline changes that are common but don’t meet the criteria for standard change (usually because they’re either not performed frequently or they involve higher risk).

Change Models in action?

Consider change models for changes like:

• Application deployments, especially where automated
• Deploying monthly PC patches
• Service requests that are not routine, like
  • Access requests to critical infrastructure components
  • Firewall policy changes
• Regular system maintenance like
  • Balancing server loads
  • Storage capacity upgrades
  • Installing new wireless access points

In simple terms, change models are a generic, pre-defined procedure. Once approved by CAB, requestors simply plug in the particulars of their situation, components and parameters.

The model should include:

• Process steps for completing the change
• How to identify and address varying risk levels
• How to identify and notify impacted customers.
• How to identify and engage stakeholders in business impact assessment?
• Generic roles and responsibilities, including
  • Who will perform which parts of the change
  • What change authority approves the change
• Time frame for change implementation, including rollback checkpoints
• Escalation process in the event things do not go as planned

A model citizen

Let’s say that your organization occasionally adds new Wireless Access Points to your wireless network. This is a classic candidate for a change model! Each follows the same basic process, but the customers, physical location, network address space and configuration parameters are unique for each change.

The models helps identify situations (customer segments, business processes) that have specific schedules, risks, or or circumstances that require special handling.) They should take into account weekly/monthly/seasonal business patterns. (I.e. no changes in the Accounting department during month end close.)

The change model ensures a consistent approach is followed and that all risk and customer impact are addressed.

A properly constructed change models will significantly reduce operational risk by using a tried-and-true approach that’s been vetted for risk and has a proven record of success in practice.

In practice

In day to day operation, change models become standard operating practice for defined types of changes. IT staff use the model to identify key parameters of the change being considered, and follow the steps for execution.

With a solid track record of using the model, CAB and the Change Manager will have data to evaluate the ongoing success and effectiveness of risk mitigation. CAB can then give change-modeled RFCs greatly reduced review, focusing primarily on the scheduling and logistics issues, and not so much on the inherent risks of the change itself.

As appropriate, combine change models with delegated change authority to further reduce changes coming to CAB, while maintaining predictable levels of risk management and business outcome realization.

Remember, the goal of change management is the outcomes it produces, not following a rigid process. Change models can improve change execution while reducing bureaucracy and undue process. If you’re not using change models, why not give them a try. Your IT staff will welcome the reduced process, and your customers will appreciate the speed and precision they bring to change implementation.