Despite being many years into building software, government still manages to blow it. The federal government has commissioned experts to build de-risking guides, specialists work with agencies and states to do things right, and projects stubbornly fail. Mistakes are repeated. How can this be?

Why It Matters

The failure of government software projects impacts the services government provides and the success of its programs. The federal government has stood up organizations like USDS and 18F to attract experts from Silicon Valley. They have done research and the work to help government understand how to build software. But government continues to pop out dud after dud. This costs taxpayers money and negatively impacts the life of residents.

Each Software Project is a Gamble

Every time I worked on a government software project I analyzed it like a game. Some projects you were dealt bad hands. These were death marches, they inherently lacked the conditions to succeed. Other projects had good hands, but the other players could still derail your chances of success.

The Optimists

The optimists spend a lot of time concerned about the challenges of massive success. You may have a good idea and budget for something that can work for a few hundred or thousand people, but they want to spend all the project resources on problems that show-up when you get to hundreds of thousands of people. By focusing on these issues, the fundamentals are neglected. Useful features for a small or medium sized project are cut or starved of resources. The large scale problems never happen.

The Artists

Building software requires craftsmen that do consistent and quality work. Sometimes this is boring to folks that land in the field and feel their creative energy is constrained. A project idea and budget lands in their lap and a good cup of coffee leads them to ask “what if we try a new approach?” to reach the goal. Their charisma or position leads other folks to agree, and this novel but unproven approach snatches defeat from the jaws of victory.

The Pessimists

Sometimes people have been through a few too many death marches. They look at a project and write it off before it has the chance to work. They have been in the game for a while, and they smell a good project-jacking victim. If the project is going to fail anyways, why not try and use it to learn React or Docker? Coming from software developers this is colloquially known as resumé driven development. Sometimes the best thing you can do to a death march is cannibalize the project and get something useful from the budget, but many times folks, especially software developers, are premature in pronouncing it dead.

A Successful Project Needs a Champion

Government projects live and die by their champions. Ruthless pragmatists who are not afraid to bloody their knuckles to drag the thing over the finish line. In private companies and even political campaigns you tend to have more of a command and control structure. A manager (general) is given charge to make the project work and then other folks (soldiers) do their best to execute on it. In civil service government the structure of organizations creates lots of stakeholders (generals) that have different ideas and power to make them happen. The best champions can identify the motives of these stakeholders and unite them towards a common goal.