Ronan O RourkeRetired Executive Manager, Water & Drainage Operations| RetiredBray, Ireland
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 Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
In addition to Ronan's suggestion, include the applicable risks from WBS analysis and project resource analysis. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Think about what will be impacted and create the statement based on it. Saving Changes...
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.
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. Saving Changes...
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 Saving Changes...
Lonnie PacelliAuthor & President| ProjectManagementAdvisor.comBellevue, Wa, United States
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. Saving Changes...
Yousaf KhanPM Consultant| City of TorontoToronto, Ontario, Canada
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. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
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.) Saving Changes...
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.
