By Steve Kelman

Blog archive

More debate about pre-RFP talks between government, industry

In this post, I would like to reflect on some of the interesting comments on my last post -- on pre-RFP communication between government and industry -- and return in my next post to issues and challenges in terms of creating IT technical expertise available to government to make it more possible for the government to be a smart buyer of complex IT solutions.

Let's start by going back to basics. First, none of the comments disagreed with OFPP Administrator Dan Gordon's observation that industry frequently sees an IT procurement going off track and, for whatever reason(s), doesn't tell the government what it knows/feels/suspects. Can we agree -- without worrying about apportioning blame -- that this is a problem?

Second, in my experience it is a relatively common occurrence that after contract (or task order) award, government and the contractor have problems (sometimes ending up in court) because of differing interpretation of language in an RFP and the resulting contract. If more could be done to deal with even a portion of these problems upfront, the government would avoid many painful problems later on. At a minimum, it would be a good thing if industry informed the government about any possible confusion in the wording of an RFP and solicited clarification. I am guessing this happens sometimes, but far from always.

Finally, let us remember one of the reasons government contracts out activities in the first place: To take advantage of specialized knowledge and outside insights about what they are buying. So it would be a good thing -- and this is the purpose behind a lot of the customer-vendor communications occurring in IT contracting inside the private sector -- if the government were able to gain from industry any insights into its requirements. For example, if the government sets an availability requirement of 99.9 percent, and vendors could shave 25 percent off the price if the availability requirement went down to 99.5 percent, vendors should let the government know that.

But those talks should not include approaches to meeting the requirements -- that is for the proposal, and should be a subject of competition among bidding vendors, rather than something shared pre-RFP with the government.

Conclusion: pre-RFP government-industry communication, including in one-on-one settings (often the only venue where vendors will speak openly), is an important part of improving the IT acquisition process. This view, incidentally, was specifically endorsed and acknowledged when Part 15 of the Federal Acquisition Regulation was rewritten in 1997.

Of the comments on my last post, the one that disturbed me the most was the suggestion that many government officials are afraid of communicating with industry for fear of violating organizational conflict of interest rules. This one wanted to make me cry.

OCI rules are designed to deal with issues when a contractor paid to work on the requirements for the government also bids on doing the work. The procurement system is specifically designed to allow potential bidders to present unpaid input to the government on such issues before the RFP has come out. I know the contracting environment has become infected in the last few years, but the perception that OCI issues are involved here sounds like a gangrene threatening the life of the system. Dan Gordon, can OFPP make a pronouncement, or even a revision to the FAR, about this?

On the government's fear of giving away inside information, I would say that the dysfunctions caused by refusal to talk with industry one-on-one, which this fear creates, are serious enough that the government needs to take on this issue directly. How about one simple meeting for an hour or so before a series of one-on-one meetings with industry to discuss guidelines and things to be careful about not disclosing? Are we really going to accept a process that doesn't work because we fear we can't handle this issue like responsible adults?

On the observation by "govie" that industry sometimes seeks to sell the government a solution that corresponds to the firm's capabilities rather than the government's interests, this is indeed why the government needs to have technical knowledge at its disposal -- to separate the insightful wheat from the self-serving chaff (and of course there is a lot of chaff). This is a topic to which I will indeed return in my next post.


Posted by Steve Kelman on Sep 28, 2010 at 7:26 PM

Reader Comments

Fri, Oct 8, 2010 Jaime Gracia Washington, DC

The OCI issue is a major barrier to increased communications from industry. Many firms fear that being proactive in helping shape requirements will OCI-themselves out of competition for a particular procurement. This is a major issue that needs more thoughtful analysis, as the point of crowdsourcing is to solicit information from all parties equally, and allow for even greater opportunities for competition with requirements that are not overly restrictive and well understood by industry. Firms should not be penalized, nor should they have fear of being penalized. The government is doing itself a disservice by not properly proving these protections.

Thu, Oct 7, 2010 Bill the Proposal Guy

"it would be a good thing if industry informed the government about any possible confusion in the wording of an RFP and solicited clarification. I am guessing this happens sometimes, but far from always." Steve, It actually happens all the time. If you go to fbo.gov, you'll see that most solicitations provide a point of contact and a deadline for submission of questions before the proposal due date. Some large solicitations receive hundreds of questions, and ambiguous RFPs of all sizes often generate enough vendor questions to cause the Government customer to re-think their requirements and amend the solicitations with extended due dates. Responses to questions are published to all potential offerors at fbo.gov or through other means. Under the FARs, the Government is obligated to any question that materially affects the requirements of the solicitation. The problems are usually when the Government responds to a question such as "Does the Government anticipate a fixed-price or a time and materials contract?" with "Yes." In addition to planned orals, the Government can call in vendors, one at a time, to discuss or clarify elements of their offers.

Thu, Sep 30, 2010 Edmond Hennessy United States

Steve - this is an insightful article and can be viewed, as controversial, depending what side of the fence one is on. Certainly, realize that the way the Government approaches IT may be different than the way Government/Military approach working with Industry on Weapons Defense Systems (although there should be similarities). Your reference to lack of pre-RFP interactions (and the range of issues that surface) in the IT world are not fail-safe in the Weapons Defense segment, however Government/Military, Defense Contractors/Integrators and COTS Technology sources have been going to the table (early in the cycle) to shore things up. Common for Government/Military to go out in Industry and do an exploratory thru feasibility studies and RFI's - just to get a lay of the land, before things get buttoned-down, serious and BAAs and formal RFPs are garnered. As mentioned - this is not goof-proof, however it mitigates a lot of the uncertainty, churning and hassle that you reference taking place in the IT segment. Do the agency sources talk and gain from cross-agency, experience?

Wed, Sep 29, 2010 Christopher Yukins Washington DC

During our recent colloquium to discuss the work of the GTO-21 commission, the lawyers raised several legal doctrines that relate to this issue of government-industry communication. One is the doctrine of "patent ambiguity": if a specification is obviously (patently) ambiguous (i.e., flawed), a bidder must bring that problem to the government's attention; if he fails to do so, and wins the contract, the bidder/contractor may not later recover the additional costs caused by the flaw/ambiguity. This incentivizes the bidder to share information with the government when he foresees problems with the specifications. In IT procurements, however, which are typically opened-ended competitively negotiated procurements, the specifications are generally "performance" specs, not "design" specs, and so describe broad performance goals of the proposed system. As a result, it is far less likely that anyone will recognize a "patent ambiguity," or that anyone will lose money because he has failed to identify such a flaw to the government. In the world of IT procurement, therefore, this important, traditional spur for contractors' early disclosure -- the patent ambiguity doctrine -- simply lacks the same punch.

Wed, Sep 29, 2010 Mark

Blaaaa to fairness advisors. Another layer of bureaucracy looking over the CO. A CO needs to be able to make these determinations on there own, that's their job. No need to hire more government employees to do subset of the COs current responsibilities. What an obvious waste of time and money in an era of declining budgets. Just have a frank, honest, and legal discussion. -contracting 6yrs

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

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 June 7 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.