Risk Management

Baseball players may earn glory by hitting the ball only three of every 10 times they come to the plate, but for information technology managers, there are no accolades given out for batting .300 when it comes to bringing in projects on time and on budget. Indeed, it's a sad and not very secret fact that most major IT projects rarely resemble their original requirements or cost estimates.

"Next to the Year 2000 crisis, the often very visible failure of so many major IT projects is probably the biggest problem that the industry faces," said Mike Benzen, chief information officer of the Missouri Office of Technology.

The solution, many believe, lies not in more complex technology or earlier financing but in a simple, early intervention strategy known as risk management. The strategy, considered part of good project management, involves identifying potential problems before a project is implemented, developing containment strategies and tracking that risk and strategy throughout the course of a project.

"Risk management minimizes the risk of problems occurring at any stage in the life cycle and then, if [problems] do occur, [it] minimizes the impact of those problems," said Kelvin Murray, operations manager for Robbins-Gioia Inc., a consulting firm in Alexandria, Va., that provides third-party risk management for a variety of private-sector and public-sector organizations. "It's basically putting some forward thinking to what might go wrong, but in a full-blown, very disciplined way."

The methodology, which has been embraced by many corporations and federal agencies, could be especially useful for state and local governments, according to many observers. Among the reasons: the devolution of government programs such as welfare from the federal to the state level; the increasing need to build more complex and more centralized IT systems; the lack of experienced IT designers at the state level; and mandates from state legislatures and state budget offices for IT managers to better justify their costs and show better accountability.

Indeed, there are already a few high-profile converts in the state and local market, including Benzen and John Thomas Flynn, California's chief information officer. What's more, the State Information Technology Consortium (SITC), the technical arm of the National Association of State Information Resource Executives, in February began offering workshops in risk management. So far, enrollment has been brisk. Missouri, for example, already has used the workshop to help managers identify risks and develop strategies for two new IT projects. California developed a risk-assessment model and corresponding management strategies on its own, although it has also gone through the workshop to help enhance its program and train statewide IT managers.

"We can't guarantee that risk management will eliminate all project failures," said Jim Marple, who teaches the workshops and is a project manager with the Software Productivity Consortium, a nonprofit organization that works with SITC. "But what risk management can do is significantly reduce the number of surprises to your budget and your schedule and give you some advance warning as to when one is going to happen [in order to] help you minimize its impact."

A Formal Approach

Like any other methodology, risk management is only as good as the people practicing it, proponents say. To do it correctly, IT managers must be a bit prescient, have a solid understanding of key individuals and their roles in a project's organization, a willingness to be honest and to face hard truths, a strong and formal management plan to go by and simple software tools such as spreadsheets and databases.

The Risk Management Method

While different organizations may label the steps differently, most risk management plans are similar to the step-by-step plan being outlined by the SITC's Risk Management Workshop. The steps are as follows:

n Determine your stakeholders. According to market research firm The Standish Group, the most critical factor contributing to the failure of IT projects is a lack of user involvement. Risk management proponents note that long before project implementation or project design, IT managers have to identify the stakeholders: those who will use the new system, build it, maintain it, pay for it and interface with it as well as anyone who will be affected by a project's success or failure.

"You've got to bring everyone together and make sure that the stakeholders agree on what the system is supposed to do," Marple said. "Without that agreement, all the rest of the process is not going to work, and you're not going to get the right system."

n Assess your risks. A risk, by definition, is simply a potential problem. Unfortunately, when it comes to expensive, complex and mission-critical IT systems, the number of potential problems is huge.

California, which spent a year putting together a risk-assessment model, has come up with five general risk categories and nearly 40 questions (see sidebar, Page 24) to help assess weak areas, while Robbins-Gioia has worked up a list of some 1,200 problematic areas in its catalog. Marple notes that not only does the question of risk need to be put to project managers but also to all stakeholders. Typical risks include:

* The users won't accept the system after it's completed.

* The program manager doesn't have experience managing large IT projects.

* The requirements or scope of the project will change.

* The new system won't interface with the old system.

* Lack of commitment and sponsorship from management authorities.

n Measure the risk. First perform a qualitative analysis of the risk: Is it a big risk or small risk? Highly probable or improbable? High impact or low impact? Then take it one step further with a quantitative measurement: What's the percentage that the risk could actually happen? If it does happen, what are the minimum and maximum effects it will have on schedule, cost and the performance of the system?

n Rank the risk. Once such questions are answered, risks need to be placed in order of priority. Marple advises that organizations compute a Risk Exposure (RE) number, which results from numerical measurements of the probability and the consequence of each risk. "It's a way to not only prioritize your risks but also to keep tabs on how the risks are performing," Marple said. "If the RE is going up then you've got a potential problem, and it's time to look at your mitigation strategy and perhaps even change it."

California's system actually uses a traffic light motif to symbolize risk priority, according to California's Flynn. A red designation means a risk has a high probability of occurring and the potential to do great damage to the project's outcome, while a risk designated by green offers low probability and a low impact.

* Communicate. Set up a meeting with stakeholders to discuss again the risks involved and how stakeholders can be expected to help with the mitigation.

* Develop a mitigation strategy. Determine what steps will help either prevent the risk from happening or offset its impact. If user acceptance of the system is a risk, early implementation of a user training program is a typical strategy. If the project manager is lacking experience, replace that person with another project manager or supplement the position with a third-party vendor. Any mitigation strategy needs to be a very specific plan, Murray said. "Instead of simply stating, 'Let's implement a user training program,' you would determine who's going to write that program, who's going to determine the best methods of delivering it, who's going to make that decision, when are they going to make it, and who are they going to notify of their decision," he said. "Don't leave it [undecided]; otherwise, the chances of the strategy working are reduced."

The SITC plan also calls managers to tag each risk with a Risk Referent number, which predicts how the RE will perform if certain mitigation strategies are applied. For example, a program manager might expect a user training program to reduce by 20 percent the risk of users not accepting the system.

* Manage the risk. The key to risk management is to track the performance of the risks and reassess every two to three months. "You need to compare where the risks are vs. where we thought they would be, given the Risk Referent [number]," Marple said. "If the risks are not going down as fast as you'd like, you might need to put in some new risk mitigation strategies."

* Close the risk. Once the possibility of a risk occurring has passed, managers need to document the process, note any lessons learned and store the information in a database for future reference to similar risks.

But Does It Really Work?

Risk management is not a panacea for all IT system woes, but most proponents agree that when used correctly and continuously, it has tremendous benefits. Flynn said that while the typical IT project in California used to escalate in cost by an average of 85 percent, his office has seen that figure reduced to just 15 percent since using the risk management program. Missouri Deputy CIO Tom Stokes believes that a move to risk management will simply improve the state's ability to finish IT projects on time and within estimated costs.

"Quite simply, your chances of having a true catastrophe on a project are lowered significantly when you incorporate risk management," Marple said. "You can't guarantee that you won't have any setbacks, but when organizations begin using this process on a regular basis, they start identifying risks a lot more readily and dealing with them more effectively. It just becomes a way of life."

Heather Hayes is a free-lance writer based in Stuarts Draft, Va.

***************************

Missouri Takes a Hands-On Approach

The Show-Me State may be one of risk management's most vocal supporters, but Missouri expected a lot more than theorems when it sent its IT personnel to the workshop put on by the State Information Technology Consortium. Together, instructor and students applied the step-by-step process to two fledgling IT projects. Here's what they came up with for the implementation of mobile computing devices in police cars for the Missouri State Highway Patrol:

Risk: The use of new and unproved communications technologies.

Mitigation Strategy: Perform an up-front evaluation and prototype of each of the various technologies.

Risk: A complex infrastructure and standard interface issues.

Mitigation Strategy: Run a pilot project to identify which technologies work before implementing a system statewide.

Risk: Timing and coordination difficulties due to the need for a large number of vendors.

Mitigation Strategy: Put one agency person in charge of all scheduling.

Risk: Long-term funding.

Mitigation Strategy: Do plenty of research up front, prepare a cost estimate that details as many specific costs as possible and request a realistic appropriation.

********************************************

California: Taking Charge

California has been so happy with the success of its risk-assessment model that the state decided to share the model with the rest of the world. Recently, the state put the document out on the World Wide Web, and more than 4,000 organizations have downloaded it.

"It's an extremely simple questionnaire that manages to point out very clearly what areas of concern people might not otherwise have thought of before embarking on a project," according to state CIO John Thomas Flynn.

The following includes each category that was explored and sample questions found within the state's model:

Strategic Risk. To what degree is the project's purpose aligned with the agency's overall business strategy? Have metrics been established to verify the successful completion of each project phase?

Financial Risk. Are the cost/benefits clearly defined with a documented write-up? To what degree have existing expenditures met budgeted amounts?

Project Management Risk. Does the project management team have relevant experience? Have scope changes occurred that appear to exert pressure on schedule demands?

Technology Risk. Is there a plan for ensuring that deliverables meet the need of the users? How many computer systems must the project system interact with?

Change Management Risk. How is the user-acceptance testing plan being developed? How severely would business be impacted by a system failure?