the lectern banner

By Steve Kelman

Blog archive

Help for contract requirements

If you talk with contracting people, there is probably no theme that comes up more often than the challenges of working with program people to develop statements of requirements (hopefully performance-based as much as possible) for what they buy. Many program people don't know how to do this, and often they resist doing so -- seeing it as a bunch of bureaucracy imposed on them by contracting weenies.

While not denying that contracting people are capable of imposing valueless bureaucratic requirements on program folks -- sometimes because they just want to, though often because they are required by law -- in this case I think program people should reconsider any instinctive hostility. If you can't put down on paper what you want out of a contract, it is much more likely that the contractor won't give you what you need to get your program to work well, or that you will get overcharged due to rework and wheel-spinning.

Yes, requirements typically change over time, and it is often difficult to know exactly what you want when you are starting buying something new, but it is really in the program's interest -- and not just a bureaucratic requirement -- for program folks to do their best.

There is some good news here. Internet-based tools now exist to walk program people through the development of requirements, taking the contracting jargon out of the process and not demanding that the program folks be walking FAR-ites.

One tool, called Automated Requirements Roadmap Tool (ARRT) and developed for the Defense Acquisition University, basically uses a TurboTax-type interview approach, which is a really good idea. Just as TurboTax doesn't require you understand the tax forms and just asks you a bunch of interview questions -- and then reformats the answers to correspond to the tax forms -- ARRT does the same thing. It asks the program person a number of questions, and then creates a requirements document. ARRT is designed to help develop requirements for buying services, which are often the hardest for program people to do. The program person still needs to know what they want -- no tool can solve that problem -- but the tool basically takes a lot of the bureaucracy out of the process. This tool is available free; all you need to do is register. Thanks to the Defense Acquisition University for making this available.

A second tool, part of the Tailored Acquisition Portal developed by the company ASI Government, is similar in that it allows the program person to sidestep bureaucracy and stay focused on the task at hand. It uses a somewhat different approach to development of the actual requirements, however, focusing more on recurring requirements (for services or products) and centered around the use of templates that fill in most of the features of a requirement. Hence this tool is adapted to specific customers and their specific recurring requirements.

A tool ASI has developed for the Army Medical Command allows, for example, quick development of a requirement to buy contracted nursing services -- most of the elements of the requirement are in the template, and the customer fills in such supporting data as how many nurses are needed, for what period of time, and where, along with details of the source selection criteria (such as whether price or past performance is more important.) ASI is a for-profit company, and they charge customers for their tool, including tailoring the tool to the specific recurring requirements the organization wishes to cover. (Full disclosure: I have no financial connection with ASI Government, but I have spoken at a number of ASI conferences over the years, and received modest speaking fees.)

These great tools, as noted, don't do all the work for the program people. Program people should still consult with a good contracting person in their organization who can help them think through how to express requirements in words (I always like starting with the question: "How will you know if this contract has succeeded after it's done?"). I also am pleased that a number of contracting organizations, and some program organizations, are using actual boundary-spanners expert in both the program (engineering, IT) and contracting worlds to help the two cultures communicate for the purposes of developing better requirements.

Posted on May 10, 2012 at 12:09 PM


Reader comments

Fri, May 18, 2012

Writing requirements documents is one of the primary transaction costs in issuing a contract. The internet and IT revolution has slached transaction costs for all kinds of merchandise, but complex services are a *much* more difficult row to hoe. Give up castigating the Program folks about bad requirements documents, my fellow COs. Become much more active in helping them-you will both be better off for it. My only rule is make the Program folks do the first draft, and stress you can only refine what's on the page, you can't reliably detect what's missing.

Fri, May 11, 2012 Vern Edwards

Steve: It does not make sense to talk about requirements analysis unless you say what kind of requirements you are talking about. Are you talking about hardware or services? If services, what kind? Short-term transactional or long-term relational? The government never gets anywhere with this problem because it thinks shallowly and without facts. Instead, it relies on half-baked ideas and myths like the Wright Brothers Contract. This is a serious problem that will be solved only when and to the extent that serious people reason from facts to reach valid conclusions before writing policy letters and launching websites and training programs. As for the complaints from contracting people about program people, it’s time for them to stop complaining about how poorly program people do something that contracting people cannot do themselves and cannot even explain. They should shut up, stop issuing policies and regulations, and read a book or two about the subject before they utter another word or hire another company to develop another website. It might help them come up with a new idea or two about how to contract for things that are not susceptible of up front full specification. They shouldn't complain about how other people do their jobs until they can do their own jobs well.

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