In contracting language, close doesn't count

Theology, like the law of government contracts, often makes big distinctions
between similar objects.


The late Chief Justice Warren Burger was fond of the following story: A woman asked an
Anglican bishop, “Your Eminence, pray tell me about the differences between seraphim
and cherubim.” The bishop replied, “There were indeed once differences between
the two, but they have composed their differences, and now all is serene.”


Not so with government contracts.


Whether a software development contract is called a contract for services or a contract
for a product can become a contentious issue. Despite the seemingly artificial nature of
the difference, determining whether the government has ordered a service or product may
have significant repercussions at the inspection and acceptance stage of the project.


The government has broad discretion to issue a task order or delivery order under a
contract as long as the task order is within the scope of work, terms and dollar value of
the contract. Therefore, a task order for services to develop software may easily fall
within the scope of a service contract, but a delivery order for developed software may
not.


If a government agency has an urgent requirement for a software solution, its staff
will research how to satisfy this requirement in the speediest way. They’ll look for
companies that can satisfy the requirements and have existing contract vehicles the agency
can use. If the agency has identified such a company, its next step is to award a task
order.


Going through the full-and-open competition required by the Federal Acquisition
Regulation is not what an agency typically wants to do, even if the software being
developed would qualify as a major system acquisition under FAR Part 34. An agency may
expedite the process by using, for example, one of a multiple-award set of contracts whose
scope includes the type of services, such as labor, that will be needed to develop the
required software.


Suppose the agency identifies a company capable of the required software development
but not part of an available acquisition vehicle. The agency must find a contract that
covers the scope of the services required and will permit including a new subcontractor.
Once the agency has found the vehicle, it can point the software vendor in the direction
of the prime contractor.


The terms and conditions of the software development task order awarded by the agency
are those of the prime contract—terms and conditions that were general enough to
cover a variety of products and services or both. As such, the prime contract probably
contains the FAR inspection clauses that cover supplies, services, time and material, and
cost reimbursement requirements, if any.


The question at the drafting and completion of the task order—and at the software
delivery—is: What inspection clause will be used? Software, whether custom or
off-the-shelf, contains defects. A typical government buyer will want an inspection clause
that applies to software services. The federal service-related clause allows vendors to
remedy the defects within reasonable time.


But the agency may prefer to have an easy way to terminate the task order for default
and would want the inspection clause for supplies to provide an off-ramp. Here’s the
rub: When an agency uses a contract to acquire services for software development, the
agency is bound by the FAR clauses that apply to service contracts. The clauses permit
reperformance and are not as easy to terminate.


Agencies should not be allowed the latitude to choose, at the end of the performance
period, clauses that do not comply with what has been acquired under the task order.


The clause problem is aggravated when a subcontractor is performing the lion’s
share of a software development. Where a prime-sub relationship exists, generally only the
prime contractor has the right to file a claim against the government for an improper
termination for default unless the subcontract specifically allows the subcontractor to
step into the shoes of the prime.


So be careful how you define things at the beginning, and watch out for clauses
mismatched to the initial choice of definition.  


Stephen M. Ryan is a partner in the Washington law firm of Brand, Lowell &
Ryan. He has long experience in federal information technology issues. E-mail him at smr@blrlaw.com.



inside gcn

  • Phishing

    Phishing is still a big problem, but users can help shrink it

Reader 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

More from 1105 Public Sector Media Group