In 2010, less than a year into his presidency, Barack Obama told a group of CEOs that the government’s “best efforts are thwarted because the technological revolution that has transformed our society over the past two decades has yet to reach many parts of our government.” He outlined priorities to make the government a better user and buyer of information technology. Now, his administration’s signature initiative is embroiled in a massive IT project gone wrong. Here are the main reasons.
The federal government isn’t good at buying IT services. Most large public IT projects are over-budget or over-time. While it’s still a mystery exactly why people trying to sign up for insurance on healthcare.gov faced site crashes and data transfer problems, there’s general agreement that procurement and workflow procedures—how the government buys stuff—is at the heart of the problem.
Government employees in charge of contracts are trained to buy either large, discrete objects like battleships or simple services, like painting a room. Neither one is a good analogy to hiring a company to design and maintain a website for the public to use. In particular, the government relies on a top-down project-management style known as a “waterfall” approach—in which a project’s goals and specifications are all decided in advance—rather than the “Agile” methods favored by tech companies, which incorporate multiple prototypes and feedback, and often use open-source standards and code posted on transparent databases like github.
The Obama administration didn’t do much to adopt a more Agile approach. The Obama team had a big agenda for IT reform when it came into office—making more data available to the public, consolidating data centers, adopting cloud computing principles. It also wanted to reform procurement, part of which meant making it easier for government agencies to use Agile project management. But most of their time was spent on the first set of ideas, which offered more attractive up-front cost savings, while procurement reform has faced hold-ups.
Some of the problems are internal—for instance, the White House’s much-lauded IT project dashboard, a central portal for keeping track of how IT projects are progressing, relies on waterfall-style project management. Others are external: The White House Office of Management and Budget, which is responsible for these initiatives, hasn’t been able to get Congress to tackle contract reform in between debt-ceiling crises.
Then there’s the culture clash. Still, some government agencies have adopted Agile methods, with good results. But government tech workers Quartz spoke to stress that most public employees who write the contracts for tech projects are career civil servants without an in-depth understanding of modern software development. If the requirements are too generic, companies that don’t use modern development methods or open-source coding standards—like those responsible for healthcare.gov—end up with the contracts. “There is NO way one can actually write good requirements, IMHO, if they still don’t write code,” one government tech manager said in an e-mail.
At the current pace of technological innovation, it will take a while before most US civil servants understand enough about software to integrate it effectively into the public sphere. But judging by yesterday morning’s congressional hearing on healthcare.gov’s problems—where the website was compared to a house, a car’s engine, and scrambled eggs—a tech culture upgrade is needed throughout the capital.