In risk register risk management Risk | 2 comments
By Elmar Kutsch
We (Elmar Kutsch, Neil Turner) have published the following in Today's CIO:
It is common for Risk Management to be described as the single most important process to apply, yet it is also often cited as the one that goes horribly wrong in IT projects. Risk management is designed to assist in controlling the risks on a project by either preventing them from occurring or managing the impact if they do, so that overall objectives can be met. As with other project controls, it is prescribed in practitioner frameworks and sets of internal organisational processes. The risk management frameworks such as those described by the APM or PMI are a continuous cycle of identifying, assessing, and responding to risks. They are designed to be iterative throughout the life of the project and assist in actively controlling risks.
The purpose of the identification stage is to recognise potential risks to the project and its objectives. Identification involves a number of techniques designed to help stakeholders consider potential positive and negative events, such as risk checklists, lessons-learned logs from previous programmes and projects, risk identification workshops, cause and effect diagrams, brainstorming, and gap analysis. Assessing and prioritising risks often includes the variables of probability and impact. These can be quantitative or qualitative in nature, and often a mixture of the two will be used throughout the risk register. Finally, the response to risk may involve actions to reduce the probability of the risk occurring, the mitigation of its impact, the transfer of that risk to another party, or just a toleration of the potential effect.
Hence, managers should transform a world of uncertainty into measurable and controllable risks, by following a process from risk identification to closure through a suitable response. So it is advocated. However, although this makes sense, in our research we observed that that this is not what many managers actually do. A large number do not follow the process through to the ultimate stage of responding to the identified risks, thereby leaving them more vulnerable. Roughly a third of all risks associated with critical incidents in IT projects were not actively managed, with the biggest drop – surprisingly – at the last stage of the risk management process – responding.
The disengagement at the process stage of responding to risk is worrying. The reasons are manifold, but three aspects stand out:
The Lure of Positivity
A risk is a concept often associated with negativity. So, at times, is the response to it. Responding to a risk may be interpreted as an acknowledgement of failure, the failure to prevent the risk from existing in the first place. A response is therefore the obvious consequence of that failure. As a result, in order to maintain a positive ‘image’ of a project - one characterised by the perceived absence of risks – managers may choose to ignore it rather than respond to it. A response is a visible action, under the scrutiny and watchful eyes of stakeholders. Not responding to a known risk, however, emphasises ‘out of sight, out of mind’.
The Lure of Noncommitment
A risk is an event that has not happened yet, but Risk Management asks us to commit a response to it. By default, we like to keep our options open, and in particular to a fictional risk. Hence, deferring a response until the risk actually materialises as a real issue is convenient. This propensity to defer a response is powerful, and this helps explain why many known (identified, assessed) key risks were responded to with a severe delay, or even not at all.
Deterrent of Powerlessness
Knowledge is power, as the adage goes. Yet, knowing more does not necessarily mean that we can exercise power over our environment. Some of the managers involved in our study raised the issue that they ‘knew’ a range of risks, but felt unable to exercise any control over them. They felt powerless. It is this perception that explains another form of disengagement from risk response. Time and effort has been spent on identifying and assessing risk, yet there the process seems to stop. The apparent lack of control associated with a specific risk can lead to little, and in most cases no, dedicated resources (money, time, etc.) being allocated to the specific risk response.
Consequently, many known risks remained unmanaged and therefore had the potential to derail the IT projects we studied. This does not imply that the projects we looked at all ended in disaster. Quite the opposite, in fact. Managers showed great skill in managing major issues and recovering from crises in a timely manner. That’s not the point, though. Isn’t it a considerable waste if we spend scarce resources on identifying and assessing risks, in accumulating ever-greater perfection in forecasting, if we fail to use our newfound knowledge wisely?
- What are your experiences with risk management?
- Do we need a 'revolution' in managing risks?
- Is the process of managing risk a 'nuisance'?
- What are the benefits of managing risk as advocated by APM and PMI?