Risk Assessment is somewhat of a guessing game that pessimists excel at, and consists of making a list of: What could go wrong?
Let's create an imaginary list of potential risks for a project:
- A key engineer takes vacation
- A new component is faulty and cannot be integrated
- An earthquake destroys the building
Analyzing risks.
Typically, each risk is rated on a scale of 1 to 5 for probability and severity using the following rules:
Probability:
- 1= low chance of this happening
- 3=there's a 50/50 chance of this happening
- 5=almost sure this will happen
- 1=project will not really be affected if this happens
- 3=project will be seriously impacted of this happens
- 5=project will fail if this happens
Risk Description | Probability | Severity | Score
1. Vacation | 3 | 4 | 12
2. Component fault | 4 | 4 | 16
3. Earthquake | 1 | 5 | 5
Prioritizing the Risks
In the above sample, we would first want to deal with Risk #2 as it has the highest score:
A new component is faulty and cannot be integrated
Typically the involved parties would brainstorm how to minimize the risk, and a game plan will be drawn up that will be tracked periodically; every few days if needed.
In this particular case we may decide to start integration and testing of the component ASAP - even before the design is ready, to make sure we have a head start.
In parallel, we may want to do research for alternate solutions as well as a web search to see what issues other people have encountered with this component.
We may also want to have a contingency plan in case we have to deliver without this component; this may involve warning management about this risk and its implications.
We would then tackle Risk #1 as it has the next highest score:
A key engineer takes vacation
Here we we have a high score that is easily solved. Call in all key engineers and ask them about their vacation plans for the duration of the project, and set down clear rules for future vacations, e.g. you need to give us 10 days warning before going on vacation.
In addition, we may want to insist that all engineering work is done in pairs so that no single engineer becomes indispensable. Or we could insist on periodic peer reviews, so that more than one engineer is familiar with each aspect of the project.
We then look at Risk # 3 - An earthquake destroys the building - and decide that with its low score of 5 we do not have to deal with it. If it should occur we would handle it using Crisis Control, something we will discuss in a future post.
Tracking our risks.
Tracking - as we mentioned - would be done periodically in a quick meeting. The agenda would be:
- Risk #2: Key component:
- Progress update on integration
- Progress update on search for alternatives
- Status of on-line help
- Risk #1: Key personal
- Present peer-review plan
- Approve vacation schedule
- Remove this risk from next week's agenda
- Did anybody identify new risks?
However, a good Project Manager will be continuously be doing a Risk Assessment of the project, until it is safely delivered. This is done almost subconsciously.
As my good friend and former CTO of Answers.com - Jeff Schneiderman - was wont to say:
Managers hate surprises.
A manager wants to find out that a project may not be delivered on time, as soon as he can, in order to create a contingency plan and inform relevant parties.
Typically a Project Manager will raise a Red Flag when he suspects the schedule is in jeopardy. Worst case scenario he over-reacted and his suspicions are wrong. As the saying goes:
It's better to be a pessimist; you are continuously either being proven right or pleasantly surprised.
Risk Assessment minimizes the surprise factor in a project - and allows one to use the wisdom of hindsight in advance.
If you ever said "why didn't I think of that" after your project failed, then you need to improve your Risk Assessment skills.
In a future post we will discuss who to brainstorm - a crucial component of coming up with potential risks.
- Danny Schoemann, Jerusalem
No comments:
Post a Comment