Requirements are the Achilles’ heel of procurement.

Ask users, managers and regulators for a program’s requirements and you will get a vague description of products and services that are currently available. They inevitably “require” what they already know could work today. And that’s a problem because by the time the request for proposals is released, the proposed solution might be overtaken by better and more affordable options.

What a program requires is a competitive procurement that complies with regulations and delivers the desired results. The challenge is determining what a program really needs. How can we define those needs in such a way that bidders can propose solutions that take advantage of what’s available today but also retain the ability to meet changing and future needs?

One answer is to ask the “What are your requirements?” question in a few different ways. Tom Love, CEO of Shoulders Corp., offers hope in this regard. He suggests we bench the term “requirements” and use other terms that will unearth real needs. In other words, pose the question to elicit more thoughtful and thorough responses.

Love has put together a list of 18 terms or concepts that can help deepen a discussion and bring real needs to the surface. For example, one idea is develop “story cards” that show how the solution might be used. Love also encourages people to incorporate refreshment plans for updating technology and decommissioning plans for bringing systems to a close. The full list of terms appears below.

This approach can help us break our reliance on known and preferred solutions and focus instead on the actual needs of users — to transform from solution understanders to user-oriented requirements understanders, as Jim Beveridge put it in his sales and marketing seminars in the 1970s.

It might also help us finally resolve what renowned software engineer Barry Boehm calls the IKIWISI problem — “I’ll Know It When I See It,” a common problem that makes it difficult to define needs.

As the needs are identified, we might prioritize them by creating three categories: needs, wants and desires.

For example, we need a payroll system. We want to include the ability to issue W-2 statements within the required period. We desire to deliver it all on the first official release day to impress our employees with our support services. Discussing perceived needs might unearth some interesting possible solutions and bring to light the readiness to accept new or revised solutions.

A lot of this comes down to semantics, but in this case, semantics matter. The ultimate solution might very well come out better if we pose the question in a different way.

What do you think?

Tom Love’s suggested terms for identifying program needs:

• User input
• Project charter
• Unique security profile
• Functional specs
• Business cases
• Use cases
• Performance metrics
• Operational scenarios
• Transitional scenarios
• Nonfunctional needs
• Interface needs
• Screen designs
• Application mock-ups
• Story cards
• Validation tests
• Acceptance tests
• Refreshment plan
• Decommission plan

— by Ray Kane, a consultant who has worked in the federal market for more than 40 years, on Oct. 15, 2010