FrankJon

Did you allow offerors to submit a single proposal responsive to more than one region/solicitation? This is what we did to save paperwork on their end and avoid redundant evaluations on our end. We also tried to convince the customer to consider a regional workload model, as acquisition leadership was much more comfortable with a contract structure divided according to objective criteria instead of the discretion of the customer. But the customer wouldn’t agree to this. So in the end, apart from meeting the minimum guaranteed quantities (each a healthy sum), the government may use each contract entirely as it wishes.

Scenario recap: Two years ago, I received a multibillion dollar requirement for nationwide commercial services over a five-year period. The customer requested two contract awards. Workload would be assigned daily, and could vary significantly from day to day. The most appropriate delivery arrangement would be an indefinite-delivery contract or FSS BPA. The customer also had one unusual request: for national security purposes, the contractors would need to remain at workload parity. In other words, the Government would need the flexibility to give each contractor an approximately equal share of the work over the lives of the contracts so that at any moment one contractor would be able to stand in for the other and rapidly scale its workforce to take all or part of the other contractor’s workload. The FAR and DFARS applied. Problem: The FAR doesn’t describe a way to award two IDCs for the same requirement and allocate work between them. It specifically precludes allocation in a multiple-award IDIQ scenario (FAR 16.505(b)(ii)(B)) and stipulates that a requirements contract is for “one contractor” to fulfill the Government’s requirements (FAR 15.503(a)). In addition, FAR 8.405-3 establishes a multiple-award BPA ordering process that basically mirrors the multiple-award IDIQ ordering process. Proposed Solution: After researching the issue, I landed on the strategy of awarding “split” requirements contracts (which I referred to at the time as multiple-award requirements contracts). We had a robust discussion about the merits of this approach here: Outcome: Despite legal concurrence, neither the customer nor SSA would agree to this strategy. The SSA was uncomfortable operating this far outside of the seemingly clear language of FAR 16.503. The customer believed our projected quantities were too speculative to meet the legal standard of a requirements contract (and did not want to be locked into a promise we couldn’t keep). After several briefings to advocate for this approach, the SSA told the acquisition team to start over. We looked at multiple avenues. We considered a deviation to fair-opportunity procedures (blocked by statute), FAR part 13 BPAs (ordering threshold too low), and very high guaranteed minimums in a multiple-award scenario (too risky). We considered other methods, too, but struggled to come to consensus on anything. We were basically at the end of our rope when legal counsel joked, “I wish we could just award two single-award IDIQs.” On a whim, I started to look at how that could conceivably be accomplished under the FAR, and landed on the following path: There would be no way to avoid fair-opportunity competition in a multiple-award scenario. Every definition of “multiple-award contract” at FAR 2.101 contemplates a “single solicitation.” So to avoid classification as a multiple-award contract, we could issue two, substantially identical solicitations simultaneously, with each cross-referencing the other and encouraging offerors to respond to both. Assuming each offeror responded to both solicitations with the same proposal, the question then became how to prevent one offeror from winning both awards. The answer was under FAR 6.202, which allows us to exclude a source from award in order to maintain another source. We would determine the awardee for one solicitation, then execute a D&F pursuant to FAR 6.202 excluding that source from consideration under the second award. And this is exactly what we did. We called them “parallel” single-award IDIQs. Though nobody within my agency could articulate a strong reason why this approach would not work, we nevertheless faced a lot of skepticism and criticism. The SSA accused me of playing fast-and-loose with the rules (I responded that this is exactly what “acquisition innovation” looks like). Many said that this was all unnecessary because many agencies utilize allocation to place orders against their multiple-award IDIQs and BPAs (though no one could ever explain how this was allowable under the rules). Others said that having dual contract files would be administratively burdensome and that conducting the source selection under each solicitation would be too complicated (we considered the risks and didn’t agree; ultimately, ~95% of each contract file is composed of identical documents, including the proposals). Luckily, a new SSA took over midway through this process and gave us the green light. We were careful to vet this with industry, too. We explained the delivery arrangement in a draft solicitation and gave contractors an opportunity to air concerns, but none did. We were also sure to explain within the solicitation the reason we needed to take this approach, the exact steps we would take to execute it, and the risks the contractors would be accepting if they received award. Nobody complained. Nobody questioned it. We’re presently scheduled to make award in December and thereafter will have total flexibility to utilize these IDIQs in a manner that best suits the Government, with virtually no concerns of protest mid-performance. And that’s what happened. I’m proud of this one. It’s been a long time coming (too long), with many hard-fought and probably unnecessary battles along the way. It’s an important requirement with a troubled history and significant national security implications. The prices are good, the customer believes that these contracts give them exactly the flexibility they need to mitigate risk going forward, and I believe the contracts are defensible under the FAR. I’ve done contracting for 11 years now and can’t say I’ve derived much satisfaction from it in that time. But this one, in this moment, makes it all seem worth it.

Parts 8 and 16 cover a lot of different topics. Are you referring specifically to subpart 8.4 (GSA FSS) and section 16.505 (IDIQ ordering) procedures?

The name of the game, sir.

Vern - It appears GSA’s practice is to include the full text of 52.212-4 in the contract with the deviated text replacing standard text. They label the whole thing as 552.212-4. FAR 52.212-4 is not cited.

I was very surprised to learn today that, apparently, it's not uncommon practice for ordering agencies to include FAR 52.212-4 in their GSA FSS orders when the base contract already includes GSAM 552.212-4. I'm told that even the DoD Procurement Management Review looks to ensure the former clause is included in these situations. I think this is a mistake. GSAM 552.212-4 is an authorized deviation to FAR 52.212-4 that flows down to the order. By including FAR 52.212-4 as well, we are introducing conflicting terms. Do other practitioners see this practice as well? Does anyone disagree with my position?

Based on a FAR Case that @Don Mansfield shared with me in November on a topic pertaining to the award of multiple/split requirements contracts, my responses are: (1) a single contract with multiple parties; and (2) I don't know about IDIQs, but in the context of requirements contracts, it matters. In 2010, the FAR Council explained FAR Case 2008-006, in part, as follows: https://www.federalregister.gov/documents/2010/03/19/2010-5989/federal-acquisition-regulation-far-case-2008-006-enhanced-competition-for-task--and-delivery-order Despite this, they left FAR 52.216-21 Alt. III in place. This states: On one hand the Council is stating that "a" requirements contract cannot "be awarded to multiple sources." On the other, it permits the award of 2 distinct requirements contracts for the same subject matter. Based on the use of the singular in the former, I believe what distinguishes these ideas is that "multiple-award" refers to one contract that is "shared" among parties. I also think this idea extends to IDIQs, though I don't know whether this "matters" for IDIQs. But it does matter in the context of two or more requirements contracts, as we want to avoid the fair opportunity requirements of FAR 16.505(b). It's nice to see you "unretired" from Wifcon, Vern. We spoke a bit at the 2019 N&CR Roundtable, a million years ago. You advised me to avoid outings with birders at all costs. 😉

Don - I apologize if I haven't been descriptive enough, but the contrast is significant. I'll try to be more specific in this post. (1) As we know, DFARS 215.470 requires a CDRL when the Government requests data. "Data" is not defined in the DFARS as far as I'm aware. (2) DoD 5010.12-M purports to provide comprehensive instructions for the acquisition and management of data, including the preparation of CDRLs. It defines "data" expansively (see above), to include technical data and data incidental to the contract, like financial and management data. Likewise, it defines "technical data" as having "the same meaning" as "data." As I mentioned at the top, I think this DoDM is a flawed document of questionable authority, primarily because it lacks a DoDD or DoDI to supplement. Without those, I don't see how it stands as anything more than a guide. (3) Alternately, in its "How to Complete a CDRL" guidance, DAU states: Likewise, the Government Contracts Reference Guidebook (4th Ed.) defines a CDRL as: and technical data as: (4) Thus, the DoDM would require CDRLs for all "recorded information regardless of the form or method of recording," whereas the latter sources would only require CDRLs for technical data, and exclude data incidental to contract administration. I don't believe it's appropriate to require CDRLs for all "recorded" deliverables. I believe CDRLs are only required for technical data, as defined in the GCRG and at FAR subpart 27.4. But...I lack an authoritative basis for this belief and the DoDM is admittedly a complicating factor.

As the word is used in DFARS 215.470. Most sources I have seen indicate this is a reference to technical data as described at the DAU link (see also the Government Contracts Reference Guidebook definitions of CDRL and technical data). On the other hand, DoD 5010.12-M states: And: So there seems to be a clear conflict between how the DoDM defines "data" and how other, more modern, sources define it.

And thank you for the reminder about the applicability of FAR subpart 27.4 in DoD. I should have reviewed the DFARS on this prior to posting. Despite this, there are various sources (none primary that I recall) that describe the CDRLs meaning of data as it is defined at FAR subpart 27.4 or similarly.

Hi Don, I'm not questioning whether it's active. I'm questioning whether it's necessary and reasonable to treat it as mandatory policy without an underlying DoDD or DoDI at its foundation. DAU also appears to reject the expansive DoD 5010.12-M definition of data. See: https://www.dau.edu/tools/Lists/DAUTools/Attachments/654/High-Level CDRL Plannng_26 June 2020.pdf pgs. 19-20.

Carl...respectfully....you're killing me. That doesn't get me any closer to an authoritative definition of "data" as it pertains to CDRLs.

At issue within my office are the conflicting definitions of "data" found at DoD 5010.12-M and FAR 27.401 as they pertain to the CDRLS requirement. If DoD 5010.12-M is not authoritative, then we would look to other sources, such as FAR 27.401, for the definition. A DoD Manual "implements policy established in a DoDD or DoDI." (DoDI 5025.01, pg. 17.) DoD 5010.12-M was "issued under the authority of DoD Instruction 5000.2, 'Defense Acquisition Management Policies and Procedures.'" The referenced DoDI 5000.2 no longer exists. The modern DoDI 5000.02T "Operation of the Defense Acquisition System" does not appear to be directly relevant. The DFARS references various manuals, but not DoD 5010.12-M. Defense Pricing and Contracting ain't answering the phone. My thinking is that DoD 5010.12-M lacks clear authority to mandate procedures pertaining to CDRLs, and is otherwise severely outdated to the point of obsolescence (e.g., try following some of the references). I would therefore advocate for a modern understanding of the term "data," which according to FAR 27.401 "does not include information incidental to contract administration." I would be interested in reading the opinions of others on this topic as it pertains to CDRLs.

Thanks for the enlightening discussion, all. I’ve yet to check all the references but it seems like I now have a few workable options to put forth.

Formerfed: Apology accepted, but I would respectfully disagree with your characterization of how I consider the information shared on here. For instance the idea of a pre-competed BPA raised by Don and Carl is new and very interesting to me. I don’t merely disagree to be contrarian; rather I try to provide reasonable interpretations of often ambiguously-written text (in this case, 13.305(b)). If that shows inexperience then I have a hard time imagining what experience in this business looks like. If that annoys you then perhaps another hobby is in order. All due respect to ji, but s/he takes a famously flexible view of FAR language (to the envy of many) and is not infallible. I recall earlier in this discussion revealing scholarly information about multiple award requirements contracts that was not known to many and that supported my initial ideas. I also found a former post by one of the “Old Guard” at Wifcon supporting my view that DOD may lack the authority to issue calls above the SAT. So it seems at least possible that my individual findings and interpretations bring some value to this forum, despite the views of more seasoned professionals. I think one should and can do both things at Wifcon: critically question ideas while recognizing the enhanced value of the “Old Guard’s” input. I do hope that your counterparts haven’t also found my posts to be dismissive. It certainly is never my intent here.