This post is an excerpt of the Breaking the Change Management Barrier whitepaper by Ron Forrester, Sr., Jayne Groll, Chris Hill, Dr. Steve Mayner, Erica Morrison, Scott Nasello, Scott Prugh, and Rosalind Radcliffe.

During an era of rising regulation and linear, waterfall software development, enterprises adopted a rigorous approach to IT’s change-management process in order to regulate releases into production systems and demonstrate auditable Information Technology (IT) controls. (For the purposes of this post, the term “change management” refers to enterprise technology changes.)

In the past best practice frameworks advocated for the creation of Change Advisory Boards (CABs) that would be responsible for assessing requests for change (RFC) against risk and impact, as well as collision avoidance. The intent was to create a holistic advisory group with the skills and experience to evaluate “normal” changes and strike a balance between stability and innovation. By definition, normal changes were unique and had no history of risk or reward.

As change management became entrenched in the enterprise, the CAB shifted from an advisory group to a decision authority for most, if not all, requested changes. The burden on the change initiator grew as RFC details, timelines, and level of pre-submission approvals increased.

Traditional change management places more emphasis on managing RFCs over the change traceability, or change record. The net result has made for longer lead times, increased impediments and overhead costs, and frustration from the Development and Operations teams, business leaders, and customers. Once an enabler of innovation, command-and-control change management is now considered a constraint.

The business climate has changed, and IT must adapt its processes accordingly. IT has to implement changes more rapidly to gain or sustain a competitive advantage in this disruptive landscape. Smaller releases with risks mitigated by frequent and automated testing can deliver value faster and more frequently if allowed to deploy into production with a minimum viable process. Determining what’s “just enough” change management depends on the risk appetite and compliance requirements of the organization. However, even small improvements to change management and the CAB can result in big advancements. 

This post offers several patterns that can be applied in tandem or as appropriate by leaders seeking ideas and opportunities for optimizing the ongoing value of change management while reducing its complexity.

What Business Leaders Care About

Any discussion of transforming the change-management process must begin with a recognition that legacy change practices were put in place for a reason. Boards of directors and officers of corporations have fiduciary accountability for ensuring the ongoing viability of the organization. Public-sector leaders are similarly responsible for the use of taxpayer funds to provide vital services to citizens. These responsibilities frequently involve compliance with a complex spectrum of laws and regulations. As organizations become increasingly dependent on technology for critical business capabilities, system failures represent an unacceptable threat to them and to society, requiring business leaders to institute measures that anticipate and reduce these risks.

More specifically, laws such as the Sarbanes-Oxley Act of 2002 in the United States, international standards bodies such as the Payment Card Industry (PCI) and International Standards Organization (ISO), and regulatory agencies such as the Food and Drug Administration (FDA) prescribe adherence to change management best practices as a compliance requirement. The governing bodies commonly write standards with a bias toward traditional, process-heavy change practices. Executives, compliance officers, and internal and external auditors can all be held personally accountable for failure to comply to these guidelines. This frequently, and understandably, leads to a range of responses, from skepticism to outright rejection, when considering proposals for implementing modern change management practices.

IT leaders including chief information officers (CIOs), chief information security officers (CISOs), program managers, technical managers, and even teams themselves are invested in ensuring changes are applied to production systems in ways that don’t result in outages, invalid data, poor responsiveness, and more. Failures in critical technology capabilities lead to a loss of confidence in the IT organization, as well as the diversion of limited resources away from innovation to recovery and remediation activities.

Dysfunctions with Traditional Change Management

Well-intentioned, traditional change-management processes frequently display a series of dysfunctions and anti-patterns. They include:

1. Disjointed ownership of workflow and responsibility: many different teams and individuals are involved, and flow is sacrificed.
2. Large batches of work: changes are queued with long lead times.
3. Unproductive CAB meetings: with so many changes reviewed at each meeting by several individuals, meetings can become watered down and valuable time that could be invested elsewhere is wasted.
4. Approval removed from accountability and responsibility: those farthest from the change have the approval authority; those closest to the change are removed from the approval process.
5. Resource dedication to “process excellence” and job security: incentives to keep things as they are remain strong.
6. Tool silos or tool swivel: change management tools often differ from team level work management tools.
7. Overuse of change moratoriums and freezes: leaders believe that not changing the system results in stability; in reality, batching up work introduces risk, as does forcing teams to defer or reorder change implementations.
8. Lack of continuous improvement capabilities: while continuous improvement has permeated many other aspects of DevOps organizations, it’s not routinely applied to change management.
9. Multiple approval theater: those farthest from the issues are allowed to weigh in and approve or deny changes; there is a sense that by the simple act of getting to approve changes, safety will be introduced.
10. Decisions are often made based on emotion instead of metrics.

Foundations for Improvement

Before exploring the specific patterns in evolving the change-management process for modern systems development, it’s important to address the foundations that provide a principled backdrop for each of the below recommendations.

Embrace Lean Thinking

The first overarching pattern is to understand and embrace Lean thinking. “Lean” refers to a body of knowledge that was first pioneered in manufacturing by Toyota in the 1940s. It describes a set of principles, practices, and tools that enable people to continually improve their work.¹ These improvements focus on reducing waste and increasing quality.

The concepts of Lean have been adapted to technology development by Allen Ward, Don Reinertsen, and others. In addition to reducing waste and increasing quality, the application of Lean to product development aims to create a continuous flow of value in the form of working systems and software features. While these thought leaders have described many concepts and practices for Lean product development, three are particularly relevant to the discussion of rethinking the traditional change-management process.

1. Reduce Batch Sizes

One of the keys to creating continuous flow of value in product development is to reduce the batch size of work. Research cited by thought leaders, such as Reinertsen, shows that smaller batches move through the end-to-end development process quicker, with less variability and fewer defects. In the context of change management, smaller, more frequent changes represent less risk as there are fewer variables that have the potential to result in an error or outage. Smaller batches are easier to test, and defects are easier to find and correct.

2. From Long Queues to Short Lists

Another important concept from Lean is that longer queues increase the lead time in which it takes new features to flow through the process from inception to delivery. This principle is described in the queuing theory known as Little’s Law that states the average wait time for a service from a system equals the ratio of the average queue length divided by the average processing rate. In other words, the longer the queue, or list of committed items in the backlog, the longer the wait time for customers to receive the value represented by the new feature.

Applied to change management, long queues of changes cause delays. Therefore, the change-management process needs to be optimized to commit to short lists of changes, while all other changes are simply “forecasted.” This maximizes the flexibility to add, delete, or re-sequence changes to deliver the highest value changes in the shortest lead time. Not only do queues create long lead times, but they also create an opportunity for lost context and knowledge as the work is handed off from one team to another. We like to say that: “Not only do queues not scale, but they also don’t learn.”

3. Experiment and Learn

An impediment to proposing a new approach for change management is the daunting prospect of replacing deeply rooted processes that were once widely accepted as best practice. It’s ironic that the fear of change is one of the biggest barriers to improving how we change. Fortunately, the principles of Lean and Agile once again provide a path forward. Each of these bodies of knowledge draw from the language of the scientific method by initiating change as a hypothesis, followed by experiments testing that hypothesis. Once the experiments have concluded, observations and learnings develop the next hypothesis based on the results. The guidance here is to evolve change-management practices as a series of small experiments, enabling the organization to iteratively understand and adapt these processes over time based on validated learning and measured improvements in quality and flow.

Empower the Teams

The next foundational pattern’s purpose is to empower teams to participate in and contribute to the development of modern change-management practices. After all, the teams generate changes that ultimately flow into the production system and have valuable insights into techniques such as automation that can manually provide
previously performed validations. Not only do they provide better solutions for improving change management but being a part of the improvement process also engenders ownership and accountability in the teams for the overall execution. Lyssa Adkins, a well-known thought leader in Agile coaching, states, “Accountability sticks when you mindfully work towards getting to a solution rather than passively receiving directions from another.”⁴

Eat the Edges Incrementally

We understand that many organizations have deeply entrenched change processes that have evolved over years and even decades. This includes lengthy CAB meetings, multiple approvers, and dedicated people who manage these changes. Disrupting this head-on will be difficult. With this post, our hope is to provide a set of patterns that can be applied incrementally to improve change in your organization. We recommend an approach that “eats the edges incrementally” of your change-management process. For example: start with applying easier patterns, such as low-risk classing and exemptions to reduce overhead and gain wins. Then, begin moving to more complex
patterns, such as localizing changes and CAB. By this manner, you can deliver both value and credibility faster. Attacking the entire change process at once will likely lead to setbacks, and we do not recommend starting with that approach.

Patterns for Improving Change Management

The figure below represents a set of patterns that can be adopted in support of the transformation. Each pattern provides a brief summary of the pattern, the problem it’s addressing, and a proposed solution. Our goal is to demonstrate ways organizations have transformed and to help provide specific guidance that will improve the
change process in your organization. Where applicable, we also include concrete examples of what has worked in other organizations. The patterns are introduced by increasing difficulty of adoption for traditional organizations with entrenched change processes.

To read the details on each pattern, please download the Breaking the Change Management Barrier whitepaper here.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•