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.