Let's say I wanted to asses the risks in a project like the one in this link: https://github.com/tanay-bits/baxter_skeletonteleop, where I am tele-operating a robot using a vision sensor. How can I facilitate a project risk assessment?

  • Hi King, welcome to PMSE! As your question stands, it's highly likely to be considered too-broad and thus potentially closed. Besides, there's no canonical answer for 'what risks you see in my project', so I'd ask you to rewrite your question to address the actual problem(s) you might have found doing your risk assessment.
    – Tiago Cardoso
    Commented Apr 14, 2017 at 22:41
  • Try this tool of mine: 0rsk.com: Cause + Risk + Effect
    – yegor256
    Commented May 16, 2019 at 8:52

2 Answers 2


A bit of googling will probably give you too much information. I'm going to take the position that you facilitate a risk assessment for your project the same way you facilitate a risk assessment for any project. The key is to facilitate; Subject Matter Experts (SME's) will propose risks peculiar to the project.

The number of methodologies for facilitating risk management sessions is roughly equivalent to the square of the number of people involved. I'll offer up two that I think are most useful.

  • the one which is most applicable to your project is to gather everyone for a pre-emptive post-mortem (a pre-mortem). Put up a calendar for 1 month after the projected delivery date and announce that everyone is here to understand why the project failed. We all acknowledge that we did our best, but the project failed and now we need to understand why. Collect theories on why the project failed. record all the theories, then group similar risks to discover themes.

  • The best approach (impractical for you ) is to collect data for a year and then analyze the data to determine risks. Data is always superior to theory; the only excuse to prioritize theory over data is when there is beer involved. Most people don't have this as an option, but beginning 5 minutes after the facilitation session you should start to gather data, and to prioritize risk analysis based on data over risk analysis based on anything other than data. The session you're going to facilitate will help you to determine what data to collect.

Once you've collected a set of candidate risks, you'll want to iteratively assess, analyze and document the risks, develop risk response strategies, risk indicators, triggers, monitors, etc.

A couple of things I would advise you to do:

  • explain the Godzilla clause and use it heavily. If necessary, assign someone the responsibility of invoking Godzilla. For every concievable project someone will begin to discuss risks that are as damaging as Godzilla, but also as likely as Godzilla. When someone starts discussing risks that are like Godzilla, invoke his name and move on.

  • Keep a parking lot - I can predict that someone in the session will begin to exhibit an obsessive fascination with elements that the rest of the group perceives as less than fully relevant. You need to keep that person's trust by recording their obsession, but you need to stop that obsession from hijacking the discussion. The parking lot is where we record those, and it is your obligation to research the issue and get back.

  • Start with a calibration exercise. A risk session without calibration is like Thanksgiving with your racist uncle; pointless and satisfying only to those with malice. Define likelihood ( If we ran 100 projects like this one, then a rating of 1 indicates that the event would occur 10% of the time or less...) and consequence - (A rating of 1 indicates that the event would adversely affect the schedule/scope/cost/quality by a 10% variance....). Experience indicates that many of the ferocious arguments in risk meetings are really about "I thought medium meant 50%, and you thought it was 75%". That discussion generates heat, not light.

(My boss will not permit discussion of probability - it is sufficient to merely assert that it is not 100% certain and it is not Godzilla improbable. Subsequent analysis (based on data) can refine the value.

A couple of things I strongly advise you never do: * Don't solve the problem - identify the risk. Shut down any attempt to argue over how the risk should be addressed. It is fine to propose one possible mitigation, but don't permit discussion - move on to the next risk.

  • Don't permit any discussion of consequentialism, frequentism, likelihood, bayes, probability, etc. Any time the discussion veers off into nuances that your grandmother wouldn't be able to track while preparing Thanksgiving dinner, drop the hammer. Bayes vs frequentism is fascinating but should only be done when all participants are fortified by an unending supply of pints & pretzels.

  • I have never found it productive to categorize threats into natural hazards and others. If my data center is destroyed by a hurricane, a meteor, a terrorist, or because Godzilla has chosen to nest there, what matters is how to get the data back up and running, not isolating the cause.

  • Develop a threat model and decompose that threat model into categories, then collect your SME's and ask them to rank the categories on likelihood and probability. (DOD and the US Government eat this up - they adore this kind of paralysis by analysis.)

I've got to stop before I write a book.


Use a Risk Breakdown Structure to help the team facilitate analysis.

See Risk Breakdown Structure, Risk Doctor

This works just like a WBS or OBS, and breaks down threat areas in a logical manner to a more discreet level of specificity, enabling you and your team to ask the types of questions that will enable you to identify the threats on your project.

Once you get the structure of your facilitated work sessions, then you need to combat the human psychology of all of this, where you need to work through a set of various biases that sort of inhibit our ability to assess threats in a cogent and objective way. Good luck on this last part. Very tough nut to crack.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.