While Reliability Risk (which we met in the previous section) considers what happens when a single dependency is unreliable, scarcity is about quantities of a dependency, and specifically, not having enough.
In the previous section we talked about the reliability of the bus: it will either arrive or it wont. But what if, when it arrives, it’s already full of passengers? There is a scarcity of seats: you don’t much care which seat you get on the bus, you just need one. Let’s term this Scarcity Risk, the risk of not being able to access a dependency in a timely fashion due to its scarcity.
Any resource (such as disk space, oxygen, concert tickets, time or pizza) that you depend on can suffer from scarcity, and here, we’re going to look at five particular types, relevant to software.
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” (become profitable) before the runway ends.
Startups often spend a lot of time courting investors in order to get funding and mitigate this type of Schedule Risk. But, as shown in the diagram above, this activity usually comes at the expense of Opportunity Risk and Feature Risk, as usually the same people are diverted into raise funds instead of building the project itself.
Since staff are a scarce resource, it stands to reason that if a startup has a “Runway”, then the chances are that the founders and staff do too, as this article by Entrepreneur.com explores. It identifies the following risks:
You need to consider how long your staff are going to be around, especially if you have Key Person Risk on some of them. People like to have new challenges, move on to live in new places, or simply get bored. Replacing staff can be highly risky.
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. Anything you wanted, you could create yourself within your infinite time-budget. Rocks don’t need money, after all.
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 whims of the market, share prices being the obvious example of that effect. In Finance, we measure this using price, 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:
… 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.
Student Syndrome is, according to Wikipedia:
“Student syndrome refers to planned procrastination, when, for example, a student will only start to apply themselves to an assignment at the last possible moment before its deadline.” - Wikipedia
Arguably, there is good psychological, evolutionary and risk-based reasoning behind procrastination: if there is apparently a lot of time to get a job done, then Schedule Risk is low. If we’re only ever mitigating our biggest risks, then managing Schedule Risk in the future doesn’t matter so much. Putting efforts into mitigating future risks that might not arise is wasted effort.
Or at least, that’s the argument: if you’re Discounting the Future To Zero then you’ll be pulling all-nighters in order to deliver any assignment.
So, the problem with Student Syndrome is that the very mitigation for Schedule Risk (allowing more time) is an Attendant Risk that causes Schedule Risk: you’ll work within the more generous time allocation more slowly and you’ll end up revealing Hidden Risk later. And, discovering these hidden risks later causes you to end up being late because of them.
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 under-shoot 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 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 at statista.com).
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 Scarcity Risk, such as…
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. This is shown in the above diagram: mitigating Red Queen Risk (by keeping up-to-date) has the Attendant Risk of costing time and money, which might not seem worth it. Any team who is stuck using Visual Basic 6.0 is here.
Here are a selection of mitigations for Scarcity Risk in general:
Much like Reliability Risk, there is science for it:
In this section, we’ve looked at various risks to do with scarcity of time, as a quantity we can spend like money. But frequently, we have a dependency on a specific event. On to Deadline Risk.
Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.