It often surprises me how many companies initiate expensive projects without performing any risk analysis. To me, risk analysis is probably the single most important activity that managers must engage in before they commit funding and other resources to a project.
The level of risk associated with a project drives a good deal of the amount of effort most of us are willing to devote to planning, analysis, and design. If I told you that the outage of a new application that your company was building would cost a dollar a day, how much would you be willing to spend on making sure the application worked perfectly? Not much, I bet. Would your perspective change if I told you that the outage would cost a hundred thousand dollars an hour? Of course it would.
Finding out the cost of outage -- and other valuable pieces of information -- is why we do risk analysis. Sadly, we don't do it often enough. And so we end up getting burnt, over and over again, by not being ready when a risk becomes reality and our project is threatened.
It just makes sense to do a little risk analysis.
While there are many other methodologies, I follow a relatively easy approach called impact risk analysis. Here are the steps in that approach:
Identify the assets to be protected. An asset is anything of value whose loss would hurt the project or organization. An asset can be data, a person, a piece of hardware, a program. In other words, an asset is something that you feel you need to get the job done.
Identify the threats to the assets. A threat is any event, person, or organization that could somehow attack those assets. An act of nature can be a threat. A disgruntled employee might be a threat. The competition might be a threat. You have to identify those threats so you can start to figure out how they might attack you.
Identify the modes of attack used by the threats. A threat may take multiple forms. An act of nature might be a flood, a snowstorm, a tornado. A disgruntled employee might steal data, destroy equipment, or introduce a computer virus into your network. The government might introduce damaging legislation or force an audit of the organization. It is important to identify as many potential attacks as possible.
Calculate the probability of a successful attack. While it may be difficult to come up with a precise number, you can assign a general value to the odds that an attack will actually take place. Try to avoid expressing the probability as a percentage. That tends to lead to one party saying the probability is, say, 62 percent while another says it's 68 percent. Some organizations use a five-point scale. I like to use a three-point scale of high, medium, and low (H,M,L). I find it is generally easier to reach consensus on a three-point scale.
Calculate the impact of a successful attack. Here again I find it helpful to use a three-point scale. Remember, the impact of a successful attack is not always measured in monetary terms. For example, if a hospital loses access to its water supply (a critical resource) the impact will not be expressed in dollars but rather in patient care. Expressing that impact as high, medium, or low can be extremely useful.
Multiply the probability of an attack by its impact. By multiplying the value of each item in number 4 by its value in number 5 you will build a ranked list in the format HH, HM, HL, etc. Assign each one of the pairs a unique value: it can be a number, a letter, anything convenient. You can now plot those values on a graph where one axis is the probability of an attack and the other is its impact.
Pair the probability of an attack with its impact. By combining the value of each item in number 4 with its value in number 5 you will build a ranked list: HH, HM/MH, HL/LH, ML/LM, MM, and LL.
If your project has many HH, HM, or MH items, then it is probably a high-risk project. If most items are in the LL, LM, or ML range, then your project incurs a lower risk. High-risk projects need more attention paid to risk management. Lower-risk projects can probably get by with less effort -- not only in risk management, but also in project control, planning, and so on.
How do you manage higher-risk projects? How can you lower the probability of a successful attack or minimize its impact? For that information, you'll have to read How to manage a risky project.
Jerry Golick is an independent project manager, and freelance writer, specializing in networking technology. In addition to consulting, he also provides custom technical training programs on a variety of topics.
Reproduction in whole or in part in any form or medium without express written permission of Computerworld Inc. is prohibited. Computerworld and Computerworld.com and the respective logos are trademarks of International Data Group Inc.
