By Steve Kelman

Blog archive

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.

Posted on Dec 08, 2010 at 12:08 PM


Featured

  • Cybersecurity

    DHS floats 'collective defense' model for cybersecurity

    Homeland Security Secretary Kirstjen Nielsen wants her department to have a more direct role in defending the private sector and critical infrastructure entities from cyberthreats.

  • Defense
    Defense Secretary James Mattis testifies at an April 12 hearing of the House Armed Services Committee.

    Mattis: Cloud deal not tailored for Amazon

    On Capitol Hill, Defense Secretary Jim Mattis sought to quell "rumors" that the Pentagon's planned single-award cloud acquisition was designed with Amazon Web Services in mind.

  • Census
    shutterstock image

    2020 Census to include citizenship question

    The Department of Commerce is breaking with recent practice and restoring a question about respondent citizenship last used in 1950, despite being urged not to by former Census directors and outside experts.

Stay Connected

FCW Update

Sign up for our newsletter.

I agree to this site's Privacy Policy.