Major government software procurements fail at a high rate. There are a lot of methods of reducing the odds of failure, but how do you know if that’s necessary?
Developers talk about “code smells”—small things that are off in ways that indicate that there may be larger problems. So, too, are there procurement smells—the little tells in requests for proposals and associated materials that vendors use to know if this is a project they want to have anything to do with. We can use similar procurement smells to determine if a project has any real chance of success, or if it will join the ranks of the supermajority of major procurement that don’t pan out.
It works like this: Review the list of statements below, and tally one point for each statement that describes the project in question. Cumulatively tally similar statements, so that e.g. a 1,000 page RFP would be awarded a point for being 100 pages, a point for being 500 pages, and a point for being 1,000 pages.
- The RFP is longer than 50 pages
- The RFP is longer than 100 pages
- The RFP is longer than 500 pages
- The RFP includes 10 requirements
- The RFP includes 50 requirements
- The RFP includes 100 requirements
- The contract is for both technical services and non-technical services (e.g., both building software and running a help desk)
- The contract is for customized COTS
- The contract is for more than $10 million
- The contract is for more than $50 million
- The contract is for more than $100 million
- The contracting officer insists on “one throat to choke”
- The agency has no intent or capacity to inspect the vendor’s code
- The RFP says nothing about user research
- The contract is fixed price
- Work is to be delivered to government only at the conclusion of the performance period
- The period of performance exceeds three years
- The vendor will own the resulting software
OK, now score your project!
0 points: This could work
1 point: This is not impossible
2 points: You’re going to have a bad time
3 points: Get out while the gettin’s good
4+ points: Abandon hope, all ye who enter here
(To learn how to avoid these problems from happening in the first place, see 18F’s De-Risking Guide, particularly “Budgeting and overseeing tech projects.”)
Have any additions to propose? Comment here, email me, or reach me on Twitter