Home / Two Lessons Learned from the State of Oregon vs. Oracle Lawsuit

Two Lessons Learned from the State of Oregon vs. Oracle Lawsuit

Oregon recently filed a lawsuit against Oracle over the failed deployment of the “Cover Oregon” healthcare exchange website. The State spent over $240m on the development and deployment of this portal, and the lawsuit seeks to reclaim over $200m in damages. Oregon claims it was falsely promised a “95% out-of-the-box” solution for its portal, and that Oracle’s actions amount to a “a pattern of racketeering activity.”

Oracle counters these allegations by counter-suing the State of Oregon over unpaid bills, noting “The government bureaucracies and Cover Oregon worked poorly together. They did not agree on work priorities, they competed with one another for resources and in decision-making, and they failed to provide authoritative direction to all of the contractors working on the project.”

So I just finished reading the entire 150+ page lawsuit, and this failed project can be tied back to a completely broken IT procurement process that ensures companies and governments end up picking the wrong technology. Here are two important lessons I’d like to share after reading the lawsuit:

1) Stop Buying Technology Based on RFPs and Product Demos

The gist of this lawsuit is that Oracle lied to the State of Oregon about the amount of custom development it would take to deliver the proposed Oracle solution. Oracle positioned itself as providing an “out-of-the-box” solution that required minimal configuration. The phrase “out-of-the-box” is used over 40 times in the lawsuit. Here’s one quote:

Oracle sold the State of Oregon a lie. According to a former Oracle employee,
‘There was no solution.’ The cobbled together collection of products that Oracle called the ‘Oracle Solution’ was not flexible, was not integrated, and most importantly, did not work ‘out-of-the-box.’ Oracle’s 2010 and 2011 claims to DHS and OHA were patently and categorically false.

Most of the evidence provided by the State comes from Oracle’s RFP response with a list of over 450 requirements. In the RFP response, Oracle proposed an “Oracle Solution” comprising of Siebel, Webcenter, and other Oracle products. Oracle was asked to score each requirement, noting if a particular requirement was “out-of-the-box” or required “customization”. It shouldn’t surprise anyone that Oracle scored over 95% of the requirements as being “out-of-the-box”. After reading the response, Oregon shortlisted Oracle, and asked them to come in and present a demonstration, which reinforced Oracle’s RFP response that their “Solution” was pre-integrated, and easy to deploy.

I’ve spent most of my career selling enterprise software, and I’ve been in hundreds of technology selections comprised of the same “RFP response + product demo” evaluation process.

And let me tell you, this is an absolutely terrible way to select technology.

  • Does it really surprise anyone that Oracle might have overstated its capabilities in the RFP selection process?
  • Does it really surprise anyone that Oracle could craft a magical solution demonstration where all of its products appear to work together seamlessly - at least for the few hours of the demonstration?

It shouldn’t, because that game has been played by vendors for decades, and its time for companies and governments to stop taking shortcuts, and instead take time to properly evaluate complex, enterprise technology. The State of Oregon should have required Oracle to demonstrate their “out-of-the-box” solution against a limited number of use cases, closely watching the amount of custom development required to implement it. This would have quickly demonstrated the validity of Oracle’s claims. Here are more of my thoughts on the importance of the “Proof of Concept”.

2) Read the US Digital Service Playbook, and Default to Open

The Obama administration unveiled a new program called the U.S. Digital Service. The Digital Service is a team of America's best and brightest digital strategists. This initiative was created based on learnings from the successful partnership between public and private sector in the turnaround of the Healthcare.gov project.

One of the first outputs from this team, is a new digital services playbook, outlining 13 key plays based on best practices learned across public and private sector digital transformation projects, which hope to guide Federal agencies through the successful implementation of digital projects.

One of the key recommendations made is to Default to Open:

When we collaborate in the open and publish our data publicly we can improve Government together. By building services more openly and publishing open data, we simplify the public’s access to government services and information, allow the public to easily provide fixes and contributions, and enable reuse by entrepreneurs, nonprofits, other agencies, and the public.

One of the main lessons from Healthcare.gov project was the need for openness and transparency in the development process. Healthcare.gov was delivered as a traditional "waterfall" software development project, with little transparency into the project timelines, requirements, etc. Modern application development practices minimize risk and unwanted surprises through processes like code reviews, unit tests, standup meetings, and the continuous delivery of code.

In the case of the State of Oregon, “defaulting to open” - e.g. open source software and open agile processes - would have provided a level of freedom and transparency that would have prevented this $240m failure from happening. With open source, the State of Oregon would have the freedom to control its own destiny - something the State of Georgia learned when it made the decision to move away from its legacy proprietary platform to Acquia and Drupal.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.