A collaborative and visual technique for identifying risk

One of the key functions of the software architecture role on software development projects is the identification and mitigation of risks, particularly those that have the potential to cause your project to fail or you to be fired! This all sounds very sensible but assembling a list of risks is often seen as a boring task and it's often neglected. Furthermore, if that list is assembled, it will typically only represent the viewpoint of one person. Like estimates, risks in the real world are rather more subjective than they ought to be and for this reason alone, it makes sense to get input from more than just a single person, especially if that person is the solitary software architect on the team.

I talk about risk on the Software Architecture for Developers training course and use a technique I call "risk-storming", which is a collaborative and visual way to identify risk. There's more information about this in the Software Architecture for Developers book, but here's a quick summary.

Step 1: Draw some sketches

Draw some sketches of your software architecture. I typically use my C4 approach (context, containers, components and classes) but any approach that gives you a small number of different diagrams at different levels of abstraction will do the trick.

Step 2: Identify risk individually

Get the whole team together and ask each person to individually (because risk identification can be subjective) identify the risks and score them based upon probability and impact. If you multiply the probability and impact scores together (see diagram below), you'll come up with a number and you can use these numbers to group the risks into low (1-2), medium (3-4) and high (6-9) priority. Ask everybody to write each risk they identify on a sticky note, preferably colour-coded according to the score that you come up with. Timeboxing this exercise (10-15 minutes) can work well.

Risk scoring

Step 3: Converge risks on the sketches

Ask everybody to place their sticky notes on the sketches. For example, if you identified a risk with a component that may perform too slow, place the sticky note representing this risk over the top of that component on your sketch. If you see duplicate risks, just overlap the sticky notes rather than removing them from the sketches.


Step 4: Discuss and prioritise

As with software development estimates, some people may not agree on the probability and impact of some risks, so further discussion and prioritisation may be needed.

You still need to mitigate your risks

Now you should have a nice "at a glance" view of where the risks are across your software architecture, which might include everything from the use of new technology through to design complexity and infrastructure becoming unavailable at runtime. If you've used different colour sticky notes to represent different priorities of risk, it should be very obvious where the riskiest areas of your software architecture are. If you've ever struggled to sell a prototype to your management, this sort of picture may really help. Don't forget that you still need to deal with or mitigate those risks though!

About the author

Simon is an independent software development consultant specialising in software architecture and the author of Software Architecture for Developers. Simon lives in Jersey and regularly speaks to audiences around the world. You can find Simon on Twitter at @simonbrown and .

consider scale Re: Risk-storming

Consider the scales. A medium impact may be 10 times the impact of low impact item; a high impact item may be 100 times. Considering the impact in terms of story points or $s or time can help adjust the scale. Likewise, a highly risky item may be much more than 3 times as risky as a low. Low risk might be 5% whereas high risk might be 75%. Depending on the scale, you may need to consider ALL your high impact risks first. Or maybe you may need to consider ALL your high probability risks first. Furthermore, large programs should probably use a Monte Carlo simulation to compute a risk adjusted schedule. Using the type of computation above to figure a schedule or cost adjustment would be a misapplication of "Expected Value" since (1) we aren’t dealing with discrete random variables, (2) the risks aren’t coming from one population of data (one random variable from one distribution), and (3) we generally aren’t repeating the experiment a large number of times, or at the very least aren't interested in the expected value over a large number of releases, but rather something more like an 85% confidence interval for THIS release. Another thing to consider is that distributions in IT scheduling are more likely to be Weibull distributions than normal distributions (they are likely to have a long tail). The authority on all this is a colleague of mine, Troy Magennis: http://focusedobjective.com/

Add a comment Send a TrackBack