Change Management is an interesting proposition, when it comes to risk. At first pass Change Management sounds like the kind of discipline where it would be important to minimise risk.

In practice, Change Management is better described as balancing risk.

Changes are inherently risky. Any time we upset a known quantity, we’re introducing risk.

It’s not enough to talk about minimising risk; without meaning to sound facetious, the best way to minimise the direct risk of any given Change is not to do it.

But there’s a really significant problem with that approach; change is necessary.

It’s necessary at the strategic level, and at the operational level. Businesses that don’t change, don’t survive – because the world changes around us, all the time. We can adapt to that, or we can fail.

It’s therefore unsustainable to suspend all changes indefinitely (and moreover it doesn’t decrease risk over the long term, as we’ll see).

However, in keeping with the theme of balance, we can and do actively change our position on the balance of risk due to patterns of business use. We do sometimes stop making changes in the short term; we implement a Change Freeze to coincide with the start of Semester One precisely because we’ve decided, at the strategic level, that protecting the experience of using our services during this peak period is our foremost priority. Yet if we adopted this approach year round, our services would die on the vine.

In addition to taking a holistic view on the necessity of supporting change, at the operational level there is almost always a corresponding, direct risk to not making a proposed change.

For example, it is risky to install an application patch. It is also risky to run the unpatched application. The decision about whether to proceed depends on understanding how these risks interplay. The risk of Change is not a one-way street, in other words. It is always an act of balancing.

Meanwhile, over time there are also a host of indirect risks to controlling change too tightly.

One example of this is the risk of increasing technical debt, which can arise from stagnation around change. This can lead to a vicious cycle, where the risk of making changes increases because of technical debt, but the technical debt increases with our aversion to change.

In some cases that aversion may be well founded – but regardless, when such a situation arises, without a decisive position on the balance of risk we can spend a lot of time and effort digging ourselves ever deeper into a hole.

So, Change Management is about balancing the risks of making changes, with the need of the business for those changes. You could also say that it’s about balancing the risks of making changes, with the risks of not making changes. But what does that look like in practice?

Well, firstly, the key to balancing risk, is understanding risk.

Risk likes to hide in dark places. By far the biggest source of risk is what we don’t know. Any time we don’t understand a risk, we have to work on the assumption that the risk is significant.

For example, if we haven’t tested a release satisfactorily, the release is going to be considered risky not because of what we know about it, but rather because of what we don’t know about it.

In a world with perfect knowledge of risk, we would not need to test releases at all. But in the real world, testing gives us some of that missing clarity on risk. It doesn’t negate risk, but it reduces its potency. We gain confidence in the likelihood of success, as well as understanding about the scope and severity of the predicted impact.

And risk should be understood as a value judged against these two scales. The first is best described as the likelihood of that risk obtaining. The second is best understood as the consequence of the impact that would, or could, obtain.

The University takes an official position on how to evaluate this balance, per this chart lifted from our “Risk Management Guidance Manual”, and the Go CAB works to an aligned set of principles.

At the Go CAB, we look for unexpected risks, such as conflicts between the technology or resources around co-scheduling changes. But we also ask questions specifically to understand and mitigate common risks, such as understanding what we would do if something were to go wrong.

We also need to consider that there are different types of risk that we face. We often get a little bit too hung up on purely technical risks (when looking at implementing IT changes in particular).

But we also need to continue to develop our appreciation of business risks: patterns of use, stakeholder engagement, communication practice, even customer perception of reliability; these are all factors that will affect our overall position on risk, regardless of how the work is executed technically.  The more we engage with change management from the perspective of the services we are offering, rather than the technology that supports them, the more likely it is that we will be able to account for that full spectrum of risk surrounding changes.

Finally, if all this talk of risk has left you feeling a little anxious, remember that the best response to risk is knowledge. A really significant proportion of the work that I do as Change Manager is not original, but rather the curation of what we know about changes, and the presentation of that knowledge in a way that can inform decisions.

When we have the right information in front of us, these decisions are usually nowhere near as challenging as the range of considerations I’ve outlined might make them seem!

Change Management: A Risky Business / ITIL Tattle by blogadmin is licensed under a Creative Commons Attribution CC BY 3.0