How to Create a Risk Analysis Process
As the director of foreign exchange at Merck, Art Misyan uses statistical risk analysis for evaluating the impact of foreign currency volatility. Like Sanchez, he's puzzled by IT's laissez-faire attitude towards risk analysis. "Risk gives you the ability to look at a whole range of outcomes, but IT looks at only two possible outcomes," he says. "Either you hit deadlines or budgets, or you don't."
IT needs to think in probabilities, Misyan says, not ones and zeros. The best way to start is for the CIO to formalise the risk process. "First you have to set up a process to determine and track risks," he says. The good news is that much of the risk process is built into project management methodologies CIOs have been adopting anyway, so it should be familiar. Here are the basics for developing a risk analysis process.
Gather experts to determine project risks. These brainstorming sessions should be free and creative. "You want the pessimist in the group, the dark cloud," says Anne Rogers, director of information safeguards at Waste Management, who teaches risk analysis. "You want the person that will ask, What if a truck ran into the building?"
When you don't ask the off-the-wall question, you run the risk of smacking into it. "Motorola gambled on developing Iridium satellite phones and charging $US7 a minute," recalls DeMarco. "No one seemed to wonder what would happen if [mobile] phones came along offering similar service for 10 cents a minute and free nights and weekends."
Assign researchers to uncover known risks. "We came up with 20 or 30 risks we knew we'd face by research," says Sandy Lazar, director of key systems for the District of Columbia, who is overseeing a five-year, $US71.5 million administrative systems modernisation program (see "Get a Grip on Risk", page 62). "If you read up, you realise ERP has failed over and over for the same reasons for 15 years now." In fact, there are five typical risks to software projects that every CIO should include in a risk analysis .
Divide risks into two categories - local and global. The risk of staff turnover during a project is a local risk. War is a global risk. Often, those new to risk analysis focus only on the local risks, but they need to consider the global risks and their impact.
Create a template for each risk. The template should include a unique risk number, a risk owner, potential costs (in dollars and other terms), a probability of occurrence (a low-medium-high scale will do at this point), any potential red flags or signs that the risk is materialising, mitigation strategies and a post mortem for noting if the risk factor actually happened. (A good example of such a template can be found in Waltzing with Bears. Go to http://www.cio.com/archive/070103/risk_form.html for a sample Risk Control Form.)
One important footnote for developing this process: Value consistency over accuracy. If you do things in a consistent manner and the numbers are off, at least they'll be off in a consistent - and therefore fixable - way. "The process," says Raytheon's Rhoads, "is so much more important than the maths rigour. Mature, consistent processes - you need that first."
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.