A legal dispute between Oracle and erstwhile client Montclair State University illustrates that despite the steady evolution of ERP technology and implementation methodologies, these projects can still turn ugly.
The two have filed suits against each other over a failed project, called the “Bell Tower Initiative.” Montclair has accused Oracle of violating the terms of its agreement to build a new Web portal for the school. It claims that Oracle’s gross negligence resulted in project cost overruns of some US$20 million.
Oracle, for its part, says the New Jersey school still owes it for work done — to the tune of $5.3 million. It has filed suit demanding payment and requesting that Montclair’s charges be dismissed. Among other allegations Oracle has made is its claim that the school didn’t have the tech savvy to fully understand the scope of the project or what its completion might entail.
Both Oracle and the university declined CRM Buyer’s requests to comment on the matter.
A Trip Down Memory Lane
Such disputes were more common 10 years ago, when most firms saw ERP as the only choice for a wired, integrated operation; cloud computing was barely a concept then. Also, ERP software tended to be far more cumbersome and difficult to use than it is now.
Some things, though, haven’t changed — at least based on the Oracle-Montclair debacle — and that is the risk of misaligned expectations on both sides.
Oracle and Montclair State University’s legal conflict is a classic case of a relationship gone bad for that very reason, Nour Group CEO David Nour told CRM Buyer. “You said you were going to do this, and you did something else — with a gap between the outcome I experienced and what I expected from the onset. Now we have a problem.”
Misaligned Expectations, No Buy-in
This happens for several reasons, he said. One is that most large implementations are not scoped correctly. Also, most large implementations are technology-focused vs. business-outcome focused.
“Implementers can forget that the technology is an enabler of the business results,” Nour pointed out.
Finally, most large implementations are launched with grand visions vs. a stair-step approach.
“They forget that success comes in incremental stages, and we should take smaller bites,” said Nour.
Buy-in from the key stakeholders at the company is essential, Patrick Gray, president of the Prevoyance Group, told CRM Buyer. “Companies act as absentee landlords and let their implementation firm run the show, expecting them to show up with a working system some number of months later.”
In these situations, he said, “something” gets produced by the implementation firm, but it will take three times as long — and not meet the needs of the end-users.
A related problem is that a defined decision-making process is rarely put in place, continued Gray.
“For an ERP to finish on schedule, tough decisions on scope, processes and schedule must be made,” he explained. “In many environments, making the wrong decision is punished so onerously, no one wants to make any decision. Implementation firms often don’t help this process, since a long decision cycle adds billable hours.”
The Short Route
If nothing else, the Oracle-Montclair legal dispute serves as a timely reminder of why more firms began gravitating to shorter, more discrete projects, J. Lance Reese, president of Silver Peak Consulting, told CRM Buyer.
“Larger implementations that take several years no longer make any sense for CIOs. By the time the applications go live, many of the features may not apply or no longer serve the needs of a rapidly changing business,” he said.
As a result, more CIOs are avoiding large ERP implementations, said Reese, and pursuing best-in-class applications, systems comprised of multiple vendors, and products that can be integrated — especially if the integrations are already built-in and supported.
“Integrations come with their own headaches,” he acknowledged, “but are minuscule compared to the difficulties faced in implementing, supporting, upgrading, and ultimately trying to remove a massive ERP solution when it is too outdated.”
Loading ...
As a full-cycle developer with several decades of experience, I have seen this situation many times. Contracting agencies love naive customers. A company comes in with a low-ball bid on a complex project, knowing that never in the history of the planet has a client been able to completely and accurately spec out a project.
Then the contracting company charges through the nose for the inevitable change-orders.
It’s an old game that is still going on.
What poorly-managed businesses still do not seem to get, after all these years, is that outsourcing is not a substitute for having technical competence in house.
Over the past twenty years, I have seen large businesses and governments lay off and fire their skilled IT staff, thinking they can be replaced by contractors.
But IT is more than just bits, bytes, and coding.
In many businesses, the IT staff is the repository of the business logic of the computer system.
In more than one company, I’ve asked managers how they verify that the data coming from the computer is accurate, and they shrug their shoulders – it’s ITs responsibility. In large and medium-sized companies and agencies, it is very unusual, in fact, I would say I have never seen a situation where there was even one person not in the IT department who knew what every piece of data was supposed to represent, and how they all fit together.
And then the IT department gets laid off, the job is outsourced, and that institutional knowledge is lost. The contractors are desperately trying to understand how it all fits together. The documentation is out of date, or missing. A small piece of information, like "We need sub-categories of race, in addtion to the eight categories" discovered half-way through the development cycle can throw a monkey-wrench into the whole project.
I discovered early on, when I was developing an RFP for my own company, that I needed almost the same level of expertise to select and hire a consultant as I would need to do the work myself.
The supervising manager, when told that the project is past due, and over budget, needs to be able to assess if the problem is
a) the original scope and delivery schedule were unrealistic and need to be renegotiated or
b) the team doing the work is incompetent, and will never get it done right or
c) it really is just a little behind, and will come in as promised in the new schedule.
This requires a level of technical competence not usually found in the bureaucrats or budget analysts given these projects.
All companies with complex IT projects need to have at least one highly skilled employee who understands not only the business needs, but also understands the technology. Modern computer systems have a great many features built-in, that come with no extra charge. I’ve seen clients insist upon search procedures that have to be written from scratch, because the original specs were written by someone who did not know to take advantage of the free, built-in search features of the database they were using.
The contracting companies are well aware of these issues, and take advantage of the naive customers, who do not fully understand how to manage IT projects, or even how to competently use a computer system. I applaud the efforts to make these contracting companies accountable so that hopefully they will be more cautious in the future.
On the other hand, there really is no excuse for a company managing contracts worth millions of dollars to not provide a career path for its staff that produces competent managers with the necessary institutional knowledge and technical skills to manage those projects.