Modernizing IT Change Management within Complex Adaptive Systems

"Systems theory is the interdisciplinary study of systems, which are cohesive groups of interrelated, interdependent parts that can be natural or human-made. Every system is bounded by space and time, influenced by its environment, defined by its structure and purpose, and expressed through its functioning. " ~Wikipedia

I recently had an email exchange with a long-term fellow advocate of IT service Management about his excellent work within his organization on a proposal to modernize (reduce bureaucracy and improve flow) their ITIL Change Management practice. Which is my view is a worthy goal and exactly the perspective that ITIL4's renaming of the practice to Change Enablement is trying to encourage.

In his proposal he correctly identifies how change reviews and approvals should be based on risk and that by leveraging DevOps continuous delivery practices and automation for both deployment and recovery that many changes could be classified as standard / pre-approved. In many cases peer review would provide the necessary accountability, controls and verification needed and that the high-risk changes should still flow through a formal Change Advisory Board.

In asking for my thoughts, I shared that I respected the work that had been done and agreed with many if not all of his conclusions. However, it was equally true that many of his proposed changes were dependent on other organizational factors and that they presupposed a level organizational, technology and architecture maturity in several connected domains that I rarely see when working with my clients.

Here is what I shared back with him:

Hello {Friend}

Looking through your deck I can see that you have been certainly paying attention to the concepts discussed in relationship to High Velocity organizations and cultures.

I have no concerns with what you have captured, written and sourced.

My only suggestions are that what you are proposing pre-supposes a fairly high degree of organizational maturity in several domains.

Information Technology & Architecture 

• The majority of the technology environment is software defined and supports continuous delivery automation, cloud-based elasticity, self-healing and remediation. (Infrastructure, Software defined network, database configuration, environmental configuration)
•  Change risks can be lowered through leveraging abstraction techniques such containerization, serverless computing
• Testing coverage and confidence covers the majority of the environment to support continuous deployment based on automated go / no-go decisions based on trusted test results
•  Shared platform tooling is leveraged by the product teams which is enabled by standard artifacts, scripts and orchestration automation

Organizations and People

• Developers are willing to use standard scripts and engage in practices such as test-driven development and daily commits to trunk
• That testing is done closer to the source (quality at the source /shift left) and not delegated to downstream teams removed from the developers
• That the developers or change initiators are accountable for the quality of the change and have to deal with the consequences of a failed change themselves (authority and accountability must match)
• The organization invests in proactive problem management with blameless post-mortems to learn from past issues vs simply focusing on major incident reviews.
• That the culture does not punish people for making mistakes or alternatively loads them down with more controls. Instead mistakes are understood as inevitable within complex systems and that they should be used by the organization to learn and get stronger rather than look for a scapegoat.  

Value Streams and Processes

• The organization is leveraging deployment and release strategies that lower risk such as Canary, Blue / Green, Feature Toggles and Dark Launches to progressively test releases and fall back rapidly if necessary
• The organization has a strong discipline around configuration management, version control 
• The organization understands that the question of production assurance, change readiness is established by the Validation and Testing practice not Change Management / Enablement. 
• The change model being used is based on risk and that as you have indicated in your document there are a variety of different change channels with only high-risk changes going through the CAB as a change authority.  

Partners and Suppliers

•   Partner contracts include aspects of all of the points above as well as the agreement to follow shared practices and be involved in continual improvement as a member of the team

I shared with my friend that as he read these points that I hoped that he did not think I was disagreeing with his proposed approach. He did a nice job on describing how change modernization should occur at a process level. It’s just that there are many other systemic dependencies to support the goal of change management modernization.

On a related topic I also wrote the following white paper: The Top 5 Leadership Enablers for Effective Process Governance.

 Best Regards

Troy DuMoulin

VP R&D, Pink Elephant.inc