How to improve procurement: Stop talking about requirements

Ray Kane is a consultant who has worked in the federal market for more than 40 years.

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

About the Author

Ray Kane is a consultant who has worked in the federal market for more than 40 years.

Reader Comments

Thu, Mar 29, 2012 Michael Ayres San Francisco

Sure, those other words are further down the path of requirements decomposition, as derived requirements, or supporting requirements and also in the systems engineering domain.

Fri, Nov 5, 2010 Kay Ramesh

The article is right on the message. Today's challenges with the procurement process has to be definitely addressed, especially considering the long bid and evaluation process. In this economic climate this advice comes to us at the right timing. The needs, wants, desires is also a great way to control scope creep on current projects. Great article. Thanks Ray.

Mon, Nov 1, 2010 Mary Davie

I’m responding to Ray’s commentary with some highlights of ideas we received on the BetterBuy Project site ( as well as a robust discussion that took place on this very topic in the Govloop Acquisition2.0 group (
I’m only listing/describing a few of the ideas and ones that aren’t often discussed but feel free to visit both sites to view and contribute to the discussions.

• Build repositories to share market research across government (and for that matter, shared SOWs, SOOs, PSWs, etc)
-ex: “DoDTechipedia (and crowdsourcing component, was created. Market research should be a shared responsibility both govt-wide in collaboration with Industry.
• Collaboratively build requirements in the open on a wiki asking for input from anyone (GSA tested this one and had success – (see
• Leverage Integrated Product Teams to define requirements and frame solicitations
• Create agency advisory boards comprising the eventual users of the procured items/services
• Segment acquisitions into smaller pieces for faster procurement and more competition:
- Crowd source ways of breaking projects into smaller pieces that can start immediately. A risk with using social media for requirements gathering is that the scopes will become impossibly large.
- Require open standards, open development environments, and open source code so that individual pieces of the project can be tracked as they are developed and will fit together.
- Keep the pieces small enough that vendors can effectively compete for them, reducing cost for the government through competition and creating small business jobs.

And from the Govloop Acquisition2.0 Group:
• “Use of social collaboration to reach beyond contractors such as academia, retirees; reducing scope and cycle times to reduce functional obsolescence, improve competition”
• “Use of Agile Management and Agile Software Development - first principle is the only constant is change; specifically, changing technology and requirements. We often confuse capabilities with requirements, and requirements with user expectations. There are rarely changes in what capabilities the government is asked/legislatively required to deliver. Here is the rub: the Federal Acquisition Lifecycle doesn't allow for this level of innovation. Technology is moving at an exponentially increasing rate faster than Moore's Law. Remember, Moore's Law only applies to hardware. Software in turn, has not progressed at the same rate as hardware as evidenced by the fact that most computers have more processing capabilities than software using the processors. Bringing it back down to Earth: The Federal Acquisition Lifecycle is no longer aligned with reality for software and systems implementation.”

Mon, Nov 1, 2010

The problem is not identifying the shortfalls, most of us have seen them all. The problem is forcing a solution. The intent of the FAR is to insure that the government gets the right product, at the right price, through an honest and rigorous competitive process. Today we see an unmistakable, often formally mandated, shift away from a rigorous and objective source selection process to what is euphemistically called "best value" decision process. The up-front, public definition of "best value" makes perfect sense, i.e. pick the proposal that balances the greatest probability of success against any small cost differences. Hiding underneath, a "best value", subjective decision is easier to defend in court than a poorly done objective decision. "Best value" selection opinions, written up in appropriately vague terms of subjectiveness, can not really be contested. While avoiding costly and time consuming court cases is a noble goal, the counterpoint is that the door swings open to "best value" decisions that, frankly, may not be supported by good judgment and credible assessments. There is always the suggestion that the selection was capricious or even corrupt, not based on considered technical factors and good business sense. The real solution is perhaps right in front of us but sufficiently unpalatable as to be conveniently ignored. We must spend the effort to get the right "requirements" and relative values, including the "non operational" requirements that get lumped together in a proper "best value" decision. We must restore a rigorous, objective assessment of each critical factor and let the source selection decision stand on technically and operationally supportable hard numbers rather than a smoke cloud of "best value" rhetoric. Perhaps more important than the source selection, REQUIRE that the program be executed by people with the same "operational and technical" understanding of the system so that the intended capability is not eroded to nothing through cost and schedule adjustments. Is it hard? Of course it is. It requires technical and operational expertise from the lowest levels of the process to the top, not career bureaucrats and business school-anointed careerists. (Notably, this is a hard sell to career bureaucrats!) If providing the right product, at the right price, in an innovative, competitive, and objectively assessed environment is too hard, then perhaps we, sadly, have no choice but the sham of "best value" as we know it. The procurement system will survive, as it always has, but users and US taxpayers, who we in the government procurement system are, by the way, sworn to "support and defend", will continue to be the losers.

Thu, Oct 28, 2010 Jaime Gracia Washington, DC

It is the fear of change, combined with a risk averse culture, that has created a procurement process for technology that is outdated and obsolete. Instead of focusing on needs, the government focuses on buying specificity by the dreaded “shall” statement. Specifications are larded into a SOW to the point where best value is not possible. Instead, contracts go to the lowest bidder, along with ubiquitous contract modifications to create failing programs that are over budget and behind schedule.

Show All 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.


WT Daily

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.