How expert witnesses assess failed software projects: requirements failures, development practice, supplier duties, and forming an opinion under CPR Part 35.
Failed software project disputes arrive with a surface complexity that can be misleading. Two parties, conflicting accounts, incomplete records, and often a tangle of shared decisions that neither side now wants to own. From the outside it looks like a mess, but in my experience, the technical assessment is usually the clearest part of the whole affair.
Most of what constitutes professional software delivery is not written down anywhere in the contract. Nobody specifies that requirements should be gathered from actual users, that developers need a shared coding standard, that you do not push directly to a production system without testing in a safe environment first. These things do not need to be written down because they are what competent software delivery looks like. The expert’s job is to know that, to look for whether it happened, and to say clearly when it did not.
This guide documents the methodology I use. It is written for solicitors who want to understand what a rigorous technical assessment involves, and for practitioners working in this space. The standard I apply is not derived from a checklist. It comes from knowing what good software delivery looks like in practice, and being able to explain the gap when it is not present.
How Were They Actually Working?
The starting point of any assessment is to understand what the team actually did. I want to understand how the project operated, how requirements were gathered and by whom, whether developers knew what they were building before they started, how testing was conducted and by whom, how problems were recorded and resolved, how the system was deployed and monitored. That operational picture is what I am trying to reconstruct.
I build that picture from whatever evidence exists.
Governance documents first: contract, statement of work, any development or testing methodology the supplier defined. These tell me what was intended and committed to.
Then the operational record: requirements documents, bug reports, test results, status reports, change requests, incident logs, sprint artefacts. These tell me what actually happened.
The two rarely match perfectly, but that’s not always a problem. Where governance documents are absent or thin, that is not a gap in the evidence. It is itself a finding. A supplier who began development without a documented approach to requirements, testing or deployment has already told me something important about how the project was run.
When Professional Practice Falls Away
Most of the failures I encounter in disputed projects are the kind of thing any experienced software professional would recognise immediately as wrong, measured against the industry standards that govern competent practice. The contract does not need to prohibit them.
Requirements are a consistent source of failure. The most basic professional obligation in software delivery is to understand what you are building before you build it, and that means speaking to the people who will use the system. Requirements assumed or invented without user research are not requirements. They are guesses. When I see a requirements document with no evidence of user workshops, interviews, or stakeholder engagement, and a client who confirms their staff were never consulted, that is a material failure regardless of whether the contract specified a requirements methodology.
Regulatory requirements deserve separate mention because I have seen them treated as optional. A system handling financial transactions, personal data, or clinical information carries obligations that exist regardless of what the contract says. I have seen systems handling personal data with no documented consideration of data retention, access controls, or breach response — none of it mentioned in the project record. A supplier who did not identify and address the relevant regulations has failed professionally. The client may share that failure if they did not raise it, but the supplier cannot claim ignorance of a legal landscape that any competent professional in their domain would know.
Development practice failures are often the most concrete to present in court, because they are visible, testable, and leave a trail. A team with no shared coding standards produces inconsistent, unmaintainable code that cannot be independently verified or maintained after handover. A team that does not use automated testing relies on manual checking that is slow, incomplete and prone to errors. A team that holds no refinement sessions produces developers who start work without a shared understanding of what they are building or who to ask when they are uncertain. Each of these is a professional failure.
Deployment and operations failures are particularly telling because their consequences are immediate and measurable. Pushing code directly to a production environment without first deploying to a staging or UAT environment is a clear failure. It means the first time the software runs in realistic conditions is when real users are depending on it. Any defect that testing would have caught becomes a production incident instead. Similarly, a production system with no monitoring or alerting means nobody knows it is failing until a user picks up the phone.
A Worked Example
The specifics below are illustrative composites drawn from typical engagements.
A financial services firm engaged a supplier to build a regulatory compliance system covering FCA SYSC obligations and MiFID II transaction reporting. The contract was fixed price at £450,000, with a 12-month timeline and PRINCE2 governance specified as a contractual requirement. Eighteen months later the system was incomplete: some features worked, others functioned but did not meet operational needs, and several remained unbuilt. The relationship had broken down. The firm wanted its money back. The supplier maintained it had delivered what was specified and that the client had changed requirements throughout. Both positions had email trails supporting them.
Contract and requirements
The signed requirements document ran to 68 pages, covering 127 functional and 23 non-functional requirements — formal sign-off, clear contractual terms, the look of competent procurement. On closer reading the requirements were written in vague business language (“the system shall support compliance workflows”) that did not translate into testable specifications. The email record then showed substantial changes to core functionality throughout the project. Some were formally documented and approved. Many were agreed verbally in meetings without impact assessment. The change-control process defined in the contract was not followed. Neither party operated it.
Project management
PRINCE2 was contractually required, which committed both parties to a Project Board, stage gates, formal risk management, formal change control. None of those existed. The risk register was set up in the first month and never updated. Status reports were sporadic, and repeatedly reported “on track” when the evidence showed the project was not on track. The supplier did not escalate the divergence. The firm did not challenge the reports.
Code quality
By contrast, the code itself was professional: well-structured, unit and integration tested, sound in its security practices, following recognisable industry conventions. The architecture met the specified requirements. What had been built aligned with the requirements as written, even though the requirements themselves did not reliably describe what the firm actually needed. UAT had been conducted and signed off; the firm later requested changes to functionality it had previously accepted. These were not bug fixes but reinterpretations of vague requirements.
Client performance
The contract required the firm to provide timely access to subject matter experts and to make decisions within five working days. The email record showed access requests going unanswered for weeks at a time and decisions routinely taking three to four weeks. Where executive approval was required, delays of four to six weeks were common. The firm’s senior stakeholders rarely attended what should have been Project Board meetings, but the Project Board never formally existed for them to attend.
The assessment did not produce a clean account of failure on one side. Both parties contributed materially. On the supplier’s side: PRINCE2 was not implemented as contractually required, change control was bypassed, status reporting was misleading, escalation did not happen. On the client’s side: requirements were poorly defined, stakeholder access was unreliable, decisions were slow, verbal change requests were issued without timeline acknowledgement. The technical work itself was competent.
The financial picture mapped to this apportionment. Of the £450,000:
- ~£280,000: work delivered and functioning, though imperfectly aligned with the firm’s actual needs
- ~£90,000: cost driven by client-initiated scope changes
- ~£80,000: legitimate supplier failure to complete contracted work
With that breakdown in front of them, both parties could see what was negotiable and what was not. The case settled without litigation.
The Supplier’s Duty to Flag What It Cannot Do
The supplier carries a professional duty that goes beyond executing instructions. A competent supplier is expected to know what good delivery practice requires, and to raise it when the circumstances make it difficult or impossible. If the client will not provide access to end users for requirements gathering, the supplier’s professional obligation is to document that fact, explain the consequences in writing, and obtain the client’s acknowledgement. A supplier who does that has discharged their duty, even if the resulting requirements are poor. I would note the constraint in my report but I would not attribute the requirements failure to the supplier.
A supplier who simply assumed what users needed, without raising the access problem, is in a weak position. The failure there is not just the poor requirements but the absence of professional judgement that should have flagged the problem before work began. That distinction matters for how liability is apportioned, and it is one the evidence usually makes clear: either the concern was raised and documented, or it was not.
The same principle applies more broadly. A supplier who flags that the project timeline does not allow for adequate testing, gets the client to accept that risk in writing, and proceeds on that basis is in a different position to one who simply skipped testing without comment. The professional duty is to know what is required, raise it when it cannot be met, and document the outcome.
Forming the Opinion
When I have built the operational picture and identified the failures, I write a report that says what happened and why, in plain terms. A clear account, grounded in the evidence, of where professional practice was absent and what the consequences were. If a developer started work on a feature without any refinement session, without a clear definition of what done looked like, and the feature was delivered incomplete, I will say that. I will say who was responsible for ensuring that process existed, and whether they discharged that responsibility.
What that account produces, in most cases, is not a finding of total failure on one side. It is a map of specific failures, attributable to specific parties, with a factual basis for each. Some will sit clearly with the supplier: development that began without adequate requirements gathering, a production environment treated as a test environment, a team with no shared standards producing code nobody else can maintain. Some will sit with the client: users who were not made available, decisions that were delayed for weeks, acceptance testing that was performed as a formality.
Sometimes the picture is cleaner in either direction. Where the evidence shows the supplier systematically violated professional practice, with no substantive testing, no shared coding standards, deployments performed without procedure, or security defects from negligence, the apportionment lands clearly on one side, and the report says so. Where the evidence shows the supplier did competent professional work to the requirements as specified, and the failure sits in how those requirements were defined or in how the client engaged with delivery, the apportionment lands the other way. The methodology does not bias the answer; it follows the evidence.
An opinion is only useful to the court if it is built to the standard the court expects. My duty as an expert is to the court, not to the party instructing me, and the report reflects that. It is independent, it shows its reasoning, and it stays within my area of expertise, as the duties set out in the Ikarian Reefer judgment and CPR 35.3 require. The evidence-grounded method is what makes the opinion hold. Every finding traces to something in the record: a requirements document, a commit history, a test result, an email. So when the opposing expert tests it, or when I answer written questions under CPR 35.6 or give evidence at trial, the basis for each conclusion is already on the page. An apportionment that rests on documents survives scrutiny in a way that one resting on impression does not.
What the Assessment Achieves
The assessment serves audiences beyond the two parties in dispute. Solicitors advising on legal merit are not in a position to assess technical merit themselves; they need expert input to give that advice. The instructing party, whether claimant or defendant, often needs to explain to a board or senior management what happened and what their position is. An independent expert finding gives them a defensible account that contested narratives between the parties cannot.
In my experience, the technical assessment is where many project disputes find their resolution. Not because it decides who wins, but because it replaces each party’s version of events with a shared account of what the evidence actually shows. A client who believes the supplier is entirely to blame and discovers that their own conduct contributed materially adjusts their position. A supplier who believes their work was professionally sound and discovers a clear pattern of failures in the evidence adjusts theirs. The opinion does not decide the case, but it does create the conditions for the case to be resolved.
What to Ask in a Letter of Instruction
The instruction shapes the report, so it’s worth framing the questions in terms the assessment can actually answer. A technical assessment answers technical questions; the legal characterisation stays with you. The most useful instructions I receive ask me to address specific, answerable points rather than the broad question of who is to blame.
Questions that work well in a failed-project assessment include:
- Whether the supplier’s requirements process met the standard a competent software supplier would apply, and what the consequences of any shortfall were.
- Whether the development, testing, and deployment practices were consistent with recognised professional standards.
- Whether the project’s governance and change control operated as the contract required, and where they didn’t, what followed.
- The extent to which each party’s conduct contributed to the outcome, and on what evidence.
- Whether the delivered software met the requirements as written, and separately, whether those requirements described what the client actually needed.
Framed this way, each question maps to something I can establish from the record and defend under examination. I’m happy to discuss the scope of an instruction before it’s finalised, and to say where a question would be better answered by a different kind of expert, or isn’t capable of a technical answer at all. An early conversation about scope usually produces a tighter instruction and a more proportionate piece of work.