Prioritisation

Most organisations don’t suffer from a lack of innovative ideas, they suffer from not being able to pick and nuture the best ones, and deliver them quickly enough. Thanks to the consumerisation of IT and software “eating the world” this is getting worse. Innovation and “software development” is already synonymous in most organizations.

“If you are not moving at the speed of the marketplace you’re already dead – you just haven’t stopped breathing yet.” – Jack Welch

So how do we improve the way we prioritise to ensure that we’re delivering value quickly and not wasting our precious capacity to innovate? Some organisations reach for the MoSCoW method, attempting to categorise everything into four groups of priority: Must have, Should have, Could have Would have. The problem with MoSCoW is that you invariably end up with most of the list under the “Must have” category. Trying to get multiple stakeholders to agree over what the must haves are is a bit like an NP-complete problem.

One alternative is the Equity model. The basis of this approach is an attempt at fairness. Usually this is done on an annual basis, where a percentage of development budget is allocated to different departments, stakeholders or  large projects. This approach is still largely blind to value, assuming that the proportions allocated will deliver the most long-term value for the organisation as a whole. This can work,  if there are no dependencies between the different departments, but this is hardly ever true. In most cases, the budgets are set without a proper understanding of the capacity constraints, assuming that development capacity can be turned on and off like a tap. Making this worse, most organisations are not organised along value streams, so there are significant dependencies between teams who usually have no way of making the trade-offs between different demand streams, other than by responding to whoever shouts the loudest. Needless to say, the silos are often in competition with little reference to what matters most for customers, or for the organisation as a whole.

Almost all of the methods typically employed in large organisations end up resembling the Eurovision competition. This is essentially prioritisation by politics, horse-trading and to some extent popularity. To get things done you have to call on favours from friends and make deals – you scratch my back, I’ll scratch yours. To some extent, this can be part of the reason why the fuzzy front end of development is so fuzzy. In this system the rules are dynamic as everyone is trying to work out what the rules are, optimise how to play the system for their benefit. This then drives further changes to the rules as you would expect of a complex adaptive system. This wouldn’t be a problem if it wasn’t for the excessive waste that it drives into the system. Survival of the fittest has delivered some amazing innovation over the eons – but by definition it takes a lot of time and is extremely wasteful.

Organisations who operate with some form of “Agile” aren’t spared this. Scrum has nothing to say about which projects to start, and nothing to say about when to stop and move on to something else. Within the project, most implementations attempt to decouple prioritisation by deferring to what we like to call the HiPPO model of prioritisation. This is where prioritisation is mostly driven by the Highest Paid Person’s Opinion. Ever found yourself doing something that everyone on the team believes is mad, but someone much further up the food chain has made apparently made a commitment that everyone feels powerless to do anything about? Welcome to HiPPO-land. If you happen to find yourself with a HiPPO that scores high on the Epistemic Humilty scale, then you’re in luck – they will probably seek out the opinion of others and rely more on data-driven decisions with small experiments that are safe to fail. Unfortunately, these people are often not the ones that get promoted to these positions. You’re far more likely to be assigned a HiPPO that suffers from Epistemic Arrogance: blind to what they don’t know, and prone to making bold commitments rather than keeping options open.

Perhaps there’s a better way?

How to survive in a world where stakeholders want it all CD3
Since economics is all about scarcity, we can turn to economics to help us quickly discover, nurture and speed up the delivery of value. We need to understand value and urgency of the options and know the Cost of Delay. We can then use CD3 to prioritise and improve ROI.

Comments 3

  1. You really make it appear really easy with your presentation but I in finding this matter to be really something which I
    feel I’d by no means understand. It sort of feels too complicated and very vast for me.
    I am looking forward to your next post, I’ll attempt to get the hold of it!

  2. hello – we had a great presentation from Ozzie Yuce at Barclays today (11 Oct 2017). Clearly presented and articulated with real-life examples.

    One question i thought about after the session was how do you incorporate CoD into backlogs where you have inter-dependencies – so if i calculate CoD in one backlog – it may push an item required by another item down the priority list which has a large cost of delay.

    I’m sure i don’t want to be calculating CoD for all my dependencies and cross-referencing their backlogs!

    Any tips on what approaches to take here?

    thanks,
    Sheeraz

Leave a Reply

Your email address will not be published. Required fields are marked *