Skip to main content

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:

  • "The bus to work leaves at 7:30am" or
  • "I can't start shopping until the supermarket opens at 9am".

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:

  • By taking the bus, we are mitigating our own Schedule Risk: we're (hopefully) reducing the amount of time we're going to spend on the activity of getting to work. It's not entirely necessary to even take the bus: you could walk, or go by another form of transport. But, effectively, this just swaps one dependency for another: if you walk, this might well take longer and use more energy, so you're just picking up Schedule Risk in another way.
  • Events are a mitigation for Coordination Risk: a bus needn't necessarily have a fixed timetable. It could wait for each passenger until they turned up, and then go. (A bit like ride-sharing works). This would be a total disaster from a Coordination Risk perspective, as one person could cause everyone else to be really really late.
  • If you drive, you have a dependency on your car instead. So, there is often an opportunity cost with dependencies. Using the bus might be a cheaper way to travel, so you're picking up less Fuding Risk by using it.

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:

  • Don't build into your plans a need to start shopping at 9am.
  • Arrive at the bus-stop early.

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:

  • The funding on the project runs out, and it gets cancelled.
  • You have to go back to a budgeting committee to get more money.
  • Members of the team get replaced because of lack of faith.

.. 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:

  • Schedule Risk is continuous, like money. i.e. you want to waste as little of it as possible. Every extra day you take compounds Schedule Risk additively. A day wasted at the start of the project is much the same as a day wasted at the end.
  • Deadline Risk is binary. The impact of Deadline Risk is either zero (you make it in time) or one (you are late and miss the flight). You don't particularly get a reward for being early.

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