Identifying Risks

Risks are things that keep people up at night. Not just you, anyone. Taking a risks can make you feel alive, scared, overwhelmed, excited,…

Risks are based on Feelings

People often try to quantify risks. Any project with higher compliance requirements will tell you they estimate Likelihood and Impact, that they then put those in matrix and show which ones are minor, major or critical risks. Apart from helping you pass an audit, these practices also look nice and make you feel safer…
‘Feel safer’. No matter which process you use to quantify risks, it won’t ever remove that it’s all based on feelings. It’s a crucial piece of insight you need when discussing Risks: whatever you think, predict, foresee, expect,… is all based on feelings.

You’re a rope walker, who needs the right amount of skills, confidence and situational awareness to survive. Fear will paralyse you, overconfidence will unbalance you.

Trade-offs and Feelings

Remember this very same header in the “defining quality” section? It’s simple: Risks are the reverse of Quality medal. In a world where you’d have infinite resources you would still need do the same balancing act. They are two different ways to think and talk about the same thing. Ying & Yang, but dealing with them is exactly the same.
From a Quality point of view, in order to increase the fluency and flow for the User Friendliness aspect you gather data to find out where people leave, are blocked or face issues. In the same sense, added monitoring and user tracking, which might help you identify and deal with risks quicker, might infringe on people’s perception of privacy.

Ugh. Feelings? Balancing acts? Can’t measure or quantify any of this? Bah!

– Many people in IT

If you can accept this though, it will help you understand that the things we do in our field to deal with these problems are entirely beside the question. Without going too far into detail, there’s this model called Cynefin. It teaches us that different types of problems need different types of solutions.

If you believe Likelihood x Impact = Importance and your next step is checking several boxes to show the risk is dealt with, you believe the problem space is either Obvious or Complicated.
If you believe that risks are based on feelings which are different on who you ask, are bound to change and might need several possible and probable solutions you may or may not keep or discard, you believe your problem space is Complex or Chaotic

The important distinction is that you understand that nobody has done exactly the same thing as you are right now. There are no best practices, no guidelines, no experts who have done the exact same thing again. Almost by default, your first realisation should be that you are lacking information.

Defining Risks

Following Phase 1: Defining Quality you should have a selection of important Quality Aspects, but more importantly: a better and shared understanding of what’s important for your product and project. This is an excellent starting point to explore and identify potential risks.

1. Gather people with specialities in: analysing, building, testing and operating
2. For each Quality Aspect, One by one:
   • Think about 2 to 3 ways it might be impacted negatively
   • Write down your ideas
   • Include for every risk: Event, Cause, Result
3. Have an open discussion about Risks

Gather people with different specialities

Traditionally, someone doing Risk Analysis would create a spreadsheet, make a list of all the risks they could think of and then consult the following people:

• A Business Analyst to add a number to each risk for Impact. Something like: 1 if there’s almost no loss of money if the risk would happen and 5 if we’d lose a lot of money.
• A lead Developer or Architect to do the same number-game but for Likelihood. 1 if it’s very unlikely the risk would happen, 5 if it could happen any day.

I’m not entirely against this process and especially like the interaction with other roles. However, some things we want to change in RiskStorming:

• Include more specialities into the discussion such as testing & operations
• Invite more people to quantify Likelihood & Impact values
• Use the values, not as goals, but as discussion points

Writing down Risks

“If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.”

Gerald Weinberg – Secrets of Consulting

I’m less strict than the famous Mr. Weinberg and will only ask you for at least two examples of how your plans could go wrong. Yet, seriously take your time to think in different angles about your product and project. Testers are particularly trained in this skill, give them some input and see which questions they come up with.

Once you identified an idea of how something could go wrong it’s not sufficient to just note down ‘Hackers get in and steal our data!’. Though this is a good starting point to discuss further, try to specify three aspects for each risk:

1. Cause: There are inconsistencies between layers of the application, leaving an exploitable gap
2. Event: Someone with malicious intent gains access to the inner workings of our system
3. Result: Data is stolen, removed or worse. We may face lawsuits, lose users and loss of business.

Exploring these three aspects to a risk gives you and the team a better sense of the gravity, possibility and consequences of the problem. You’ll be better informed as well as better prepared to take countermeasures.

Have an open discussion about Risks

Working together, you have now identified several risks that are actually tied to quality aspects that are important. They are well understood and discussed by the team. Nobody should later blush and say ‘oh, I didn’t know that was important’.

For each risk, people who can make an educated guess can specify a likelihood & impact quantifier, others can leave it to ‘?’. These values can help you prioritise, group or use them as a basis for your compliance process.

What’s next?

If you don’t do anything else with RiskStorming at all, having done Phase 1 and this phase with your team, understanding the lessons and taking heed to what you discussed, you’ve taken a huge step forward to building a successful product.

Now that you’ve identified the most probable and dangerous threats on your journey, you’re better prepared and equiped to deal with them. Phase 3 offers your team a whole lot of prompts and ideas to deal with them. Figure out what works for you, discuss and plan.