Marin County restarts ERP project; Deloitte under scrutiny in CA and MA

Marin County restarts ERP project; Deloitte under scrutiny in CA and MA

Summary: California's Marin County has started a new enterprise implementation and learned lessons from the past. Meanwhile, Deloitte consulting is under scrutiny for recent IT failures in Massachusetts and California.


Three years after terminating a failed ERP project, Marin County, California, is once again trying its hand at an enterprise implementation. This time around, the county has learned lessons from the past that may help drive success.

Marin County restarts ERP project; Deloitte under scrutiny in CA and MA
Image from iStockphoto

Marin's original project went $30 million over budget and culminated in a lawsuit claiming fraud against Deloitte Consulting and software supplier SAP. In the lawsuit settlement, Deloitte Consulting paid $3.9 million to Marin and all claims against SAP were dismissed.

Also read:

Marin's lawsuit presented a one-sided argument that Deloitte and SAP were entirely responsible for the failed project with the county as victim. As I explained at the time, this position was significantly flawed because it did not accurately reflect the county's role in creating a negative outcome:

Marin's position seems to imply that all responsibility lies with these external vendors, because the county had "little or no prior knowledge of SAP software or experience with complex ERP implementations."

On the surface, this position perhaps seems reasonable; however, enterprise implementations always require shared involvement between a customer and its vendors. Therefore, such an extreme position bears little connection to the requirements of actual software deployments. The question is where to draw the line on responsibility.

As it prepares to restart its ERP project, Marin appears to have learned from prior mistakes and taken the following steps:

  • Created a formal business case (PDF) document
  • Hired external consultants (for almost $600,000) to evaluate (PDF) Marin's business process needs and define the project scope
  • Re-examined the business fit of large software systems relative to the county's capacity to absorb the business process change and financial requirements of a large ERP implementation

While Marin moves forward, we should review Deloitte's association with IT failures, including:

Both California and Massachusetts recently conducted hearings into failed rollouts of unemployment systems that Deloitte implemented. These events raise the question whether Deloitte has systemic issues that lead to problems with such projects.

ERP implementations are among the most complex software projects in business. When the interests of customer, software vendor, and system integrator converge, the likelihood of project success increases; conversely, failure is virtually inevitable when interests diverge. The IT Devil's Triangle concept describes these dynamics.

Also read:

Exploring the Devil’s Triangle
The IT failures blame game (part 1)
The IT failures blame game (part 2)
‘Pain chains’ and the IT Devil’s Triangle

When inexperienced enterprise customers relinquish control to outside vendors, costs tend to rise and schedules may slip. To avoid this, enterprise buyers should spend time and money, upfront, to analyze requirements, areas of business process change, and the implementation plan (including testing) in great detail. Frequently, however, management and stakeholders demand rapid progress at the start, leading to rushed and incomplete preparation.

If this advice seems like motherhood and apple pie in its obvious simplicity, ask yourself why so many projects fail. In point of fact, getting these things right is neither simple nor easy. In this case, Marin may finally be on the path to doing things properly. 

Disclosure: SAP is a current client related to CIO innovation

Topics: CXO, Enterprise Software

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
  • Fair Treatment

    Mike, I have emjoyed your articles and although not involved I thought it would be fair to also mention all the projects in the same categories you mention above that Deloitte has delivered successfully.

    I believe your assesment is correct in the complexity and some equal blame but the articles seem to paint a very bad view of Deloitte overall without mentioning their successes.

    I'll look forward to reading more of your articles in the future.
    • Examining Deloitte

      Thank you for the comment and for reading. I try to paint a balanced picture, but success is expected on these projects. The real issue becomes why Deloitte keeps surfacing on the IT failures radar, in comparison to other large integrators. Is it purely chance, bad PR, or an underlying systemic problem at the company?
  • Large IT projects should go to IT companies

    And not accounting firms and defense contractors, especially those with lousy track records at it, like Deloitte and the likes of Lockheed-Martin. I suspect that they think they are acting as mostly middlemen for the likes of Microsoft and Oracle and their armies of partners to do the grunt-work on large scale projects, but no -- it doesn't work at all well that way.
  • Complexities...

    Ok so the state of California has their issues with SAP too, so there's one I don't think is Deloitte to make all feel better. You may know better but the complexities of computer code today is taking it's toll. Open source is great too but when you are trying to combine and link some of the entities that within themselves is complex to other complex systems, there's just more truckloads of code and not even the best compilers seem to be catching it, but again when compiling that's only one part of complex systems today.

    I looked at the technologies used in the government healthcare site, many and a lot of app code to integrate and thus there I said why not take the off the shelf Oracle integrated solutions and then build more code rather than to create bigger mixed bags and at least follow some routes that have been tested and are used by the enterprise.

    Good old days of customizing integration components seem to have vanished with current day complexities.
    • Complexity is Not Just in the Code, and the Problem with Customizations

      Often times, it's the complexity of the business rules that many public systems have to abide by-- some rules and regulations at the federal level may be at odds with state and local rules and regulations.

      A human can juggle between the rules. But implementing these regulations requires programming the business rules, which causes problems.

      This is on top of the usual issues of workflows, new software, and changes in tasks that these systems involve.

      Regarding customization of off-the-shelf systems, unless these are applications that integrate with the off-the-shelf system, code modifications and additions may not survive upgrades of the system. In addition, any application development project carries the usual problems.
  • Business Process Flexibility a key

    The 3rd point is likely the most important as Marin may need to adjust their business processes to minimize customization of the base product. Many organizations also benefit from the business process assumptions inherent in all ERP products.

    The likelihood of project success is much higher if the county is prepared to work with any implementation partner as both processes are defined and implemented. Staying focused on the end result can be a difficult endeavor but well worth the time.