Jump to content

Architecture & Engineering "Design-Build" and Biased Ground Rules OCI


govt2310

Recommended Posts

 

A Biased Ground Rules OCI is when Contractor A writes the requirements (the SOW) for Contract #1, then Contractor A tries to compete for Contract #2 (which has the SOW that Contractor A just wrote).  That is why FAR Part 9 conflicts Contractor A out: Contractor A cannot submit a proposal for Contract #2.  While in theory, an offeror can submit an OCI mitigation plan, for a biased ground rules OCI situation, there is no way to mitigate it, not even by subbing the work for Contract #2 to a subcontractor. 

Well, the scenario above involves two contracts.  What if an agency just did one contract where the SOW was to both figure out the agency's requirements, write it up, then provide the requirement.  This sounds ludicrous to me, but it is an actual question that has been raised.  They are thinking, how is it that FAR Part 36 allows for Architecture & Engineer contracts to be "design-build"?  In essence, the agency is saying, we don't know what our requirements are, all we know is the broad scope (we need a new building), and it relies on the contractor to flesh out the details and make the building.  Why couldn't this concept be applied to other stuff, like software development, cloud computing, etc?

I think this is wrong, but what law/regulation/court decision do I cite to show that this can't be done?  Or can it?

 

Link to comment
Share on other sites

In Federal FAR-based design-build contracting, the design-build contractor or it’s A-E firm, if not designed in-house, doesn’t define the requirements and isn’t allowed to develop the design criteria for the design-build solicitation, consistent with FAR 36.209.

See FAR 36.104 for Design-Build statutory and regulatory citations.

See 36.3 for the Two-Phase D-B policies and procedures.

The design-builder performs the role and responsibilities of the Designer(s) of Record, in contrast to the owner in the traditional design-bid-build acquisition method. But it doesn’t define the building requirement and the design criteria.
 

That’s the “short story”. 

Edited by joel hoffman
Link to comment
Share on other sites

Please note, specifically, 36.302 Scope of work.

“The agency shall develop, either in-house or by contract, a scope of work that defines the project and states the Government’s requirements. The scope of work may include  criteria” [i.e., “design criteria”] “and preliminary design, budget parameters, and schedule or delivery requirements. If the agency contracts for development of the scope of work, the procedures in  subpart  36.6 shall be used.”

Link to comment
Share on other sites

In re-reading your question, I note that you are referring to 

2 hours ago, govt2310 said:

Architecture & Engineer contracts to be "design-build"

Please note that a design-build contract is a construction contract, not an A-E contract. An A-E firm could be and occasionally has been the prime contractor for D-B but it is technically a construction contract.

Per 36.302, the government provides the scope and requirements for the design-build construction contract - separately from the actual design-build construction contract. 

 

Link to comment
Share on other sites

I’m sorry if what I am saying is confusing.
I’m familiar with the D-B concept and am familiar with the 36.209  prohibition against an A-E firm preparing the scope and the functional and engineering design criteria, or partial or full design, then competing for the construction contract (which can be either straight construction or design and construct/build).

It should logically follow that the same A-E firm can’t define the requirement and design criteria, then design the project and construct it. It doesn’t matter if there is only one contract or there are two contracts to do all this. 

 

Edited by joel hoffman
Link to comment
Share on other sites

FAR 36.104(a) states: "Unless the traditional acquisition approach of design-bid-build established under 40 USC Chapter 11 .  .  . or another acquisition procedure authorized by law is used, the CO shall use the two-phase selection procedures authorized by 10 USC 3241 or 41 USC 3309 when entering into a contract for the design and construction of a public building . . . ."  What is the definition of "design-bid-build"?  I don't see it in FAR 2.101.  To me, what an A&E firm does, as described in 40 USC Chapter 11, is only "design."  They don't build anything.

I'm sorry that my question is causing confusion.  I am being told that the Government can and does by "design-build" services to build public buildings, and I am being told this justifies applying this approach to other things, such as computer software.  I'm trying to figure, is that true?  Does the Government buy "design-build" services to build public buildings, where there is only one Contract, and that Contractor does both the design and the build?  If so, how can this be?

 

Link to comment
Share on other sites

See 36.102 Definitions:

“Design-bid-build means the traditional delivery method where design and construction are sequential and contracted for separately with two contracts and two contractors.” **

“Design-build means combining design and construction in a single contract with one contractor.”

**This term is misleading because the government can also design the project internally without resorting to hiring a contractor. In the design and construction industry, it means that the owner furnishes the constructor the design and is legally responsible for the design.

Then read 36.3, concerning Design-Build acquisition.

As alluded to in 36.104, there are a couple of other design-build approaches authorized by law. However,  the overall concept of one contract with a single contractor providing both design and construction solutions to the government’s defined scope and design criteria are essentially the same. The design-builder furnishes the completed design and constructs the project.

If you are somewhat confused by the sparse coverage of design-build in the FAR, it’s because there is hardly any coverage or details in the FAR.

The FAR doesn’t address the unique and non-traditional roles and responsibilities of the owner and its design and construction contractor, who provides the “designer(s) of record” *** along with their responsibilities.

When the two-phase design-build process was being added to the FAR in 1996-1997, the D-B industry commented that the FAR committee needed to address the unique/revised roles and responsibilities of design-build

The Committee stated that this was beyond the scope of the FAR implementation of the authorizing Statute. My HQUSACE lawyer, who was the DoD chairperson on the Part 36 committee told me that they had thought that the FAR coverage was adequate.

The truth of the matter was that none of the Government committee members knew any of the details of how design-build works or the unique differences in the  roles and responsibilities of the parties for DB vs. D-B-B.

Other USACE DB proponents and practitioners and I taught a week long DB Construction course for over 20 years. 

 

Edited by joel hoffman
Added details
Link to comment
Share on other sites

7 minutes ago, govt2310 said:

Ah ha!  Thank you, joel hoffman!

I edited my post while you were responding. 🤠

Link to comment
Share on other sites

@govt2310 There’s nothing wrong with this going back to your original question.  It all involves defining the scope of what you are soliciting for.  This approach is quite common as you questioned originally for software development and cloud computing.

Edited by formerfed
Link to comment
Share on other sites

Yes, indeed. I’m not responding to anything other than questions concerning Part 36, as pertains to Architect-Engineer design, construction contracting and design build construction.

It doesn’t translate directly across to other types of acquisition.  

Link to comment
Share on other sites

FAR 36.104(a) cites to 40 USC Chapter 11, as well as to 10 USC 3241 and 41 USC 3309.  41 USC 3309 appears to state that an agency can use a "traditional acquisition approach of design-bid-build," but if it chooses not to use that, then "the head of an executive agency shall use the two-phase selection procedures authorized in this section for entering into a contract for the design and construction of a public building, facility . . . ."  It sets forth criteria that the CO is supposed to use in determining whether two-phase selection procedures are appropriate.  It states that "The agency develops, either in-house or by contract, a scope of work statement."  The title of 41 USC 3309 is "Design-build selection procedures."  FAR 36.102 Definitions defines Design-bid-build to mean "two contracts and two contractors."  Then it defines Design-build as "combining design and construction in a single contract with one contractor." 

 

It appears to me that there is statutory authority to do "design-build" by one single contractor, for the sole purpose of making a public building/facility.  In order to apply this thinking to something else, like software design, development, and delivery, wouldn't an agency need Congress to pass a statute giving it this kind of authority?

Link to comment
Share on other sites

23 hours ago, govt2310 said:

It appears to me that there is statutory authority to do "design-build" by one single contractor, for the sole purpose of making a public building/facility.  In order to apply this thinking to something else, like software design, development, and delivery, wouldn't an agency need Congress to pass a statute giving it this kind of authority?

To my knowledge, no special authority is necessary for a contract for software design, development, and delivery.

Similar to design-build contracting, the government would prepare a solicitation, defining the scope of the IT effort, define the functional and performance requirements, and any other requirements of the software. Kinda like a new aircraft acquisition, right?

The reason that special authority was required for design-build was that the laws and all processes and regs, etc. were written around the traditional, Legacy approach of design-bid-build, either by contract or by in-house government designers.

Under the Legacy approach, to hire an A/E contractor to design a public facility requires following the Brooks Act, qualifications-based selection procedures. The designer of record works for the owner, not the constructor.

Design-build is a fundamentally different approach,  and combines design and construction in one, construction contract. The design-builder provides the designer of record and assumes that responsibility, authority and liability rather than the owner’s designer.

Every state has also had to pass legislation in order authorize the Design-Build process for public projects in their state.

The “Legacy Approach” actually evolved in the latter part of the 19th Century and in the 20th Century.

————————————————-
P.S., the design-build concept actually dates back thousands of years. It was  used in Egypt on the pyramids and in Europe since the Middle Ages.

The designer was the master builder or was associated with the master builder. The combined entity was legally responsible and liable for the safety and adequacy of the design.

They often faced imprisonment or execution for failures and loss of lives.

Even as of the 1980’s in Germany, the construction contractor assumed some legal responsibility/liability for the adequacy of the design for seven years (I think) after completion.

Under German trade laws, our Contractors would make changes to designs to correct what they deemed were design deficiencies. They were responsible to notify the owner as soon as they became aware of a problem but didn’t always do that.

Since the German re-unification in 1990 and the advent of the European Economic Community, I don’t know if those trade laws are still in effect in Germany.

As of last week, Turkish and Syrian officials were investigating holding contractors and/or designers liable for damage and loss of life in the recent, massive Earthquake. Under Shiria Law, those penalties can be severe…

Having worked in the Middle East in the 1980’s, I can attest to the widely prevalent unskilled, shoddy construction practices there. 

Edited by joel hoffman
General changes plus added the P.S. to provide some background for the importance and practices in design and construction industries.
Link to comment
Share on other sites

Thanks, joel hoffman!  Well, situation that prompted this question has to with research on "agile software development" and "agile acquisition."  In "agile," the agency doesn't define the requirements up front.  While it defines the scope by making a "Product Vision" (just 1-2 sentences), it doesn't do any more than that.  Even in a SOO situation, where the offeror writes up the PWS, all of the requirements are written only in terms of cost and schedule.  In "agile," the "definition of done" (the acceptance criteria/requirement) is defined during contract administration/performance, not in the solicitation.  At least in A&E and builiding design/construction, the Scope of Work defined by the Government actually gives you a concrete idea of what functions/constraints the final "product" must meet ("Contractor must construct and deliver a building at X location, it must accommodate at least 5,000 federal employees in office spaces, it must meet security requirements, it must have X parking spaces, etc"). 

Link to comment
Share on other sites

 In order to apply this thinking to something else, like software design, development, and delivery, wouldn't an agency need Congress to pass a statute giving it this kind of authority?"

@govt2310 Is not the authority to do so wrapped in FAR Part 12?  It would seem market research would show it is commercial practice for IT.  

Link to comment
Share on other sites

Agile is a commercial practice for IT.  I think I see what you mean, C Culham.  Agencies are treating agile as only a "commercial service," not a "commercial product."  But in the end, doesn't the agency want a working software, a commercial product, delivered to them?  I think this is being forgotten by many agencies.  In any case, thanks!

Link to comment
Share on other sites

“ In order to apply this thinking to something else, like software design, development, and delivery, wouldn't an agency need Congress to pass a statute giving it this kind of authority?“

Nope.  Agencies have been using this approach over decades with “waterfall” development.  While many will argue having a single contractor do it all as opposed to competition among vendors at various stages, it often is done with one contractor doing it all.  The acquisition is broken up in the various stages -requirements analysis, design, development, testing, implementation, training, deployment, etc.  A common argument is braking the work into pieces that can be competed among a limited pool of multiple awardees so you aren’t at the mercy of the company that started.  No special authority is needed other than sometimes having to justify your acquisition process with OMB to get funding.

Link to comment
Share on other sites

On 2/17/2023 at 4:53 PM, govt2310 said:

Well, situation that prompted this question has to with research on "agile software development" and "agile acquisition."  In "agile," the agency doesn't define the requirements up front.  While it defines the scope by making a "Product Vision" (just 1-2 sentences), it doesn't do any more than that. 

The Agile Contracts Primer referenced in this thread explores multiple contract pricing arrangements (and is a great read in any case). It seems like T&M may be the basic starting point for a Government agile contract, but it has some other ideas.

As for FAR authorities which would allow you to use a quasi design-build concept outside the construction arena I'd recommend considering a single-award IDIQ that describes the general scope of services to be acquired under the contract (FAR 16.504(a)(4)(iii)) as a starting point.

Link to comment
Share on other sites

On 2/16/2023 at 7:52 AM, govt2310 said:

What if an agency just did one contract where the SOW was to both figure out the agency's requirements, write it up, then provide the requirement.  This sounds ludicrous to me, but it is an actual question that has been raised. 

@govt2310I am confused by your opening post. Why do you think that hiring a contractor to design and specify something and then produce it is "ludicrous"? Did you see FAR 9.505-2(a)(3)?

Quote

In development work, it is normal to select firms that have done the most advanced work in the field. These firms can be expected to design and develop around their own prior knowledge. Development contractors can frequently start production earlier and more knowledgeably than firms that did not participate in the development, and this can affect the time and quality of production, both of which are important to the Government. In many instances the Government may have financed the development. Thus, while the development contractor has a competitive advantage, it is an unavoidable one that is not considered unfair; hence no prohibition should be imposed.

If I have grossly misunderstood you, please feel free to take a poke at me. But most of the acquisitions that I worked on as a CO and a staffer were for the design, specification, development, test, and production of various things. We've been doing those kinds of acquisitions for a very long time.

Link to comment
Share on other sites

Thanks for all the responses.  Both TechFARHub and the GAO Guide say there are already flexibilities in the FAR to do Agile (but then they both only name 1 example, which is modular contracting), but Nash & Cibinic wrote in an article that the FAR is not compatible with Congress' instruction to do "agile."  FAR 9505-2(a)(3) is for "development work."  I believe this is for a situation where the contractor "invented" something, developed a new method/technique, and why would the USG want to cut out the leader in the field here (or rather, the only one who can do it).  A contractor that does software development is different.  The contractor did not invent the software.  What is supposed to happen is, the USG defines its requirements ("the software must accomplish tasks 1, 2, 3, etc . . . . the software must have features 1, 2, 3, etc . . . ."), the the contractor "builds" the software.  The USG did the design, and then the contractor did the build.  Or, the USG can hire contractor #1 to do the design, then contractor #1 has a Biased Ground Rules OCI and cannot bid to become contractor #2, who builds the software.  With agile methodology, the same contractor does both "design" and "build."  Now, I realize there are many sources that say that it is the USG that retains all decision-making authority, approval authority, however, if the requirements are not defined up front, and if agile is about being "collaborative," it is highly likely that the federal employees will just "go with" whatever the contractor thinks the requirements should be.  In that scenario, the contractor is defining the requirements and also fulfilling them.  How can this be ok?  Additionally, if the requirements are not defined up front, how can the USG do the IGCE?  How can the offerors calculate the price to bid?  Everything is too wide open here.  And how can the agency hold the contractor to delivering software that meets all of the requirements?

Link to comment
Share on other sites

@gov2310  You’re depicting the situation where the government knows exactly what they want, what it will look like and how it will function, and how it will assess acceptability once it’s delivered.  It that instance, the government writes the detailed requirements or has a contractor do it for them.  But the government always doesn’t want to do it that way.  For example, the government may know what function it wants performed or problem solved.  They may know there are multiple ways to achieve the end result and may also know there are existing software tools already available to perform or a large portion of their work.  They may decide they don’t want to constrict approaches to any single solution so they write a high level statement of need rather than a detailed requirement statement or design.  Then they solicit competing approaches.  

With this scenario, offerors propose varying solutions.  Oferprs might be required to propose a series of steps in contract performance.  The steps might be  high level system design followed by a series of modules or releases.  The government must approve the design prior to the contractor proceeding with the initial development.  The contractor should also propose test plans are various points.  So it’s not a situation where the government just “goes with” what the contractor wants

In this manner the government can leverage individuals experience, expertise, resources and past performance in performing the type of work.  If the government wrote the detailed requirements, the government may likely see only one approach rather than picking among multiple choices.

This is done not just for software but for many other commodities the government buys as Vern Edwards pointed out.  

Link to comment
Share on other sites

@formerfed   It has sunk in.  I think I see what you are saying.  But I am still doubtful that the agency could make a reliable IGCE based only on a high level Product Vision and that the offerors could price their bids on the same.  But apparently, it is being done.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...