Waldo Jaquith+ Your Authors @waldojaquith Working dad. Thought follower. Fed. Male software developer. Former political appointee at @WHOSTP44. He/him. Last name pronounced JAKE-with. Feb. 05, 2020 2 min read + Your Authors

When government pays companies to build big custom software programs for them, they succeed just 13% of the time. Now I will tell you 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 RFP, 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 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 @Randy22401, @RobinCarnahan and I wrote about budgeting for agile software procurements.  https://github.com/18F/technology-budgeting/blob/master/handbook.md 

It turns out that a lot of people wanted to read this thread about custom software RFPs in a more reasonable place than Twitter, so I posted it as a blog entry.  https://waldo.jaquith.org/blog/2020/02/stop-procurement-failures/ 


You can follow @waldojaquith.



Bookmark

____
Tip: mention @threader_app on a Twitter thread with the keyword “compile” to get a link to it.

Enjoy Threader? Sign up.

Since you’re here...

... we’re asking visitors like you to make a contribution to support this independent project. In these uncertain times, access to information is vital. Threader gets 1,000,000+ visits a month and our iOS Twitter client was featured as an App of the Day by Apple. Your financial support will help two developers to keep working on this app. Everyone’s contribution, big or small, is so valuable. Support Threader by becoming premium or by donating on PayPal. Thank you.