Five questions to measure outcomes

I co-created a workshop with the wonderful Emily Webber called Five Questions to Measure Outcomes. 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 some 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.

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.  

View fullsize

“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.

View fullsize

View fullsize

View fullsize

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.

View fullsize

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

View fullsize

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

Seven questions to build a roadmap

In my last post I wrote about why roadmaps are for everyone. This post is about techniques for building one and how the use of language can help align your pure agile or mixed methodology programmes.

In government service delivery programmes there's always a mix of methodologies between agile and waterfall. Some of this is cultural, some of this is for practical reasons. The techniques I describe below fit within this context.

The prerequisites

The prerequisites for a good roadmap are good leaders and clearly articulated goals. If your future is driven from above by preconceived thinking or your teams don't emotionally buy-into the programme's goals it's not a happy place.

Good leaders set and articulate goals that inspire you.  They allow teams to challenge the seemingly sacred.  They empower them to come up with creative approaches to achieving strategic goals.  If you don't have these then your roadmap could end up as an exercise in group-think.

Ask 7 simple questions

Gather the team and your subject experts (e.g. ops, legal, security, policy, HR) and ask yourselves these questions*:

1. What are we trying to learn or prove?

2. Who are the users?

3. What are we operating?

4. What are we saying?

5. What are our assumptions?

6. What are our dependencies?

7. What capabilities do we need?

A timeline is not dirty

The Waterfall methodologists feel comfortable with long timelines.  They typically work 'right-to-left' from a desired delivery date;  the agilists prefer to work iteratively, 'left-to-right' as much as, and where possible.  Whatever your preference, timelines are important and an inescapable part of delivering.  A timeline is not a dirty concept.

I start this conversation by sticking post-its across the top of a wall with time intervals running left to right. I use 3 or 6 monthly intervals over 1 or 2 years, but whatever is right for you. Choose a timeframe that creates some discomfort for your colleagues to think beyond the immediate "deadline" in everyone's head and to get them to think strategically.

Place known, real or imagined, time constraints and events across the top too, maybe on a smaller or more muted colour post-it so they don't become the only focus of conversation.

You get better roadmaps by asking questions

The language you use is important. Asking everyone to answer questions is good for finding common ground and helps get better inputs. Asking "What are we trying to prove or learn?" for each time interval helps people think about the evolution of your service and grounds it in iterative delivery.

The agilists are used to thinking about learning and value-based incremental delivery. They feels comfortable with it.  The waterfall methodologists typically think more about deliverables. That's OK, you can easily ask what are the outcomes they want from it? What will it prove when we deliver it? What will we learn from delivering it?

Ask how we measure stuff and set some sensible targets. These be your performance indicators (KPIs) and a step towards an awesome dashboard for your programme.

Who are the users? Everyone wants to deliver for users so no controversy.  No one is itching yet.

"What are we operating?" gets people thinking about the service as a whole and how it will work and evolve over time.  Talking about it with everyone helps. It gives teams focussed on digital a feel for challenges of the Operations folks (e.g. in the job centre, in warehouses, on the service desk) and Operations get to say how they want to rollout and operate it.

Capture assumptions and dependencies whenever they come up in conversation.  That always helps bonding.

A roadmap can write your comms plan for you. By asking "what are we saying?" (to your organisation, your users, the press) for each time interval you are telling the story of your evolving service.  The Comms folks are now itching but I think it is excitement not concern.

Capabilities are to do lists for everyone

Finally, "What capabilities do we need?" (to operate the service). I find everyone gets the word capability after a gentle nudge (e.g. pay, inbound-telephony, search, dispatch, training). Add a description and an owner to each one if you can. Describing them and giving them a label is hard but both the agile and waterfall camps understand the word and can come up with a sensible list of them.

The agilists, especially the architects, can begin to see the beginnings of their systems, the epics and minimum-viable features within their backlogs. The waterfall folks can imagine their gantt charts and what needs doing by when.

Show it off. Get people talking about it

These techniques give you a holistic view of the service from a near standing start. This exercise does not answer everyones' questions. There's still uncertainty and no one feels 100% comfortable with the unknowns, but you have the backbone of a strategic approach. One that is grounded in user centred, iterative delivery and provable outcomes.

Everyone can take something away with them and use it to inform their own planning activities - whatever they are. Turn it into an illustration if you like. Present it to important people. Keep pointing at it, talking about it and improving it.

This is your roadmap.

* I want to credit Richard Pope who came up with some of these questions on the hoof when I did this for the first time. I've run with them and tweaked.