Steve Kelman spotlights two areas where real obstacles to effective IT contracting may exist -- and suggests solutions for each.
Steve Kelman argues that agencies often overpay for web design that could be handled better, and more cheaply, by smaller firms.
A recent FCW story by Mark Rockwell, "Teaching feds not to fear the FAR," has gotten a fair amount of attention in the Twittersphere and is definitely worth reading. It discusses a number of efforts underway -- including a “Buyer’s Club” led by Health and Human Services Chief Technology Officer Bryan Sivak and a TechFAR document being prepared at the Office of Federal Procurement Policy under the leadership of the indefatigable Mathew Blum -- to lower the fear factor in the government IT community around the Federal Acquisition Regulation (FAR) and to emphasize flexibilities available in the regs.
These are very good efforts that deserve support. Many new and exciting procurement techniques, such as contests and crowdsourcing, are -- as those quoted in Rockwell’s article note -- already permitted by the FAR. The government can access some crowdsourcing websites for less than $3,000, which means services there can be purchased without further ado using a government credit card.
We do, however, need to ask ourselves whether there are important areas of IT contracting where the FAR actually is a genuine impediment, as opposed merely to a vague source of fear.
I have two nominations, involving very different kinds of IT procurement – purchasing web design and stand-alone web app services from new, innovative firms, and then contracting for agile development. I’d like to get a dialogue going about whether these are genuine obstacles, and whether there are others that should be added to the list.
My guess is that agencies frequently dramatically overpay for mediocre web design and web app development work done by large, traditional government IT contractors. There are oodles of small startup firms out there that should be doing this work. In terms of the actual procurement process, simplified procedures for commercial-item buys up to $1.5 million should make the process relatively simple. The problem, I suspect, lies in the various “socioeconomic” contract clauses, many of which even apply to work under $100,000, that frighten small companies.
If I’m right, this is costing government and taxpayers a lot of money for benefits that are minute at best. Do these garage startups really need affirmative action plans that go beyond those applying to companies in general?
Here, though, statutory change is needed. I would propose eliminating all such clauses (as we currently do with purchases under $3,000) for contracts or task orders with small businesses that have had five or fewer government contracts.
The problem with agile is different, and centers on the bureaucratic nature of the government’s past performance system. Agile development, with its very general requirements for individual short spurts, works well in the commercial world because private-sector customers can easily and quickly stop giving work to vendors who screw up on one too many iterative "sprints." Federal agencies are not allowed to be nearly so nimble in changing or curtailing a contract.
Here my suggestion is that agencies work to obtain, either for an individual contract or for all agency software contracts using agile for a set period of time, a deviation from FAR past performance documentation requirements. We could then test what happens when the customer can stop giving orders to a poorly performing vendor with only a moderate explanation of why. Even better, Congress could pass a test program authorizing such experiments for all agile contracts for three to five years.