Custom software projects fail at an extremely high rate in government, and that’s because of two core problems: the decision makers who set contractual requirements are far removed from users, and those decision makers are far removed from the software development team. These are really the same problem: decision makers are out of touch with key constituencies, which prevents them from grasping the underlying need and from understanding or controlling the work that’s being done.
How does this happen?
Under a traditional government contracting process, nobody ever talks to the users to find out what they want. That’s simply not a part of the process. Instead, a program office is aware of a need that they think is best addressed by software, which so they go to the procurement office to say they need to buy a thing. Nobody is in charge of saying “wait, do you really need to buy that thing—how do you know?” If the program office has the budget, they generally get to make the decision to buy something. So the procurement office says “you need to tell us your requirements, so that we can paste them into our RFP template. The program office then asks IT to come up with a list of requirements, plus they’ll toss in a few of their own. If they’re flush, they’ll pay a consultant to come up with the list of requirements. Whoever comes up with the requirements they do so by, basically, thinking real hard about it. Those requirements go in the RFP, which becomes part of the contract, and the vendor is on the hook to build software that does what’s required. Again, nobody ever talked to the users.
Then it’s time to actually do the work. So the vendor assigns a team of developers to write code that meets the requirements, and they go away and spend months or years doing that, without the agency ever seeing or using that code until the very end of the project. The developers never get to talk to users, but they’re no fools—they are capable of seeing that the requirements that they’re building toward are Actually Bad, and that their employer has underbid and overpromised. But the developers don’t meet with agency leadership or even agency employees to communicate that. The vendor has a client relations person who gets updates from the team’s project manager, periodically meets with the agency’s project manager, and maybe talks to the contracting officer’s representative once a month.
The result of this game of telephone is that the client agency has no real idea of how the work is going. Sure, they’re given quarterly stoplight charts that say everything’s going great, but it’s not—the developers know that this project is dead on arrival. And they tell their team lead that. And their team lead tells their project manager that the developers have concerns. And their project manager tells the agency’s project manager that there are some wrinkles but it’ll all be fine. And the agency’s project manager tells their change control board that everything is fine. And the change control board tells the CIO that everything is great, who tells the agency secretary that the project is on time and within budget. At every step of the way, people are lying to their superiors—this is known as “strategic misrepresentation,” and is famously analyzed in “Underestimating Costs in Public Works Projects: Error or Lie?” by Bent Flyvbjerg et al, which I recommend highly. (The paper answers the title’s question: lie.)
What’s to be done?
The answer is, naturally, my hobbyhorse: pair user research with incremental delivery of software via Agile development practices. No project should receive funding without user research that validates the underlying problem and the proposed solution. Leadership needs to ask the right questions and require the right answers. Agencies need to use an Agile contract format with a time & materials contract type to allow for user-centered software development, incremental delivery, and to facilitate trivial termination of contracts when a vendor is not performing. Agency principals need to oversee the work, and their deputies need to oversee the work more rigorously still.
In short: close up those gaps in the organizational chart that ignore user needs, and allow project statuses to be built atop layers of lies. If the users’ needs are understood, and the software is incrementally being delivered as it’s determined to solve user needs, that makes failure far less likely.