What is Risk?
Posted by Brad EgelandWe’ve discussed issues and Risk tracking and we’ve gone over the Risk Management Plan. What we really haven’t done yet is define what Risk truly is on a project. For me, it’s always been one of those grey areas that I was never comfortable admitting was grey. So let’s get to the bottom of this.
Definition of Risk
As we identified in The Risk Management Plan article, the definition of Risk Management is…
“Risk management is the systematic process of identifying, analyzing, and responding to project Risk. It includes maximizing the probability and consequences of positive events and minimizing the probability and consequences of adverse events to project objectives.”
And the definition of Risk is…
“Exposure to the chance of injury or loss; a hazard or dangerous chance.”
So when we discuss the concept of Risk in terms of a project and Project Management, we are looking at those events or issues that arise during the course of an engagement that may affect the successful outcome of a project and therefore need to be assessed and planned for mitigation.
A Risk can be nearly anything. It can be the upcoming performance of an activity that has never been performed before and therefore the outcome or duration is very uncertain. It can be the potential loss of a key project personnel resource to another project. It can be the unknown status of funding from the customer side for an upcoming phase of the project. Or it can be the use of a new technology for the overall solution or for accomplishing specific tasks on the project.
Identifying Risks
The way I look at it, Risks are basically issues that progress or need to have a plan. Not always, but usually, a Risk arises from an issue that is discovered or discussed by the project teams. Issues are tracked and may become Risks to the project. And they are only Risks if they have a potential negative impact on the outcome of the project – either success, timeline or budget.
A risk is something that is identified, can be planned for, and can be potentially mitigated. An emergency that arises on a project – like a natural disaster or the unforeseen removal of a key customer resource – is not a risk because it was not something that was a potential issue from the beginning.
Under extreme risk planning…if you’re attempting to cover everything…you can plan for these events but for 6-12 month projects it’s likely a waste of time and resources to develop a full-blown Disaster Recover Plan or to plan for the potential loss and course of action for every possible resource. Generally, risk identification comes out of known issues or real potential issues and attempts are made to plan for them and plan for a course of action or actions to take in the event that they are realized. That is called Risk Mitigation.
Summary
Risk items come up on every project. Recognizing issues as Risks when they arise is a talent and it’s one that the Project Manager and the delivery team need to acquire to help ensure project success. Sometimes it requires out-of-the-box thinking and not just basing everything on the fact that it’s “never happened that way before.” That’s a dangerous mentality. Check for Risks throughout the project and keep revisiting the list of Risks that have been identified to ensure that they are planned for in the event that they are realized during the lifetime of the project.
Related posts:
steve says:
There are many types of risks like: Budget / Cost Risk,Business Risk,Environment Risk, Information Security Risk,Infrastructure Risk, Quality and Process Risk, Resource Risk,Supplier Risk, Technology Risk,Technical and Architectural Risk etc.. they should be carefully identified & managed.
Varun Poddar says:
To supplement the info presented in this post, if you are looking for specific areas to identify risks, check out a list at http://www.poddarco.com/2009/04/06/findingrisks/
Reading through some comments may help see what areas others have suggested too.
Cheers!
-V
mtrots says:
One more good article to supplement the initiated topic: http://www.executivebrief.com/article/ranking-risks-rare-to-certain-negligible-to-catastrophic/ (advice on how to correctly rank risks your project or business is exposed to).
Denise says:
A couple of points to be noted in connection with this article:
First, we need to remember that a risk is simply an uncertainty that may impact our project IF it occurs. Although (realistically) most risks are negative some uncertainties can be positive, and those are opportunities to be exploited or enhanced.
Somewhat in the same vein, it’s helpful to remember that risks are NOT (yet) issues…they are only potential issues that we can try to mitigate or avoid.
Finally, I have to take issue with the assertion that “an emergency that arises on a project” isn’t a risk “because it was not something that was a potential issue from the beginning”. The potential for emergencies exist in every project, although some may be easier to identify and analyze than others. Also, it certainly isn’t my experience that the only risks we need to worry about are those that exist at the beginning of a project. Conditions both internal and external to the project frequently give rise to new risks throughout the term of a project, so that risk identification and analysis should be recognized as iterative and continuing processes.
Brad Egeland says:
Denise-
I understand what you are saying and I do agree with you. In fact, in the next paragraph after talking about emergencies, I state…
“Under extreme risk planning…if you’re attempting to cover everything…you can plan for these events but for 6-12 month projects it’s likely a waste of time and resources to develop a full-blown Disaster Recover Plan or to plan for the potential loss and course of action for every possible resource.”
I’ve worked on long-term 5 year government programs and developed full-blown disaster recovery plans for them including annual offsite disaster readiness production processing demos. But for a shorter project, extensive planning for possible major disasters is usually not practical.
And I wholeheartedly agree that risk planning is not something you do based on risks identified at the beginning of a project. Just like issue tracking, risk planning and tracking happens throughout the project and should be revisited weekly as part of a formal weekly status call with the delivery and customer teams.
Pradeep Bhanot says:
It is worth keeping in mind that some risks can be identified at the beginning of a project and others appear during the course of the project.
In software projects, the ones that appear towards the end of the project cycle are concerned with having to release a deliverable with some low priority QA failures or not having a long enough customer testing due to schedule or resource constraints.
The mitigation is usually documenting these as known issues and offering workarounds.
empee says:
What is not clear to me on this article is how to distinguish between risks and issues.
I had been taught and have worked on the basis that:
* A risk is something that MIGHT happen with some consequence
* An issue is something that HAS happened and has to be dealt with – it might have been identified as a risk before in which case it is now an issue
This article seems to imply an issue can arise first, maybe I have misunderstood what is meant by an issue in the context of this article?