Discover more from The Forcing Function
#003 - How to prioritise, not just set priorities
Welcome to Issue #003 of The Forcing Function - your guide to delivering the right outcomes for your projects and your users.
🤔 Made me think: When your stakeholders aren't aligned on what the user truly needs.
👨💻 Worth checking out: One tip from Brad Feld and a fantastic yet simple approach to brewing your own coffee.
What links the effective triaging of battlefield injuries with overcoming the constraints on a software delivery project?
In the early 1800s, the Napoleonic Wars raged across Europe.
Millions perished in the conflict. From this dark period of European history, one innovation meant that some didn't needlessly perish. That was the development of modern medical triage.
Perfected by Dominique Larry, his triage system treated the wounded by the gravity of their injuries and the urgency of medical care. Not by how high-ranking they were, or by their nationality, or if they were friendlies - as was the norm.
Larrey's approach resulted in a far more effective use of the limited time and dire resources in the heat of battle to save as many of those who could be saved. His system accepted that not everyone could or should be saved.
Whilst there are no parallels to the literal life and death decisions that Larrey's system had to cope with, the same question persists to this day for projects: when you have constraints, how do you achieve the best outcome that you can?
In place of Larrey's lack of surgeons and reliable drugs, it's the classic complaint of not enough time, not enough money, and too much to do that you often hear in software delivery projects today.
But let's take a minute here. What's needed versus what's being asked for? And how much is enough for a successful outcome?
MoSCoW only tells you the priority level - not how to prioritise
So, we need to prioritise what needs to be done. In business analysis, one of the more widely-used prioritisation techniques is the MoSCoW.
This acronym simply stands for each of the priority levels you can classify a requirement into:
Won't Do (for now)
Whilst that's useful for classifying what should be delivered first, the elephant in the room is that MoSCoW still doesn't tell you where each requirement does go.
Take these two examples:
For a customer facing product: The development team may want to build this new exciting feature. Versus the the customer support team who just want the existing features to work better to reduce the number of support cases and customer complaints.
For a solution used internally: The end user may want to see all their customer data in once place - regardless where the data actually is. Versus the compliance team may want to compartmentalise that same data to minimise the impact of any data breach.
Who's right? Who's wrong? Neither.
Each team has perfectly legitimate reasons but if everything is important, then nothing is important.
So how do you work out and agree what the priority is?
The answer is that it goes back to why you're prioritising. What answer are you looking to get out of doing this exercise?
If you're in the early part of a project and looking for a directional view about what's important?
Then consider a qualitative approach where you gather subjective opinions from your key stakeholders and plot it on a simple 2x2 grid.
ℹ️ Just remember that this can be quicker but can be prone to bias or dominated by strong voices.
Establish the list of requirements that need to be prioritised
Agree what 2x2 dimensions that you will plot each requirement against. Here are a few examples of what each axis could represent. And, if you have time, using multiple 2x2 grids provides different perspectives on the same requirements.
Effort versus impact
Importance versus urgency
Value versus cost
Then, with your stakeholders, determine which quadrant each requirement should go into.
If needed, work out the position of each requirement within each quadrant.
If there are too many in a quadrant (e.g. High Importance + High Urgency), then try force ranking them to identify the weakest and could arguably go elsewhere.
Finally, look at all the 2x2 grids and sense-check with your stakeholders.
If you're in the latter part of a project and looking to build consensus for a formal sign-off?
Then potentially a more quantitive approach is needed. This helps you provide your workings and evidence for the prioritisation as well as constraining any different opinions to the numbers.
One technique I would use here is to run a weighted score exercise to calculate the relative "value" of each requirement against a set of dimensions that are weighed by importance.
ℹ️ Just remember that estimated numbers are still estimates.
Establish the list of requirements that need to be prioritised.
Agree a standard set of dimensions that each requirement is going to be measured against. These could include:
Size of users / customers that this benefits
Value to the user / customer
Level of effort to delivery
Level of effort to maintain
Regulatory / compliance impact
Establish a standard scoring scale and how that's used for each dimension (e.g. 1 to 5 where 5 is the optimal for that parameter).
Determine the weights that will be applied to each parameter so that more important dimension have a larger share of the 100% across all dimensions.
Then, with your stakeholders, score each requirement against each dimension and calculate the overall score for each requirement.
Finally, use the overall scoring to establish the prioritised order of requirements and do a sense-check with your stakeholders.
There are a number of other prioritisation frameworks and techniques - some far more advanced than the ones described above.
Regardless of which you use: it's not just setting priorities, it's knowing why you need to prioritise and thus how you should prioritise that's key.
PS: Larrey's humanitarian belief to triage friendlies and enemies alike saved his life when he was captured by the Prussians. It was only when he was about to be shot that he was recognised as the surgeon who had earlier saved the Prussian general's son life.
🤔 Made me think
When your stakeholders aren't aligned on what the user truly needs.
Those of you who have been involved with software delivery projects will likely recognise the modernised versions of this classic cartoon.
It shows the issue you have when you have different stakeholders each with their own view of what's needed, their own agenda, and their own outcomes they want to achieve. More often than not, these outcomes contradict other stakeholders and the user ends up not getting what they wanted - let alone, needed.
Although it's unclear when the original illustration was published (apparently from the 1960s!), this "division of labour" continues to be a longstanding issue in projects today.
One of the key benefits of business analysis is effective stakeholder management which mitigates this issue. Not just by getting everyone aligned to what the user truly needs but also ensuring that everyone keeps aligned to that tenet throughout delivery.
🧑💻 Worth checking out
One tip from Brad Feld and a fantastic yet simple approach to brewing your own coffee.
🔗 What Are We Trying To Get Out of This Section (Brad Feld): A simple yet effective technique to get all the attendees aligned on "what's the ask?". It's so useful that I apply this regularly in my requirement workshops.
☕️ The Ultimate Clever Coffee Dripper Technique (James Hoffman): 6 weeks into using this £25 gadget with Hoffman's technique, I've already put away my highly-engineered coffee maker. This simple gadget is far more manual but it rewards me with delicious coffee and I now look forward to this daily ritual. A lesson for me that not everything has to be optimised.
🖖Until next Thursday ...
If you enjoyed this newsletter, let me know with the ♥️ button or add your thoughts and questions in the comments. I read every message.
And, if your friends or colleagues might like this newsletter, do consider forwarding it to them.
For now, thank you so much for reading this week's issue of The Forcing Function and I hope that you have a great day.
PS: Thanks to P for reading drafts of this.