We get this question a lot. It is referring to the denominator of CD3 (Cost of Delay Divided by Duration). For various reasons, people struggle with this. There’s perhaps an element of bikeshedding involved too, with people generally more comfortable talking about what they know and understand, and avoiding the Cost of Delay part, which is far more consequential.
Nevertheless, it’s a valid question, to which we normally respond with…
What is your most scarce resource?
Remember, CD3 is a scheduling algorithm. It’s not a great tool for making strategic investment decisions. You still need some other way to make those decisions (among others). CD3 then helps you by maximising the outcomes you deliver in a given period of time by minimising the total Delay Cost you incur within a given capacity constraint.
The problem is that most organisations foolishly treat capital as their most scarce resource. Horace Dediu puts it nicely:
“We are obsessed with allocating capital when in fact capital is over-abundant and should be spent freely.”
I’ve previously argued that people and time are your most scarce resource, not capital:
If capital is over-abundant, that leaves two truly scarce resources that we should be primarily concerned with managing carefully: People and Time. This is why Cost of Delay and CD3 matter. Cost of Delay puts a price tag on time for every idea you might want to invest in. CD3 suggests the optimal way of scheduling those ideas. The objective is to achieve the most you can, in any given time period, with a constrained resource: your capacity to innovate.
Most organisations can access additional money if they really need to. For instance, if they came across a great idea that required additional financial investment (i.e. they couldn’t reallocate from some other area) they would still be able to raise new debt or equity to fund it. On the flip side, getting access to additional development capacity is fiendishly difficult. A “wicked problem” even?
Relearning old lessons: Mythical Man-month Edition
You can try to outsource, or hire new staff but there are two main flaws with this approach.
The first flaw is that additional capacity is not like a tap that flows immediately on demand. It takes a lot of time for new staff or outsourced providers to get up to speed. They are often contending with three different learning curves at the same time:- How to work with the tools, technology and existing codebase;
- How to work with each other as a collaborative team, with sufficient trust and psychological safety to be effective, and;
- A deep enough understanding of the problem space they are operating in. What is the true need underlying the problems we are trying to solve.
We also know that adding people to a system increases it’s complexity due to the increase in communication lines required. At some point, the ability to scale requires more overhead in communication than you gain by adding people in the first place. Fred Brooks’ wrote about this over 40 years ago in “Mythical Man-month“. (Unfortunately, each generation of senior managers seems to insist on forcing the organisation to learn this the hard way, again and again.)
The second flaw presents an even bigger problem, however. Even if you do manage to somehow add to your capacity, in the vast majority of cases you will find there are dependencies or integrations that ultimately need to be handled by some of the very same internal capacity that you didn’t have enough of to start with.
Demand outstrips supply (and budget isn’t the problem)
It’s a common thing in large corporates to find that they underspend their IT budgets. Not because they don’t have loads of work to do (they have more than they can handle). Rather it’s because they are constrained in their ability to grow their capacity. This is why we say that we are more interested in how long something is going to block the pipeline for than we are in the cost.
That doesn’t mean you can completely ignore cost though! That’s not what we are saying. It’s not Duration OR Cost, it’s both – but at different levels. In most cases, Cost increases linearly with Duration, so it’s not like you’re completely ignoring it. But if the Benefit Cost Ratio of an initiative is less than unity, you shouldn’t do it at all. That would be dumb. Remember, CD3 is not an investment decision algorithm, it is a scheduling algorithm. Assuming all of the options we are scheduling make sense as investments, at that point I’m more interested in the total return I can generate in a given time period. For that, I need Duration on the denominator.
Nevertheless, if you feel strongly that you need some combination of Cost AND Duration on the denominator, go for gold. Nothing stopping you from doing that. (You could even A/B test Cost OR Duration alongside each other and see what impact the inputs have on the suggested ordering.)
Our main suggestion would be to encourage you to focus more on the numerator. It’s the Cost of Delay part of CD3 where most teams and organisations are weakest.
A typical example
Here’s a case we’ve heard a few times: 2 Features, A and B. Feature A can be delivered in parallel by 5 teams, blocking each of their capacity for 1 week. Feature B can be delivered by only one team, also blocking their capacity for 1 week (leaving the other teams to pursue some other value-adding option. CD3 might tell you these are both of equal priority – but only if you leave your brain at home. To me, the answer is pretty obvious (ceteris paribus). You would of course choose to do Feature B before Feature A.
If this is a common situation in your context, I would suggest using the combined Duration, not the duration it blocks each of the teams involved. In practice, I find these examples aren’t that common and are easy enough to adjust for when you spot them.
The example does however give you some indication of how you might want to set up your teams. As much as possible your teams should be independent of each other and capable of shipping a feature end-to-end. Would Feature A take one team doing it on it’s own 5x as long as Feature B? That would be a better Apples for Apples comparison. Of course, large corporates tend to have dependencies across teams. This is likely to be the reality of your current state. If you have a shared codebase (e.g. internal open source) and grow your capabilities to avoid this, that solves a whole bunch of problems, (the least of which is the scheduling issue!).
Unsurprisingly, no fancy scheduling algorithm can hide the fact that you have a poor organisational design. CD3 is not a silver bullet. Nor is it a reason to leave your brain at home.
Fund, Approve, Schedule, Capitalise…
To summarise, here is a simple guide for what I’d recommend goes where:
1. Fund the Capacity (i.e. the teams). Make adjustments quarterly.
2. Approve the Initiatives, with Objectives, Key Results to monitor success <– use ROI, BCR, HiPPO or whatever you like here! Strongly recommend you don’t overload your capacity with Initiatives. If more than 70% of your capacity is dedicated to top-down “initiatives” you may well be missing out on late-arriving, low duration opportunities with very high Cost of Delay.
3. Schedule MVPs, Experiments, Spikes and Features, <– use CD3 to dynamically order your options here.
4. Capitalise the outputs (ex post)