4 Best Practices for Documenting Project Risks

English: Iceberg around Cape York, Greenland

 Projects fail.

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:

ID Risk Description
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:

ID Risk Description
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.

e.g.

ID Risk Description
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:

ID Risk Description
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 Identification
# 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.

Advertisements

2 thoughts on “4 Best Practices for Documenting Project Risks

  1. Yeah its a very good article.As a project manager, I use Scrum in my projects. The Guide to Scrum Body of Knowledge by SCRUMstudy provided a complete reference for the Scrum project I am working with. It is a very good book and extremely readable. I really liked sections on risk and quality. The tools mentioned in the processes were very helpful. I highly recommend this book if you are planning to implement Scrum in your organization. You can go through the first chapter available on http://www.SCRUMstudy.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s