How do we deliver policy, quickly and effectively?

“A policy is a set of ideas or plans that is used as a basis for making decisions, especially in politics, economics, or business.” ¹

I’ve worked with many policy makers over the years, both inside and outside of government, these are highly skilled and motivated individuals who really care about the impacts of the policy that they are writing.

They just want to do a fantastic job and produce great policy that matters and makes a real difference to people’s lives, but there is a tendency for them to be hamstrung by the very siloed nature and culture of the organisations for which they work.

I’m a massive fan of Jeff Patton and his user story mapping approach to building out product roadmaps and backlogs, however there is one concept of Jeff’s that really strikes a chord with me and it’s his use of the rock analogy, for me it really is the core of Jeff’s message.

If we think of a problem as a rock then we know that some rocks, just like problems are bigger than others.

Some are small enough and perhaps well enough defined that as a concept we can, perhaps with a bit of huff and puff move the rock along and solve the problem.

However, some problems are that large or complex that we simply struggle to get our heads around them, let alone move them along towards a solution.

The truth is though that this holistic, whole rock view is really what senior stakeholders care about, this is no different in policy circles and this pressure to delivery all of the policy in one go upfront in a waterfall approach, is ultimately what causes many of the downstream problems we see.

By the way there is nothing intrinsically wrong with waterfall, when used in the right context, in a set of circumstances where we can truly understand the problem that we are trying to solve. Where perhaps we have done something the same or similar before, then we could and should plan out what we are going to do and execute the plan.

However, in highly complex environments where the problem space is simply vast and also usually includes people, we cannot nor should we attempt to do this, here we need to take an experimental incremental approach.

And this is what we often see policy colleagues struggling with, driven by a need to follow a direction to complete the whole policy in one big go,  to understand all of the issues, all of the complexity before taking it to senior stakeholder for sign off.

Sadly, this ultimately leads to a situation where policy simply isn’t delivered in a time frame that works for many of the teams trying to fathom out how best to enact the policy through people, processes and systems, many of these team wanting to use agile or lean approaches to deliver.

What invariably happens is that these downstream teams work on assumptions, built on assumptions and just like a house of cards things can and do at times come crashing down, which will inevitably lead to finger pointing and blame, which simply feeds and persists the existing culture.

At this point I would like to point to all of the great work that has been done within government, especially to change the way that policy is developed and delivered, to make it more inclusive and user focused and I would highly recommend a visit to the policy labs.

However there is a better way, a leaner way.

We’ve known in product development for a while now that the best way to tackle a problem is to break it down, to create something that is just good enough that allows us to work with our users to really understand their circumstances. To understand their problems and needs and to create a solution that works for them by solving a real problem. We do this through the use of an MVP, although as I’ve already discussed this term in itself can be misleading.

Here what we need is to create a minimum viable policy, we need to treat policy in the same lean way that we develop products.

In crude terms we need to take the big policy rock and smash it up into lots of smaller rocks.

Next, we start to prioritise the policy by it’s value, this being quantified as the impact that we expect the policy to deliver. To do this we use tools such as impact mapping to help us understand and map the impact to users and the cost of delay as the broad mechanism for prioritisation.

Taking the highest priority policy area we create the first cut or slice of the policy to be tested with users, this is just a thin cut across, an experiment, just enough policy to test with, not to be signed off.

Above we have the 5 main policy areas to be examined, we start small running simple tests across a number of key policy areas.

The are of course many different ways of testing policy with users and stakeholders, we have had success using story boards and prototypes to lead internal policy colleagues / stakeholders through the end to end user journey as it’s adds valuable context and is great for them to visualise how the policy will look and feel when built into real services.

Within government this has been done using the Heroku prototyping kit.

It’s important that testing is done in quick rounds of 1-2 weeks, allowing you to achieve rapid insights on the potential efficacy of the policy, which is then feed back into policy colleagues to either iterate or increment upon.

We now start to build the policy up, iterating policy tested based on the feedback from our users and stakeholders, or adding new policy for testing until we get to the point at there is just enough policy, good enough to be delivered and to start to make a real impact.

Here we have gone through three rounds of policy testing, in some rounds we have iterated policy based on feedback received and added new policy ideas to be tested.

The benefit of this approach is that rather than waiting for signed off policy we can move forward testing as we go, it enables the unblocking all of the downstream teams that have been waiting for policy decisions to be made and working dangerously to assumptions, these teams work on that first bit of stable tested policy, whilst the rest is being designed and tested as we go.

Policy really doesn’t have to be delivered in a big upfront policy design approach, it can where appropriate be delivered , just like software in slices and built up, using the people it is hopes to impact positively to help drive the policy forward, one bit at a time.

The key really is to remember that everything is rocks, smash them up, break them down and test the important parts first and remember, good enough.

¹ Definition of policy from Colin’s on line dictionary