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


  • POWER TRAINING: How to engage your customers

    Don't miss our July 12 Washington Technology Power Training session on Mastering Stakeholder Engagement, where you'll learned the critical skills you need to more fully connect with your customers and win more business. Read More


    In our latest Project 38 Podcast, editor Nick Wakeman and senior staff writer Ross Wilkers discuss the major news events so far in 2019 and what major trends are on the horizon. Read More

contracts DB

Washington Technology Daily

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.