WSRcg ERP Expert Witnesses

What We Do as ERP Expert Witnesses

Our ERP consultants and expert witnesses have consulting expertise on projects and/or testifying experience in litigation involving the following ERP vendors/systems:

  • SAP and SAP Retail,
  • Oracle Applications Suite, Oracle e-Business Suite,
  • PeopleSoft, J. D. Edwards,
  • Retek (grocery stores), Cerner (healthcare),
  • Microsoft Dynamics,
  • Lawson Software,
  • Others.

As ERP Expert Witnesses we have consulted on legal matters, and/or provided expert witness reports and/or testimony at trial, arbitration, mediation and special hearings regarding ERP projects systems and in-process and delivered ERP systems in North America, Europe, and Asia. For ease, we divide our expert witness work regarding ERP system work into two categories: 1) Litigation regarding how the project was executed. 2) The suitability of the delivered system delivered.

Project Execution Testimony Areas:
  • Poor project estimates
  • Poor project planning
  • Bad project staffing; member skills, availability, number, turnover
  • Non-execution of promised SDLC
  • Not enough time left for testing
  • Not static or workbench reviews
  • Intermittent QA
  • Rosier than actual progress reporting
  • Poor use of automated tools
  • Fail to plan and follow a proper testing regimen
  • Lack of action taken when risks arise
  • Failure to escalate disagreements as per the contract
  • New Users not properly trained; did not attend training
  • System failed in field because BPR not performed
  • Going live when system, users, help-desk, managers not ready
  • An extended period for the system to settle post Go-Live with high frustration, overtime, workarounds, emergency releases, failure of the system to perform
  • Non-acceptance of the system by the customer
Suitability of Delivered System Testimony Areas:
  • Disagreements between stakeholders
  • Customer changing requirements w/o changing contract, scope, cost, schedule, quality, risks
  • Adherence to contract responsibilities
  • Takes more than 24 hours to perform daily processing
  • Coding standards ignored (maintenance will be problematic)
  • Impact of improper and incomplete testing,
  • functionality, -ilities missing
  • architecture and structure don’t provide needed scalability,
  • GUI is not friendly to use by older employees (70+ years),
  • Unreadiness for go-live,
  • Systems progresses w/o passing phase & quality stage gates
  • Not suitable for purpose or customer situation/needs,
  • Non-adherence to specs, documentation & system demos,
  • Non-compliance w contracts, agreed-to SLOs/SLAs,
  • meeting government requirements (SOX, HIPAA, IRS, etc.),
  • Completely/accurately processing all transactions end-to-end,
  • Poor backup, recovery & restart capability; ability to correctly back out partially committed atomic transactions

In ERP system and/or in large scale project failure litigation, we review related project discovery including documentation of all kinds, read depositions and declarations, test software if necessary, perform internet searches, and conduct interviews with fact witnesses and other experts, if applicable, to determine the root causes of ERP project failure.

While the various contracts or course of conduct may define success or failure, we usually are asked to clarify ambiguous or non-existent contract clauses, roles and responsibilities, and the quality of certain deliverables and decisions made to help determine success, failure and accountability regarding:

  • Cost overruns and cost to complete,
  • Schedule delays,
  • Quality of deliverables,
  • Scope/depth of delivered functionality (or NOT),
  • Performance/suitability of the products delivered,
  • Risks identified/mitigated
  • Stakeholder expectations
  • The value of artifacts/ deliverables left behind

While it is usually true that all parties could have contributed to the causes of the software or system project failure in a specific area, it is our experience that:

  • One party usually contributes more to the failure and its root causes,
  • One party will have done something (or did not do something it was supposed to or should have done) to set the wheels in motion or the dominoes falling to create the root causes of project failure – although it was not evident until we discovered that during our investigation and review of discovered materials.