When deciding which IT projects to analyze, I look for distinguishing characteristics such as large size, ability to demonstrate important lessons, and so on.
Oracle's legal battle with Montclair State University is interesting because many of the issues revolve around working relationships and arrangements between the parties. Oracle's aggressive defense, which does not provide much detail, is also noteworthy.
In 2009 Montclair State, New Jersey's second largest public university, contracted Oracle to replace an aging collection of PeopleSoft systems and implement a common enterprise platform. According to Montclair's complaint (PDF), these legacy systems include financial management, human resources, student administration, data warehousing, budgeting, and its enterprise portal.
[I]mprove its planning and budgeting capabilities, maintain better administrative controls over its spending, improve services to its students by making course work, financial aid, and other information more readily available and accessible, improve its human resource systems processing and reporting, improve reporting of information for financial and other decision making, and have a fully enabled web solution that provided for increased productivity for University employees and significant service improvements to students.
The school purchased about $20 million of software, support, and implementation services from Oracle. The lawsuit alleges:
Oracle failed to deliver key implementation services, caused critical deadlines to be missed, refused to make available computer resources that it had promised, failed to deliver properly tested software, and, overall, failed to manage properly the project.
The legal filing claims these Oracle deficiencies significantly delayed the project, increasing the University's costs by "more than $10,000,000."
Project Management. Montclair's legal claim reads like a handbook for project management failure. Some key quotes from the lawsuit show the tone of Montclair's allegations:
Oracle was unable to create a workable document repository through iProjects after numerous failed attempts.
The lack of an Integrated Project Management Plan led to confusion amongst Oracle and University staff, preventing either group from addressing resource and task conflicts and from identifying missing integration tasks.
[I]ssues and risks were not properly documented, tracked, and addressed.
Oracle's unilateral change to [risk] color coding in this report was an intentional act to
downplay the seriousness of the risk and mislead the other members of the BTl Project team.
Oracle failed to provide accurate and timely project status reports to manage the application tracks, creating constant uncertainty for the University regarding where they were in the BTl Project, what tasks were to be done next, and who was responsible for what tasks.
Oracle refused to integrate University tasks and resources into its report to help manage the BTI Project.
The status reports and project plans Oracle did create had no standards in place which made cross project tracking difficult and the results reported inconsistent. Resource loading was inconsistently shown by Oracle and, because University resources were not included or generalized by using phrases like "HCM staff," there was no way to have an accurate picture of the entire project status, resources, and costs.
Oracle treated the project planning report as a nuisance rather than the critically important tool it is for effective project management.
[C]ertain Oracle employees finally admitted that they were not familiar with the Oracle Methodologies and were implementing. the BTl Project the way they thought they should.
Oracle refused to provide the necessary project information upon which any assessment could be made but constantly assured the University that the project was on track for being completed within the time periods stated in the contract.
Labor quality. After blaming Oracle for numerous project management deficiencies, Montclair then claims that Oracle supplied inexperienced and poor-quality labor:
Oracle continually rotated staff into and out of the BTl Project creating confusion on task and project duration and requiring work to be redone as new Oracle staff wanted to do things their way.
Most of the off-shore staff assigned to the project by Oracle worked part-time and often confused the BTl Project with other projects they were working on for other clients.
Oracle undertook its own internal audit of the BTl Project. Although the University was entitled to a copy of this audit report under the terms of the FPE and demanded a copy of the audit, Oracle refused to turn over a copy.
Design and testing. The lawsuit also accuses Oracle of performing incomplete testing:
Given the lateness in testing, Oracle recommended that the University conduct the various tests concurrently, a practice that is not supported by Oracle's own methodologies or any generally-recognized industry standards. Although the University rejected Oracle's offer as contrary to industry practices and contrary to Oracle's contractual obligations, the University did perform a test of the software, and the systems integration failed. Despite the failure of the test, Oracle recommended that the University go live, even though security was not ready to be tested and even though there existed major defects in the software applications that were not being corrected by Oracle in a timely manner. Specifically, Oracle failed to prepare a security design strategy.
Montclair's suit describes how negotiations between the sides broke down completely and Oracle eventually stopped work. Montclair finally decided to abandon the partially completed project and seek another system integrator.
In response to most of Montclair's allegations, Oracle's filing (PDF) repeats the mantra, "Defendant denies each and every allegation."
However, in a striking attack on Montclair's leadership, Oracle's response filing states:
Counterclaim Defendant MSU owes Oracle over $5 million for intellectual property and services MSU has already received and yet refuses to pay for, in spite of its clear contractual obligation to do so. Instead of paying Oracle for the work it performed, MSU embarked on a misguided ruse which, unfortunately, is costing the taxpayers of New Jersey millions of dollars and threatens to waste millions more.
Oracle then stakes its turf as a cooperative partner, blaming Montclair's management for the problems:
When issues arose during the course of the project, it became clear that MSU's leadership did not adequately understand the technology and the steps necessary to complete the project. Instead of cooperating with Oracle and resolving issues through discussions and collaboration, MSU’s project leadership, motivated by their own agenda and fearful of being blamed for delays, escalated manageable differences into major disputes. At critical points in the project, MSU’s leadership refused to work with Oracle and rebuffed multiple attempts to resolve the issues and complete the project.
MSU’s inability to manage the project created a vacuum for outside consultants to exercise perverse influence over its direction. Indeed, at the point when MSU decided to terminate the contract with Oracle and refused to pay amounts owed, a lawyer from Illinois was, in large part, running the project for MSU, and continued to profit from promoting a dispute with Oracle at taxpayer expense.
Most telling is MSU's striking admission in its Complaint that, instead of paying Oracle what it owes for the use of the intellectual property which Oracle has already provided, its out-of-state consultants have decided to start the project anew and pay a completely separate vendor yet again for the same work done by Oracle.
Its entire complaint and scorched earth litigation strategy is a pretext designed to blame Oracle for its own leadership failures.
Although Montclair describes specific instances where Oracle made project management errors, the vendor's explanation is equally plausible. We've all seen projects where the customer lacked the skills, experience, or focus required to manage and execute their own project responsibilities.
Most of the accusations reflect alleged incompetence, poor cooperation, or agendas that redirected attention away from project success; the lawsuit does not suggest the Oracle software itself is an issue. Instead, breakdowns of communication, inexperienced resources, and other human failings seem to be fundamental issues.
What really happened? Having been involved in many technology-related projects, both sides of this story seem plausible.
However, Montclair's filing offers tremendous detail that Oracle attempts to sweep away with broad generalizations. Given Oracle's size and legal resources, I believe the lack of detail reflects weakness in Oracle's position.
The legal filings leave unanswered questions. For example, why didn't Oracle include Montclair resources in schedules, as the suit alleges? Perhaps Oracle did not believe the Montclair folks had sufficient skill to contribute properly, or maybe Oracle did make serious planing mistakes as Montclair alleges. Without uncovering facts around these basic details, it is virtually impossible to distinguish "truth" from legal posturing.
The IT Devil's Triangle principle tells us that the software vendor, system integrator, and enterprise customer all contribute to most IT implementation failures; in this case, Montclair was the customer and Oracle played the role of both software vendor and integrator. Most likely, both Montclair and Oracle contributed to this failure.
Advice for CIOs and enterprise buyers. Consider three points to help your organization avoid situations like the one described in this post:
Be realistic about your own organization's capabilities. Take a cold, hard look in the organizational mirror and see whether your team has the skills and experience to handle your upcoming project. If not then simplify the project, find appropriate resources, or delay until you have the capacity and capability to execute successfully.
Evaluate external system integrators more carefully. Look past the marketing and ask specific questions about project staffing, scheduling, and the skills of those who will be assigned to your project. Don't believe all the marketing that consultants and system integrators throw at you.
Own your own implementation. Regardless of your system integrator or software vendor, you are ultimately responsible for success and failure on your projects! The best consultants may well save you in the end -- but don't count on it.
Achieving success requires attention to details that many organizations downplay or ignore. These three suggestions can help you create better projects, at lower cost, with higher delivered value than would otherwise be possible.
Both Montclair and Oracle declined to offer substantive comment for this post. Image from iStockphoto.