Five questions to measure success

in

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.

5 years ago I was running a workshop and struggling to get the participants to describe the desired impact of their work. Everything we wrote on our post-its came out as a solution (a feature or a thing delivered) and try as we might, we couldn’t get past this.

Emily popped 6 questions on the wall to help shift our brains into outcome-oriented thinking. They really worked and I’ve been using them ever since. We’ve put them into a template and created a little workflow to help teams find the keywords and phrases that describe the impact and value of their products, services, projects and programmes.

It’s a simple exercise which you could use to set or recalibrate direction.  You could use it as part of your kick-off or part of your strategic planning rhythms.  Give it a go.

Benefits of working in the open

in

Working in the open is scary at first but then feels liberating. Publishing our team’s website and data landscape felt like a big deal at the time. Should the Welsh Revenue Authority be talking about land and property platforms? Will people outside the team understand why we’re doing this work?

And then people started to notice and say nice things.

It’s lovely to have plaudits but there are other benefits to working in the open.

Working in the open…

Improves alignment

We thought we were sure from the outset about our objectives and why we were doing the work but it turns out the jeopardy of making things public forced us to clarify these before we published. Everyone in and around the team is more aligned and clearer.

Reduces collective anxiety

Once we were out in the open you could feel the weight fall from our collective shoulders. It was safe to talk and collaborate with others from outside the organisation. Focus shifts to the work, rather than crafting the message.

Tests empowerment

There’s lots of organisations that say they trust you and ask you to bring yourself to work, but do they? When an organisation encourages a team to work in the open, they demonstrate that they trust you.

A fabulous calling card

The more we opened up, the more people turned up to the Show & Tell to ask us some good questions; People outside of the organisation have put their hands up to collaborate or offer advice; It is helping us hire a fantastic team.

The thing is, we don’t know who we don’t know. By being out there people can find us and help us join the dots. To give you a good example, we discovered that a team in the Netherlands is working on something similar. This would not have happened had discussions been limited to internal meetings and closed email distribution lists.

Allows others to build on existing work

We document our work and thinking on GitHub. It’s a public history of the work and our thinking. We have built on other people’s fantastic work and we hope others might take what we’ve done and build on it too. By working in the open the institutional knowledge doesn’t get lost or forgotten on an internal file system.

This way of working is, in many ways, familiar to WRA. The level of trust and tone of voice are already established aspects of the culture but it is not the norm for teams to share weeknotes and thinking-out-loud in the same way we have with this project. We can say it has honestly helped us and made it more enjoyable. We hope others give it a try.

This post was originally published on the Land and Property team’s website.

Ice cream sketch

I did a sketch for Public Digital’s Signals to help illustrate an article written by Heath Arensen on digital public goods.

The park is a metaphor for government investment; the ice cream store for a thriving eco-system of organisations that deliver additional public good (tasty treats for park visitors). It’s Heath’s metaphor, but I enjoyed thinking about it and sketching.

Sign up for copy and get a lovely Signals through the post.

Multidisciplinary teams are brilliant

Multidisciplinary teams contain all the skills needed to run and continually improve digital products and services

Product people are brilliant. They set direction and lead the team. They own the product vision and its roadmap. Ambitious but humble Developers are brilliant. They write code and give the team the ability to  ship and test their product in days
Designers are brilliant.  They come in many flavours: interaction, visual, content and service and they help the team create products which are easy to use that people love Delivery people are brilliant. They set the rhythms and rituals, and help unblock the team. They brings expertise in lean and agile to help the team deliver the next most important thing
Subject experts are brilliant. Every team needs their expertise to help them understand the problem space. They come in all shapes and sizes (e.g. Ops, data, policy) - every team is different User researchers are brilliant.  They obsess with understanding the emotional and functional needs of users and uncover actionable insights

*others combos and skills also applicable.

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