IT catfight in Portland, OR

Portland, Oregon's late and over-budget ERP implementation has become a battleground between city officials and system integrator Ariston Consulting & Technologies. As the failing project's budget ballooned from $31 million to $49.45 million, finger-pointing and mutual blame have obscured faults on both sides.

Background. According to a February, 2004 report by Portland's Financial Reporting and Compliance Project, the city faced numerous system-related challenges:

[T]the City has developed a number of separate, and in some cases duplicative, systems that limit the free flow of financial data and information and the ability to share knowledge and training opportunities among accounting staff across bureau lines. In the absence of a more robust or fully featured centralized financial information system this approach, while serving individual bureau needs, limits the ability to achieve higher levels of productivity and efficiency citywide. In order to improve services and reduce costs, this approach to technology tools and investment will need to change.

In plain English, the old financial systems were so bad that employees across the city developed their own ad hoc tools on a workaround basis. Computerworld interviewed Mark Greinke, Portland's chief technology officer:

Because it was hard to add new components to that application, "shadow systems" were created by various city departments to add needed features that weren't tied directly into the main legacy application. What that created, he said, was a diverse IT system made up of single Microsoft Access database files, single Microsoft Excel spreadsheet files and more that weren't connected in a useful way. The new IT infrastructure is being created to tie all of that data together in a unified system, he said.

Proposed solution. To solve these problems and create an integrated city-wide financial reporting tool, Portland decided to replace it's old IBM mainframe with a web-based ERP solution from SAP. It appears the city purchased the software from SAP but engaged Ariston to provide implementation services. (Neither SAP nor Ariston responded to requests for comment on this post.)

Problem description. Last December, a third-party reviewer found Ariston's project plan lacking. From The Oregonian:

[A] consultant hired to do regular quality control updates told city managers that Ariston was working too slowly and that the city and the contractor lacked the kind of detailed plan necessary to get the new system working on time.

A payroll system test last December produced unexpected and incorrect results, causing the city to terminate Ariston and hire SAP to provide consulting services needed to complete the project.

THE PROJECT FAILURES ANALYSIS

This case highlights the oft-repeated assertion that projects live or die based on management and planning rather than technology. The SAP Watch blog explicitly gives a clean bill of health to the technology:

It isn’t clear who’s to blame for the cost overrun and project delay, but Portland and Ariston will no doubt implicate each other in time. The soundness of the underlying SAP software itself has not been questioned by either party.

Mutual blame game. In my view, both Ariston and Portland underestimated the project's complexity from the start. In a rather naive approach toward public relations, each side has publicly blamed the other.

Portland's chief administrative officer, Ken Rust, blasted Ariston (emphasis added below):

Ariston, a 30-person firm, did not show the kind of guidance city leaders needed.

"No one in city government had ever installed a system like this before," Rust said. "We hired a consulting firm to lead us through the process. Instead, we saw a complete lack of leadership."

Rust said there's little city administrators could have done differently. Ariston had good references and a successful track record. The only red flag city leaders might have noticed, he said, is that Ariston had never led a project this large and complicated.

These comments demonstrate the city's inexperience and lack of insight. I find it disingenuous for Rust to claim the city had no responsibility, despite selecting a vendor that clearly didn't possess the requisite experience.

Ariston responded in kind:

Ariston's president referred questions to Stoll, the Portland lawyer, who noted that Ariston has handled several large government contracts. He suggested that Portland administrators did not realize how complicated the job was.

"Frankly, there are a lot of silos within the city," he said. "When you try to go from the silo system to one overall system, and nobody has looked at how they integrate and whether they even can integrate and what it's going to cost to integrate them, it's very difficult for a consultant to come in and be successful."

Ariston continued (emphasis added below):

From Ariston's point of view, [Stoll] said, city officials who prepared the project requirements and put it out for bid weren't familiar enough with their overall IT systems and needs, making the goal for the work an impossible target to hit. "It's sort of garbage in, garbage out, if you know what I mean. I certainly don't think that Ariston made any mistakes."

Portland's systems are genuinely complex. For example, the city must consider 16 different labor contracts when calculating payroll. This complexity was not clear to either Ariston or city officials during the project planning phases. As a result, both parties entered an agreement ultimately doomed to fail.

My take. The city didn't provide sufficient direction to Ariston regarding project goals and requirements, and Ariston accepted a poorly defined contract that went beyond the company's capacity to execute.

This project was doomed from the start and affirms my belief that many IT failures arise at the intersection of greed, arrogance, and inexperience.