I typically advocate using cost-of-delay as the basis for prioritisation since it ensures a development pipeline is optimized for maximising return-on-investment(ROI). The basic CD3 model assumes one development pipeline without any dependencies. This post looks at how three simple rules can be used to adapt the model for multiple delivery pipelines.
CD3 prioritisation model: a quick recap
To briefly summarise the basic CD3 model… prioritisation is about deciding what to do first and what to do later. If a team is to prioritise between doing task A (cost-of-delay $10k/week) and task B (cost-of-delay $20k/week) clearly it makes sense to to choose task B (all other things being equal).
On the other hand, considering only the size of the tasks, task A (4 weeks work) should be scheduled before task B (16 weeks work) since we are getting value out earlier.
So a high priority task should either i) have a high cost-of-delay, ii) be of short duration or, even better, iii) both of these things. To do practically this we assign a numerical priority score to a task using the formula:
We call this CD3 (cost-of-delay-divided-by-duration). Prioritising this way can be shown mathematically to maximise return-on-investment.
In this example case, the priority score for task A is $10k/4 weeks = 2.5 and for task B is $20k/16 weeks = 1.3 so we do task A first as it has a higher CD3 score!
Note: some teams find it simpler to use either cost or effort as a proxy for duration. When this is done correctly, it doesn’t change the validity of the calculation. (The subject of using proxies for duration is outside the scope of this blog post).
CD3 for multiple development streams
Meet Kate. Kate is a project manager who wants to implement a business feature. Most importantly, Kate has already determine that the feature can’t be broken down into smaller pieces – i.e. its a minimum viable product . Kate’s business feature requires changes in both GMM and FTC in order to release business value. Kate has calculated that this feature has a cost-of-delay of $30k/week and she knows that to implement the feature will be 6 weeks work for the GMM team and 3 weeks work for the FTC team.
GMM and FCT have separate dynamic priority lists (DPL – the backlog of prioritised task that the team pulls from when they have capacity). The two teams need to calculate the CD3 priority score in order to know where this task fits in their DPLs compared to the other tasks they could work on.
To calculate the CD3 priority scores, both the GMM team and the FCT team should use the full overall cost-of-delay $30k. It doesn’t need apportioning between them – this makes sense as both changes are needed to realise the business value so delaying any one of them will delay the feature.
Rule 1: Lower level tasks have the same cost-of-delay as the parent business feature
On the other hand, each team uses their own duration. So the priority score for the GMM task in the GMM DPL is $30k/6 = 5 and the FCT task in the FCT DPL is $30k/3 = 10.
Rule 2: Duration is always the duration for the local delivery stream
This rule might come as a surprise – since it implies that there is no overall priority score for the feature that can be used everywhere. Indeed, prioritisation is inherently local since we are always competing for local resources. This needs some thinking about – it implies management directives along the lines of “this feature is top priority” do not maximise ROI (sorry Kate, don’t ask senior management for this). To maximise the return for the organisation, management should say “the cost-of-delay for this is $3m/week” and let teams then work out their own priorities.
Critical path dependencies
There is a further complication that Kate needs to take account of. What if the FCT team already have a lot of high priority work in their DPL and won’t be able to start work on their task for 10 weeks? If the GMM team start work on their task immediately, they will be done within 6 weeks. It will be a further 7 weeks before the FCT team finish and any business value is realised.
Clearly, not a good idea – the GMM team could have worked on something more urgent for 7 weeks and then started on their task. So it would seem that if a piece of work is not (yet) on the critical path for the delivery of business value then the cost-of-delay is zero. In the case of the GMM task, it become on the critical path after 7 weeks and at this point it should then be assigned the full cost-of-delay given above ($30k).
In reality, we probably wouldn’t wait the full 7 weeks to start the GMM work. The risk is too great that if there is the slightest problem with the GMM work, there will be a delay in the delivery of the overall feature. We’d probably start the work after maybe 5-6 weeks or so to be sure.
Rule 3: Cost-of-delay is zero until a task is near to being on the critical path for the business feature
In practice, Kate should identify when tasks are near to being on the critical path and coordinate this between delivery streams. It’s a tricky job because dynamic priority lists(DPLs) are, well, dynamic and the project manager needs to be able to predict them (crystal ball, anybody?).
In the very worst case, Kate might communicate that the GMM team should wait 5-6 weeks before starting only to find out that a flood of higher priority tasks had then suddenly arrived in the GMM DPL. It is now no longer FCT which is on Kate’s critical path but now it’s GMM. If Kate had been able to predict this from the start, she could have avoided this situation by ensuring the GMM task was completed before the sudden rush of higher priority items. Kate might not always get it right but prioritisation is not about getting right every time – its about making the best decision with the information available at the time.
Hopefully, this post has demonstrated that the simple CD3 model can be expanded to multiple delivery streams using three rules:
- Rule 1: Lower level tasks have the same cost-of-delay as the parent business feature
- Rule 2: Duration is always the duration for the local delivery stream
- Rule 3: Cost-of-delay is zero until a task is near to being on the critical path for the feature