‘I am happy with the launch.” That’s what Massachusetts Labor Secretary Joanne Goldstein had to say about the state’s new online unemployment system, which erroneously cut benefits and continues to cause problems for hundreds of unemployed workers. The system, built by Deloitte Consulting, came in two years late and $6 million over budget.
If this is success, what would failure look like?
Massachusetts isn’t the only government with information-technology woes. A new $59 million computer billing system in Los Angeles led to incorrect utility bills going to tens of thousands of customers. Glitches in a $45 million overhaul of Pennsylvania’s workers’ compensation processing systems have delayed payments for hundreds of injured workers. California spent 10 years and $254 million on a failed attempt to modernize the state’s antiquated payroll system. And we’ve all read about the problems with HealthCare.gov.
The public should demand better, because we experience better when we use dozens of high-quality software and Web services every day. There’s no good reason we shouldn’t expect the same from our government.
Not that every private sector launch is a success. The Standish Group, which reports on IT development projects, finds the success rate for all IT projects is only 39 percent — that is, only 39 percent come in on time, on budget, with the right features. This number plummets to just 10 percent for projects with budgets over $10 million. The bigger the project, the likelier it is to fail.
We have a bias in government towards big.
Unfortunately, we have a bias in government towards big. Rather than allocating enough operating funds for ongoing IT upgrades, we fund projects through our capital budget — otherwise used for roads, bridges, and other expensive items with long lifespans. This approach leads us to purchase large, custom-designed products that take years to design, build, and implement. But technology evolves rapidly. By the time a massive software project is in use, it’s already years out of date.
We also do a poor job choosing contractors, as the Deloitte example makes clear. Our risk-averse purchasing rules favor large companies willing to navigate complex bidding processes, even if newer, more nimble firms can do the work more cheaply. And state government doesn’t have enough managers with the technical expertise to craft and manage these contracts properly. We end up buying features we don’t need, and we lack the flexibility to learn as we go.
It’s time for a new approach. From the construction world we can borrow the idea of design-build IT contracts, where we collaborate with a vendor over time to figure out which technology would best help us solve a problem rather than dictating the specifications up front.
In this approach, rather than launching a huge new information management system all at once, an agency could roll it out feature by feature, gathering input from users at each stage. The agency and its contractors can adapt to unanticipated user needs — and catch problems early, before they spiral out of control. It would also end failure-prone “big bang” launches, like that of HealthCare.gov, in which it becomes clear all at once that nothing’s going right.
We could avoid many of these contracting issues entirely by emulating the United Kingdom, which created an in-house digital-services team in 2011. This team is doing a complete overhaul of the country’s digital services — often building new technology with its own staff — and has saved UK taxpayers $20 million a year while dramatically improving services.
Granted, recruiting and retaining government IT staff is a perennial problem. One approach is the successful model used by the Consumer Financial Protection Bureau, which brought in talented private-sector developers by offering two-year fellowships designed for those who were motivated by public service, but didn’t see government as a life-long employer.
One way or another, we have to make these jobs desirable. We may not be able to compete on salary, but the chance to work on socially valuable projects with like-minded people can be a strong draw. Here’s another way that creating a central team helps: rather than isolating ambitious tech staffers in various agencies, they can work as part of a larger, cutting-edge team.
Finally, we have to empower them by limiting the bureaucratic barriers that so often undermine creativity and innovation. To avoid future failures like the ones we’ve been seeing, we should follow the UK example: Set up the team, and let them loose.