Caspar’s presentation made some important points about the way we look at risks. This included highlighting the fact that, although a lot of organisations are risk averse, in reality avoiding all risk is neither achievable nor, usually, desirable (I will allow exceptions for things like nuclear power station control systems!). However, one always has to remember that where there is risk there will inevitably be, at times, failure. His analogy was that, to win at poker, you have to play the long game and accept that you will regularly lose individual hands. Again, this is something that the corporate world regularly forgets, with many organisations having a tendency to embark on a witch-hunt whenever something goes wrong.
So, how, from a strategy perspective, should one approach risk and the management of risks?
Well, first and foremost, I believe that the approach to risk as defined in the IT strategy has to align to the overall organisational appetite for risk. This sounds obvious, however in the real world, it can be difficult. Sometimes the organisational appetite for risk is not clearly stated and therefore has to be extrapolated. Sometimes the attitude to risk documented in the organisational strategy does not align to the attitude to risk demonstrated within the organisational culture. It is certainly not unknown for a strategy to make quite bold statements about encouraging risk while the organisational culture remains one of witch-hunts.
The challenge for the CIO, therefore, is to navigate an appropriate path within all this for the IT department. Of course, in a mature organisation, one would also hope that the CIO would be involved in the debate about the overall organisational view on risk, which should make things a little easier.
Another question that comes up at this point is how to define what level of risk is acceptable in objective terms. This is, again, can be difficult. I think of the various conversations I have had with financial advisors over the years where I have been asked about my attitude to investment risk. Broadly this has tended to come looking at the risk level of the potential investments in relative terms (essentially; high, medium or low or something along those lines). Similarly, therefore, a way to identify where efforts should be focused within a strategic programme of work would be to plot potential initiatives onto a matrix showing high, medium and low risk and reward on the two axis. Potential initiatives can then be ranked in relative terms and the high reward, low risk ‘no brainers’ and low reward, high risk ‘avoid at all costers’ identified.
What you then end up with is a picture something like this:
It’s not perfect but it is a relatively simple way of getting some structure into this discussion and is also a good first step in getting to the more sophisticated approach of having a balanced portfolio of projects at different risk levels.
One other vital point is not to forget risks during the implementation of the strategy - the bit that often gets forgotten. Individual projects should, of course, have their own risk registers which are regularly reviewed and updated, but it is also a good idea to monitor the risk inherent in the portfolio as a whole in reviews of the overall strategic balanced scorecard.
One approach that I have found helps here is to make a division between technology-related risks and management/commercial risks (essentially the stuff that isn’t directly technology related). There is a valid argument that this distinction is essentially artificial as all risks should be ultimately appraised in commercial terms, however my feeling is that, given that technology is fundamental to the IT department, it makes sense to separate out those risks from the risks that might be found on any organisational unit. This also helps ensure that you haven’t missed anything important.
These risks then may be considered from the perspective of things that might happen as a result of something that is planned within the strategy (e.g. an implementation of a new application or a migration to a new outsource partner) or, equally importantly and, again, often forgotten, things that might happen as a result of not doing or delaying something (e.g. not upgrading your desktop in the life of the strategy or not increasing your focus on succession planning). This way, one can continuously ensure that the strategy is still appropriate and, when necessary, adjust it to take account of changing circumstances.
One final thought. I have never seen a perfectly implemented strategy and some things will inevitably go wrong. When they do, a witch hunt may be an inappropriate response, but that isn’t the same as ignoring what has happened. A failure is definitely worth a review. What happened? Why did it happen? What can we learn? These are all valid questions. This is not the same, however, as saying that someone must be to blame or that this should never be allowed to happen again.
Anyway, that’s my take on risk. As ever, I would be delighted to learn how you all deal with this tricky issue so all comments are most welcome.
