Scarcity Risk
Any resource that you depend on can suffer from scarcity,
Schedule Risk is the term for risks you face because of lack of time.
You could also call this "Chronological Risk" or just "Time Risk" if you wanted to.
Schedule Risk is very pervasive, and really underlies everything we do. People want things, but they want them at a certain time. We need to eat and drink every day, for example. We might value having a great meal, but not if we have to wait three weeks for it.
And let's go completely philosophical for a second: Were you to attain immortality, you'd probably not feel the need to buy anything. You'd clearly have no needs, and anything you wanted, you could create yourself within your infinite time-budget. Rocks don't need money, after all.
Let's look at some specific kinds of Schedule Risk.
Let's get back to the bus (which, hopefully, is still working). What if, when it arrives, it's already full of passengers? Let's term this, Scarcity Risk - the chance that a dependency is over-subscribed and you can't use it the way you want. This is clearly an issue for nearly every kind of dependency: buses, supermarkets, concerts, teams, services and people.
You could also call this availability risk or capacity risk of the resource. Here are a selection of mitigations:
- Buffers: Smoothing out peaks and troughs in utilisation.
- Reservation Systems: giving clients information ahead of the dependency usage about whether the resource will be available to them.
- Graceful degradation: Ensuring some service in the event of over-subscription. It would be no use allowing people to cram onto the bus until it can't move.
- Demand Management: Having different prices during busy periods helps to reduce demand. Having "first class" seats means that higher-paying clients can get service even when the train is full. Uber adjust prices in real-time by so-called Surge Pricing. This is basically turning Scarcity Risk into a Market Risk problem.
- Queues: Again, these provide a "fair" way of dealing with scarcity by exposing some mechanism for prioritising use of the resource. Buses operate a first-come-first-served system, whereas emergency departments in hospitals triage according to need.
- Pools: Reserving parts of a resource for particular customers.
- Horizontal Scaling: allowing a scarce resource to flexibly scale according to how much demand there is. (For example, putting on extra buses when the trains are on strike, or opening extra check-outs at the supermarket.)
Much like Reliability Risk, there is science for it:
- Queue Theory is all about building mathematical models of buffers, queues, pools and so forth.
- Logistics is the practical organisation of the flows of materials and goods around things like Supply Chains.
- And Project Management is in large part about ensuring the right resources are avaiable at the right times. We'll be taking a closer look at that in Risk-First Part 3 sections on Prioritisation and the Project Managment Body Of Knowledge.
By agreeing a time and place for something to happen, you're introducing Deadline Risk. Miss the deadline, and you miss the bus, or the start of the meeting or get fined for not filling your tax return on time.
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.
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.
Opportunity Risk is really the concern that whatever we do, we have to do it in time. If we wait too long, we'll miss the Window Of Opportunity for our product or service.
Any product idea is necessarily of it's time: the Goal In Mind will be based on observations from a particular Internal Model, reflecting a view on reality at a specific point in time.
How long will that remain true for? This is your opportunity: it exists apart from any deadlines you set yourself, or funding options. It's purely, "how long will this idea be worth doing?"
With any luck, decisions around funding your project will be tied into this, but it's not always the case. It's very easy to undershoot or overshoot the market completely and miss the window of opportunity.
For example, let's look at the iPad, which was introduced in 2010 and was hugely successful.
This was not the first tablet computer. Apple had already tried to introduce the Newton in 1989, and Microsoft had released the Tablet PC in 1999. But somehow, they both missed the Window Of Opportunity. Possibly, the window existed because Apple had changed changed the market with their release of the iPhone, which left people open to the idea of a tablet being "just a bigger iPhone".
But maybe now, the iPad's window is closing? We have more wearable computers like the Apple Watch, and voice-controlled devices like Alexa or Siri. Peak iPad was in 2014, according to this graph.
So, it seems Apple timed the iPad to hit the peak of the Window of Opportunity.
But, even if you time the Window Of Opportunity correctly, you might still have the rug pulled from under your feet due to a different kind of Schedule Risk, such as...
On a lot of software projects, you are "handed down" deadlines from above, and told to deliver by a certain date or face the consequences. But sometimes you're given a budget instead, which really just adds another layer of abstraction to the Schedule Risk: That is, do I have enough funds to cover the team for as long as I need them?
This grants you some leeway as now you have two variables to play with: the size of the team, and how long you can run it for. The larger the team, the shorter the time you can afford to pay for it.
In startup circles, this "amount of time you can afford it" is called the "Runway": you have to get the product to "take-off" before the runway ends. So you could term this component as "Runway Risk".
Startups often spend a lot of time courting investors in order to get funding and mitigate this type of Schedule Risk. But, this activity usually comes at the expense of Opportunity Risk and Feature Risk, as usually the same people are trying to raise funds as build the project itself.
If a startup has a "Runway", then the chances are that the founders and staff do too, as this article explores. It identifies the following risks:
- Company Cash: The Runway of the startup itself
- Founder Cash: The Runway for a founder, before they run out of money and can't afford their rent.
- Team Cash: The Runway for team members, who may not have the same appetite for risk as the founders do.
You need to consider how long your staff are going to be around, especially if you have Key Man Risk on some of them. People like to have new challenges, or move on to live in new places, or simply get bored. The longer your project goes on for, the more Staff Risk you will have to endure, and you can't rely on getting the best staff for failing projects.
In the section on Coordination-Risk we'll look in more detail at the non-temporal components of Staff Risk.
A more specific formulation of Schedule Risk is Red Queen Risk, which is that whatever you build at the start of the project will go slowly more-and-more out of date as the project goes on.
This is named after the Red Queen quote from Alice in Wonderland:
“My dear, here we must run as fast as we can, just to stay in place. And if you wish to go anywhere you must run twice as fast as that.” - Lewis Carroll, Alice in Wonderland
The problem with software projects is that tools and techniques change really fast. In 2011, 3DRealms released Duke Nukem Forever after 15 years in development, to negative reviews:
"... most of the criticism directed towards the game's long loading times, clunky controls, offensive humor, and overall aging and dated design. " - Duke Nukem Forever, Wikipedia
Now, they didn't deliberately take 15 years to build this game (lots of things went wrong). But, the longer it took, the more their existing design and code-base were a liability rather than an asset.
Personally, I have suffered the pain on project teams where we've had to cope with legacy code and databases because the cost of changing them was too high. And any team who is stuck using Visual Basic 6.0 is here. It's possible to ignore Red Queen Risk for a time, but this is just another form of Technical Debt which eventually comes due.
In the section on Feature Risk we looked at Market Risk, the idea that the value of your product is itself at risk from the morés of the market, share prices being the obvious example of that effect. In Finance, we measure this using money, and we can put together probability models based on how much money you might make or lose.
With Schedule Risk, the underlying measure is time:
- "If I implement feature X, I'm picking up something like 5 days of Schedule Risk."
- "If John goes travelling that's going to hit us with lots of Schedule Risk while we train up Anne."
... and so on. Clearly, in the same way as you don't know exactly how much money you might lose or gain on the stock-exchange, you can't put precise numbers on Schedule Risk either.
Schedule Risk, then, is fundamental to every dependency. But now it's time to get into the specifics, and look at Software Dependencies.
