A Tool For Your Toolbox: Risk Poker
This is an idea that I read about in Managing the Design Factory (detailed outline). Around page 226, Reinertsen says:
Let us start with the first source of technical risk, the high-risk subsystem. Which subsystems have high technical risk? To assess this we must perform our project-level analysis to determine how each program objective (expense, cost, performance, and speed) will impact profits. Then we assess each subsystem to determine how it might impact each of these factors. The easiest way to do this is to use a team meeting in which members estimate the downside risk for each subsystem in terms of magnitude and probability. This can be done by having each member assess risks independently, having a discussion on why different team members have rated risk differently, and then having team members reassess risks. The output of such a meeting is a surprisingly good understanding of project risk. Contrary to the common view that unknown risks are most important, most teams are surprisingly aware of where they are likely to fail in a program.
This reminds me so much of the Agile practice of planning poker that I’m dubbing it “risk poker”. Both practices make sense to me because they use crowdsourcing to solve the problem. I think software teams are more aware of the risks on the project than they typically give themselves credit for, leading to the paradoxical value of this practice. By doing this practice, teams make explicit the knowledge that they already have but are often hesitant to act on for one reason or another.
While doing some basic research to see if this term had been employed yet, I also stumbled across protection poker, which deals more with security risks.
Perhaps I’m reinventing the wheel and risk poker is a well-known concept with a different name. Has anyone employed something like this on a project?
next post: Review: Managing The Design Factory
This fascinates me. I have performed some “Hazard Analysis” for a couple of projects that I worked on. It was a completely different mindset than what you are talking about, but we did it in a very similar fashion. At least 2 people sat down and came up with all the hazards they could think of, then we came together and did even more brainstorming.
I strongly agree with this approach! Whatever cliche you’d like to use – two heads are better than one in many ways. I find that I think of hazards in a different way than say, David Mott does. Together I felt like we had a very BROAD coverage of hazards. And together we could easily weigh each hazard effectively.
I’d be interested to see/hear your results of using this approach for risks. I assume this would be something done at the early stages of a project? Or perhaps iteratively as the project progresses and/or scope changes?
To answer your question – we didn’t have a name for it, we simply called it “brainstorming”.
I haven’t actually used this technique, just thought that it made a lot of sense. It seems like you guys have done something very similar, and it worked out well. I would think about doing this periodically throughout the project.
When I’ve worked on projects, I have a pretty intuitive sense of what is going to take a long time because we aren’t sure about the requirements or the technology. It seems helpful to formalize this, even if you are on a solo project, because it keeps you from slowly rationalizing away perfectly valid concerns.
Thanks for your comment, it was quite helpful in seeing that people I know have been doing something like what the post suggested!