Overview

Change management can be a powerful way of maximizing the number of changes an organization can safely deploy or a bureaucratic nightmare. In the years during which service management frameworks have gained mainstream adoption, the tools used to manage and assess changes, along with automated deployment tools have grown tremendously, with the capability to make change management even better. With all of this in play, it’s possible to bring innovation to how change management is performed, using automation and decisioning tools to lower risk while speeding up the ability to authorize a deployment: making it more agile. This approach looks at how to combine tools and adjust processes to streamline change, right-sizing it based on risk. The end state of the journey is replacing the weekly Change Advisory Board (CAB) meeting with virtual approvals and daily stand up meetings, removing the need for expedited changes to approve work that falls in between meetings and bringing agility to the process. This approach also works well in DevOps environments, by respecting the level of automation they bring to change deployments and right-sizing the process to support the approach.

Change today

Ask any Change Manager who runs a robust change management practice and they’ll tell you their process, and the bureaucracy that comes along with it are all a necessary part of managing the risk associated with deploying changes in the production environment. They’ll likely quote the ITIL books and prove out the reason for all of the hoops the process has people jump through. The truth is, the books don’t say make it hard for people to deploy changes. They do say that changes should be properly authorized (at an appropriate level for the change being made), there should be good communication during the entire service transition process and that risk should be minimized or at worst, understood and communicated. So, where did change go wrong?

It’s the “quick fix” mentality that has turned change management into a highly bureaucratic, rigid process. Many organizations still work in silos, wait until it’s time to deploy a change to communicate about it and do a poor job of planning deployments in advance. The result is an effort to ensure success at the last minute: right before a change is deployed. The hero culture then swoops in, doing their superhero best to ensure none of the planned changes take down critical services. The result is a highly attended weekly meeting where people brainstorm and put their knowledge to use to validate the likelihood each proposed change can be deployed successfully. 
None of this is really necessary or even advised.

The objective of change management is to enable changes to be made in support of business objectives while minimizing risk. Or, said in another way: meet the changing needs of the business while minimizing the effect of unintended consequences. In today’s world, this means the pace needs to be quick, the process needs to be agile and risk still needs to be minimized. 

The good news is that changes in technology make this easier than ever before:

With all this in place, why are we still managing change the way we did ten years ago? Mainly because we think we’re successful because we’re able to executive changes without downtime (most of the time) and our measures bear this out. The part that’s not measured is the delay in executing change and slowing down the ability to deploy along with the impact on the business.

This guide provides an instructional innovating change management, providing a conceptual approach to agile change management and providing ten basic steps to achieve it. To build the foundation for this, it’s important to understand the critical success factors for planning and deploying changes.

Critical Success Factors for Change Management

Understanding the scale of the change and right-sizing the process

For change management to be successful, the first key concept to consider is that IT should only be making changes that are needed to support business initiatives. Yes, there are some housekeeping changes that need to be performed: applying patches to operating systems, securing the enterprise against known security vulnerabilities, replacing end-of-life equipment and the like. Beyond that, however, changes to services and applications should be driven by the business and approved by the business before they are built. So it’s clear that from the start there are several extremely different paths a change might take:

For change management to work, therefore, the organization needs to understand the differences and build appropriate change models to manage all of them. Each of these needs to “right-sized” to the situation and have the proper approving authorities. The Change Advisory Board should be structured to manage all of them while bypassing those that don’t require their review.

Communication and Planning

Most organizational change-management practitioners will tell you communications are essential to an effective change initiative. Organizational change-management communications can’t be done ad-hoc – they must be managed, and information must be given to the right people at the right time. Communicate incorrectly and the change initiative may be destined for failure. Change-management communications can’t just be one-way messaging from the organization’s leader or initiative sponsor and then broadcast throughout the organization. The organizational change-management plan will outline different groups of individuals and their communications needs. Often, how a change is communicated will have a greater impact on the success of the change than the design of the solution.

Regardless of the size of the change, any change that requires more than one team to execute (and that’s most of them) requires good cross-team communication and planning. This should start from the inception of the change, not when the change is ready to deploy. This helps ensure that when it comes time to deploy all of the required equipment is available and the capacity for the change is present at the resource level. The deployment process itself is also understood, with teams knowing their tasks and execution timing beforehand rather than at the last minute. This ensures all of the required resources are available when needed. For a high-risk change, it’s possible teams might want to do a dress rehearsal or two to ensure the change can be successfully deployed.

The longer this communication and planning is delayed, the more likely issues might occur that affect the deployment. Thus, the concept of bringing a change to a weekly CAB meeting for planning and deployment means waiting until the last minute to communicate and plan the effort and a higher likelihood of failure.
 
There are other critical aspects to planning a change, beyond its smooth deployment. Depending on the scale of a change, both the business and support teams need to be prepared.  For a new service, or even significant changes to an existing service, there may be training, and communications needed at the business level. This needs to be completed before the service is deployed to production, thus the reason for requiring business signoff for the readiness of the change. Here too, when a change is properly planned, the business testing and training needs are understood while the change is being built, so there is no delay when it’s time to deploy the change.

IT’s ability to support the change is just as important. Operations needs run-books and training in supporting the service and the Service Desk needs to be prepared to take calls and support users. If this does not occur until the final deployment, the overarching initiative is likely to run into operational concerns once the service is deployed, lowering the perceived value of the final solution.

Change Management "by the book"

When looking at the documentation for service management frameworks, particularly ITIL and ISO20000, there are three types of changes typically defined:

For each of these change types, approving authorities and models can be built to ensure they are right-sized based on risk and routine nature of the change. For example:

There are a few misinterpretations of the processes that have been adopted widely or are underutilized:

It's Change Management NOT Change Control

With all of this said, the purpose of change management is not to stop or control change. IT exists to support the business and change is critical to ensure the business remains competitive. The value of change management is speeding up the rate of change while lowering the amount of unanticipated downtime. The idea is to adopt a set of practices that enable the organization to appropriately manage change. This includes the authorization to make a change, management of risk associated with the build and deployment of the change, an assessment of organizational readiness for the change and then, the final ability to deploy successfully.

The truth about change management is that the earlier it begins, the more likely is it to deploy the change successfully! 

Change management is therefore about ensuring all changes are known, properly documented and managed, but there are several balances that must be achieved:

Stability and growth

The ability to continue to grow the organization’s services and capabilities must be balanced against the need to operate those services effectively

Bureaucracy and communication

Communication is a key component of good planning and successful execution of changes. Forcing it leads to bureaucracy, replacing communication with touchpoints, approvals and forced quality gates.

Management and controls

It is possible to meet the controls set forth with management rather than control. The process should account for ensuring all required documentation needed to meet controls is collected and available but should be agile enough to execute changes at a pace that supports business needs.

Four Pillars for Agile Change Management

There are four basic concepts (or pillars) that support an agile approach to change management, some of which require a cultural shift and a level of maturity that will need to be gained before achieving this approach:

Pillar 1: Early engagement:

change management really starts at the inception of a change request, when it comes from the business. Once it is chartered and resources are allocated to do the work associated with making the change, all appropriate technical parties should be engaged. This means development teams working with operational teams to ensure everything needed to build and deploy the change is available or procured in alignment with the effort.

Pillar 2: Planning:

planning the deployment of the change also needs to start early, as the build is nearing completion and being tested. This is when deployment resources should be arranged, and deployment planning should get underway. If dress rehearsals or deployment testing are needed for a large, high-risk change, they can happen while final UAT is underway. This way, when the change is ready to be scheduled for deployment, everyone involved is already on board.

Pillar 3: Virtualized CAB approvals

if appropriate personnel are engaged early and the deployment planned ahead of time, there is no reason CAB approval for the scheduled deployment cannot be gathered virtually, via automated approvals in the IT Service Management (ITSM) platform. In this model, the CAB would have chartered/approved the change to be made and all of the technical CAB members would be involved in early planning. Thus, any final CAB approvals needed could be gathered online, rather than wait for a formal CAB meeting.

Pillar 4: Short, daily CAB meetings (think scrum):

if appropriate personnel are engaged early and the deployment planned ahead of time, there is no reason CAB approval for the scheduled deployment cannot be gathered virtually, via automated approvals in the IT Service Management (ITSM) platform. In this model, the CAB would have chartered/approved the change to be made and all of the technical CAB members would be involved in early planning. Thus, any final CAB approvals needed could be gathered online, rather than wait for a formal CAB meeting.

with the three prior pillars in mind, the only changes that might need to be discussed in CAB meetings are exceptions:

With this in mind, it’s possible to hold a short scrum meeting daily to approve the changes that could not follow the virtual CAB process. The benefit of this is huge as it eliminates the bottleneck caused by a weekly meeting. Changes scheduled to deploy in the next 24-48 hours can be reviewed in just a few minutes. Over time, the number of changes addressed should continue to fall off and the CAB might meet for just a few minutes daily.

Change Management 4 pillars Change Management 4 pillars

Service management processes provide a foundation that supports the four pillars of change, which in turn enable an organization to achieve agile change management:

Service management processes found in Service Design and Service Transition ensure a change can be properly built and tested, while early engagement and proper planning pave the way to virtual approvals. Where insufficient communication results in a failure to gain approval virtually or where the change is being deployed very quickly after approval is gained, a short daily meeting can finalize readiness and approval. By moving to a short daily meeting, the concept of a change being expedited as an emergency because of a weekly CAB schedule is eliminated. Change becomes a smooth, agile process that is always occurring, rather than a slow, batch process.

This approach rewards good behavior, providing an innovative and agile approach:

Ten steps to achieving agile change management

With this in mind, the question that will come to mind is “how do I achieve this in my organization?” Here are ten steps to take to achieve agile change management. These steps provide the ability to perform an internal assessment, then create a plan to close the gaps and move towards this process.

It's Change Management NOT Change Control

Not every technology environment is ready to move towards this model. Virtualization or environments with sufficient resiliency or redundancy are needed. So is a good understanding of the environment and relationships between the components that support services, a complete understanding of the organizations’ technical configuration:

Virtualization/redundancy

Virtual environments provide resiliency along with tools that can be used with other automated deployment tools to automate the deployment of a change, lowering the risk of human error causing a deployment problem. Additionally, whether achieved through virtualization or redundancy, the ability to deploy a change to a limited portion of the environment and validate success before deploying throughout the entire environment lowers risk. 

CMDB readiness and Artifical Intelligence

The virtual CAB and approval process relies heavily on the ability to automate the risk assessment process and the ability to check for conflicting changes automatically. Where enough data is present, predictive analysis can be instrumented to find similar changes and predict success rates, further adding to the accuracy of the automated risk assessment. All of this relies on the CMDB: the ability to determine all configuration items that come into play when making the change or which could be impacted by a change, including other services or applications running on shared infrastructure. This means the CMDB must be complete, including relationships to the business service level where services defined or at least the application level where services have not yet been defined.

The combination of a complete and accurate CMDB added to resilience and redundancy automate some of the most critical aspects of the weekly CAB meeting: decisions regarding the risk associated with the deployment. Most of the time, the meeting focuses on discussing high-risk changes so key technical personnel can vet the plan. With a complete CMDB with some predictive analysis in place, tools and automation can do this faster and sometimes more accurately than people can. Add in resilience and redundancy and the risk of skipping the discussion is even lower.

Automate as many changes as possible

This ensures the organization is able to meet control requirements while leveraging the automation DevOps practices often use to deploy changes. Even if the organization has not adopted DevOps, this type of automation is still desirable.

Embrace standard changes

The beauty of standard changes is that the more they can be leveraged, the more agile the change process becomes. Anything that is repeatable, or which can be automated should be a standard change. Many ITSM tools have the ability to build templates and workflows associated for repeatable work, making it easy to control the use of the standard change type only for approved standard changes, but also to record the change and drive all of the tasks needed for its execution.

There seems to be a thought that standard changes should be limited to routine maintenance, like backups, but this is not the case. ITIL specifies the use of the standard change to streamline the process whenever appropriate.

Understand why deployments fail and build knowledge

This is very simple. Any time a deployment fails, a post-implementation review should be held. Failure includes the inability to finish within the expected window, running into unforeseen issues during deployment or having to back out the change completely. The purpose of the review is not to point fingers, but rather to discover why the deployment failed and build correct and clear instructions on how to perform it the next time a similar change is made. Building a knowledge base of clear deployment instructions is a great way to move towards automating deployments as well as improving the success rate of change and lowering risk.

Get strategic

We all tend to go down into the weeds of working tactically, and change is one example of a process that’s intended to be strategic, but which is often very tactical. Looking at change management from the strategic level actually improves management of risk and ensures everyone is on board and ready when it’s time to deploy the change.

Approve at inception

Approval to deploy should never be the first time the CAB sees a request for change. The change should be approved before it’s built (or fully planned and tested for infrastructure maintenance). Early engagement allows all technical resources to get involved early in the planning and testing, which could lead to fewer problems when it is time to deploy.

Perform readiness assessments

Rather than waiting to approve a change when it hits the calendar, a readiness assessment should be performed by a peer or stakeholder team member prior to scheduling the deployment. Many organizations do this informally before requesting final approval, but to support the virtualization of the CAB meeting this should be part of the planning and a formal task or approval gate. This assessment should include the following

Approve the final scheduled deployment: The last quality gate before final deployment should be approval to go live by the affected business unit(s) and/or infrastructure manager/director for infrastructure changes. This is generally an audit requirement as well, but at the strategic level, it indicates the business is ready for the change to go live.

Automate risk assessment

Whenever possible, the risk assessment process should be automated. This will often include a few questions about the nature of the change, which are weighed against the criticality of the affected services or services that could be impacted by the change and some custom risk criteria. This is more accurate than manual assessments, but if it cannot be done, perform the manual risk assessment prior to the final readiness assessment and incorporate it into the final review. 

Another capability that is starting to become available is the use of predictive analysis (or artificial intelligence) to predict the success of the change. Again, where available this should be leveraged, but where it is not, the configuration item and change history can help perform such an analysis manually.

Implement automated approvals

Once these prerequisites are in place, the organization is ready to move towards automated approvals. The first step will be to document the approvals needed for normal and emergency changes based on risk and/or configuration item type. Many organizations already have this, but the final approvals are gathered manually. Regardless, once a proper matrix of authorities is documented and approved by the CAB and change manager, workflows can be adjusted to gather these through the platform, rather than manually or in a meeting.

There is one aspect of this process that does need to be addressed: this is not a rubber stamp and it does need prompt attention. Approvers should be ready to actually review the change, it’s planning and scope and think about it with the same seriousness they would if they were attending a meeting to discuss it. At the point of approval, they should already know it was coming and should have a level of confidence in the deployment. If they have concerns, they should not approve the change, so it can be discussed prior to deployment. 

Address the culture

By now it should be obvious that cultural readiness is a big part of making this change in the organization’s process. Technical and application teams need to be ready for adopting this and understand they are expected to work a little differently. This is an area where a rigorous organizational change management effort and sufficient training effort will pay off. Without it, the change of process is doomed to fail. Consider the benefit of rewarding people with the ability to deploy faster and without representing their change at a weekly CAB meeting:

Reward teams for good behavior 

They don’t need to go to a CAB meeting if they do all of their work early and pay attention to the details. Ability to skip the meeting is a reward, not an expectation.

Reward teams for good communication

Communication prior to deployment is key to this new process working well for the organization. Ultimately people can communicate in a weekly CAB or outside of one. If they involve the appropriate people and communicate well, they can skip the CAB meeting and get their change deployed more quickly.

Change the process and documentation

Most audit processes review an organization against their established controls and documentation. If the process is changed, even slightly, these controls and their documentation need to be updated or there is a risk of failing an audit. Therefore, the change management team should work with the audit team closely before making any of the changes discussed in this blog. There needs to be a concerted effort to work together on these changes, updating documentation along the way in order to ensure the organization’s ability to pass annual audits. This should not be taken lightly!

Ready, Set, Go! - You’re ready!

Automate deployment approvals first. It will take some time for the organization to adjust culturally, so continue to review changes in the weekly CAB meetings until the approvers are comfortable in their role and approvals are happening in a timely fashion and are taken seriously.

Move from weekly CAB meetings to Daily Scrum meetings 

As soon as the change management team and approvers feel everything is running smoothly and it looks like there would be no impact to skipping the discussion step for every change, cancel the weekly CAB, remove all deadlines and go to an exception-based, daily meeting. The agenda should work as follows:

While it may not be possible to get down to less than 15 minutes a day initially, schedule it for 30 minutes and work down from there.

Business Value

Creating an innovative process and moving towards a more agile change management practice makes it possible to move more quickly and lower the risk of failure over time. Some of the key improvements an organization will see out of this include:

Increased automation of deployment lowers risk and saves money

human error is still a large reason deployments fail. Automation lowers the likelihood of this occurring and can prevent service downtime.

More deployments mean a faster rate of change, more responsive to business needs

the digital economy makes speed critical. Whether the change is content or new features, facing external customers with digital solutions means the business needs to keep up. Agile change becomes a critical component of the competitive advantage.

Earlier engagement provides the ability to mitigate issues earlier in the process

early planning means anything that must be procured in preparation for the change can be. Consider capacity and server needs, and the impact of last-minute notification. Last minute delays are easily mitigated by good planning, earlier in the process.

Fewer emergencies and expedited changes

when a change can be recorded and approved in less than 24 hours, the number of expedited changes will drop significantly and the need to manage these as emergency changes is eliminated. True emergency changes become the repairs that must be done in under 24 hours to restore service or prevent a service interruption.

Improved resource management

with early planning, teams are able to plan staffing levels more effectively. Technical teams will know which releases will soon be moving towards deployment and early discussion along with bundling of changes can help with resource management.

Ultimately, the work that needs to be done to move towards a more agile change management approach is the same work that service management has been stressing for years: earlier engagement and better communication, along with business alignment. The result is a process that provides value to the organization by enabling change to be swift and effective.

Other Related Resources