I was wondering if this question has an answer that could help me.
What procedures do you follow to manage risk?
They don't have to be perfect answers, but something in couple of sentences so I could get an idea or guide me in the right path.
Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this communityTo go about managing project risks:
1. Define you risk management approach/plan:
2. Identify and track risks in a risk register:
3. Communicate about risks:
You can also review the questions already asked by the community under tag "risk-management".
Angeline outlines a good risk process approach. Simple and straight forward, which is what you want. I will add an approach that I use based on what I have observed when the risk process is actually practiced.
Many know how to talk a good risk game, i.e., be able to articulate why risk management is a good thing and what its value would be on any given project. However, in practice, there seems to be a reservation, denial, or complete avoidance on those things that constitute a threat to a project's well-being.
I can only speculate as to why this occurs. It might be a mix of optimism bias, something that is well documented in project managers and teams, with some kind of fear of exposing those things that could threaten your success--like if I expose this I will be replaced. It might be the type of personalities that are attracted to and excel in project management, the type A, everything's under control, failure is not an option personality. It might be the reaction of project sponsors, customers and PM bosses when a threat is raised, causing an intense amount of reporting and extra controls that do not really help.
So the individual(s) whom you assign to be your risk manager and coordinators need to be trained to hear the risks, their exposures, and actions during the normal course of work. When NOT asked 'what are your risks,' people freely let you know why they have trouble sleeping at night. When asked, people clam up and say all are good! So, a stealth approach in the identification of risks might be a good intervention if you are experiencing this, as well.
Also, another area of responsibility for the PM is to control to the degree possible the reaction of sponsors and customers when threats are raised. When someone does escalate a possible threat or an area of uncertainty, that has to be rewarded, not punished. Easier said than done, but a must nevertheless.
In a nutshell, 5 steps:
1. Risk identification
Run a risk identification meeting with relevant people that can cover all aspects of the project (i.e. Technical, business, compliance, etc). Record all risks in a register.
2. Qualitative analysis
For each risk identified, you need to define the likelihood and impact (High, Medium, Low) and determine the ranking of each risk (likelihood x impact)
3. Risk response planning
For these risks assessed as high ranking, you need to document how you are going to respond to it, like, accept , transfer or mitigate the risk. If you're going to mitigate the risk, you need to define the actions/tasks/activities that need to be performed to reduce the impact/likelihood or even eliminate the risk. If you are in the project planning phase, make sure you consider these activities in your schedule, if not, add them to your actions register and refer to the originating risk.
4. Quantitative analysis
Based on the response planning and known impact, you can calculate how much time (and money) will be required to allocate as contingency in the case of the risk eventuation. This is what is called risk based contingency
5. Risk tracking/monitoring
In a weekly basis you walk through the risk register and confirm your qualitative analysis based on the execution of the risk response planning and more clarity about the project execution. You can update the impact/likelihood to reflect current reality and go back to steps 3 and 4. You should also enquire the team and stakeholders in a regular basis if they foresee any new risks, so that you're constantly preparing to properly react to risks. Keep in mind that a risk that eventuates is not a risk anymore but an issue and should be managed as such, risk closed in the register, issue raised in the register referring to the closed risk, and actions recorded in the register to bring the issue to closure.
There is much more, different ways, different levels of rigour based on project size and criticality.
The key message is that risks need to be managed and only recorded. This is a key project management discipline that directly impacts the success of the project.
Throughout my project management career I had the opportunity to take over several troubled projects and a pattern across all of them was poor risk management.
Cheers
TTKDroid