When COTS costs too much: Oracle, the US Air Force, and a $1 billion project failure

The United States Air Force recently announced that the $1 billion you were hoping would be spent on something useful (or not at all) has been lost forever to Oracle and Computer Sciences Corp. in the wake of a failed attempt to upgrade the Air Force’s back office.

While there are usually as many reasons for project failure as there are stars in the sky, I think I found a smoking gun buried in some of the language used by the Air Force to announce what was supposed to be a major improvement in modernizing the military and controlling costs that turned into yet another major setback. What emerges is a cautionary tale about how enterprise software is sold and marketed, particularly by a company like Oracle that has make the ready integration of disparate enterprise software products a “feature” honored more in the breach than not.

The original award had the lofty goal of upgrading over 400 legacy systems in order better support how the Air Force goes to war. Considering what is at stake – making sure the 750,000 men and women in the Air Force are well supported and provisioned – the goals of the project were laudable.

Also laudable was the focus on COTS – commercial, off-the-shelf software – which the U.S. government has been using more and more to lower overall IT costs and promote standards across the board. Which is why Oracle 11i was chosen to be the enterprise software anchor of the project.

So, how did the Air Force, Oracle, and CSC blow it? The how is a little tricky, but the what — $1 billion in tax dollars shot to hell – pretty much points to the usual combination of bad planning, scope creep, cost-overruns, and other classic mistakes that you’d think would be avoidable in the 21st century.

Indeed, it’s obvious that this was a typical big bang project gone sour… But with a twist.

The twist can be found in the following statement, made in September, 2006 when the award was made: “As a result of this selection, CSC will use processes within the Oracle 11i product suite to support all logistics functions including product lifecycle management, advanced planning and scheduling, repair and maintenance, and distribution and transportation. The integrated suite (my emphasis) will replace more than 400 legacy systems.”

Oracle 11i, , a.k.a E-Business Suite, in 2006 was itself integrated, but it had relatively limited capabilities in such key areas as PLM, planning and scheduling, and transportation, among others. Fair enough – apparently the Air Force procurement office decided that these functions were good enough for the government, and Oracle got the nod.

But the functionality inherent in EBS at the time wasn’t good enough for Oracle, and in fact much of the functionality that was essential to the Air Force project was already or about to be the subject of an acquisition spree by Oracle. Transportation management in the form of G-Log had been acquired in 2005, and Demantra’s planning software was acquired three months before the Air Force award was announced. PLM market leader Agile was acquired in 2007.

So, what was the “integrated suite” the Air Force thought it was buying in 2006, and what was the integrated suite that Oracle and CSC were trying to implement starting in 2008 (when the requirements blueprint was to have been finished)? It’s really hard to tell without an actual copy of the award document, but any decent requirements blueprint for a client like the Air Force would have stipulated the very best that the vendor could provide (that’s how these things are written – no one wants to implement mediocrity, right?). That in turn would have meant that by 2008 it was apparent that key functionality like PLM, planning, and transportation management should be based on Oracle’s newly acquired products, and not the core of Oracle 11i.

The problem is that the use of these or any other pieces of acquired software not part of E-Business Suite would have meant that the solution the Air Force was thinking was “integrated”, and consisted of “processes” that lived within Oracle 11i in reality consisted of a bunch of recently acquired products in desperate need of data and process integration. And while Oracle has tried to make application integration a virtue, and has thrown unsuccessful products like Application Integration Architecture at the problem it has created by buying dozens of incompatible products over the last 17 years, the fact remains that integrating Oracle’s applications are still complicated, costly, and a major bottleneck for its customers’ implementation plans.

Also note that it was during this timeframe that Oracle Fusion hove into view, and in fact at the time of the award Oracle was preparing to claim that it was “halfway to Fusion”, as well as promising an upgrade to Oracle 11i and a comprehensive Fusion integration strategy in the ensuing year. So you can probably add a new version of EBS, some Fusion apps and middleware to the blueprint as it was being readied to be part of a billion dollar barrel of pork.

So, while the evidence is purely circumstantial, the fact that the Air Force is basically writing off the project and dooming our flyers and support personnel to living in a legacy environment for the conceivable future points to a failure that very likely included the effects of “portfolio creep” on the part of the vendor as it added new products to the mix and further complicated an already complex “big bang”.

While any project failure of this magnitude has plenty of blame to go around – CSC and the Air Force need to be taken to the woodshed too – it’s clear that if the Air Force thought it was getting an integrated suite in 2006, it picked the wrong vendor. And at each milestone, 2008 when the blueprint was finished, and 2012 when the plug was pulled, Oracle’s portfolio only got more complicated, and the integration challenge more complex.

The moral of the story, to be fair, isn’t just about Oracle. It’s about every software vendor’s promise of integration – to its own products and those of its competitors and partners: Integration is hard, and is a common and costly point of failure. The tendency is to over-promise, and the temptation to do so in order to win a chunk of a billion dollar job is too tempting.

This moral extends to the customer as well – we all like to believe what we want to hear, and surely the Air Force, struggling to overcome a massive legacy quagmire, was happy to believe that it was buying an integrated suite with integrated processes that spanned logistics, PLM, planning, and the like when it was buying something else.

And while we’re at it let’s call out CSC, which has some duty – legal, moral, or probably both – to protect the clientele that funds the bulk of its revenue – U.S. taxpayers – from its own stupid mistakes. How this project got to be a total failure is clearly as much or more about CSC than it is about Oracle. Bad software and naïve customers alone can’t kill a project, you need bad consultants too.

And we’re all stuck paying the bill.




5 thoughts on “When COTS costs too much: Oracle, the US Air Force, and a $1 billion project failure

  1. Pingback: The Civic Cloud – Accela Gives Citizen/Government Engagement a Boost | EAConsult

  2. It is easy to blame the vendor, but in reality the fault goes back to the Air Force for not having the requirements defined and allowing scope creep to progress. Vendors and consultant will sell products and services but it is up the customer to accept or reject the viability of the proposed solution and thus the failure within most government programs. The Government does not understand its own program enough to define the requirements and hope that COTS and Consultants can magically do the job. So I would lay the blame more on the Government than the vendors.


Leave a Reply

Your email address will not be published. Required fields are marked *