This article was written by Mauko Quiroga, Government Whisperer at the French Prime Minister’s government digital services incubator beta.gouv.fr and an OpenFisca contributor. The views expressed in this article are the author's own and do not necessarily reflect the opinions of the French government.

“Traveler, your footprints are the only road, nothing else.” Antonio Machado

Building a government digital service might seem like building a house.

Usually, it goes something like this: we have a great idea, we make plans, we write very detailed specifications, we build the service, we test that everything works as expected, then we go live… and boom, champagne! People use it. Rinse and repeat.

Sadly, that’s not how it works in real life.

In this article, I will deconstruct the idea that building a government digital service is like building a house, offering a better metaphor to think about your services, and a step-by-step approach to know when to go live with your service — and whether you should be building it at all.

A solution to someone’s problem

Both a house and a government digital service are a solution to someone’s problem.

What differs is the degree of uncertainty you’re dealing with.

Building a house is certain: you start with an idea, and through the analysis of subject matter experts, you can know who needs housing, where they need it, when they need it, how much they can pay, and how to build it to the greatest of details. You wouldn’t let people live in a half-built building, would you?

Building a government digital service is uncertain: you have a vague idea of what the actual problem you’re solving is or whether there’s someone out there who encounters this problem. And if you decide to build a solution, you are unsure if people will indeed use it, or if the world will be better off because of it. Then, going live with a fully-built service is already too late, isn’t it?

Uncertainty means risks. So what are those risks?

Understanding your service’s risks

Let’s say you’re tasked with building a government digital service to help people evaluate their eligibility to social benefits. The risks associated with your service are:

  • Problem risk: This one might seem obvious, but do you know if there are actually people who have problems evaluating their eligibility to social benefits? How many?
  • Solution risk: Once you’re certain that there is a real problem, do you have an idea of how to solve it? Do you have what it takes to build a solution (technical skills, UX skills, product management skills…)?
  • Impact risk: Even if the problem is one you can actually solve, should you? How’s the world going to be better thanks to your solution? Is it going to increase the take-up of social benefits?
  • Sponsorship risk: Finally, if your service is going to fix a public policy problem, it will fix bureaucracy, and that means change, and that means resistance… is your higher-level stakeholder support strong enough?

When to go live with your government digital service is all about managing these risks.

beta.gouv.fr: a step by step approach

At beta.gouv.fr, French Prime Minister’s government digital services incubator we’ve developed a government digital service delivery approach that reduces these risks, inspired by the lean startup methodology.

This approach consists of four steps:

1. Investigation (6 to 13 weeks)

The goal in this phase is to ascertain whether you should be building your service in the first place.

Checklist

  • Get stakeholder support to investigate the problem (sponsorship risk)

  • Validate that the problem is an actual one (problem risk)

  • Have a first idea of the possible solutions (solution risk)

  • Have a first idea of the potential impacts (impact risk)

In this phase, you shouldn’t go live yet.

2. Construction (6 to 12 months)

The goal in this second phase is to test your solution hypothesis in real conditions but on a reduced scope.

Checklist

  • Get stakeholder support to develop the solution (sponsorship risk)

  • Find the shortest path to your early adopters and learn from them (problem risk, solution risk)

  • Deploy a solution on a reduced scope and improve it continuously (solution risk)

  • Start measuring your solution’s impact, or its best proxy (impact risk)

You should go live with a beta version of your government digital service as soon as you can.

3. Scale out and consolidation (ongoing)

The goal in these last two phases is to deploy your government digital service on its full scope and to its maximum impact.

Checklist

  • Get stakeholder support to fully deploy your service (sponsorship risk)

  • Get stakeholder support to perpetuate your service (sponsorship risk)

  • Deploy your digital service on its full scope to all its target users (solution risk)

  • Maximise your digital service’s impact (impact risk)

Once your service is live it should stay live forever and in continuous improvement.

Peroratio

Solving a public policy problem thanks to a government digital service might seem like building a house, but as we’ve seen it’s rather like building a road: you know where you want it to lead you to, but you don’t know in advance by which detours will it do so. Going live helps you make your way through. — Mauko Quiroga

(Picture credit: Unsplash)