In 2011, Montclair State University (MSU) entered a bitter battle with enterprise software giant Oracle. The issue at hand? A $20 million deployment of Oracle’s PeopleSoft ERP software, which failed to deliver on university expectations. 

This failure still holds valuable lessons for today’s projects. While the lessons learned apply to all industries, they are especially relevant to higher education IT implementations.

Today, we’re taking a closer look at this Oracle ERP failure and sharing what companies in this space can take away from it. 

An Oracle ERP Failure Explained

Montclair State University is a leading player in the realm of New Jersey higher education. In 2009, it began an ERP system implementation meant to empower student and facility self-services across campus.

The new system would replace its 25-year-old administrative system. The university wanted its services, which spanned academic and business processes, to tie into a central university portal.

Oracle’s PeopleSoft ERP software fit the bill. The university entered into a contract that included $4.3 million in software and technical support, along with $15.75 million in fixed-fee implementation services. 

In April 2011, the university filed its first lawsuit against the software company, citing accusations that included:

  • Breach of contract
  • Gross negligence
  • Willful misconduct
  • Fraud

In the suit, the university stated that it was set to incur $20 million in expenses that went beyond the project’s original scope. MSU representatives explained that they had asked repeatedly for progress updates on the project, but the only insight they gleaned was through a series of meetings and disputes that occurred in the summer of 2010. 

At those meetings, Oracle representatives claimed they required an additional $8 million beyond the contracted agreement. The university pushed back, and the Oracle consulting team officially walked out in October of 2010. 

A Breakdown in Communication

According to case documents, Oracle tried to employ two different project management systems, but neither managed to facilitate team communication. Meanwhile, the software team failed to log or address university complaints about the project. 

In May 2011, Oracle countersued the university for $5.3 million, explaining that university officials did not adequately understand the technology or the steps required to complete the project. These issues could be attributed to the lack of communication.

In March 2013, both parties settled out of court for an undisclosed amount. 

A Failed Payroll System Implementation

Panorama’s Expert Witness team was retained to provide a forensic analysis and written report to the court regarding the failed implementation of a major software developer’s ERP/payroll system.

4 ERP Challenges for Higher Education Organizations

When higher education organizations consider new enterprise software, they should understand the unique implementation challenges they may encounter. 

As the MSU/Oracle failure indicates, accurate timelines and budgets are key in these initiatives. While some degree of scope creep may be normal, it’s important to keep a close eye on project progress to identify and limit these overruns before they get out of hand. 

Let’s look at some of the challenges that marked this ERP failure, and how you can apply them in your own ERP implementation. 

1. Prioritizing Vendor Communication

In its lawsuit, MSU claimed that Oracle did not staff its project team with qualified team members who were adept with PeopleSoft technology. In addition, the team missed critical deadlines and failed to appropriately test the software before taking it live. 

While some of these issues may have occurred even with careful communication, it’s unlikely they would have developed into major problems if the project team caught them earlier.

This is why ongoing vendor communication is essential. Customers should have around-the-clock insight into how their project is going and any issues that the ERP vendor team encounters.

Without this free flow of information, it’s easy for minor issues to get shoved under the rug as vendors attempt to save face. 

2. Performing In-House Project Management

Even with a third-party vendor by your side, it’s still important for in-house employees to be on the project team. 

Oracle claimed that some of the timeline extensions and organizational conflicts were tied to the university. In fact, when the software company countersued MSU, it claimed that the lawsuit was an attempt for the university to cover up its own shortcomings on the project, particularly regarding internal resources.

Again, communication and planning can help curb many of these disputes. If your internal team has visibility into the project, they can take measures to course-correct if a particular action is taking longer than usual. They can also schedule vendor meetings to discuss budget overruns and any other issues as they occur. 

3. Understanding Software Capabilities

Before you agree to partner with a vendor, make sure you understand the capabilities and the limits of its ERP software.

In this case, the university was seeking an out-of-the-box solution that wouldn’t require a great degree of specialization. Administrators needed to keep deployment, administrative, and upgrade costs as low as possible, so they wanted to avoid extensive software customizations.

In most cases, this is a smart route to take. Customizations can be costly and time-consuming. If a company can meet its business needs with a software’s built-in configurations, it can shorten its schedule and minimize its budget. 

While custom code might expand functionality, it also needs to be redeveloped with each software upgrade. For this reason, many companies prefer to stick to the basics, especially with cloud-based ERP software.

The only problem? Oracle’s PeopleSoft software was developed to be highly customizable. It even came equipped with designated PeopleTools that encouraged and facilitated custom code development. 

As such, its out-of-the-box functionality was limited, which MSU soon discovered. 

4. Evaluating Software Vendors

Determined to save time and money, MSU pushed ahead without customizations. University officials explain that they did so under the guise that the base PeopleSoft system could meet 95% of the university’s more than 3,200 business requirements.

Later, the university found that the software lacked the critical functionality that Oracle claimed it possessed. The university even claimed that Oracle used a faulty and rigged software demonstration to make it appear as though certain functionality was part of the base system, though it was not. 

As this experience shows, a thorough ERP selection process is key to a successful project. It can help to partner with an ERP consulting firm for an independent evaluation of all your options. 

Achieving Higher-Ed ERP Success

An ERP system can be ideal for universities, allowing departments to streamline their operations and simplify employee/student processes. 

However, as we’ve learned through this Oracle ERP failure, it’s important to find the right vendor partner and the right software solution.

By performing an in-depth vendor analysis, university officials can clearly gauge which solution best fits their needs and budget. We can help with this analysis as well as every step of implementation. Request a free ERP consultation below to learn more.

Posts You May Like:

The Pentagon Audit Failure: Unpacking DoD ERP System Issues

The Pentagon Audit Failure: Unpacking DoD ERP System Issues

The Pentagon's financial audit failures highlight systemic issues in ERP system integration and military financial management. Over-customization and legacy systems within the DoD contribute to fragmented ERP platforms and inefficiencies. Inadequate change management...

The Hidden Dangers of Choosing Software Quickly

The Hidden Dangers of Choosing Software Quickly

ERP failures stem from rushed decisions, often resulting in poor integration, unmet requirements, and costly implementation failures. The hidden costs of technical debt arise from "good enough" solutions, leading to inefficiencies, frequent downtime, and high...