Lectern

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 7:26 PM


Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

What is your e-mail address?

My e-mail address is:

Do you have a password?

Forgot your password? Click here
close

Trending

  • Dive into our Contract Award database

    In an exclusive for WT Insider members, we are collecting all of the contract awards we cover into a database that you can sort by contractor, agency, value and other parameters. You can also download it into a spreadsheet. Our databases track awards back to 2013. Read More

  • Navigating the trends and issues of 2016 Nick Wakeman

    In our latest WT Insider Report, we pull together our best advice, insights and reporting on the trends and issues that will shape the market in 2016 and beyond. Read More

contracts DB

Washington Technology Daily

Sign up for our newsletter.

I agree to this site's Privacy Policy.