IT catfight in Portland, OR

IT catfight in Portland, OR

Summary: 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.

TOPICS: SAP, Banking

IT consultant 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.


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.

Topics: SAP, Banking

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Sacrafice

    My company just finished an ERP release, successfully!

    It takes whole company sacrifice and requires separate Change Management groups to come to power to lead staff and executive management with the project and the (temporary) sacrifices in business process and political ownership. It takes years of business analysis to pull off before (or in parallel) with the new system configuration/development effort. Training by the Change Management team, is a must, and being prepared for a business-continuity during system launch, and post implementation value added projects.

    I would suspect from what I read that the consulting company has been through this before, but the city did not properly manage their expectations or provide the Change Management leadership, BA's, and functional analysis required to support the implementation.
  • RE: IT catfight in Portland, OR

    These type of projects are always more expensive than you first realize. The complexity and the testing alone continue to unfold as you implement. We learned here a few years ago after implementing our ERP system that anytime you estimate costs for something like this add 50% for cost overruns. It is just the way it is. It was painful and draining for our IT staff but after it was all in and all of the bugs of ramping up to full production are complete it is nice.
  • Poor performance on both sides.

    On a project of that scale you need a detailed plan of action. I don't know how they could have submitted a bid without a detailed migration plan. How did they estimate the man hours required? Using a magic 8 ball?
    Hates Idiots
    • Yes that's the point

      Other commenters have been quick to point out how complex these projects are. True, but it's takes two to tango, and both sides were at fault in this case.

      Thanks for sharing your thoughts.
      • Both probably lacked experience

        I'm guessing that Portland lacked experience to even evaluate the proposals they received - their current system was FUBAR. And the implementation firm obviously lacked the know how to develop a detailed plan of action - it's really not that hard. I've also seen people mention that Portland didn't manage it's own expectations but it's the implementation firm's job to manage expectations and reduce scope-creep.

        It appears to me that government on all levels goes for the cheapest proposal which is not in their best interest because they will most likely end up paying more than the most expensive proposal to clean up the mess.
        • You hit the nail on the head!!!

          Two words can summarize this mess - "LOW BID".

          30 people in the whole intergration firm? A $30 million project probably requires that many people on the implementation team.
    • Both deserved each other

      It happens when you deal with Government body, Local/State or National.

      They also don't give you time to get into detailed requirement specifications and make you bid on basis of available job requirements.

      Once your bid gets through you must assert clarity of job description, make the list of BOM (Bill of material) which needs as addition to finish the project and convince those political thick heads to accept them before giving a 'GO' to the project.
      Web Smart
  • Ariston had no business

    Going after a bid of that size. A 30 person firm designing an ERP solution of this scale? Thats laughable. For developing something of that scale their QA team alone should consist of nearly 30 people.

    And then, to make it worse. The project grew way outside its original scope because the city apparently had no clue what they wanted.

    So as the author said, this project was doomed before it ever got off the ground.
  • RE: IT catfight in Portland, OR

    Most projects - system or otherwise - would never be started, if the time, effort and money they would actually consume were known upfront. And most organizations - govt or coml - will not pay for a truly comprehensive requirements analysis. Nor does the bidding process encourage a full layout of complexities, caveats and costs, let alone the unknowns and (im)probabilities. So both parties "lie" to each other by underestimating the size of the challenge. The client hopes to get lucky by forcing more work than they paid for, and the vendor expects that sophisticated contract clauses will ultimately protect them. The outcome is predictable, and highly visible when in the public arena.
  • De Ja Vu

    Some folks from the Los Angeles Unified School District saw exactly the same thing happen when they switched their multi-siloed exception rule based driven payroll system to SAP.

    When the customer has no clue what they have, how can they say what they really need?
    This should have been a screaming red flag to the consultants...
  • Illustrates the dangers of diconnected systems.

    From the article:
    "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."

    Here is why Access is rarely a good idea in the long run. If the data you are collecting is of any importance, then Never, Ever take the easy way and build a small, "disconnected from the enterprise" type 'utility'. It's the same story, over and over. 'But we didn't have the time or money to do it right!' Here's a thought: If you think doing it right is expensive, just wait until you see how much doing it wrong will cost!

    What could these departments have done? Doing without would have been better than building the mess they have now.

    While I realize from reading the article that they ran an IBM mainframe, nothing screams SOFTIE more than when we hear about things like this. Competent IT staff would not have allowed this to happen in the first place.

    • Yes, but need is the mother of fax fixes...

      Good point. But frequently, when someone needs a quick fix, or a simple tool, they don't want to go through a procurement process. They need to get their task(s) done today, not 2 years down the road. Thus the isolated, standalone "tool."

      This goes on every day, every where. I can understand that, after all, my life too is only so long.

      However, when considering an overall solution, then it really does need some considered thought and planning. And a solid well informed IT team, w/ good interpersonal skills is invaluable in guiding people through the minefields.
    • Employees also a hurdle.

      When implementing a system where there has been an number of disconnected systems there can be a real moral problem with the Employees. Jane or John Doe comes into a department where there there is a lot of chaos on getting the job done and he or she creates an Excel spread sheet or Access database to make the job easier. They are heroes. Now the city wants to take away their solution and processes. Now they aren't going to be heroes anymore and often will try to stand in the way of a successful implementation.
      These people need to be brought in at the beginning of the project, otherwise they will fight it tooth and nail or will quit. If they quit then it just adds more time to the project because then someone else has to figure out how the home grown system works.
  • Outsourcing expertise

    One of the results of the mad fight over the last decades to outsource everything is a complete lack of any knowledge or expertise within government and corporations. The result is that no-one within the organisation can evaluate competing tenders or approaches and essentially the consultant with the best marketing and pitch (as well as often the lowest bid) will win. Not only is an organisation unable to evaluate the best consultant/implementer, they have no expertise in overseeing the project either.

    Ah well, you reap what you sow.
  • awesome picture

    Where do you find them?
    Erik Engbrecht
    • Google

      Really glad you like the photos. When writing a post, I try to imagine some image or metaphor that captures the spirit of the topic.

      In this case, most of the "catfight" images were just too nasty to use (search yourself to see what I mean). On the other hand, this image didn't really convey the intensity I wanted. Still, this seemed to be the best of the bunch.
      • Certain subtlety...

        A lot of fights between customers, vendors, and consulting firms/outsourcers involve a lot more noise and frantic movement than actual infliction of damage.

        They look mean, but when the ruckus is over they'll all go back to bed together.
        Erik Engbrecht
  • I must say I love this picture

  • RE: IT catfight in Portland, OR

    Was this by any chance a small business or minority contractor set aside contract where the contractor was chosen for every reason but the correct one?