When government pays companies to build big custom software programs for them, they succeed just 13% of the time. Here is why failure is so common, and about the simple change that turns those outcomes on their head.
Major government software projects fail because government has learned, over many years, to do exactly the wrong thing: specify down to the last pixel exactly how the software should look and function. All of those specs go in the request for proposals (or “RFP,” also known as the “solicitation” or the “tender”), telling the vendor exactly what to do.
(If you’re thinking “how is agile software development possible if you specify everything up front” then congratulations you already know the punchline.)
All those specs are created with no user research, with no regard for user needs.
The vendor who gets the contract is then required to make precisely the software outlined in that 800-page RFP, even if their own user research shows that it’s wrong.
This is, of course, madness.
Half of the major government software projects that “succeed” succeed only in the sense that they do what the RFP laid out. Was that what the users needed? Probably not!
The vendors who bid on this work know full well that it ain’t gonna work out. The staff assigned to these projects are staff who are OK with doing the wrong work that will probably never be deployed because what’s the point. It’s an industry built on an expectation of failure.
How do you stop these failures from happening? Pretty easily! Stop prescribing exactly what contractors need to do. Instead, state the outcomes that are desired and leave it at that. The 800-page RFP is now 20 pages.
Of course, this requires a government product owner overseeing work every day, this requires competent scrum teams doing work as prioritized by the product owner, and it requires a time & materials contract that pays vendors for their labor, not their software.
Basically, stop thinking of these RFPs as procuring software. You’re not buying a thing! You’re buying developers’ time, time in which they do work as prioritized by the government product owner.
That’s it! The contract is dead simple.
Is the vendor’s work not good enough? No problem — stop assigning them work and they’ll go away. You don’t even need to terminate the contract. Because they were using agile, you can hire a new vendor and them pick up where the old one left off. Done.
And that is the story of why major government software projects fail, and the simple change that stops that from happening.
For more, see the handbook that Randy Hart, Robin Carnahan, and I wrote about budgeting for agile software procurements.