Is it time to change Change Management?

This question is especially pertinent in the context of the solution development lifecycle and control processes such as change and access management when delivery teams start adopting agile, DevOps and continuous delivery methodologies.

The central problem is that approvals and segregation of duties tend to be bottlenecks that focus on ticking boxes for compliance rather than meeting the business need for fast frequent change to systems – as in hourly or daily, versus weekly or monthly.

The people who are custodians of control – governance, risk and compliance (GRC) teams (change managers, internal risk auditors, security teams and PMOs) – generally prefer everybody to follow control processes and practices that are optimized to GRC needs, regardless of the net effect they have on the product delivery cycle and increased risks they expose the business to. They might also insist that “you use our tool!” with its configuration and process of form filling and awaiting approvals.

Approvals are used as a stick to improve transparency into who is doing what and why but, if the process is a burden people will work around it. In change management, there may be a sudden jump in the number of emergency changes as smart people work around the approvals and seek forgiveness after the fact. Circumventing the process becomes a game, resulting in less, rather than more, transparency. Even worse is seeking approvals from higher authorities who have less time and knowledge to make good decisions regarding the change. Everything gets rubber stamped or held up until the approver understands all of the implications of their decision.

The fundamental purpose of change management is to build in transparency into who is making changes and when to reduce the risk of breaking things in production. The best way to do this is to get teams talking to each other, not by submitting change requests that are approved by people far removed from the actual work!

To achieve good change management, it’s necessary to trust teams to talk to each other and make them responsible for the outcomes of their changes. The logical evolution is that approvals need to come from someone close to the work who understands the complexity or relationships and will be held responsible for fixing anything that breaks as a result of a change. This could be another team member for low risk routine changes, or team leads for higher risk changes that affect multiple systems.

From a total risk perspective, trying to control all elements of change in a centralized manner just doesn’t work anymore. New methodologies and technologies such as agile development, continuous delivery, DevOps, virtual machines, cloud services and lean startup have antiquated organizations’ traditional approach to change management. Trying to maintain a traditional Configuration Management Database (CMDB) when using today’s technology is largely a waste of time. Certainly, a CMBD may be useful at the highest level but it’s not possible to control every element affected by the rapid change required for today’s businesses. So, from a risk perspective, if we can’t know everything, what do we really have to know and who is best to make the decision if the risk is acceptable for the business?

By taking a concept from the lean start-up movement, Minimal Viable Product (MVP), it’s possible to determine the Minimum Viable Process for change management which helps us to design a system that delivers true value to our business.

To start, delivery teams and GRC teams need to create a common understanding of what the change management process is trying to achieve. The goal is to reduce overall risks and allow software delivery to flow changes into production at a cadence acceptable to the business. GRC teams need to open their eyes and take a stab at understanding the technologies and methodologies used by the delivery teams. Delivery teams need to take a deep breath and consider what evidence they are producing that proves they are making good decisions.

A second step is understanding what the change management process looks like from end to end; mapping out the steps, and how much value each step contributes to the goal. What are the lead and wait times versus how much time it takes to actually do real work? Who are the players? Where are they located? Is there a faster, easier way to get the work done? If there is, are the associated risks acceptable?

This approach should enable a business to identify the bottlenecks and consider how they affect the customer. With change management, having multiple processes based on associated risk levels is far better than having one process to rule them all. High risk changes such as those that affect how private customer information is managed should be subject to more rigorous reviews and approvals. Lower risk changes such as those that deal with less sensitive information and do not affect other systems can flow through at a much faster pace with less review and approval.

Therefore, it becomes possible to improve the flow for change management: start with the minimum viable process based on the type of information, number of integration points involved to other systems and size of the change (one small fix versus many new features). Solutions can range from entries on a shared calendar supported by notes in version control and evidence of test results to full review and approval by a high level change advisory board

Our traditional view of risk and compliance is built on a “push” approach that creates bottlenecks and doesn’t lend itself to flow. Because the change management process is perceived as onerous and painful, and is optimized for the GRC team, multiple changes in systems are batched and released in one shot, which actually increases the level of risk associated with the change.

The alternative is to create more of a “pull” system and increase flow. Reduce the volume of the noise by focusing on the high-risk changes. Reduce risk by introducing avenues for smaller lower risk changes to move faster through the process. This needs cross-functional teams working collaboratively – to talk about relative risks and try different approaches to reduce overall risks whilst still providing evidence for compliance purposes. Get people and different teams to talk to each other instead of relying on a passive, remote, tool-based process to manage change.

A lot of this may seem like common sense but, traditionally, GRC teams are trained to believe their job is to stop people doing bad things rather than helping people to do the right things! The nuance is to, instead, talk about business goals, the collective responsibility for compliance and agree on the best way to achieve the agreed desired end state. The focus should shift from “Stop doing stupid things” to “how we can make this better?”

By focusing on overall outcomes of the change management process, over the outputs of change requests filled out in the correct manner, the process will continually improve. This comes down to maintaining a flow of conversation between GRC teams and product delivery teams in a culture of collaboration rather than assuming a policing role which forces an inappropriate, antiquated change management process on delivery teams.