Published on Wednesday, 28 Mar, 2018
Welcome back to the third post in the 12 months of digital transformation set! Today we’re going to be looking at something that happens every single day, sometimes formally and sometimes unconsciously: prioritisation.
Without even realising it, you prioritise and re-prioritise constantly. By choosing to read this post, you’ve made a decision that it’s worthy of your time over that cup of tea you were going to make, or that email you’ve been putting off writing (thanks!). When left to ourselves we’re pretty good at working out what’s more or less important (even if we don’t always do the important things straight away). But what happens when we need to show our justifications, or when other people are involved? It can start to get a bit more tricky.
In each of the articles I’ve posted so far this year I’ve mentioned prioritisation as an important step. At some point in your project you’re going to need to make some decisions around what’s useful and achievable to do, and in which order; to prioritise. So I bet you’re here to find the best prioritisation activity, eh? Well, sorry, but that’s not the plan.
There are tons of really well documented and widely available informations on how to do prioritisation activities, and I’m not going to reinvent the wheel by rehashing them. Instead of giving you the One Activity to Rule Them All, as usual, I instead want to help you lay the groundwork. This is about you better understanding your specific needs, so that you can work better within your situation.
We’re going to be thinking about all of the things you need to consider before you move ahead to actually doing the prioritisation, and from that, understand the type of activities that could help. We’ll look at a few options for activities, and some other resources. Okay, let’s get started.
A need for prioritisation takes many forms. You could be:
When it comes to my digital transformation work, prioritisation happens in terms of tactical, day-to-day form (“let’s prioritise speaking to people in this department before we have the Directors’ meeting, so that we’re better informed about their ideas”, “I need to get the API docs asap, but we can wait for them to set up access”), and strategic form (“let’s focus on confidently updating this system before we commit to overhauling the entire process at once”, “You should be investing in better training rather than switching your CMS”).
No matter what the situation is, you’ll be aiming to balance factors including importance, impact, and difficulty.
First of all, we’ll need to decide who’s involved in this prioritisation. Is it just you? Is it a group of people you know, like stakeholders on a project? Are you involving other people who you control less, like your customers? Who’s leading the prioritisation, who needs to be actively involved in the decision, and who needs to hear about the outcome?
Once you know who needs to be involved, think about when you need to do some prioritisation. You may think in terms of dependencies, but also think about how these people operate - are they likely to have more energy at certain times or day, or be more stressed at particular points? Try to arrange your activity for when everyone be at their best, and do what you can to hold the activity in a location that makes everyone comfortable.
This might seem obvious, but it’s a really important step to understanding which methods will work best for you.
You also need to be clear on the scope of what you’re working to. What are the things that you’ll be prioritising, and how much time is available to do them in? Is this fixed or will it flex? How many people can help to get things done, and what are their skills and availability? Having a clear understanding of exactly where these boundaries are will help make it easier to prioritise what can be done within them.
Related to this is thinking about people in the sense of importance. When we define how important each of our decision-related elements are, who are they important to? Are they going to be important to different people in different ways, or will we be able to assign them some kind of overall score? Is it even possible to score them - is it possible to be quantitative, or would we need to be purely qualitative?
Likewise with our impact, consider how you’re going to define and compare items on this basis. The elements that we need to prioritise could potentially have all kinds of different impacts: economic (quantitative), customer satisfaction (qualitative), social good, time efficiencies, staff happiness, and more. Who will our decisions impact on, and what would they think? (They may not necessarily be in the room for a prioritisation activity)
Difficulty, complexity, or the time and resources needed can be important to capture alongside other factors in order to establish what’s most important. Are there some things that really have to happen even though they’re incredibly hard, because they’ll make a big difference? Or are there some little tasks that won’t have much of an impact, but will make people happy and are extremely quick to do? When we prioritise we need to have a rounded view of what it means to get things done.
Underpinning each of these elements is the story of where this need came from - why are we discussing it, who has been talking about it, and for how long? Are we unknowingly prioritising those who shout the loudest, rather than quieter voices? Being able to trace back the source of each item on the table will help with giving context to its prioritisation.
Tied to this is the confidence you have in all of your other assumptions. You may have a hunch that a new feature could make you millions, but have no insights to back that up. Conversely, you may have evidence to show that every one of your customers would like a new feature and be willing to pay for it.
If we’ve done some previous prioritisation exercises what worked well and what did we need to improve? What can we learn from priorities that we maybe found out weren’t quite right? How should we deal with any unhappiness that arises out of our selection process? And how can we better measure the success of what we’re prioritising now, for next time? An highly important consideration is making sure that valuable insights that come out of your current prioritisation don’t get lost for the future.
Once we’ve considered all of the above, it’s time to think about the kind of activities that will be a good match.
Now, I know that I promised I wouldn’t give you The One Activity, but actually, if you wanted to go ahead and plot all of the things you need to prioritise against a score for the key factors above, you’d probably come out of it with a pretty good idea of what’s worth doing. You can absolutely do that, and it’s sometimes how I structure some decision making. However, it’s also pretty time consuming, and let’s face it… usually people are very keen to avoid situations where they have to sit in rooms staring at endless rows on spreadsheets.
This is where the level of formality of your organisation and the team members involved will probably come in. Sometimes you’re going to need to be formal - for instance GOV.UK’s Service Manual cites the MoSCoW process as their preferred way of prioritisation Deciding on priorities. MoSCoW is extremely common, but it’s not the only option out there. This article by Daniel Zacarias outlines a whole set of alternatives that you may not know about: 20 Product Prioritization Techniques: A Map and Guided Tour.
Alternatively, your situation may mean that you could want to push back on formality. The method that you use can be as simple and informal as one person making a selection based on their best guesses, or a group of participants using Dot-voting to make their final selections. I also really like some of the more ‘fun’ suggestions in this article by UX for the Masses: 5 techniques for prioritising features (or user stories) to try out - UXM
The next time you’re looking to undertake a prioritisation activity, consider following along with the process that I’ve outlined in this post.
I hope that this has been useful. As always I’d love to hear from you if this is something that you’ve used, or if you’d like to discuss help with your prioritisation please get in touch.
Header photo thanks to Jungwoo Hong
Back in time:
Audits as a strategic tool
Forward in time:
Mapping a technology ecosystem
Sally is the lead consultant and founder of Records Sound the Same, helping people with digital transformation. She's also a speaker, coder, gamer, author, and jasmine tea fiend.