Project Management Central

Please login or join to subscribe to this thread

Topics: Risk Management
what is best way to do Risk Description/Statement?
Network:0



if there is or if you have, please share detail with exactly examples.
Sort By:
Page: 1 2 next>
Network:441



The best way to do a basic Risk Assessment among the team and then invite all the Stakeholders to an initial Risk Workshop to review all possible risks under the usual headings (procurement, installation, maintenance etc). Also at the Workshop the risks are ranked based on likelihood and severity. I think the highest rated risks would form the basis of the Risk Description/Statement
Network:958



In addition to Ronan's suggestion, include the applicable risks from WBS analysis and project resource analysis.
Network:1897



Think about what will be impacted and create the statement based on it.
Network:1623



Yong Feng -

If you are asking how to word a risk event, I've always been a fan of the "If cause occurs, then effect will occur" as that captures the risk, the impact and the fact that there is a probability of occurrence.

Kiron
Network:337



I agree with Kiron in concept, but in practice I generally don't use If Then statements for 2 reasons:

1) Clarity - Combing both the If and the Then can require a lengthy sentence. This can make it difficult to write very clearly. As a technical writing rule of thumb, short clear sentences are preferable to large wordy sentences.

2) Utility - Sorting risks and consequences by categories is easier if broken into separate fields for cause and effect, which can be useful for risk management planning. One course of action can involve many risks (cost, schedule, quality), and one type of consequence may include many sources (multiple schedule risks).

Instead I prefer to break cause and effect into a linked pair. The If then Is implicit.
Network:95



I'm currently reviewing internally how we write risk statements as it seems many projects are having difficulty in providing clarity as to what exactly the risk is. I personally prefer to look at risks from the following perspective:

1. Driver
2. Event
3. Impact

Most risk statements are written simply as "cause" and "effect" which again, depending on how the risk statement is written can be unclear, and even confusing,

For example, take the simple but representative case:

1. Cause - It may rain tomorrow
2. Impact - I may get wet

Many risk statements I've reviewed follow this logic, but then ask yourself - so what?

I would prefer something along this line of logic:

1. Driver - Forecast says 80% probability of rain tomorrow
2. Event - I may get wet
3. Impact - I could catch a cold and miss work and miss pay

Mitigation Strategy:

Depends on your risk tolerance.

1. Low Risk Tolerance: I can't take any chance of getting wet and possibly catching a cold, and missing work and missing pay, so I will bring an umbrella to work tomorrow.
2. High Risk Tolerance: I don't believe their forecasts, and I'm willing to bet they are wrong, and see no need to bring an umbrella. If it rains, I deal with it then somehow
Network:140



Think in terms of risk/consequence/mitigation. Just as important make sure you actively manage the risk on a regular basis and report significant risks to management on a regular basis.
Network:94



Great feedback from everyone here. I tend to keep my statements focused on what can occur and the result of the occurence. Very similar to the If Then type method mentioned by Kiron. E.g.

1. Technical Developer may be reallocated to operational work which may delay delivery of code.

Along with the other fields in a risk register for impact and probability, this form of statement provides the key information for the risk. The probability and impact assessments can be quantified in relevant columns to provide all information needed for planning risk responses.
Network:104004



Like Steve, we structure our risk statements in the form of a trigger - possible event - affected project outcome.

As an example:
Given a public transit strike, team members may be unable to come to work which would delay the project schedule.

The important clause in the statement is the affected project outcome. This is the litmus test to know whether it's a project risk or someone else's risk. (Hint: Sometimes it can be both.)
Network:95



Out of curioisity, l would like to know if people view the following as project risks, and if so, why?

1. Fluctuating foreign currency exchange rates
2. Upcoming regularly scheduled federal election, keeping in mind the project is to bring about an outcome that meets the current government objectives
...
2 replies by Keith Novak and Kiron Bondale
Oct 02, 2019 7:07 AM
Kiron Bondale
...
By themselves those aren't risks but might be a trigger which causes a risk to be realized (e.g. cost overrun due to increase in FX rate).
Oct 02, 2019 1:22 PM
Keith Novak
...
Exchange rates can certainly affect the business case, but I would expect Finance to book it on the business management side, rather than the PM themselves.

Elections and federal budget cycles are often a risk on government projects, but there is usually not much we can do at a project level other than accept the risk and wait to see what happens. If a new party takes control and cancels the project budget, we box everything up and ask our bosses where to report to work tomorrow. There is no mitigation other than it's a good time to use up some vacation.

I've had a $1B risk on a project related to a potential federal regulatory change, but it just sat there on our risk matrix as a reminder that if it suddenly occurs, it will terminate the project immediately.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one."

- Mark Twain

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events