Software delivery project failure and PII: the claim patterns UK IT consultants face

~5 min read

Reviewed by Matthew Bartlett, Director · Last reviewed 2026-07-06

Software and IT delivery projects fail at a much higher rate than is generally reported publicly. Industry surveys have consistently found that 30-50% of substantial IT projects miss their initial scope, budget or timeline by significant margins, and around 10-20% fail outright — abandoned, replaced, or delivered without meeting the business case. Not every failed project generates a professional indemnity claim, but a meaningful subset does. Understanding the claim patterns that emerge from failed delivery is central to how IT consultancy PII is underwritten and defended. This entry sets out the common claim types, the file discipline that helps defend them, and how insurers assess project-failure exposure at proposal stage.

The typical failed-project claim

A failed IT project claim usually arises after the client has terminated the engagement, replaced the consultant, or attempted to salvage a partially-delivered solution at additional cost. The client's claim typically alleges some combination of the following: the consultant failed to deliver against the agreed specification; the consultant failed to complete within the agreed budget; the consultant delivered a system that fails to meet acceptance criteria in operation; the consultant provided negligent advice on scope, technology choice, or delivery approach; and the consultant failed to warn the client about risks it should have identified.

The quantum is typically claimed as the difference between what the client paid the consultant and what a competent consultant would have delivered — plus, in serious cases, downstream losses (business interruption, replacement supplier costs, reputational damage). Quanta can be substantial. A £400,000 delivery that fails and is replaced at £700,000 with additional business interruption of £300,000 gives a £1 million claim head.

What tends to trigger a claim

Four scenarios trigger claims disproportionately.

First, scope creep without formal change control. Where a project's scope expanded during delivery without a documented change request process, the client can later argue that the additional work was always within the original scope and the consultant's charging or delivery was excessive.

Second, missed acceptance criteria. Where a system fails to meet stated acceptance criteria in user acceptance testing or production operation, the client's claim head is clear and quantifiable.

Third, technology choice failure. Where the consultant recommended a technology stack (a specific platform, a specific database, a specific integration pattern) that turned out to be unsuitable for the client's needs, the client can argue the recommendation was negligent — with claim quanta reflecting the cost of the replacement.

Fourth, delivery methodology failure. Where the consultant applied a delivery methodology (waterfall, agile, iterative) unsuited to the client's requirements or team capability, the client can argue the methodology choice itself was negligent.

Contract terms as the primary defence

The single most important defence in a failed-project claim is the contract. Consultancies that operate under well-drafted contracts with clear scope, defined acceptance criteria, structured change control, limitation-of-liability provisions, and defined exit terms are materially better positioned than those without.

Specific contract provisions that recur as claim defences include limitation of liability capped at fee value or 12 months' fees; exclusion of consequential loss; defined acceptance testing procedures and time-limited acceptance windows; and jurisdictional and governing-law provisions that fix the forum for dispute resolution.

Consultancies with a standard master services agreement and disciplined use of statements of work face materially fewer claims than consultancies that operate on ad hoc engagement terms.

File discipline as the secondary defence

Where a claim proceeds, the consultant's contemporaneous file becomes the primary evidence. Well-disciplined files typically include: the initial engagement letter or statement of work with agreed scope; documented change requests and change-order acceptances during delivery; documented risk registers with client acknowledgment of specific risks; project status reports with client sign-off; documented acceptance criteria and acceptance testing results; and email records confirming key decisions and instructions.

Consultancies whose files are complete and contemporaneous defend claims far more effectively than those whose files are patchy. Files reconstructed retrospectively after a claim has been intimated are of materially less evidential value than contemporaneous ones — and insurers scrutinise file quality at proposal stage.

How insurers assess project-failure exposure

IT consultancy PII underwriters focus on four questions.

First, contract discipline — does the firm use standard master agreements and statements of work, and does it enforce them?

Second, project size — what is the largest single project the firm has delivered, and what is the largest currently in delivery? PII exposure scales with project value.

Third, project failure history — has the firm had a claim or notification arising from a failed delivery in the last six years? If so, what has changed?

Fourth, delivery methodology — does the firm operate a documented delivery methodology, or is delivery ad hoc? Documented methodologies signal professional maturity even where they are not directly relevant to a specific claim.

Aggregation on multi-workstream projects

Large IT projects often run as multiple workstreams — a data workstream, an integration workstream, a UX workstream, an infrastructure workstream. Where multiple workstreams fail related to a common underlying issue (unrealistic scope, inadequate architecture, mismatched technology choice), claims from the client can aggregate under the wording. Whether related workstream failures count as one claim or many for each-and-every limit purposes depends on the aggregation wording — a question worth confirming at renewal for consultancies engaged on multi-workstream schemes.

Worked example

Illustrative only. An eight-consultant firm delivering a £750,000 core-system replacement for a mid-market client under a fixed-price statement of work. During delivery, scope expanded significantly through informal client requests without formal change orders. The project overran by six months and £200,000. Client terminated on cause after the delayed go-live failed user acceptance testing. Client claimed £850,000 (return of fees plus replacement supplier costs). Consultant's defence: the standard MSA contained a limitation of liability capped at 12 months' fees (£450,000), the SoW contained defined acceptance criteria, and the file included contemporaneous email records documenting client requests and consultant warnings. Settlement at £275,000, materially below the claim head. PII responded to the settlement and defence costs. Insurer's post-claim proposal-form question at next renewal focused on scope-change discipline going forward.