If you want to make better Product Development decisions, it really helps if you quantify the Cost of Delay. But what if you’re allergic to numbers? Perhaps a qualitative assessment of Cost of Delay would help get you started?
Having helped lots of organisations quantify Cost of Delay across their portfolios, we know very well that it isn’t easy at first – that it takes a bit of mental effort. We also know that it gets easier, and that it’s worth that effort: better decisions, improved prioritisation and a change in the focus of the conversation – less obsession with cost and dates, more on speed and value.
So, we really want to make it as easy as possible to get started with Cost of Delay. We are always looking for ways to quickly explain and put into practice the concepts and thinking. While a qualitative approach would lack many of the benefits of a quantitative approach, perhaps it would at least get people thinking about Cost of Delay? Then when they’re ready, they can build on those foundations and have a go at quantifying Cost of Delay.
So, let’s consider what a qualitative assessment of Cost of Delay might look like…
Value x Urgency
Cost of Delay has two essential ingredients: Value and Urgency. To understand the Cost of Delay you really need to understand both. These ingredients are NOT additive (as some might suggest), but rather they act on each other.
One simple way to represent this would be to put them on a 3×3 matrix. We can put Value on the vertical axis and Urgency on the horizontal, a bit like this:
Now let’s think about what is actually on each of these axis…
Qualitative Value
Let’s take a look at relative value first. To do this, we need to consider Value as independent of Urgency. This can be hard, as we tend to conflate the two together in our heads. In fact, we often make the mistake of treating things that feel Urgent as if they are therefore Valuable – and vice versa.
What is important is seldom urgent, and what is urgent is seldom important. – Dwight D. Eisenhower
Rather than using a simple High, Medium, Low (where everything tends to end up as “High”) we’re going to use some descriptive words for each of the levels. The other reason for doing this is to try and convey that the distribution of value tends to be a non-linear, power law. It is the typical Pareto “vital few” that dominate.
- “Killer” represents the highest band of total value. These are the few things where if we do them, we stand to make an absolute killing, or; if we don’t do something, it will probably kill us. (The challenge, as with all relative/qualitative approaches, is to try and avoid inflation. There should be very few in this highest band, otherwise we end up in MoSCoW Hell, where everything is tagged a “must do”.)
- “Bonus” represents the middle band of total value. What this means will be context dependent (of course), but I’m meaning it in a couple of different ways. Bonus could be those delighting things that we would want to tell our Customers about, perhaps even worth writing a press release for (try writing it before you start development). Customers will (hopefully) like it enough to give us money, or if they are already customers, to stay with us. The other way to think about it, would be that this is valuable enough that if we deliver this (and it works) we’ll grow revenues or reduce costs enough for us all to “make bonus” for the year!
- “Meh” represents the lowest total value band. This is the pocket change stuff. The things that are still valuable and worth our time and effort doing, but they’re not the sort of thing that customers are likely to rave about – more maintenance-level stuff. This is the work that keeps the lights on but won’t get anyone too excited or move the needle significantly.
(If you want to dig a bit deeper, you could think about Value in terms of these four buckets and make a separate qualitative assessment under each of these headings. Value can of course contribute to all four, so these can be added together. Eventually, you might even be brave enough to surface your assumptions behind the qualitative assessment and turn it into a quantitative assessment.)
Qualitative Urgency
Normally, I would recommend considering these four Urgency Profiles – but that requires some effort to understand the rate of change of Value with respect to Time, paying attention to the units on the y-axis. Many of us haven’t used basic calculus since high school, so let’s see if there is a more simple way of approaching Urgency…
A very basic three-category scale of Urgency could go something like this:
- “ASAP” represents the highest band of urgency. If we don’t deliver this ASAP, then the value (whatever total value that might be) will quickly evaporate – someone will get there before us or the opportunity (however big or small) will be massively impaired.
- “Soon” represents the middle band of urgency. If we don’t deliver this Soon, then the value will start to decline or the risk of loss increase – reduced market share, reduced opportunity size. Whether Soon means in a matter of days, weeks or months you will need to decide for your context, given the distribution of urgency you are dealing with.
- “Whenever” represents the lowest band of urgency. What this means is that the total value isn’t massively affected by delay. Most cost-reducing initiatives would normally fall into this band. Other initiatives where there is little or no competition, might also initially fall in this band.
Again, we need to try and think about urgency independently from the value.
How to deal with dates?? An important question, and one that is often misunderstood because the date is (more often than not) simply an internal date and is unconnected with any external effect if things are delayed. At any rate, to handle dates you just have to dynamically shift the urgency. As an example: the urgency could start off as “whenever”, and then as the option expiry date approaches it could shift into “soon” – and then finally, as the option expiry date gets very close it can shift into the “ASAP” band.
Cost of Delay is dynamic, and can change hugely between when you first triage the option and when it eventually becomes urgent enough to start work on it. When quantifying the Cost of Delay it comes as a surprise to many people that most of the things that have a date attached to them start off with a Cost of Delay of $Zero/week. They are so used to using dates as a way of communicating urgency it can take some time for this anti-pattern of coercion by dates to fade away and be rendered obsolete.
(If you want to dig a bit deeper and you’re not afraid of simple calculus and charts, take a look at the four most common patterns of urgency.)
Here’s what these two look like when combined:
A value of “Killer” combined with an urgency of “ASAP!” would result in a “Very High” Cost of Delay. At the opposite end of the scale, a value of “Meh” combined with urgency of “Whenever” would result in “Very Low” Cost of Delay.
One thing to remember is that Cost of Delay is NOT a sum of money, except in extreme examples of total loss due to delay. More typically, the value leaks away gradually – so it is almost always a rate. If you are delayed one week, then the Delay Cost incurred is often a fraction of what it would be if you were delayed by 10 weeks. For this reason, it’s usually better to express Cost of Delay as a rate, like this:
As we’ve already said, the urgency can change, but our understanding of the value at risk can also change. Just because an idea or feature might initially plot as “Meh” and “Whenever” doesn’t mean that it can’t change along both axes.
What to to do with this?
Try using this qualitative framework for Cost of Delay to score each of the ideas, initiatives, that are in your portfolio. You can also try applying it to your teams’ backlog of features. How you go about this is up to you, but I usually find that it’s better to do this as a group, where you can challenge each other’s assumptions and perhaps surface new information. This is also a good way to help avoid HiPPO-driven decision-making.
Better decisions
You may well discover that the Cost of Delay for some of the things you’re working on is different to what you may have expected. We don’t have terribly good intuition about Cost of Delay, so doing this should at least help you focus more on the things that are both valuable and urgent.
Using this, you should start to get a feel for the relative Cost of Delay across the portfolio of features, ideas or initiatives you are working on. If something with a “Very High” Cost of Delay is waiting in a queue or is blocked by something with a “Medium” or “Low” Cost of Delay, you may decide to switch. A good example of this, (which happens naturally in e-commerce businesses) is if a key part of your site goes down then everyone drops what they are doing to fix it. It’s painfully obvious in this case that time is money.
Understanding the Cost of Delay also helps with the hundreds of trade-off decisions, especially those that involve trading off value for time.
Improved prioritisation
You can use this assessment of Cost of Delay to help with prioritisation as well. Assuming that you are dealing with things where the duration is highly variable I would recommend dividing the Cost of Delay by Duration. The CD3 (Cost of Delay Divided by Duration) scheduling algorithm will generate more total value in a given time for a scarce or constrained capacity.
Don’t get hung up on Duration. This can be as quick and easy as a simple T-shirt sizing of the various options. As long as you are consistent, the resulting scheduling should be better than most alternatives. Other, more involved estimation techniques may well be employed already. I’d start with what you already have and use that as your denominator. Going into great detail for estimating duration (or expecting precision) is mostly pointless. The software industry would be doing a lot better if we spent even half as much time and effort understanding the value of what we would like to develop as we do the cost of it.
Change the focus of the conversation
Product Development is an area that is drowning in opinions. One of the few things we can easily track is cost, so we shouldn’t be surprised that so much focus goes on this. This is called Availability Bias, where we concentrate on the things we know and have, even though they may not be the most important thing, or even worse, drive the wrong behaviours.
The same thing happens with dates. Asking when something will be done by is the sort of question any idiot can ask and it takes a very strong individual or group to resist that, or explain why it’s difficult to say. Once the cat is out of the bag though, it tends to be the thing that gets communicated as a “deadline”, even when the Cost of Delay beyond that date is exactly the same as the Cost of Delay before that date (an all too common scenario, I’m afraid).
When we understand and can easily communicate the Cost of Delay though, we now have something far more valuable to focus on. We tap into a human bias to be loss averse and we can quickly understand the need for end-to-end speed. We can quickly and easily make trade-off decisions and priority order can be quickly determined. We don’t need the Cost of Delay to be precise for this to work. In the land of the blind, a one-eyed person is King. Perhaps qualitative Cost of Delay is the start of being able to see, even poorly.
If you’re spending tens of thousands of dollars a week, it should be embarrassing that most people involved don’t know whether a week of delay is worth $1,000 or $100,000. Product Development is riddled with trade-offs, and many of them involve trading off time for money. It pains me to think of all the trade-off and scheduling decisions that are made without even a ball-park understanding of the Cost of Delay. Nevertheless, the above qualitative approach will at least get you started with the concepts. Hopefully over time you will find this valuable and maybe see the need to go one step further and quantify the Cost of Delay.