WSRcg Software Expert Witnesses

Software & System Failure Litigation

WSRcg provides expert witness services for litigation involving large-scale system project and software failures. We have provided opinions or testimony in such matters in North America, Europe, Asia, and in courts at all levels including US Federal Courts, Superior Courts, and the Court of Federal Claims, and in arbitration and mediation. As pioneers in the areas of systems development methodology, systems testing and acceptance, systems contracts, and CPR (Cooperative Project Renewal) – A Methodology for Resuscitating Drowning Projects, WSRcg experts use their particularly rich experience and diverse expertise to quickly uncover the root causes of why a system and/or project has failed in terms of quality, cost, schedule, functionality and performance.

WSRcg has learned over the past 20 years in over 100 IT, computer, software failure and software project failure matters in North America, Asia, and Europe, that the same underlying causes become important claims in the pleadings/complaints prepared by both parties! These claims, for sure, weigh in very heavily as potential root causes in virtually all such failures (and successes).

While in most cases, multiple parties tend contribute to a failure, courts typically hold one party more responsible than the others, and often the determination of liability can be counter-intuitive. To help the court correctly attribute the primary blame for a software or software project failure, it is important to carefully isolate and identify the root cause of failure, which itself depends on the degree to which each of the eleven forces and related decisions played a role in shaping the events of a project.

Typical Issues/Charges between Parties in Software Project Failure Litigation

While the IT, computer and software industries have changed dramatically over the past twenty years with the flattening world’s adoption of the internet and the world wide web, 4th generation languages, Sarbanes Oxley, smart phones, mobile computing, web 2.0, outsourcing, SaaS, hosting, cyber terrorism, identity theft, Bill Gates’ retirement, ever more complicated and sometimes overreaching ERP software solutions – computer and software failures still abound in almost record numbers. The newest smart phone cannot be activated for hours, and in some cases, days. ERP software failures and software project failures are reported each week. Over $55 billion was written off for failed and scratched computer, software and systems projects in the USA alone a few years ago -- and that’s only what was reported!

Over the past 20 years, Warren S. Reid, Managing Director of WSR Consulting Group, LLC has compiled, updated (although little has changed) and published what he believes are the same main complaints between the constituents of software projects (1) Acquirers (i.e., in-house counsel, CXOs, Board members), (2) Vendors/Integrators/Consultants, (3) User Departments and Users, and (4) In-house IT departments. These same claims and charges are universal. Warren Reid’s well published work, “He Said ... She Said...” is linked here:

While it is oftentimes true that all parties could have contributed to the causes of the software or system project failure in each 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.

WSRcg’s Unique Avenue of Inquiry

Warren Reid’s experiences in software implementation and litigation matters have led him to further investigate and deconstruct the business, corporate cultures and profit models of vendors and customers, and the impact these factors have on new product launches - including new software development, substantive system upgrades and configuration, implementation, maintenance projects. The results of these investigations show that in many cases, computer/software projects fail even where constituents employ strong SDLC, requirements elicitation, staff, scope/schedule/cost control, testing, and project management processes. Software projects will continue to fail if internal conflicts and divergent goals are not surfaced, addressed and/or mitigated.

One avenue we pursue that other experts don’t is to identify and understand the internal clashes and conflicts between the four institutional groups participating in software projects: the users; the C Suite; in-house IT; and systems integrators and consultants. These different groups can have a dramatic impact on system selection, project costs, schedule, requirements, and success. The clashes and conflicts are oftentimes unspoken. Uncovering them may help lead to the root causes of failure.

These clashes and conflicts are different from and in addition to the typical reasons that software projects fail such as: limited functionality, unable to meet performance targets, inexperienced project teams with high turnover, promised SDLC abandoned or not used, poor user training, incomplete data conversion, lack of customer management support, etc.

Examples of conflicts and clashes are demonstrated in the table below:

Clashes Between Groups (a few examples)

<- scroll left to right if needed ->
System Users
The C” Suite
Integrators / Consultants
Internal IT Dep.
Many Features Mission Cost Effectiveness Flexible Contract Ease of Transition
Changeable requirements Limited development budget & schedule Ease of meeting budget/schedule Ease of Maintenance
Applications compatibility Regulatory standards compliance Stable requirements Total Cost of Ownership

Conflicts Within Each Group (a few examples)

Ability to change requirements as they learn more Alignment with strategic plans and goals To pull Best Staff off certain projects mid-stream to work on more profitable ones Develop in-house vs COTs or ERP systems
GUI right for their capability (i.e., Digital: Dinosaurs; Immigrants; Natives; DNA’s Rigorous contract; Privacy and security “Maverick” methodology vs. Industry standard or promised one. Operations/Maintenance to Stay In-House vs. Outsource

Going Deeper into Software Project Failure

Uncovering internal party conflicts requires special skills/experience beyond software project, technical and IT leadership expertise. WSRcg’s special skills allow it to delve into departmental and cross-departmental conflicts, divergent goals, company culture, leadership preferences and the level of risk tolerance in all groups.

This knowledge must then be paired with an understanding of the larger business climate/risks/goals including worldwide technology disruptors, the general economy, competitive pressures, industry consolidation, war, and near and longer-term business intelligence. Together, these data points and inferences tell a story of why executives, technologists, department heads and professionals originally made important project decisions, and then perhaps changed them. These types of business analyses require new and creative document discovery approaches and requests, and deposition questioning first to unearth and then to prove these hidden realities in litigation. In a couple of our cases, the final verdicts/judgments were dependent on these discoveries and a clear and simple presentation of these facts and opinions to the triers of fact.

This discovery, insight and knowledge can then be useful and instructive for:

  • Turnarounds: Uncovering the causation of poor decision-making which can then be used to turn around a project by developing concrete and practical work plans, work assignments, recommendations, collaborations, and actionable metrics/measures to help assure project and product success.
  • Litigation testimony: by uncovering the hidden agendas of specific party actions/inactions that damaged the chances of project or product success. Explaining such self-interested beliefs, strategies, and intentions by the parties is instructive to the triers of fact. Litigators and judges have told us it is often helpful to a jury’s understanding and appreciation of the facts to know not only what was done, but why something was/might not have been done, and how that contributed to “alleged project failure” -- or why the customer is being uncollaborative or unreasonable in not accepting a “successful system” delivered per the contract or industry standards.