Risk management in three easy lessons

Last fall, a friend of mine from Vancouver was organizing an outdoor barbecue for some of his clients. Vancouver, as most people know, can be quite wet in October. My friend looked at the weather forecast only to find out that showers were predicted. Not wanting to risk any problems with this important event, he ordered a large canopy to cover his guests should the forecast prove accurate. In addition, since he didn't want to risk running out of food, he ordered extra steaks and B.C. salmon.

My friend also made note of the fact that Vancouver is in a zone that is susceptible to earthquakes. But he decided to assume that risk since there was not much he could do about it. (By the way, his barbecue was a success and it didn't rain.)

Why is it that people naturally think of all the potential risks for a $500 barbecue but assume that everything will go as planned for a multimillion-dollar IT project?

A few years ago, I was helping with the preparation of a proposal for a federal government department. This proposal was for a major systems delivery initiative to be staffed by an Ottawabased consulting company. A key component of the proposal was a software package not offered by the local consulting company. The government decided to partner with a U.S. supplier of that package. As usual, many long hours were invested in the preparation of this professional proposal. However, at 11 p.m. on the day before the proposal was due, the U.S. supplier decided to pull out because it did not like some of the conditions of the partnership.

Since the bid team had no time to find another supplier of the package, it proposed an alternative that was not satisfactory to the client and the bid was lost.

In another situation, one of my clients was developing a new accounting system using a database management system and a CASE tool they had just acquired. The project went well and they were impressed by the improvements in productivity they could achieve with the CASE tool. The surprise came when they conducted their first functional tests. An update run of the database took much longer than expected. They projected that with the database fully loaded, each "daily" run would take approximately 28 hours to complete. The problem was eventually solved with some heavy tuning and a redesign of the database.

What do these two sad project stories have in common? In both cases, the person in charge of the project assumed that everything would go as planned. Risk management is a key success factor with any project. There are three steps to follow in risk management:

* Identify the risks. I find a good way to identify a risk is to use the following: Given this condition we fear that impact.

An example would be: Given this it is the first time we will be using a CASE tool code-generator, we fear that the response time may be unacceptable.

* Quantify the risks. Here, the project manager has to determine the cost to the project if the risk materializes.

* Develop a mitigation plan. These are the actions to be taken when a risk occurs. Acceptable actions also include avoidance (eliminating the cause of the risk) and acceptance (accepting the consequences of a risk because, for instance, it would cost too much to mitigate it).

The project manager then has to control and report on all risk events during the project.

Remember: A smart project manager never forgets that an unmitigated risk is an invitation to disaster.

By Jean Labelle

Jean Labelle. PMP is the director of the Project Management Core Competency Centre for DMR Consufting Group Inc. in Montreal. Jean can he reached at (613) 228-6032 or [email protected].

Copyright Plesman Publications Ltd. Apr 2000
Provided by ProQuest Information and Learning Company. All rights Reserved