Featured

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:

cost-of-delay/duration

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.

Conclusion

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

A common problem in increasing the flow of work through a development pipeline is over-specialisation. The bottleneck might be in getting the analysis done, yet we have plenty of developers who have nothing to do since they have no analysis skills. Then the bottleneck moves to the front-end development yet we discover we have plenty of back-end developers but none who know how to code the front-end. And so on. Enter the T-shaped individual which is a common lean-agile practice applied to address this issue and increase throughput through the development pipeline.

What is a T-Shaped Individual?

A T-shaped individual is not the same as a generalist. He or she has deep expertise in one area but is able and willing to turn his/her hand to other things.

How can I promote this approach?

Teams I have worked with that have been committed to this practice have found the following helpful:

Hire people who want to develop outside their specialism An expert in, say, workflow, is not going to get an opportunity to learn just about workflow. In developing T-shaped individuals, the learning opportunities might be in rules or service bus, business analysis, performance testing etc. New hires have to want this.

Organise around the flow of value If the team are not organised around the flow of value but instead around developing components which are only part of the whole, then there will be little opportunity to develop skills outside one’s own specialism.

Actively manage the skill map One way of doing this is to identify all the different skill areas required to produce value. Then the entire team score themselves against this in one of 4 ways. This skill map is then used helping the team decide who does what and for managing skill development. This also enables team members to learn and develop in the areas that interest them and helps with minimising dependencies on key individuals.

I can teach others

I can do the job with help from others

I can do the job alone

I am eager to learn

Fig. 1. A simple rating of skill level

Try…

Would T-shaped individuals help improve the throughput of your delivery pipeline? Are you willing to make any necessary changes to your hiring practice and organisation?