products

Tips for better prioritisation

“Prioritisation” is what you do to determine the things that should be done to deliver the most value at a point in time, given the constraints.

Imagine this scene:

Boss:“Is everything going to plan?”

Team: “Yes, we are focusing on the next most important thing”

Boss: “OK, that’s great. Crack on!”

Wow, wouldn’t that be a great way of working?  Imagine if you only needed to focus on a few, priority things and everyone was cool with that.  

Prioritisation is an essential skill for teams and organisations.

A good prioritisation process should build consensus and confidence. 

Better yet, a good prioritisation process should make it safe to say ‘No’. 

We make prioritisation decisions hundreds of times a day and our brains are well trained to do it. And yet, when it comes to groups - couples, families, teams, organisations - it gets much more complicated and messy.  

“Clean oven”, “Raise Buddha” - someone else’s priorities

Good news! There are plenty of tools and techniques to help you overcome this.

That said, there’s no silver bullet. In the end, prioritisation decisions come down to conversation, and negotiation

Tools help, but you need to know which ones to use and how to set them up for success.

Hopefully these tips and techniques will help do that.

Tip 1: Work out who is doing the prioritisation

Is it you and your team? Is it an external group? 

Knowing who will be making the decisions influences what tools or techniques you use. 

For example: if it’s just your team, you might use a simple list and ask the team to rank the items on it: 1, 2, 3, 4... Good enough.

If it’s a large, external group of stakeholders, then you might need to put some upfront structure in place (e.g. scoring criteria, scales and weightings) to allow you to have better conversations.

If you’re being wonderfully lean and user centred, then prioritisation might be heavily influenced by your users’ behaviours. Do you have the right insights and data?

Tip 2: Understand what triggers prioritisation

When you know the triggers you can create the right rituals. Is it your weekly team planning session? Is it a quarterly review of objectives? Is it a resourcing conversation?

Knowing the triggers allows you to create the right cadence and invite the right people.

Making prioritisation a regular thing, rather than a one-off, helps build consensus and ownership.  

Tip 3: Make the constraints clear  

Prioritisation means making trade-offs. Knowing the constraints in which you are operating is essential.

Focus the conversation on the trade-offs, rather than forcing participants to mentally model the constraints.

For example, try drawing a grid to visualise work-in-progress limits, or the number of teams available.

Tip 4: Prioritising bad ideas is a bad idea 

Whatever you are prioritising, make sure the people doing it are clear about what each thing is. 

Those prioritisation sessions that go around in an endless loop of “what is this thing again?” are a waste of time. Make sure the things being prioritised are easy for everyone to understand. 

For example, an ‘ELMS system’ might mean something to you, but it might not mean much to others.  Whilst you want some back and forth about “does this thing include [x]?” you don’t want the whole conversation to be about that.

Label things in plain language (i.e. not business-speak or jargon), or offer up pre-reading material so people can get their heads around what they are about to prioritise.

Go into the prioritisation conversation prepared.

Prioritisation techniques

Here’s just a few techniques I use.

2x2 grids

Whack a 2x2 grid up on the wall, or in your favourite online tool, and pick an x/y axis. Simple and adaptable. This helps you talk about each thing and where to place on the grid.

To avoid people gaming where to place things on the grid, don’t reveal what each quadrant means until the end.

Another trick is to move one of the gridlines right at the end of the conversation. For example, moving “important” axis lines upwards really does focus minds on the things that are near the top / really important. Once you’ve done this, ask participants “So these are most important things, right?” and watch them gulp :)

MoSCoW

A classic from the days of lengthy requirements documents. Even so, it’s still a useful way to whizz through a list of things and ask:

“This thing: let’s prioritise it. Is it something we…”

Must have?

Should have?

Could have?

Won’t have?

It makes a long list much shorter, very quickly. And for that, we love it.

Scorecards

Scorecards allow groups to agree a set of prioritisation criteria, weight them and score them. Some groups really love them because it feels like you’re doing clever maths.

I’ve found this technique most useful for scoring things against a set of accepted objectives.

Score card example

Cost of Delay

This one is a favourite because it’s a very good way of balancing ‘jam today’ vs ‘jam tomorrow’. It’s definitely not an everyday prioritisation technique and it’s not for the faint-hearted.

The fibonacci sequence is useful as scale for prioritisation exercises because it forces distribution

The fibonacci sequence is useful as scale for prioritisation exercises because it forces distribution

Prioritise delivering the smallest, most valuable things first using Cost of Delay

Conditions for success

Public Digital asked me to contribute to their periodical Signals and I’m reposting here. It’s about how to create the conditions for teams to successfully deliver modern, digital services.

Signals-summer-2019

Designing and operating modern, internet-era services is different from what you might be used to, but it’s not rocket science. It’s the application of a few simple principles, a simple flow of work and some tweaked behaviours.  If you’re a leader thinking of doing service design for the first time, these are some of the things you can do to increase your chances of success.

Empower teams by giving them problems to solve

Resist the temptation to jump to guessed solutions. It’s important to openly acknowledge that understanding the problems to solve, especially those of the user, is the place to start. By better understanding challenges, opportunities and the needs of users you increase the chances of delivering the right thing.

Set up a small, 100% dedicated, cross-disciplinary team with the relevant expertise to explore a problem space for 3-5 weeks. Direct their efforts on an area of opportunity that has potential to deliver on your strategy, but where the edges are unclear.

Investing in discovery activities like this saves wasted effort later on and creates the beginnings of an inspired, empowered team, committed to solving a problem with a habit for learning.

Test your riskiest assumptions by building working prototypes

Explore the art of the possible by building a working prototype (an ‘alpha’) and testing it with potential users. It is a quick and effective way to test your riskiest assumptions and better understand the needs of the user. The value of learning is in reducing the risk of prematurely committing resources to delivering the wrong thing or making incorrect assumptions that prove costly.

Don’t build an app, build a team

Empower a team to meet the needs of the user.  Make sure they can do this free from the imposition of political constraints to avoid building a product or service that suboptimally reflects the shape or behaviours of the current organisation.

Trust the team to own their process and choose the tools they wish to work with. Support them to shape their working environment in ways they want. There is no simpler, more powerful way for a leader to signal empowerment than by allowing a team to break some long-standing but innocuous rules.

During an alpha it is important the team can demonstrate they work well together and that they’ve understood and sufficiently explored complex areas of the service (e.g. security, legal, identity) – not just a shiny new interface.

Embed the change where you want to see it happen

An essential measure of success is landing new ways of working into the organisation. You can vastly increase the chances of that happening by co-locating a 100% dedicated, cross-disciplinary team where you want to see the change happen.

By the end of an alpha, the team will need to generate sufficient political momentum to surmount the internal barriers to the service going live (usually as ‘beta’).

Quickly put a real service live in front of real users

Everyone should expect the ‘beta’ service to be put in front of users quickly – say within a month or so. It won’t be complete but it will be the beginning, a thin slice, of a real service with real users. For organisations not used to working this way this is an important psychological hurdle to overcome, and a condition for success for delivering modern, internet-era services.

Deliver incrementally and iteratively

Ensure the approach to delivering the service remains incremental and iterative, driven by desired outcomes rather than a fixed plan. Allow the team to experiment with both the service design and how the service is operated.

It doesn’t matter how big or complex the imagined future service is, break it down into smaller parts and build in short, timely feedback loops.  Learning this habit and way of working will help you build a service that better meets the needs of end users and front line workers who provide the service.

Start small and grow organically

Sponsors should understand it’s better to start small and grow organically. The organisation must resist the temptation to impose programme structure on a beta team, or believe that by adding more people, workstreams or management layers it will deliver faster – it won’t.

Over engineered programme-level hierarchies or overbearing governance produce noise; noise slows down self-organising, motivated teams. Your role as a leader should be to support the team to figure this out as they go.

Commit to challenging the status quo

Provide the top cover, including committing day-to-day leadership from within the organisation – someone who is trusted and capable of navigating and challenging the status quo.

In fact, it should be understood that the beta will be outside the norms of programme management and governance. Part of the beta will be to explore how both need to adapt.

Go and see delivery for yourself

You’ll know this approach is working and whether you’ve nurtured a good team if they can demonstrate they can regularly deploy and iterate the service based on real user feedback.

Encourage all stakeholders to commit to going to see what and how the team is delivering and to listen to how users are responding. They will see the service coming to life and continuously improving week by week.

This is a far more effective way of assessing true progress and providing timely challenge than by reading and responding to an emailed report sent from afar. Get out of the meeting room and go to see delivery for yourself.

Outcomes, goals and objectives

In my experience, the best leaders are crystal clear about outcomes and focus their energies on achieving them. They’ll communicate goals and objectives to steer and inspire their teams but they don’t sweat the deliverables.

This is how I think about them:

A goal describes the broad direction to achieve an outcome

e.g. “Cater for a memorable birthday party”

An outcome succinctly describes the desired change or impact.

e.g. “Happy memories; full stomachs”

An objective makes goals specific, measurable and time-bound

e.g. “Sandwiches for 20 party people that everyone can enjoy”

A deliverable is a defined output that (may) achieve an objective or goal

e.g. “Party sandwiches”

Update: I co-created a workshop with the wonderful Emily Webber called Five Questions to Measure Success. It’s a tool for teams and leaders wanting to describe and measure outcomes.



GOV.UK beta goes live. I'm proud.

 

At 9h.03m.9s on 31 Jan GOV.UK, the beta version of the UK Government's single domain project, was released to the public for the first time.  I was the Delivery Manager on the project and it feels like an awesome achievement and I am very proud to have been part of it.

I think we've delivered a slick product.  It's beautiful (imo), reduces obfuscation, is task focused on user needs and uses search based architecture rather than browse hierarchies. It's only a start and there is so much more to do but early feedback on Twitter and GetSatisfaction has been extremely encouraging so far.

Also, unusually for UK Government IT projects it came in on time and slightly under budget which is testament to the skills of the team, our iterative approach and  (cough) careful management.  More on that in another post.

Most gratifying is that we've been given permission (or did we just seek forgiveness?) to develop this project out in the open.  From the beginning we've been tweeting and blogging about our emerging thinking and code has been available for public scrutiny on GitHub.  Only this week the first member of the public made a pull request, made some changes to the code, committed and we deployed the same day.  This is fundamentally changing the way Government IT works.

The Government Digital Service (GDS) is a new organisation within the Cabinet Office.  It's exciting times, with some commentators saying its like having the coolest start-up at the heart of government.  I can confirm it feels like this from the inside too.  It's been an amazing journey so far and I know we're only just beginning to crank it up.

Related links