This book is arguing that governments need to change their processes for managing technology projects. The old way: multi-year projects planned up front with budgets in the millions or billions, executed over multiple years using waterfall methodology, rolled out all at once in a “big bang” deployment at the end. What the authors want: something more akin to the “agile” processes popular in the private sector. They organize their approach around the three elements of “design”, “data”, and “delivery”.
Design: Make sure you know what users actually need. Do user interviews, watch users use the existing system, make sure you and your designers and developers get experience actually using the existing system yourselves, etc. Remember that “users” includes both the beneficiaries of government services and the staff of the government agencies involved.
Data: Have concrete, measurable goals for your project and a way to get data to tell you whether you’re meeting those goals. Remember that technology is a means, not an end, and the decision to even use technology should not be made until you’ve established why it’s the best way to achieve your actual goal.
Delivery: Scope your project so that you can deliver something useful relatively quickly and cheaply. Do pilot projects / experiments that improve a single workflow for one group of users; don’t try to scale up to more users or solve additional use cases until your pilot project has proven successful in the real world.
There are some inspiring success stories:
Bob Filbin, Crisis Text Line’s cofounder and chief data scientist, points out that the CDC and NIH surveys are written by scientists, which by default means that scientists are the ones drawing the boundaries of what qualifies as a crisis.
“Our data starts from the opposite direction, allowing the users to define what crisis looks like to them….”2
In the examples I found most impressive—the ones regarding foster families and homelessness—it’s not clear to me whether the differentiator was really an emphasis on the authors’ principles of “design, data, delivery”. What stands out to me, rather, is that these involved teams of highly motivated and empowered people putting special focus on the task.
That the authors’ methodology is not a panacea is apparent from the first chapter. They tell the story of the US Citizenship and Immigration Services’s attempt to go digital, the ELIS project, whose first iteration was a spectacular failure. The book then describes how ELIS 2 did better user research and used (to some extent?) “agile” processes; yet:
…even with all the improvements made by both the USCIS team and USDS, ELIS 2 dragged along in a semi-usable state for years. By 2016, after the system had been rolled out for additional forms, immigration officers were using ELIS grudgingly and with a fair amount of seething hatred. One field office made a video of themselves kicking a computer with “ELIS” taped to it on paper.6
…which just sounds like another spectacular failure to me. I might speculate that part of the lesson here is: it’s really hard to actually implement the ideals of being user- and data-driven and doing rapid iteration, as opposed to just paying lip-service to them. Actually accepting these ideals means accepting some unpleasant things: that you can’t accurately estimate the cost or timeline of a whole large project up-front, and also that you will inevitably put time and money into some projects which turn out to be bad ideas and need to be thrown out. I think I and other software engineers tend to be cynical about so-called “agile” processes because the organizations implementing those processes are often unwilling to accept the tradeoffs. Rather, the organizations believe that implementing the right set of weekly meetings, project management workflows, etc will allow them to get the benefits of being agile while avoiding the tradeoffs. That’s a hopeless quest which generates lots of useless, time-wasting processes.
But the ideals are good, and I’m glad there are people trying to promote them in the public sector. Doing so sounds exhausting; the book indicates that, in government, even projects operating in the comparatively agile way they advocate for tend to take years. It also emphasizes that you need buy-in from a “person at the very top—the mayor, the governor, an agency head”7 as well as “from the people on the ground”8. Given the amount of patience and politicking required for someone to effect substantial improvements in public services, it seems especially important for society to provide adequate incentives for people to try, but of course that’s difficult too:
If the government wants to adapt its hiring practices to include higher salaries or modern benefits, it requires an act of Congress. This is true across developed democracies the world over. This feature alone makes keeping up with the speed of transformation a true challenge.9