I though Oracle database software was a super powerful and sophisticated package that ran the logistics of huge billion dollar companies around the world, and now we see that it was not capable of meeting the demands of the USAF logistics per this article.
How USAF Blew $1B on Logistics System
If Oracle was not powerful enough to do this what is?
Lots of things at work in this case:
1 - The failure of the project is most likely (based on my experience with ERP systems and projects), due to the sheer size of the project. It is very difficult to manage something so big, how many project managers have the experience to deal with something of this size? (answer, most likely 1 or zero).
2 - The actual ability of the software is rarely the real problem in a case like this. Just like when Nike’s I2 system screwed up or Hershey’s SAP implementation had problems, these are usually people and project issues, not the software itself. I’ve seen it first hand where projects are not handled properly but the company ends up blaming the software.
The software is just a tool and if it can’t support specific types of transactions, then you find some solution (build, buy, manual work around), but all of this happens before you go live.
3 - The previous two reasons do not mean Oracle (or SAP or anyone else) can do everything required for the USAF out of the box, and it’s possible, due to the USAF size that no software exists that would handle all of their special requirements. But that just becomes part of the project and you build to fill the gaps.
Frequently these projects are nuked by a lack of understanding by top business sponsors, they don’t listen to the ERP project experts and possibly don’t support the effort within the organization to the level that is truly required to get such a massive thing completed successfully. In addition, personalities make a difference and someone within the organization with power and influence can send things sideways.
If I were the USAF, knowing that enormous projects rarely succeed, I would have broken it down into smaller projects and paid for success by expending additional dollars with having temporary inefficiencies that would eventually go away. For example, group X or dept Y, implement your piece and if that means we build interfaces to older systems that will disappear in 2 years, that’s ok, because spending that money on the interfaces is a small price to pay to reduce the scope at any point in time and ensure success.
A significant number of software projects, of all sizes, fail. The primary reason for a software project failing, in my experience, is that the requirements are not clearly understood before the budget is finalized. As we see in this case.
As for blaming the software, I am with RaftPeople on this one.
To me, article had quite a definitive reason:
Requirements is where it’s at (my specialty wink-wink). You can build the most sophisticated system ever but if it does not serve the purpose expected from the user you can wrap it in $100 bill and throw it in garbage.
On the other hand, there’s a tendency to rely to much on “out-of-the-box” solutions and in a highly complex, dynamic environment with real-time requirements that are expected Oracle technically is not up to the job.
Based on the fact that SAP complained about Oracle’s proposal, I’m going to guess that the problems/defects weren’t with the Oracle Database itself, but with some flavor of Oracle ERP - either EBS or JD Edwards.
Global ERP implementations, especially those that are supposed to replace 240 legacy systems without completely changing the operational procedures of the organization, can be a total bitch, and will miss time and budget deadlines.
I personally know of an organization that’s slipped by ten years and close to a billion bucks on it’s SAP implementation, and they have less than half the “revenue” and 10% of the personnel of the USAF.
It’s also worth mentioning that, while there are a lot of great people at CSC, many (most?) of them are total chuckleheads. My former employer outsourced DBA maintenance and development to those guys (firing most of our in-house DBAs in the process) and it was a complete clusterfuck.
I happen to be an Oracle DBA working as a contractor for the USAF. Not with CSC though. The whole idea of using a COTS product to run something in the military has been tried, and failed, many times before.
The military does some very strange stuff that no normal company would do. Much of it comes down from Congress with their bizarre rules and regulations. The program that I’m with is a custom made application, and we still have trouble with strange rules plus interfacing with antiquated systems. One of the first things I tell new team members is that it doesn’t have to make sense. It’s the military or government.
CSC is a fine company. Oracle is a great piece of software that runs successfully for many, many companies. Military requirements are rather unique and hard to define. The military bureaucracy is very entrenched and difficult to deal with. Approvals that I’ve see done with civilian companies in days can take months with the military.
That’s a common perception with E&Y, pwc, Accenture and such. They DO have a core of super-skilled senior guys who come in and initiate everything and then leave it to interns to finish b/c they can’t be everywhere at all times. As soon as things start going off the script it’s bye-bye for the whole thing.
Add me to a vote for failed requirements analysis and scope creep. I’ve worked for some of the larger DoD agencies and they are not actually all that huge or complex compared to some commercial airline system and the Walmart global infrastructure.
I’ve worked for DoD contractors who held themselves up as “experts” while at the same time promising the client that they could run a network server (including remote access) inside a windows based workstation window while the clerk continued to use it for daily administrative functions.
Considering that I can run Oracle on an IBM LPAR, there is no way that Oracle could not handle their requirements. NOW, there is a distinct possibility that Oracle was not the best choice for what the system was expected to do… but that isn’t a failure of the server, that is (again) a failure of requirements analysis. The blame for that falls on the DoD project manager (who was snowed and didn’t know it) and the CSC project manager who didn’t have a clue what he was doing.
The current ERP implementation I’m in went live in September, it was only two factories, it was supposed to have everything already parametrized by the time I joined and I’m still there.
It happens to have had the worse blueprinting (requirements information) I’ve ever seen. The factory manager was the team’s only contact through blueprinting and testing, as well as our source for data to load. Some examples:
Is the ERP we’re using perfect? Hell no. Are we the bestest consultants ever? Hell no. Is the mother company a Kraken with absurd control issues? Oh Hell yes.
But every other rollout has gone better, over two hundred other rollouts in the Kraken are doing better, because the fucking contacts knew their fucking needs! This one didn’t.
If the consultants weren’t able to get clear requirements, if they weren’t able to recognize nonsensical requirements (which I’ve encountered many times), or if their contacts weren’t able to provide clear answers to adequate questions, that’s not a problem with the software. It’s a problem with the implementation process.
I like blueprinting. Apparently that makes me an outlier: most consultants prefer “cookie cutter rollouts” where everything has already been defined. If a project sounds like it would need “constant re-blueprinting”, it’s one for the military!
I am not surprised at all. The military and US government is rife with empire building bureaucrats, who want NO interference in their power. These people will happily sabotage anything that appears to be a threat to them. Take procurement- the rules are that they have to obtain “competitive” bids ever so often-even if there are only two suppliers. The suppliers know this, so they go along with the charade-which is why the AF winds up paying $1000 for a $5 toilet seat.
There are other examples-the state of Massachusetts has spent over $80 million to computerize courtroom records and forms-guess what-they still use carbon copy, manual forms (like in 1950). Why? the clerks (who are political hacks) don’t want efficiency-this would threaten their power to hand out jobs to friends and political allies. Nobody in the government ever gets fired for incompetent performance-so the AF will just request more money for a new ERP project.
Correct. It was EBS. The database wasn’t the issue.
That is a perception that is well deserved. I’ve spent most of my career working for or with large consulting firms (including as a client of CSC). They don’t typically have “interns” working on those projects. But they do have an army of 20-somethings either right out of or a few years out of college who are typically better at being presentable businesspeople than they are at being highly skilled technologists.
Not that they are dumb or incompetent per se. It’s just that for a typical project, a large number of their staff will have less than 5 years experience with the firm (typically much less than 2 years), may actually be in their first professional job, and probably only marginally familiar with the particular technology or industry. You will have a number of partners and management types all looking to justify their existence by finding ways to sell follow-on work and bill against your project.
And when your project ends, the consulting project team will likely scatter to the four winds, either within the firm or outside it.
I almost took a job with Philip M Kraken Management Consulting!