Identifying risks in our software development projects
Risks are everywhere around us in our life and our brain uses ways to determine whether we should react to it or not. Let’s see some examples: you are walking down the street, get to the corner, the light is red, drivers have their cars stopped and the pedestrian signal says “walk”; without even think about it, you’ll cross the street. But, if the same situation happened on a corner without lights and cars coming from the left at a considerable speed, you would look and choose when to cross the street, finding the safest moment to do it.
At some point, in just a few milliseconds, the brain assesses the situation and determines what could go wrong and what the consequences would be. Immediately after that, the decision is clear: cross or wait.
We do exactly that when developing software, documenting it so everybody knows about the system. And we do that so we can determine a mitigation plan (waiting for a bit before crossing or just use another corner to cross in the example above). The process is very simple and consists in assessing two variables: likelihood and impact.
Likelihood: the chance of something, unexpected at this point, to happen.
Impact: how much it will affect the project.
In both cases we can use a range that goes from low to very high, having 2 or three steps in the middle: low, medium, high, very high.
But, what is risk? Everything that could go wrong? Well, not really: it is about things we can’t control. Let’s say we need to buy a printer for a project, the risk won’t be our ability to buy it, but the likelihood of not getting the money from the accountant or a delay in the shipping.
In four easy steps, the process will be:
- List the risks
- Determine the likelihood and impact
- Think of a mitigation plan
- Add a cost of the mitigation plan
Lets see an example:
( * ) numbers are for the solely reason of explaining that risks can be measured
