|
|
|
| Failure to understand who the project is for | |
| Failure to appoint an executive user responsible for sponsoring the project | |
| Failure to appoint a fully qualified and supported project manager | |
| Failure to define the objectives of the project | |
| Failure to secure commitments from people who are needed to assist with the project | |
| Failure to estimate costs accurately | |
| Failure to specify very precisely the end users' requirements | |
| Failure to provide a good working environment for the project | |
| Failure to tie in all the people involved in the project with contracts or Documents of Understanding |
The chart plots
Probability of occurrence of a risk, which is another way of saying how uncertain the
success of the task would be, against the Impact. By Impact we mean the severity of the
effect on either the budget, the timeliness of project completion, or the ability of the
project to meet the users' requirements. Whether the severity of Impact or the Probability
is high or low is a matter for the judgement of the Risk Assessor and the Project Manager
- even with rational method involved we are still talking of an art!
We have classified the four sectors of the graph, perhaps whimsically, as:
List each of your identified Risks, decide on the probability occurrence of each, and define the expected impact on schedule, budget, and ability to meet the users' requirements.
By now you have really done this. Tigers have to be neutralised i.e. the risks must be mitigated early on. Alligators have to be watched, and there must be an action plan in place to stop them from interfering with the project. Puppies similarly have to be watched, but less stringently and with less urgent containment plans. Kittens can be ignored at the peril of the project manager.
You would do this for all those risks categorised above as Tigers. We can mitigate risks by reducing either the probability or the impact. Remember that we identified the risk by seeking uncertainty in the project. The probability can be reduced by action up front to ensure that a particular risk is reduced. An example is to employ a team to run some testing on a particular data base or data structure to ensure that it will work when the remainder of the project is put together around it. The technique of building a pilot phase of the project is an example of risk mitigation. Unfortunately it often fails, because the team works closely with the pilot user group, and then thinks that all the problems are solved for the roll out. This is rarely the case.
By performing the risk assessment, we know the most likely areas of the project which will go wrong. So the project risk plan should include, against each identified risk, an emergency plan to recover from the risk. As a minimum, this plan will name the person accountable for recovery from the risk, the nature of the risk and the action to be taken to resolve it, and the method by which the risk can be spotted. A risk which has been mitigated may still be a significant and dangerous risk - it is rare for a tiger to be converted to a kitten by action before the event. These will require emergency plans as well as alligators and puppies. Kittens can probably be allowed to play at will, provided we are satisfied they really are kittens!
The owner of each risk should be responsible to the project manager to monitor his risk, and to take appropriate action to prevent it from going on, or to take recovery action if the problem does occur.
Nothing can be controlled which cannot be measured. In a project there are three things which can always be measured - the schedule, the cost, and the users satisfaction. For some more detailed thoughts on this topic see Elements of Project Success. If, when you get to this point, you realise that you cannot measure a particular risk, then back you go into Risk Assessment!
![]()
Project
Risk Management Principles
When
to use Project Risk Management
Planning
a Project Risk Assessment
![]()
To discuss the contents of this article, or for advice or information about project risk management, write to us by clicking here.
Robert Tusler
is a member of the Alliance of Business Consultants
![]()
This Page was created using WebEdit, 14 August
1996
Most recent revision 04 July 1998
Copyright details:Copyright © 1996 Robert Tusler You may read these pages on-line, and download them to read
later, for your own personal use.
|