Fork me on GitHub
Risk First Logo

Home of Risk-First Software Development



Start Here


Home
Contributing
Quick Summary
A Simple Scenario
The Risk Landscape

Discuss


Please star this project in GitHub to be invited to join the Risk First Organisation.

Blog


Consuming Hacker News 14 May 2019
Twitter Cards 22 March 2019
Next - Scrum? 7 March 2019
Available On Amazon 25 February 2019
New Proof 10 February 2019

Publications



Click Here For Details


Under Construction

Software Project Scenario

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.

Taking action changes reality, but it changes your perception of the attendant risks too

Today’s Action

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.

Attendant Risks

What are the Attendant Risks that come with that goal? Here are some to get us started:

  1. The users can’t access the system
  2. The data gets lost, stolen.
  3. The data is wrong or corrupted
  4. There are bugs that prevent the functionality working
  5. The functionality isn’t there that the user needs (Feature Risk).
  6. Our Internal Model of the market is poor, and we could be building the wrong thing.

I’m sure you can think of some more.

Our Goal, With Attendant Risks

Evaluating The Risks

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:

A Single Attendant Risk: Getting Hacked

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:

Ashley Maddison

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?

Attendant Risks of Improved Security

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.

Actions Are Dependent On Risk Evaluation

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.

Tacit and Explicit Modelling

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.