Number of studies have been conducted on how many projects fail or get cancelled as well as primary reasons of the project failure. Each study presents similar findings – projects fail due to changed requirements, lack of resources, unrealistic schedule and/or budget and poor risk management.
In my mind, most of the causes of project failure can be tied back to Poor Risk Management.
Poor or improper risk management starts from the very 1st step of identifying and articulating risks. Typically risks are identified as below in risk registers:
|R01||Unix Resources might quit prior to project completion|
|R02||Project funding not available|
|R03||Client not available to resolve queries|
All of the above are bad examples of describing risks. The following principles should be used while documenting project risks in the risk register.
1) Use the Risk meta-language
Risks should always be described using the correct risk meta-language. Risk should be expressed in terms of CAUSE, EFFECT and IMPACT.
Sample meta-language statements:
1) If CAUSE, then EFFECT may occur, leading to IMPACT.
2) Due to CAUSE, EFFECT might happen, which will lead to IMPACT.
The above risks could be rewritten as:
|R01||Due to high demand of Unix professionals, Unix resources might leave the project prior to its completion. This will lead to delay in project completion.|
|R02||Due to cost reduction directive from top management, Project may be denied further funding, which will lead to scope reduction and/or early project termination.|
|R03||Due to client sponsor’s busy schedule and frequent travel, he/she may not be available to resolve project queries, leading to delays in completing the requirements specifications.|
2) Impact should be described in as much objective detail as is reasonable
During risk identification, it may not be possible to determine the complete impact of the risk to project objectives as well as provide a quantitative impact value. However, impact should be described in as much objective terms as is possible and reasonable. This can lead to better understanding of the risk during subsequent analysis.
|R01||Due to high demand of Unix professionals, Unix resources might leave the project prior to its completion. This will lead to delay in project completion by 2 months.|
3) Risk should be assessed from different perspectives
Stakeholders should be involved in identifying risks and risks should be assessed for various categories. Equally importantly, stakeholders and project team should analyse a risk on its impact on the project objectives from various perspectives. e.g. the above risk was re-assessed from various perspectives:
|R01||Due to high demand of Unix professionals, Unix resources might leave the project prior to its completion. This will lead to delay in project completion by 2 months, budget overrun by $25,000 and loss of knowledge of XYZ application.|
4) PMO Responsibility – Improve Risk Register
PMO’s could even design the Risk register template to ensure that the risks get documented using the above principles. For e.g. the risk identification section of the risk register could be:
|#||Risk Category||Cause||Risk Event||Effect|
|01||Resource||High demand of Unix professionals||Unix resources might leave the project prior to its completion||Project completion will be delayed by 2 months, budget overrun by $25,000 and loss of knowledge of XYZ application|
If a risk gets written well, then it eases the downstream tasks of analyzing the risk quantitatively and defining the risk responses.
Do you use the above practices or any other best practice in documenting project risks? If yes, i would appreciate if you can share them here.