The new organization that I'm working for does no Risk Management on projects. We work in a high volume, quick turnaround environment where most projects are closed in 8 weeks or less. As a result, they have been of the opinion that Risk Management is an added cost, and that they don't have time to implement this in an efficient manner.
As you can imagine, this is something that I want to change. When projects go off the rails (as they do for about 30% of projects) I can almost always demonstrate how an effective Risk Management Plan would have prevented or reduced the cost.
I don't need help making the argument that Risk Management is necessary.
Where I could use some help is in how to implement something lightweight and quick that doesn't take a lot of time. What are some strategies I can implement with this team that is resistant to this change. Saving Changes...
Vladimir LiberzonR&D Director| Spider Project TeamMoscow, Russian Federation
For last 25 years we use simplified but very efficient method of risk simulation that we call 3 scenarios method.
It is based on creation and analysis of optimistic, most likely and pessimistic versions of project schedule.
Look at this presentation http://www.spiderproject.com/images/img/pd...%20Analysis.pdf for more details.
In some projects we use this way of risk simulation in parallel with Monte Carlo. The results do not differ much. Though Monte Carlo simulation is recognized as most scientific and reliable method it is based on initial data of very low quality and so its advantage is questionable. In any case both methods provide similar results but three scenarios is simple and fast, Monte Carlo requires much more time and efforts.
Let me know if you will have any questions.
...
1 reply by Miguel Figueroa
Jul 18, 2023 9:31 PM
Miguel Figueroa
...
Hello Sir, when using 3 scenarios methods are you referring to this formula (optimistic + 4*most likely + pessimistic)/6, of there is something else and I am lost about your priceless comment. Regards
You can implement software like Intelex: https://www.intelex.com/risk-management/. This allows you to identify, track and mitigate risk adequately in multiple areas of your business. Saving Changes...
At a bare minimum if there isn't an appetite for meaningful risk management, I'd recommend using the lessons from past similar projects to help identify areas of uncertainty early on, and then implement responses aimed at surfacing and addressing those as early as possible.
And make sure you make any risk-related information "matter" to your stakeholders who will execute risk responses. Tie it back to the project's expected outcomes or success criteria and be as specific as possible in the risk details.
Finally, if senior stakeholders are unwilling to act on risks which they should be responding to, get them to sign off that they willingly are foregoing any active measures to address those so you don't end up as the scapegoat...
Figure out the approach you want to take, and then phase it in.
For example, you could start with just a question that you ask for each project - What about this project keeps you up at night? Get people used to answering the question.
Obviously, you have to do something with the answers. If your stakeholders aren't ready for formal risk management, they don't need to see the risk register right away. You should, however, ask them follow-up questions - what action is needed? who needs to address this risk?
Identify risk-related tasks that need to be added to the project schedule and track them with the rest of the project tasks.
Eventually, you may be able to get into probability, impact, and risk exposure discussions, but for 8 week projects, you may not need a lot of quantitative and qualitative analysis. It may be as simple as letting the team voice their concerns and then deciding if anything needs to be done about them. Saving Changes...
Vladimir LiberzonR&D Director| Spider Project TeamMoscow, Russian Federation
Turnaround projects are short but delays in this projects are very expensive and sometimes impossible.
So they need very thorough planning and quantitative risk analysis. This analysis can be simplified but it must determine required contingency reserves and increase reliability of meeting required targets.
Risk identification, qualitative analysis and mitigation are just preliminary steps. Saving Changes...
I implemented simple risk based PM on a prior program using a 5x5 risk matrix, basic risk level criteria, and informal discussions to reach a general consensus from the PMs and senior stakeholders.
PM is really risk management. If you don't need to manage risk, ask why do you even need PMs when you can just load all your tasks into a tracking system and be done with the overhead?
Why? Because technical and organizational uncertainties disrupt the happy-path plan to the point where the results become unacceptable. The 2nd law of thermodynamics applies to organizations: entropy (disorder) will naturally increase over time unless energy is expended to reduce disorder.
Ask what are the unacceptable things you are trying to prevent and your tolerance levels for good, bad, and very bad. For each project, ask what are the 2-4 top potentials for things to go wrong. For each risk, categorize it as a team discussion in terms of high medium and low. It doesn't have to be exact and you will find most people will have similar but not identical assessments. That's often good enough.
Now when you review and manage projects, focus on the yellow (medium) and red (high) risks. Don't worry about the stuff that will fix itself if left alone. Then you can focus on what matters instead of statusing everything just in case. Saving Changes...
I have a similar problem with "quick turn" projects. Lots of small efforts that cumulatively generate a lot of revenue; the historic response was to just "pad a few hours" in the proposal--which covered some of the "known" risks, but wasn't always handled correctly in execution. I was able to incorporate an additional "Management Reserve" percentage up-front during proposals so that there was a clear dollar amount associated with risks; the "padded hours" got lost in translation from proposal to execution and created confusion with the technical team as to how many hours they had available (side note, I now "hold" 20-30% of all hours as a contingency reserve at execution; I get complaints, but it generally works well overall). All the above are great suggestions, however they take time to gather responses, and the short term of projects probably don't lend themselves to taking that amount of time to resolve before you have to really start executing. My method gets us up and executing within a day or so, and we "get by" mostly. After two years, there is now recognition that they need a more robust risk analysis. Saving Changes...
Anonymous
I'm the author of the original post. Thank you all for the thoughtful comments. I'm starting to get some buy-in. My current idea is to require a lightweight risk scoring in the proposal stage. If the score is sufficiently high it will trigger a full-scale risk analysis before the scope is completed. Saving Changes...
Community Champion
