Cost of Delay and CD3 Prioritisation at Scale

“How to generate the highest Return On Investment toward strategic priorities — across multiple teams that need to work together.”

I get asked this question a lot. I’ve also seen lots of slow, disjointed, unresponsive and generally painful ways to approach this — and in lots of different organisations.

Rather than poking holes in alternatives, here’s how I would recommend approaching it:

Step 1: Start with Strategic Outcomes

The first thing we need is to seed the system with some Value and Urgency signals. For that, I’d suggest starting with your organisation’s strategic priorities. These are the things that are likely to be on the radar of the Exec team, so it probably makes sense to at least start there.

Work out the Cost of Delay of the strategic outcomes. Crucially, this needs to be outcome focused (i.e. what will be different NOT input focused (i.e. days or hours of a team) or output focused (i.e. deliver feature X and Y or implement predetermined solution Z). Ideally, this would be expressed as $X/month or some similar common “currency” that works across ALL strategic initiatives. It could be "Baby Rhinos saved per year" but you need an Apples to Apples way to compare. It also doesn't need to be super accurate: is it worth thousands or hundreds or millions of dollars per month? An order of magnitude is often a "good enough" starting point. If you need more detail to break a tie, you can always drill into that later. Here's a framework for thinking about value if you get stuck.

Step 2: Teams Generate Options

Bring the Teams together (preferably face to face in one location) to generate options for how they might together contribute towards the desired strategic outcomes. Be careful not to predetermine or anchor them around what the “best” way might be. Be clear about the outcome, but have an open mind about how to achieve that outcome. At this point you want divergence, not convergence. If, together, the teams can't think of at least three different ways to contribute to the outcome then you're not giving them enough time or space or safety to come up with options. Don’t prematurely close down paths at this point! You should also ignore the cost or time it might take – we cover this in the next step.

To be clear, these options don’t have to fully deliver the outcome or solve the problem either. Some options may only contribute 10 or 20% toward the desired outcome. (Don't bother going down to 12% or 17.2% contribution. 10% increments is good enough at this point. If you need to break a tie, that comes later.) Obviously, doing this needs the full team, including whoever has the most knowledge about the desired outcome and can help guesstimate the % contribution.

So, now you should have a rough Cost of Delay for each option. This is the numerator of CD3.

Step 3: Rough Size Duration for Each Team

Now ask the Teams to guesstimate (this only needs to be very rough!) what their Team’s input is likely to be for each of the different options. I prefer to use Days vs Weeks vs Months vs Years as a good enough approximation. Again, breaking a tie comes later, so don't waste time on too much detail at this point. In most cases you don’t need that level of precision. Express all of these into a common unit. (I prefer weeks as the common unit, but as long as you are consistent, it really doesn't matter.)

Step 4: CD3 – Cost of Delay Divided by Duration

Combine the above into a single CD3 score for each option. For the Duration, take the longest duration of all the different teams. Don't add them up. So if Option A takes Alpha Team 1 week, Bravo Team 4 weeks and Charlie Team 0.2 weeks, then use 4 weeks as the "Duration" for that option.

CD3 assumes it is possible to develop —and ship!— the options independently and in any order. If it’s not – if there are prerequisites, then you need to add the Duration of the non-parallelisable parts. So, if Alpha Team have to finish their component before Bravo Team can start their piece, then the Duration for that option should be the End-to-End Duration for both of them. Using the Durations above, that would be 1 week + 4 weeks = 5 weeks. (We’ll discuss this a bit more later…)

Step 5: Rank by CD3 for each team

Now rank the options for each teams' pieces of work from highest CD3 to lowest CD3. This is of course the local priority, but it has been informed by a global understanding of the Cost of Delay of strategic outcomes. It also gives the required room for teams to figure out (since they are best placed to do so) how best to “move the needle” for each of the desired strategic outcomes. It also takes in to account how long each of the options is likely to block the various pipelines of scarce capacity for.

If you want to, you could also roll up and aggregate these local CD3 rankings into a global view – but it is the local view that is the master. That is the only way any of the top-down strategic outcomes are going to get worked on.

To summarise:

1. Work out Cost of Delay of Strategic Outcomes
2. Teams come together and generate Options and % Contributions toward the Strategic Outcomes
3. Teams guesstimate Duration for those Options
4. Combine Cost of Delay and Duration to get CD3 for each option
5. Order the options for each team by highest CD3

Some things you may observe:

1. There will often be faster and cheaper ways to deliver meaningful contribution toward a strategic priority that is further down the list than if you were to just stack rank by Cost of Delay. (This is a feature, not a bug!) This is why starting with a stack ranking of global priorities is suboptimal: it’s lacking a LOT of crucial information.
2. If the resulting (i.e. bottom up CD3 ranked) global priorities don't look right, perhaps you have gotten the top-down Cost of Delay understanding wrong? If there is some nagging feeling that it's not right, maybe drill into that area and look at the assumed benefits. What might you be missing? Is there some assumed longer-term benefit or risk that you haven't accounted for? Or is it just that there is a lot of lower hanging fruit relating to some of the other strategic outcomes?
3. As tempting as it might be, don't load up the teams to 100%. Not only does this create a traffic jam (with not enough slack for the emergence of late arriving information or learning about how difficult something is), it also prematurely closes down options for discovering value that is adjacent to the top-down strategic benefits. The Cost of Delay of these little wins can be truly enormous, so it's a really poor design to shut that down or be blind to it.
4. You may notice that there is excessive demand on some teams — that they are a dependency for lots of strategic initiatives. It's even more important that you don't overload these teams. Instead, try to figure out ways to shorten the cycletime and possibly expand the capacity you have in that area. Be careful though! Adding people doesn't always solve the problem. Fred Brooks wrote Mythical Man Month more than 40 years ago.
5. Likewise, just because other teams aren't getting a tonne of demand, that doesn't mean that a) that might not change in the future or b) that they aren't still adding lots of value — just that it's perhaps not on Exec’s radar or on the anointed strategic priorities list this quarter. As always, make adjustments to teams slowly and organically. Team capacity isn't a tap that you turn on and off. It can take months to get going again, so make small adjustments, not abrupt, sweeping changes. Tend to your garden of capacity. New growth takes time.
6. Do you notice any tied-CD3 priorities at the local level? Remember, it's only contention at the local level that matters. Global priorities emerge from the inputs, so tied at Global doesn't matter at all. If tied, consider the Cost of Delay parameter first. Could you halve the order of magnitude bucket size for either of the initiatives? In doing so, that will recalculate ALL of the CD3 scores for the parts, so you may end up creating new “ties”. Keep going breaking ties like this until local CD3 priorities have a clear enough separation. Depends on the number of teams, but if it takes more than three, I'd be surprised. The other thing to consider is the value of information. The numbers don’t have to be precise, remember: the result we are looking for is a sensible ordering of options. Don’t get stuck in analysis paralysis when it has next to no impact on the resulting order.
7. Prerequisite Dependencies. Ah, the bane of corporate life and complex technology landscapes often full of technical debt. As mentioned, raw CD3 ranking assumes that each option can be delivered (yes, to production!) independently. If it can't, I'd first look at how you can systematically (as in permanently) and tactically (for the purposes of this option alone) improve the independence of the teams. Let me put this in bold, so that the point is not lost down here in the weeds: CD3 is not supposed to solve complex sequencing needs between interdependent teams. Rather than looking for a fix, maybe try not having that problem?

Having said that, I know (from bitter experience) that this is a technical reality in many large organisations. Assuming we are already investing as much as we can to improve independence, I’d suggest making adjustments to the raw CD3 scores to reflect the fact that prerequisite dependencies have to be delivered before other pieces. To do this, adjust the Duration for calculating CD3 to be not just one teams' duration, but the duration of the entire required sequence. Obviously this adjusts the CD3 score across all of the parts, to reflect that that option actually blocks the combined pipeline (before any value is delivered) for much longer. (Before, this option was basically cheating.) That doing so penalises the CD3 score (and therefore the priority) is a good thing. It should encourage both investment to make teams more independent, and it should also encourage the surfacing of options that avoid prerequisite dependency, resulting in shorter Durations.

1. You may also notice that if you are measuring throughput capacity, you could also produce a forecast of when each options is likely to come out of each team’s pipeline. This helps with adjusting Cost of Delay for prerequisites and other parts.

OK. Hope that helps. There’s a bunch of related things that I might recommend depending on your context, but this is a decent starting point — one that I’ve said many times, but haven’t written down for wider consumption yet. If any of this doesn’t make sense, please let me know and I’ll try to clarify!

/Joshua