ICMI is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Advertisement

Changing Change Management: Best Practices for Modernizing Your Approach

This post originally appeared on thinkhdi.com.

Many organizations find the change management practice challenging. That’s because they’re torn between moving quickly to ensure changes can be made quickly enough to meet business needs while guaranteeing all appropriate due diligence has been performed. Let’s take a look at how to modernize the practice to meet business demands.

Change Management Defined

There are two activities involved in change management:

  • Organizational Change Management focuses on ensuring the business units affected by any change (organizational or technical) are ready for it.
  • Technology Change Management, also called change control or change enablement, allows organizations to deploy technology changes quickly and effectively without unintended consequences.

The Business Value of Change Management

The ability to respond to a business’ rapidly changing needs without negatively impacting regular operations is the primary role of change management. Communication, training and the technical due diligence needed to ensure the change is executed without causing any unexpected issues should be part of the process of defining the change to be made, building it and final testing so when the business is ready for deployment, the change can be moved to production without additional delay.

Three best practices you can focus on to achieve this modernized approach are as follows:

3 steps to modernize change management

Best Practice #1: Standardize

Not every change is the same, so not every change needs the same due diligence. This is where the concept of change models comes from. Change models enable organizations to create different levels of approval and due diligence depending on the type of change, from highly complex to very simple.  A change model should consider the following:

Phyllis Drucker's change model

Approving Authority: Whether the change is technology-driven maintenance or a business-driven software need, someone must approve the work and resources to perform it. Approval levels should vary based on the type of change, including those wide-scale business changes that may need to be considered by a board of business and technology executives, typically known as the Change Advisory Board or CAB.

Due Diligence and Testing Needed: The amount of review and testing needed also depends on the size of a change. Routine maintenance activities don’t need analysis and testing before each deployment can be expedited using the standard change process, which enables the change to be documented and locally approved.

Due diligence activities and documentation should be standardized based on the change type. Areas to consider include:

  • Unit, Quality Assurance, and User Acceptance Testing Needs
  • Risk assessment, acceptable levels of risk
  • Mitigation planning
  • Documentation to be provided along with the change record

These needs should be standardized by the type of change, such as software, hardware replacement, hardware upgrade, hardware repair, or network changes.

Deployment Authorization: Again, depending on the scale and risk of the change, final deployment approval should be standardized. The goal of the approving authority should be to ensure all required steps have been performed and the organization is ready for the change.

Best Practice #2: Automate

There are several areas where automation should be used in managing technology changes:

  • Automated testing enables test scripts to be written for all primary software features, enabling testing to be performed automatically, speeding up the delivery time.
  • Deployment and routine maintenance activities should be automated wherever possible to lower the risk of human error. Many organizations do this as part of a DevOps program, considering all automated changes to be standard changes.
  • Process documentation and approvals: Most change management software includes workflow engines that automate the paperwork aspects of change management. When a change is logged and categorized, the appropriate workflow generates tasks for testing and documentation that must be performed, as well as approvals for each step where they are needed.

Best Practice #3: Enable

Once the practice has been standardized and automated, enable your teams to go!

Using an automated workflow to manage the due diligence and approvals needed eliminates the need for properly managed changes to be reviewed in a CAB meeting[i]. Once approval is obtained for deployment, the team can go. This enables technicians to meet business deadlines and move changes through the process quickly.

Ensuring tasks are generated for UAT and user readiness approval also enables the business to control changes that affect daily operations, putting them in the driver’s seat throughout the process.



 

[i] In this case, the need for CAB review becomes an exception. Either the team responsible for the change didn’t do the work needed or there are approvers who haven’t had their concerns addressed. To keep the process responsive, consider a short, daily stand-up meeting to address these, so changes aren’t held up waiting for a weekly review meeting.