The ven-diagram of cost/time/quality.


How do we get Senior Leaders onboard?

For the last 8 months I’ve been busy running Product Management training for various Public Sector clients; and one topic cohorts are always keen to focus on and discuss is prioritisation.

Quite often there are multiple areas of prioritisation people are keen to understand further; firstly, how can they get their Senior Leaders to engage with and honour prioritisation; secondly, what tools or techniques can be used to help teams prioritise effectively; and thirdly how often should the backlog be revisited to review priorities.

That first question; how to get Senior leaders to understand, engage and honour prioritise is often the biggest area for discussion. So, what can we do as Product Managers to improve this?

The most important thing to get Senior Leaders to understand is that just because a new scope item has been allocated to the team; it doesn’t mean it’s approved and accepted into the teams working backlog. The Product Lead (Product Owner, Service Owner; whatever you want to call them!) is the one who is responsible for accepting an item into the backlog; and determining whether the team will be working on it and when.

A lot of organisations when first moving to Agile, or embracing Product Centricity, struggle with this concept; and it’s something I spend a lot of time helping organisations and teams to embrace. Whether that’s through the introduction of processes like a ‘Front Door’ process to help senior leaders trigae and agree new work items before they are allocated to any teams for review and prioritisation.

A good front door process helps Senior Leaders begin to engage with prioritisation; doing a like for like comparison of all new work items; discussing the different things that can make a piece of work more or less of a priority in comparison to other work and agreeing which 1 item of work is the most important for consideration; and ranking new work accordingly.

Jigsaw pieces showing the different things that should be considered when prioritising.

After work has been triaged and prioritised at that Strategic level, it is then normally allocated to a Product Team to consider whether it is within their scope or not. It as this point the Product Lead should be reviewing the new work item with their team to determine if enough is known about the new work to prioritise it and agree whether it’s in scope; and if not, why not? If the work is agreed as being in scope; only then is the work accepted into the backlog and prioritised for delivery.

Once a work item has been prioritised within the working backlog (or sent into the car park/ice box because it’s not been deemed within scope or a priority for development) this backlog should then be reviewed regularly to see if priorities have changed or not. When items then reach the top of the backlog, they are likely to be pulled into the Sprint Backlog to be actively worked on by the team.

One thing that is often misunderstood is the link between prioritisation and planning/estimation. I’ve worked with organisations where the Senior Leaders have fundamentally not understood that the work that is prioritised effects the plans; and that the plans and estimates need to effect what work can be prioritised. Quite often the Senior Leaders ‘blame’ delivery teams when plans are not adhered to; but when I talk to the delivery teams; there issue is that too much work, or new work items, have been deemed a ’Must’ priority. No organisation can ever ‘have it all’; usually you can pick two out of three when it comes to the time/ cost/ quality constraints. If time and cost are fixed, then quality (in this instance the amount of work that is deemed essential or a ‘must’ in terms of priority) is the thing that must change.

A ven diagram showing the balance between Cost, Quality and Time. Showing the impossibility of having it all.

Best practice states that no more than 60% of work can be ‘Must’ – this is how we build in contingency for our teams; to aid planning and delivery. When too much work is deemed essential in terms of Prioritisation; then it’s the delivery teams and their ability to effectively plan and manage their work their suffers.

This is where Senior Leaders need to hold the line; and support their teams. When new work comes in, unless the team have got capacity to spare; then it is likely that another item of work needs to move out to make room. We need Senior Leaders to stop asking teams to just constantly ‘deliver more’ – this is not only how teams suffer and people burn out; but also, how delivery suffers, timescales move to the right or budgets get blown.

Back when I started as a Head of Product many (many) years ago, and was responsible for hiring Product people; one of the main qualities I always joked about needing in new Product people was the ability to say ‘no’! Nowadays the main thing I teach new Product folks is the ability to push back and compromise; to explain why we need to make compromises and that not every item of work can be a ‘Must’ in terms of delivery.



, , ,