Prioritise my stuff first!

Seeking inspiration in what to say to a project which desperately wants it’s stuff prioritised first? Try this…

Hi project!

Our delivery team is committed to managing the capacity of our development pipeline in a way that provides the best outcome for the company as a whole. We use CD3(cost-of-delay divided by duration) as a framework for prioritisation since this maximises the company’s overall return-on-investment.

Using this approach, if the work you need us to do is not prioritised straight away, we will explore the following options together with you:

Wait. The project shouldn’t start any related work until the bottleneck resource is finished with higher priority work.

Redesign the solution to reduce the scope of the work required. Smaller pieces of work block the pipeline for shorter periods and increase the CD3 priority score (if the cost-of-delay remains the same).

Redesign the solution such that the work is not is not needed. This can either be by pursuing a tactical solution which later will be replaced or by finding some way of not needing that functionality after all.

Increase capacity at the bottleneck. This could be temporary or permanent. If we see it as a temporary bottleneck, the best would be that other project members go help with the bottleneck for a while if they have the skills (T-shaped individuals, please!)

Abandon project. It may be that the project simply isn’t as valuable as other projects we could work on and we don’t see this changing any time soon.

We believe these options create value for the company. There are two further options which generally don’t add value for the company:

Start more work in parallel. It’s finishing work that makes a difference, not starting it. Starting too much at once means that we lose focus, overhead/switching/coordination costs increase and some value is delivered later than would otherwise have happened.

Complain to senior management to get the priority score of the work increased. This can be by increasing the cost-of-delay for “strategic reasons” or because we have “suddenly” found some extra $ benefits of the project. If this kind “tampering” really really can’t be avoided, we insist that it is the cost-of-delay which is manually adjusted such that the increased urgency of this work is communicated to all teams that are involved in producing the feature. This way we avoid a situation whereby one team considers a feature very urgent and another team considers it less urgent.

In the interest of the company as a whole, we want to steer you away from these last two options. “Removing roadblocks” is often perceived as a core skill in our management culture but exercising either of these option is not normally removing a roadblock to value creation.

We look forward to exploring this further with you to get the best outcome for the company as a whole!