View from RJO

By Robert S. Metzger and Mark J. Linderman[i]

Reproduced with permission from Federal Contracts Report 102 FCR 376 (Sept. 23, 2014). Copyright 2014 by The Bureau of National Affairs, Inc. (800-372-1033) <http://www.bna.com>

Enterprise IT implementation projects fail too often in public implementation with costly results to public sponsors as well as to systems integrators and software providers.  Enormous amounts can be expended without achieving intended purposes and costly litigation can follow.  Recent examples include:

  • On July 22, 2014, a Senate investigations report accused the Air Force of wasting $1.1 billion in a failed effort, between 2004 and 2012, to implement the Expeditionary Combat Support System (ECCS), intended to replace unconnected logistics systems with a fully integrated system.[1]
  • On August 22, 2014, the State of Oregon brought suit against Oracle over its failure to provide a Health Information Exchange (HIX) and alleged breach of contract, fraud, racketeering and false claims.[2]  Oregon claims that it spent $240 million “for a health insurance exchange that never worked as promised” and for modernization of the state’s social services technology that “never got off the ground.”[3]
  • On November 3, 2013, the State of California terminated its contract with SAP for a new, integrated state payroll system, intended for 240,000 employees, and subsequently brought suit against SAP seeking more than $50 million in damages.[4]
  • On October 15, 2009, the State of Indiana terminated its $1.3 billion welfare modernization contract with IBM for cause and sued IBM seeking damages of more than $170 million.  In 2012, a trial court ruled for IBM, finding that default was not justified where there was “substantial performance.”[5]  An appellate court reversed this finding on February 13, 2014, concluding that IBM failed to fulfill the essential purposes of the contract.  The Supreme Court of Indiana has agreed to decide the matter.[6]

Failed IT systems mean that important government purposes go unmet and large amounts of public funds are wasted.  Contractors may incur losses amounting to tens or even hundreds of millions of dollars.  When large claims are filed or a customer terminates an IT project for default, litigation may result that costs further millions.[7]  Such controversies are never satisfactory either for provider or customer.

There are no “uniform best practices” to avert controversy and guarantee project success.  However, certain measures of risk identification and risk management can help both customers and contractors.  We offer 10 recommendations that reflect our experience with federal and state public sector IT projects.  In this article, we focus on the acquisition phase which precedes contract award.

1)      Legacy systems must be understood

IT implementation projects often involve the deployment of enterprise resource planning (“ERP”) systems.[8]  These involve systems integration built upon core software.  The software typically is originated for commercial customers and evolves through successive iteration as experience is gained with each installation.  But the “out of the box” solution rarely fits the particular needs of a government customer.  There will be differences between the customer’s present (“as is”) system and the prospective (“to be”) system that the customer desires.  Customization of the ERP solution is needed to address this gap.  This requires careful attention to understand the legacy environment and to define objectives of the new system satisfactory for every stakeholder.

2)      The customer must have a clear vision of the re-engineered business process

Governments pursue modern ERP systems to eliminate separate, “stovepipe” legacy systems and to replace them with integrated systems that leverage common data sets and automate many discrete governmental functions.  In theory, an ERP system will reduce the government’s operating costs, make the work of the public workforce more fulfilling and productive, and improve the ability of government to deliver services and otherwise respond to the public.  At the same time, not all stakeholders in existing systems will readily agree to new systems that require changes to old ways.  Projects can fail if owners attempt to bend back new systems to mimic legacy practices.

3)      Realistic expectations are essential to project success

When a public sector customer defines its ERP objectives, these become the “requirements” for the “to be” system.  The public sector customer must have a clear vision of what it wants in the re-engineered business process.  It can be very difficult to objectively document requirements because the customer, at the beginning of a project, may not know whether they want to employ out-of-the-box functionality or whether customization is required.[9]  If the customer has unreasonable expectations, this will increase project failure risk because there may be no achievable “target” for the contractor to hit.  Absence of clear and achievable objectives is a recipe for extended periods of contract performance and for delay or changes claims – if not frustration of fundamental purpose.

4)      The customer must have support of its stakeholders

IT projects that seek “transformation” from legacy systems involve a high degree of interdependency.  The public customer knows best its legacy capabilities as well as business needs.  It controls existing data that must be converted and transformed to test and then operate the future system.  RFPs should recognize customer-side responsibilities and contracts must clearly state that the contractor’s obligations depend upon the customer’s timely performance of its obligations.  Often, one agency will act as lead or sponsor for a system to benefit many other agencies or departments.  The sponsor must have the ability to assure that stakeholders timely perform their assigned functions as well as authority to accept a system even if risk-averse shareholders are reluctant to commit.

5)      Confirm sufficient resources are present for customer-responsible actions

Complex IT projects truly are joint undertakings.  Functions such as data conversion and integration testing depend upon the time, commitment and expertise of customer-side personnel for whom this work, though critical, may be outside their regular duties.  Project personnel also are responsible for review and approval of incremental performance – and this work typically is on the “critical path” for project success.  If the customer does not commit sufficient trained personnel to hold up its end of the project, the result is costly program extension and disruption to the planned work.

6)      Be prepared to walk away if risks are transferred and not equitably shared

Careful review of an RFP or “model contract” will reveal when a government customer seeks to transfer excess performance, cost or schedule risk to the contractor.  Because project success depends upon mutual commitment and collaborative accomplishment, RFPs that shift too much risk to the contractor present high risk of failure both operationally and financially.  Such risks can become too great to justify a bid even if competitive circumstances permit pricing that takes some risk into account.

7)      Risk recognition must temper business capture objectives

Business capture organizations within contractors naturally see large IT projects as tempting opportunities.  This can produce pressure to take excess risks to secure the “win.” This is a mistake, especially for demanding “transformational” projects.  After the contract is signed, most of the leverage resides with the public purchaser.  Rarely can or will a government contractor abandon performance.  Recent history is filled with examples of IT projects gone bad where contractors spend tens of millions of dollars in delayed performance with little likelihood of full recovery.  A common problem is that of “concurrent delay,” because government customers are not likely to pay on claims unless the contractor can show that its claim is limited to delays and costs caused by customer-responsible actions.

8)      Evaluate the reasonableness of terms and conditions and their negotiability

It can be naïve and even reckless to assume that during performance the customer will act in good faith to resolve performance problems or by agreeing to contract changes.  Those responsible for the conduct of an acquisition are rarely the same people who preside over contract performance.  This places paramount importance upon the drafting details and on inclusion of commercially reasonable terms and conditions in the contractual documentation.  In state procurements, the public buyer may not be able or willing to negotiate any changes in material terms.  Over the years, failed IT projects sometimes produce claims against contractors seeking hundreds of millions of dollars.  Limitation of liability provisions and limitations on recoverable damages are essential to contain the potential exposure.

9)      It must be clear what constitutes “the Contract”

An IT implementation contract can run to thousands of pages, e.g., where the RFP and contractor’s proposal are among the contract documents.  Contractors must assure that critical obligations are stated clearly and should strive to avoid material inconsistencies at different levels of contractual documentation.  Special attention must be paid to priorities among objectives and (of course) the Order of Precedence clause.  Another key issue is how the contract treats assumptions that often accompany a contractor’s IT proposal.  These may address, for example, responsibilities of the customer, where requirements will be met “out of the box,” where customization is proposed, and how the contractor interprets key requirements.  Disputes often arise when the public customer refuses to agree that the contractor’s performance is governed by such assumptions.  Every effort should be made to be sure that those assumptions are recognized as part of the operative contract documents.

10)  The contract must establish how the adequacy of performance is determined

In the Indiana vs. IBM litigation, the trial court found that IBM was not in breach of the contract because of “substantial performance” and because the State realized many project benefits.  On appeal, however, IBM was found in “material breach” because the appellate court concluded that the fundamental purposes of the project had not been achieved to the State’s satisfaction.  The Supreme Court of Indiana will decide this issue.  It has potentially profound significance.  IT implementation contracts typically include time-sequenced iterative obligations, involving dozens or even hundreds of deliverables.  The customer’s receipt and review of in-process deliverables represent objective anddocumented events. Similarly, achievement of “Milestones” over the course of contract performance signifies progress in meeting contract objectives.  But disputes such as Indiana vs. IBM reveal that the public customer may insist that its subjective satisfaction at some overarching policy level is the legal measure of adequate performance.  At the very least, contractors must be warned to take all feasible measures to assure that any dispute over performance will recognize not just high level requirements but the documented satisfaction of contractual waypoints.

[1] “The Air Force’s Expeditionary Combat Support Systems (ECCS): A Cautionary Tale on the Need for Business Process Reengineering and Complying with Acquisition Best Practices,” Staff Report, Permanent Subcommittee on Investigations, U.S. Senate (July 7, 2014).

[2] Ellen Rosenblum vs. Oracle America, Inc., Case No. 14C 20043, Circ. Ct. of Oregon, County of Marion. Complaint available athttp://www.doj.state.or.us/releases/pdf/FINAL_Complaint_8_22_14.pdf

[3] Id., at 6.

[4] State Controller’s Office vs. SAP Public Services, Case No. 00154918, Super. Ct. of California, County of Sacramento.

[5] State of Indiana vs. International Business Machines, Case No. 49D10-1005-PL-021451, Super. Ct. of Marion County.  Findings of Fact, Conclusions of Law and Judgment for IBM, available athttp://www.in.gov/legislative/senate_democrats/files/blog/FinalOrdersignedJuly182012.pdf.

[6] State of Indiana vs. International Business Machines, No. 49A02-1211-PL-875, Ct. of Appeals of Indiana.  Opinion, available athttp://www.in.gov/judiciary/opinions/pdf/02131403nhv.pdf .

[7] The trial in Indiana vs. IBM lasted six weeks and the court heard 92 witnesses.  Before trial, the court considered 12 motions for summary judgment. Approximately 27,800 exhibits were submitted, totaling about 1 million pages of documents.

[8] ERP is defined by Gartner’s IT Glossary, at http://www.gartner.com/it-glossary/enterprise-resource-planning-erp/, as “the ability to deliver an integrated suite of business applications. ERP tools share a common process and data model, covering broad and deep operational end-to-end processes, such as those found in finance, HR, distribution, manufacturing, service and the supply chain.”

[9] An IT project typically includes a “blueprint” phase to further or fully define the requirements that are to be achieved during design and development.  The problem is even more acute in “agile” development projects where requirements tend to be stated at a very high level with planned, short-term “sprints” during performance to achieve narrowed understandings of desired functionality at completion.

[i] Robert S. Metzger is the head of the Washington, D.C. office of Rogers Joseph O’Donnell, P.C., and Mark J. Linderman is a Shareholder in the firm’s office in San Francisco, CA.  Rogers Joseph has focused upon public contracts matters for more than 30 years.