Without accurate risk metrics, you can fail to mitigate serious risks and end up watching your project fail. Or you can misspend in an overblown effort to mitigate risks that will never come to pass or that won't cause much damage if they do. Here's how to get a handle on project risk.
Start early. "The key issue with IT project risk is that it is usually not considered until there is a problem," says Chris Thatcher, an enterprise security consultant at Dimension Data North America Inc. in Hauppauge, N.Y. "It is considered best practice to conduct a risk assessment for each IT initiative before it receives approval."
Identify risks. You should have enough information at a project's inception to know about the biggest risks, such as ineffective sponsorship, a fudged business case or inept project management, says Richard Hunter, an analyst at Gartner Inc. in Stamford, Conn. "Killing projects that exhibit those risks on Day One would save most IT organizations 50 percent of the money they spend on failed projects," he says.
Make a risk list. Good project planning will naturally address risk areas such as staffing, funding and technology, says Robert E. Taylor, CIO for the government of Georgia's Fulton County.
But there are other risks that are specific to the individual project. You can identify these by asking what would most likely cause one of the project's products, modules or processes to fail and then finding the root cause of each failure. "One of the easiest ways to get to root cause is to ask why [a failure might happen] five times," explains Mike Blake, chief financial officer at Kaiser Permanente IT. The answers will get you closer and closer to the underlying risk.
Compare your list of risks with a standard risk profile, says Tom DeMarco, an analyst at Cutter Consortium in Arlington, Mass., and co-author of Waltzing With Bears: Managing Risk on Software Projects (Dorset House Publishing Co., 2003). You may have identified more risks than are on that standard list, but make sure you aren't missing any. If you have failed to identify one of the standard risks, you may be in denial, he says. Snap out of it.
Next, look into the types of risks you've found, DeMarco says. For each one, ask whether it's a binary risk -- something that either happens or doesn't happen -- or a contiguous risk -- something that happens to some extent and causes injury accordingly.
Measure. Examine each risk, noting its potential impact and likelihood. To assess potential impact, "we look at the dollars associated with the risk: what we would lose and the negative brand exposure we would suffer," says Gerald Shields, CIO at Aflac Inc. in Columbus, Ga.
"You need this analysis to determine what you would spend to mitigate the risk," he adds, since you wouldn't want to spend more to mitigate a risk than what the event would cost you.
Then look into the actual likelihood of the risk event. "Corporations can go to the extreme, spending a million dollars to close an exposure that is minimal and remote," says Shields. Metrics are all about consistency, says Taylor. "A consistent view of the metrics and a consistent interpretation of the results are key," he explains. Only by ensuring that all stakeholders are viewing and interpreting the metrics in the same way can you begin to mitigate risks appropriately.
Projects with high-impact/low- probability risks need to be continually monitored to make sure the risk probabilities don't change, Taylor says. This is an area where consistency of metrics -- and buy-in from IT, business and finance -- is essential. If the probability of a high-impact event increases, there should be no debate as to what that means for the project.
"The key is to agree on what constitutes a low-, medium- and high-probability status and then monitor the established standards to ensure that these do not change as the project proceeds," says Taylor.
Prioritize. Creating a matrix with this impact/probability information will help you better understand how to prioritize risk mitigation.
The top risk is usually very specific to your business. "Since we're a health care company, things that endanger our patients are No. 1," Blake says. "You have what I call the untouchables. [For example,] if it happens to be the peak time in the ER, we're not going to be taking down servers during that time."
Verify mitigation. Once you've identified, measured and prioritized risks, you can take steps to mitigate them. But you're not done yet. You need to verify that steps have been taken to mitigate the risks, which is an easy task if you've done your job properly. "Risk mitigation leaves footprints," says DeMarco. "You can go into a risk assessment of New Orleans and say, 'Show me the money you spent to make sure the busses were there. Show me the contracts that you signed.' "
Improve. Keep track of the risks that actually come to pass during a project, so you have a better idea of their probability during your next project.
Learning to manage risk is an ongoing task, but your risk management capabilities should get better as your risk metrics improve.
Side bar
Identifying risks
Here are six steps to identify IT project risks, from Cutter Consortium analyst Tom DeMarco:
-- Create an environment where people can talk about things they hope won't happen.
-- Take a risk census. Hold a brainstorming session to tally team members' worst fears for the project.
-- Validate your census results. You should have a definite number of risks -- not just an estimate. The most common number for projects today is between 20 and 50.
-- Identify each risk type. Is it binary -- something that happens or doesn't happen -- or is it contiguous -- something that happens to some extent and causes a degree of damage?
-- Gauge the potential impact, even if it's just a guess.
-- Do a reality check. Compare your risks with a standard risk profile and make sure those risks are on your list.
-- Geer is a freelance writer in Ashtabula, Ohio. You can contact him at geercom@alltel.net.