IT Software Project Failure: Typical Root Causes of Action in Litigation

    DisputeSoft Admin
    software failure expert witnesses

    DisputeSoft’s software project failure expert witnesses have worked on over 100 cases where the central dispute is best summarized as a failed software/IT project implementation. 

    Based on our extensive years of experience in such matters, we have cataloged the root causes of these more than 100 cases of IT and computer software project failure, of which more than 40 have progressed to expert deposition or trial.

    This list highlights the most common root causes identified through our work: 

    1. Inadequate Requirements Documentation
    2. Lack of Subject Matter Expertise in Requirements Elicitation
    3. Improper Sign-off and Acceptance of Requirements
    4. Inadequate Requirements Traceability
    5. Unclear Customer and Supplier Responsibilities
    6. Failure to Adapt Business Processes to the New System
    7. Inappropriate Choice of Solution: COTS v. OOTB Solutions
    8. Inappropriate Implementation: Configuration v. Customization
    9. Misrepresentation of Software Capabilities / Functionality
    10. Failure to Manage Scope Creep and Exercise Control
    11. Inadequate Design Documentation
    12. Faulty Design
    13. Poor Project Management
    14. Inadequate and/or Unqualified Project Personnel
    15. Failure to Adhere to an Established Project Schedule and Budget
    16. Faulty Data Migration
    17. Inadequate Testing
    18. Poor Defect Management / Poor Maintainability
    19. Failure to Adhere to SLAs

    This list is by no means exhaustive, but it provides a birds-eye view of the complexities of IT projects, and the numerous root causes of their failure. 

    An IT software project failure tends to share many common facts and circumstances, resulting in common causes of action pled by the parties.

    Some of the most frequent and prominent causes of actions that appear in IT project failure litigation are discussed in detail below, including: 

    (1) breach of contract 

    (2) misrepresentation 

    (3) breach of warranty 

    (4) unjust enrichment 

    (5) termination for convenience 

    While the topics discussed below are not exhaustive, they cover an overwhelming majority of the legal causes of action present in the more-than-100 matters on which DisputeSoft has been engaged.

    Claim 1: Breach of Contract

    Breach of contract arises when a party fails to discharge its obligations under a valid contract resulting in injury to the other party. The contract details each party’s specific obligations to perform certain services or deliver certain goods that the other party is entitled to receive. After determining the other party did not discharge its obligations under the contract, an aggrieved party first looks to contract documents for remediation options. Often, each party cross-claims the other breached the contract.

    In most IT project failure disputes, breach of contract claims brought by a Customer tend to allege: 

    (1) a Supplier is behind schedule and/or over budget; 

    (2) a Supplier failed to deliver software that meets the Customer’s requirements; 

    (3) a Supplier failed to deliver software that conforms to the description in the contract; or 

    (4) a Supplier failed to provide adequate resources with the proper skill, training, and experience, as promised under the contract. 

    Claims for breach of contract brought by Suppliers often allege that a Customer failed to pay for services the Supplier performed, that any delay was caused by the Customer as opposed to the Supplier, and that budget overruns were the result of scope creep. In some cases, either party may allege the other failed to timely cure a breach.

    Claim 2: Misrepresentation

    Misrepresentation arises when a party makes a false or seriously misleading statement of material fact intended to induce the other party to enter an agreement, and upon which the other party reasonably relies in entering the agreement, causing injury. 

    Depending on the parties and the context, misrepresentations can be either fraudulent (i.e., made knowingly, or with reckless disregard as to its truth) or negligent (i.e., made by one owing a duty of care regarding accuracy of factual statements upon which another party may rely in entering an agreement). In either situation, however, the false statement must be material to the transaction, causing the other party to rely on its truth in entering the agreement.

    Statements made toward the beginning of the procurement process are the most scrutinized when alleging misrepresentation. False or misleading statements giving rise to misrepresentation take many forms, including, but not limited to:

    (1) marketing materials regarding current capabilities or successful installations of software;

    (2) skills and expertise of resources;

    (3) ability to reach project completion by a specific date; or

    (4) software’s level of completion or requirements coverage.

    Though Customers rely on Suppliers for their expertise, Customers must also consider its own business constraints, such as cost and time to completion. Thus, Customers can be particularly vulnerable to puffery intended to showcase a Supplier’s ability to deliver within those constraints. Expecting that a Supplier’s statements are factually accurate, Customers may be inclined to select a supplier without fully vetting a Supplier’s representations.

    Claim 3: Breach of Warranty to Perform Services in a Workmanlike Manner

    A warranty is a promise or assurance that particular facts or statements are true, which are incorporated into the terms of a contract, whether expressly or impliedly. A breach of warranty claim differs from misrepresentation insofar as warranties are based largely on statements memorialized or implied in the contract, whereas misrepresentations are based on pre-contractual representations, discussions, and negotiations. 

    The two most common breach of warranty claims that appear in IT project failure matters are: (1) breach of warranty to perform services in a workmanlike manner; and (2) breach of warranty of merchantability.

    Often, agreements for IT projects contain a warranty to perform services in a workmanlike manner, which is a Supplier’s promise that the services will be performed in accordance with industry standards and best practices, or with a similar degree of efficiency and knowledge possessed by those of ordinary skill, competency, and standing in the industry. 

    A Customer alleging a breach of this warranty claims that the work was not performed in accordance with generally accepted industry standards, or was performed by Supplier personnel lacking adequate technical skills, experience, or qualifications to perform work of this type.

    In IT projects, this claim typically arises when a Supplier deviates from industry best practices often resulting in negative impacts to the project schedule and budget. 

    For example, in one matter, the Supplier proposed building a system based on Microsoft’s .NET platform, for which many published resources are available that cover Microsoft-defined standards, best practices, and extensive technical guidelines. One such publication details system design standards for system architects and engineers, and includes Microsoft’s recommended approach. In this case, the Customer alleged that the Supplier significantly deviated from Microsoft’s standards and best practices, including using stored procedures to implement business logic and applying generic, “catch-all” exception handling features.

    Claim 4: Unjust Enrichment

    Unjust enrichment arises when one party confers a benefit upon the other party without receiving the benefit of the other party’s counter-performance. 

    This claim is typically alleged in the alternative to a breach of contract claim in case a contract is determined invalid. Where there is not a valid contract, one may be implied or judicially constructed with the objective of providing a reasonable recovery to a party that has fully discharged its apparent obligations from a party that has not.

    In IT projects, unjust enrichment claims typically arise where either: 

    (1) a Customer alleges that a Supplier fails to deliver the promised software or completely perform its services; or 

    (2) a Supplier alleges a Customer failed to pay for the software or services provided by a Supplier. 

    The common circumstance in each scenario is that one party has received the benefit of the bargain without discharging its own performance. For example, where a Supplier develops software for a Customer, but the Customer fails to pay the Supplier, the Customer receives the value of software development services without incurring costs. 

    Consequently, a Customer may be unjustly enriched by receiving the value of the software development work and retaining its payment. Alternatively, Suppliers may be unjustly enriched where a Customer has paid in full, but a Supplier has either not completed its services or has delivered software that does not meet specifications.

    Claim 5: Termination for Convenience

    A claim of termination for convenience arises most often in government contracts, but may also arise in private commercial transactions. 

    A “termination for convenience” clause is a standard contractual clause that establishes a party’s right to terminate an agreement for any or no reason. In such a situation, a terminated party is generally entitled to limited monetary recovery, typically comparable to the value of services completed. 

    Alternatively, a “termination for cause” clause establishes a party’s right to terminate an agreement if another party fails to perform according to specific terms. Termination for cause does not give rise to monetary recovery by a terminated party, and may impose liabilities.

    In IT projects, a termination for convenience claim tends to arise as a result of a Customer’s attempted termination for cause. For example, a government agency Customer terminated “for cause” an agreement with a software application Supplier after allegedly determining the Supplier’s performance delays were inexcusable under the contract. 

    The Supplier alleged that the Customer terminated the agreement without adhering to appropriate reporting protocols within the government agency for making such decisions, and at a time when the software was nearly complete, and that the termination for cause was therefore improper. 

    Consequently, the Supplier requested that the court interpret the Customer’s termination for cause as a termination for convenience, thereby entitling the Supplier to recover a portion of what it would have received under the contract.

    Conclusion

    DisputeSoft assists Customers and Suppliers in proving its claims by analyzing the technical basis for these various causes of action. 

    For example, DisputeSoft analyzes technical project deliverables and project management documentation to assess breach of contract, misrepresentation, and unjust enrichment claims relating to project scope creep, budget overruns, schedule delays, and project management best practices. 

    Additionally, DisputeSoft frequently performs software engineering analyses and testing analyses to assess the extent to which a party’s rendered services are consistent with industry standards and best practices to support claims for breach of warranty. 

    DisputeSoft‘s software failure expert witnesses also perform complete analyses to support a damages expert’s monetary claim in support of a claim for termination for convenience.