Where do the risks of the project lie?
How do we decide what needs to be done today on a software project?
Let’s look again at the simple risk framework from the introduction and try to apply it at the level of the entire project.
How should we decide how to spend our time today?
What actions should we take? (In Scrum terminology, what is our Sprint Goal?).
Let’s say that we are working in a Startup, on a project building an online service. As we discussed previously, we could call this a Goal, but we could also restate it as mitigating Risk, which gives more clarity about our intentions. For the startup, launching the Online Service is about mitigating (Funding-Risk), in order to keep the startup alive.
What are the Attendant Risks that come with that goal? Here are some to get us started:
I’m sure you can think of some more.
Next, we can look at each of these risks and consider the threat they represent. The same Attendant Risks will be evaluated differently depending on the nature of the project and the mitigations you already have in place. For example:
Let’s consider a single risk: that the website gets hacked, and sensitive data is stolen. How we evaluate this risk is going to depend on a number of factors:
In 2016, Ashley Maddison, a website specialising in aiding extra-marital affairs, suffered a data breach, revealing the personal details of all of their clients on the Internet. The sensitive nature of their business contrasts sharply with the reported sloppiness of their security arrangements.
Can our risk model explain what happened here?
This story highlights a couple of important lessons. First, when exposing a service on the Internet, it’s now a good idea to look for trouble: you should go out and try and improve your Internal Model. Thankfully, this is what sites like OWASP are for: they tell you about the Attendant Risks and further, try to provide some evaluation of them to guide your actions. Second, you shouldn’t expect an organisation with a morally-questionable business model to have your best interests at heart.
So, evaluating risks against one another other allows us to determine what actions we should pursue on any given day, by answering the question:
Which actions give us the biggest benefit in terms of mitigating Attendant Risk?
For example, it’s worth considering that if we’re just starting this project, risks 1-4 in the diagram above are negligible. It makes complete sense from a risk-evaluation perspective that we’re only going to spend time building functionality or improving our understanding of the market.
As we saw in the example of the Dinner Party, creating an internal model is something we just do: we have this functionality in our brains already. When we scale this up to a whole project team, we can expect the individuals on the project to continue to do this, but we might also want to consider explicitly creating a risk register for the whole project.
In the next section, we’re going to take a quick aside into looking at some risk theory around this.
Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.