PHIL SIMON
I have been giving quite a bit of thought lately to the topic of enterprise risk management. In large part, this stems from the fact that I have worked on more than a few projects in which my client’s risk tolerance was off the charts. I mean cray cray. In this post, I discuss three types of organizations with respect to risk tolerance:
- The Oblivious Enterprise
- The Zero-Risk Enterprise
- The Acceptable Risk Enterprise
The Oblivious Enterprise
This type of organization is perhaps best epitomized by a client of mine (call it ABC here). The company’s mind-set could be epitomized as follows: There was no such thing as risk. Period.
Here’s the crazy thing, though. ABC routinely addressed IT projects in this manner. According to lifers, every piece of software and hardware that ABC deployed in the last ten years was managed the same way. Proceed as if nothing is wrong. Ever.
This was a shock to just about every external consultant who showed up to work at ABC. You see, good consultants have been trained to identify and minimize risks throughout projects–at least, as much as they can, anyway. Sadly, the ABC’s CIO did not want us “editorializing.” Translation: keep your mouths shut. We don’t like naysayers.
From the consultant’s perspective, you can’t win on projects like these. If you broach a legitimate issue, you’ll be silenced and possibly removed from the project. If you don’t, then you’ll invariably be asked, “Why didn’t you tell us about this?” Organizations like these have high employee rejection rates; it takes a certain personality type of accept the risk of lawsuits, audits, and generally appearing foolish as you expose yourself and others to excessive levels of risk.
The Zero-Risk Organization
Now, let’s turn to the other end of the spectrum. Several years ago, I worked on a project for an organization that would not do anything when faced with even the smallest risk. To that end, it employed a full-time internal auditor to carefully monitor all IT projects. He would report his findings to the CIO.
So, you may ask. What’s wrong with this?
In the abstract, nothing. But IT projects are never abstract. Actions have consequences. The project consistently suffered as the implementation team attempted to address his concerns, and he had a bunch. Sure, many of them were well-founded, but how do you concurrently assuage an auditor’s concerns and make up time on a delayed project?
You don’t.
If your organization is not ready to take on some level of risk, then don’t start a major systems or IT initiative. Ever. All projects come with some degree of risk. It’s that simple.
The Acceptable Risk Organization
Ah, I can’t tell you how much I enjoy working with companies and people who understand risk. They possess a modicum of perspective. Serious risks are actually taken, well, seriously. Further, key people understand the time-sensitive nature of many problems. They understand that, as prolific author Bob Charette has said, risk is always a function of information, time, and money.
Of course, no organization has unlimited information, time, and money. Trade-offs need to be made, as I point out in what I call the Enterprise Risk Pendulum:
Executives at acceptable risk organizations understand the relationship between risk and cost. As such, I’d argue that they are likely to make the right calls most of the time. Things won’t always go perfectly, but these realists create contingency plans in the event that things go awry.
I have a few questions for you:
- What’s your organization’s risk tolerance?
- What causes some organizations to accept so much risk?
- Can people with one risk tolerance be successful at organizations with vastly different risk tolerances?
I wrote this post as part of the IBM for Midsize Business program.
Agreed but the blog should reflect that not everyone recognises the same probabilities and impacts.
Everyone’s appetite for risk needs to recognise the limitations of its experience and the extent to which the new project comprises new territory e.g. new Technologies /methodologies /stakeholders. The acceptability and management of risk for most OLTP is very different to that for DW & BI.
In answer to your questions:
1) Most Financial Institutions claim to manage risk but are not always good at recognising what they do not already measure.
2) “so much risk” is a subjective judgement that should vary in two aspects:
2a) corporate/institutional culture. e.g. most Governement Departments want to be seen to avoid all risk, whereas a small start-up mining company knows that it’s whole life is a risk.
2b) the weighting / importance of different risks. Is it important to deliver at any price or timescale or just be seen to manage with methodologies they have tried and proven
3) I have seen that it is really difficult for people who are steeped in one approach to quickly move to another tolerance – In IT you expect / rely on the DBAs of mmission critical systems to have less appetite for risk than developers implementing new technologies. A non-IT example is that Risk Assessors and Accountants do not often make good Traders and vice versa. In IT, those steeped in waterfall methodology can be really frightened if dropped into Agile environments. But a supportive mentored transition can be successful and mutually beneficial. Now that is simply a question of recognising and managing human risks.
No discussion of risk is complete without also discussing the “reward” side. Risk tolerance is significantly higher when the payoff is great. If the reward is negligible then the corresponding risk is also lower.
Far too often in the IT world I see people discussing risk alone without weighing in the rewards. Unless both a taken into account the entire conversation is wasted.
For example, one of my customers transitioned their CRM to the cloud. The upside of a successful migration were so high they were happy to invest whatever money, time and resources were needed.
As such, the project was implemented in phases with review milestones along the way. In the end, the project took a bit longer than expected, under budget and a complete success. Of course there were hiccups along the way, but they were smoothed over before moving to the next phase.
Thanks for the comments.
@Kenneth – You make excellent points about different people’s perceptions about risks. I probably tend to take all risks seriously because, as a consultant, my name (and often my invoices) hinge on client satisfaction.
@Louis – I know that the subject of risk is a big one, not easily contained to a blog post. I’m still trying to get my mind around your sentence: In the end, the project took a bit longer than expected, under budget and a complete success. Rare indeed that those things happened.
LOL! The funny thing about that particular project was I was taken to task by the customer because it was delivered late! You can’ t please everyone, I suppose.
However, I have found that the biggest step to ensuring a project is delivered properly is expectations management. As a consultant, I spend the majority of my time managing customer expectations.
My Chief Engineer loves to joke that I promise Hell, pain and misery while secretly forcing him to develop Tech Nirvana. At the end of it all, it’s about making sure that the customer is completely happy with the finished result.
I can’t agree with you more on the oblivious organization.
I worked at one and nothing could be more stressful. Say something, get shot down. Say nothing, finger pointing.
These types need to seriously analyze their business structure, since they probably never have.
Though, not sure if that would do any good, as they’d probably ignore the findings.
Maybe it’s just best to find another place of work/client when you run into these.
Thanks, Claudia. Don’t get me started.