The simplest way of recording risks is with a table or spreadsheet that lists the risks and their priorities. This can then be regularly reviewed by the project team and action taken appropriately to mitigate or eliminate those risks.
Below is an example of a sample risk table for a project:
|Short-term absence of key team members||High/Low||Major||Project||Accept|
|Long-term absence of key team members||Low/High||Major||Project||Reduce|
|Supplier X does not deliver product Y||Low/Low||Minor||Phase 1||Accept|
In the above table, failure by suppliers to deliver some components has been rated as a minor risk. This sort of judgement can only be made on the basis of experience and within the context of the current project. If the supplier is well known and trusted, then the likelihood of them delivering late is likely to be low and hence the risk can be classified as minor.
Labelling scheduling as a critical area of risk is also an outcome of experience. If previous projects of a similar nature have run-over due to scheduling problems then it is highly likely that this project will suffer a similar problem. Here, too, you can see the benefits of having a separate risk management officer since it is unlikely a project manager, however honest, would rate his own scheduling abilities as “high” risk.
Nick Jenkins is an IT manager with 10 years experience in software development, project management and software testing. He’s worked in various fields of IT development in Australia, Britain and the USA and occasionally he learned something along the way. Now he lives on the banks of the Swan River in Perth, Western Australia, and he publishes the odd guide to help aspiring IT professionals. Nick’s website can be found at www.nickjenkins.net.