This is the first of two posts on Risk Mitigation
The change management process in IT organizations has two main goals: to maximize the effectiveness of change implementation and to manage risk to the business. IT organizations have generally adhered to a documented change process, mostly focusing on process compliance rather than thinking consistently about anticipating and mitigating risks when and where required.
IT teams create and enforce these processes following frameworks like ITIL®. The governance that stems from this approach has made organizations very reactive. Traditional processes are too slow for today’s level of change and innovation.
It was fine when the speed of change was slower. A Change Advisory Board (CAB) could meet once a week or even once a month and come to grips with these changes. But the rate of change, both external (driven by competition) and internal (driven by opportunity for innovation), have accelerated to the point where that cadence no longer works.
As a result, important changes are put on hold because IT and the business cannot keep up. Management now recognizes the importance of the business risks these changes can introduce. Change requests get stuck in the review process, until the risks are understood. Increasingly the business feels the imperative to make these changes anyway to meet competitive threats and capitalize on opportunities, but views its overtaxed IT function as an obstacle, rather than an ally. Business people start looking for ways to work around IT, rather than engaging with it.
That’s why in the days of Agile, the traditional CAB approach has been put into question. New management philosophies like DevOps have brought accelerated change and innovation, breaking down the risks inherent in each new release into much smaller increments by dramatically reducing the scope of releases. This reduces the impact on the business if something does go wrong — which, inevitably, it will.
In this new environment, it is important for IT organizations to assess risks against three different dimensions:
- The probability of a problem resulting from a change, based on past experience;
- The impact to the business — what “lean change management” guru Jason Little refers to as the “blast radius” of the change — including the financial impact, reputational risk, safety, etc.; and
- The recoverability if something goes wrong — the ease, effort and expense involved in rolling back the change or otherwise adapting if things don’t go according to plan.
These dimensions form a triad similar to the one described in the popular joke about the customer and the contractor. (“You say you want this to be high-quality; you want it cheap, and you want it fast. Okay…Pick two.”) In theory, the business can sustain a high probability problem, with a high impact to the business, as long as it can recover quickly and easily. Or, it may be able to accept the possibility of a high impact change, even one that is difficult to recover from, if the probability of occurrence is low. But the business cannot risk a change that is high on all three dimensions.
It is helpful to broadly assess the level of risk that arises from changes using this triad. But sometimes, changes fall into larger categories of scope that also are useful from a mitigation perspective. We’ll consider that categorization in our second post in this series on risk.
KT offers a one-day workshop on Risk Mitigation for IT organizations, which provides a useful, fundamental discipline to institute basic risk mitigation in your business.
