{"id":266890,"date":"2019-01-29T11:31:10","date_gmt":"2019-01-29T16:31:10","guid":{"rendered":"https:\/\/policyoptions.irpp.org\/issues\/pursuit-of-perfection-the-enemy-of-digital-government\/"},"modified":"2025-10-07T22:23:01","modified_gmt":"2025-10-08T02:23:01","slug":"pursuit-of-perfection-the-enemy-of-digital-government","status":"publish","type":"issues","link":"https:\/\/policyoptions.irpp.org\/fr\/2019\/01\/pursuit-of-perfection-the-enemy-of-digital-government\/","title":{"rendered":"Pursuit of perfection the enemy of digital government"},"content":{"rendered":"

We\u2019re at a precarious time in the history of liberal democracy. Citizens, whose expectations are set by the rich panoply of online services, demand more than ever, immediately, from their governments. If governments can harness the promise of technology to deliver better services to all, they can meet \u2014 or even exceed \u2014 those demands.<\/p>\n

But to do so requires a sea change in how those in public service think about inertia, experimentation and iteration. It requires a bias for speed and learning. It means they have to abandon perfection, and embrace good enough.<\/p>\n

To explain why such a change is needed to make better policy, I need to dive briefly into the rather dry world of project management, because useful services are hard to deliver well unless their creators approach projects correctly.<\/p>\n

If you\u2019re undertaking a big, costly project \u2014 a battleship or a Mars landing \u2014 that\u2019s hard to update once it\u2019s built, you get only one chance to do it right. Delivering this kind of project uses a process known as a waterfall management strategy, because it follows a set of clearly defined steps that flow from one into the next, in a linear sequence: Plan, Test, Build and then Launch.<\/p>\n

But digital services aren\u2019t battleships. When Google first launched Maps, it was imperfect. Similarly, when it launched Gmail, this app was a side project, with only basic functionality. Gmail was labelled beta for five years after its launch, a reminder that the product was still in development and that users should expect changes and iterations. Today, a billion people and thousands of apps rely on Maps, and a billion people communicate via Gmail. The first versions weren\u2019t perfect. But they were <\/em>good enough.<\/p>\n

\"\"<\/a><\/p>\n

Digital is different<\/strong><\/p>\n

Modern software is built iteratively, using processes dubbed \u201cagile\u201d or \u201clean\u201d that emphasize continuous improvement based on learning how earlier versions are being used. This approach is needed because digital services are different from physical ones in two critical ways.<\/p>\n

The first difference is the ability to make changes after something has been delivered. Early versions of Microsoft Word were shipped on a floppy disc, and getting updates to people was expensive \u2014 Microsoft would literally have to test the new version on every device, then mail new floppies. By contrast, today\u2019s hosted services and applications are constantly being updated.<\/p>\n

In modern software, changes are not only easy, they\u2019re expected<\/em>. While you can\u2019t change the size of the ship\u2019s hull once you\u2019ve launched it, and you can\u2019t add fuel to the spaceship once it\u2019s on its way to the red planet, delivering a new version of a service is as simple as refreshing a web page or updating a file in the app store.<\/p>\n

The second big difference is that when you use a digital service, it learns from you. That was another disadvantage of the old floppy disc model: software makers couldn\u2019t learn from it. But Google rapidly improved its office suite because every time someone used it online, the company learned more about what it should<\/em> have built. It even launched a parallel product (called Inbox) to test out ideas.<\/p>\n

With hosted software and apps, makers can immediately see what features users wish they had, where they\u2019re getting stuck, what devices or regions aren\u2019t adopting something, and so on. They can collect feedback from everyone, constantly, and improve their offerings. Perhaps most important, they can learn which services to focus on with all their resources, and which to kill off quickly because nobody needs them.<\/p>\n

With connected devices, automated maintenance and the Internet of Things, this new, iterative model of delivery is spilling over from software into the physical world, too. Tesla, for example, collects analytical data from its cars and sends software updates.<\/p>\n

In 2013, I co-wrote Lean Analytics<\/em>, a book about using data to build better products faster. In it, we explain that at the outset, today\u2019s manufacturers aren\u2019t building a final product. They\u2019re building a product to figure out what to build.<\/p>\n

In a connected, digital world the old cycle of Plan, Build, Test and Launch has changed. Now it\u2019s the lean model: Build, Launch, Measure, Plan and Build Again, in a never-ending cycle of gradual, inexorable improvement. And this is just as true for public services as for private start-ups.<\/p>\n

Why we can\u2019t have nice things<\/strong><\/p>\n

But digital government initiatives struggle to harness the promise of rapid, exploratory, iterative innovation, thanks to a risk-averse, politicized culture that demands perfection at the outset. And this is where we get back to policy. Because when governments launch incomplete things, they expose themselves to criticism.<\/p>\n

The lean model of product development centres on the minimum viable product, or MVP: the least complete thing a company can create that will fully test an idea. That means the MVP won\u2019t work for everyone. The makers will be accused of experimenting on their users. They\u2019ll be accused of making something inaccessible. The government service they build at first won\u2019t have every feature \u2014 and critics will pick it apart, turning it into political fodder to win points and votes or further their particular agenda.<\/p>\n

In a climate where we deride imperfection when we should be celebrating progress, the safest thing to do is often nothing, or building something huge and monolithic that runs over time and budget by trying to please everyone in its first version. The demand for perfection in nascent government services breeds inertia. And yet if Western liberal democracies are to compete with command-economy nations and benevolent technocracies, we must act, or fall behind.<\/p>\n

The new project management<\/strong><\/p>\n

To remain competitive in a digital era, governments, civil servants and citizens must embrace three things: a measurement mindset; an agreement on what the minimum should be; and freedom to experiment.<\/p>\n