Better requirements -- at the task-order level

At the Future of Acquisition conference (as I reported on in my last blog post), the panelists all spoke to one degree or another about the government's need to do a better job establishing contract requirements. That should be no suprise -- it's a topic that contracting professionals almost always discuss when they are talking about how to improve acquisition in government.

Without good requirements, contracting people are inclined strongly to believe, it is much more difficult to have a successful contract.  When panelists were concerned that the government was getting better at "buying the wrong things faster," the worry was that people not spending enough time figuring out what the agency wanted to buy before going out and buying it.
 
Program people often push back on this line of reasoning, arguing that it is often difficult to establish good requirements in advance. Users have trouble describing exactly what they want;  they need to see and work with something before they know exactly what features it needs.  The effort to specify requirements in advance, in the IT arena, has often gone hand in hand with the kind of "grand design" IT projects that CIO Vivek Kundra and other experts believe are a recipe for IT systems failure.

A recent TechAmerica industry report on improving government IT acquisition also discouraged "grand design" approaches, 
 
My own view is that we do indeed need to worry seriously about requirements. But we also need, especially for large IT projects (or other complex and/or long-lasting activities), to take seriously the idea of letting requirements evolve over time, not trying to establish them all in the contract signed at the beginning of the work.
 
The result of taking both these ideas seriously, it seems to me, is to break major IT projects into task orders under a larger contract -- and then to be serious about requirements at the task order level.  For these kinds of contracts, we shouldn't worry as much about requirements in the initial RFP (Although I do think that the underlying contract should include some performance standards for the applications to be developed in the project). Task-order level requirements reflect evolving knowledge over time, along with changes in technology as the project is being developed.
 
I am also a believer in competition around requirements. Traditionally, IT projects executed through task orders have had only one vendor, and no competition on individual task orders. ASI Government issued a report several months ago arguing that changes in technology regarding architecture and interoperability have made it more feasible to maintain task-order competition among two vendors for major IT projects.  I will return to this idea in a subsequent blog.