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


Deadline Risk

Let’s examine dependencies on events.

We rely on events occuring all the time in our lives, and event dependencies are simple to express: usually, a time and a place. For example:

In the first example, you can’t start something until a particular event happens. In the latter example, you must be ready for an event at a particular time.

Events Mitigate Risk…

Having an event occur in a fixed time and place is mitigating risk:

But, Events Lead To Attendant Risk

Action Diagram showing risks mitigated by having an _event_

By deciding to use the bus we’ve Taken Action. By agreeing a time and place for something to happen (creating an event, as shown in the diagram above), you’re introducing Deadline Risk. Miss the deadline, and you miss the bus.

As discussed above, schedules (such as bus timetables) exist so that two or more parties can coordinate, and Deadline Risk is on all of the parties. While there’s a risk I am late, there’s also a risk the bus is late. I might miss the start of a concert, or the band might keep everyone waiting.

In software development, deadlines are set in order to coordinate work between teams. For example, having a product ready in production at the same time as the marketing campaign starts. Fixing on an agreed deadline mitigates inter-team Coordination Risk.

Slack

Each party can mitigate Deadline Risk with slack. That is, ensuring that the exact time of the event isn’t critical to your plans:

The amount of slack you build into the schedule is likely dependent on the level of risk you face: I tend to arrive a few minutes early for a bus, because the risk is low (there’ll be another bus along soon). However, I try to arrive over an hour early for a flight, because I can’t simply get on the next flight straight away and I’ve already paid for it, so the risk is high.

Deadline Risk becomes very hard to manage when you have to coordinate actions with lots of tightly-constrained events. So what else can give? We can reduce the number of parties involved in the event, which reduces risk, or, we can make sure all the parties are in the same place to begin with.

Focus

Often when running a software project you’re given a team of people and told to get something delivered by a certain date, i.e. you have an artificially-imposed deadline on delivery.

What happens if you miss the deadline? It could be:

.. or something else. So Deadline Risk can be introduced by an authority in order to sharpen focus. This is how we arrive at tools like SMART Objectives and KPI’s (Key Performance Indicators).

Deadlines change the way we evaluate goals and the solutions we choose because they force us to reckon with Deadline Risk. For example, in JFK’s quote:

“First, I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth.” - John F. Kennedy, 1961

The 9-year timespan came from an authority figure (the president) and helped a huge team of people coordinate their efforts and arrive at a solution that would work within a given time-frame. The Deadline Risk allowed the team to focus on mitigating the risk of missing that deadline.

Compare with this quote:

“I love deadlines. I love the whooshing noise they make as they go by.” - Douglas Adams

As a successful author, Douglas Adams didn’t really care about the deadlines his publisher’s gave him. The Deadline Risk was minimal for him, because the publisher wouldn’t be able to give his project to someone else to complete.

Deadline Risk and Schedule Risk

Schedule Risk and Deadline Risk are clearly related: they both refer to the risk of running out of time. However, the risk profile of each is very different:

So, these are two separate concepts, both useful in software development and other fields. Next up, something more specific: Software Dependency Risk.

Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.