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.
Having an event occur in a fixed time and place is mitigating risk:
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.
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.
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:
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.
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.