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
- Log the standard change to ensure a record is created
- Check for conflicts
- Execute the change as soon as any conflicting changes are completed
- Update and close the change record
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
- Validate completion of testing
- Review and validate the deployment plan, ensuring it is fully documented
- Review and validate the post-change validation/test plan, ensuring it is fully documented
- Review and validate the backout plan, in the event of failure
- Ensure all affected configuration items and services are documented
- Run or review the risk assessment
- Run or review the conflict check
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.