Why Your Supplier Health Check Stops One Layer Above the Code

A post-mortem review I worked on for a European banking group's IT services subsidiary condensed itself onto a single summary page. Three columns, one per assessed dimension. Thirteen numbered sub-findings distributed across them, three under delivery approach, four under project management, six technical. After each finding, in square brackets, the party that owned it. A three-level rating legend was printed on the page: requires intervention, concerns, satisfactory.

Read across, it is a competent failure summary of a terminated offshore build. Read down, it is something more useful to anybody currently running a supplier they are worried about, because the page has a gradient in it. The higher up the relationship a finding sits, the better the language gets.

Two grammars on one page

The column headers say it before any of the findings do. The delivery approach column is headed with a straight failure: it failed on quality, experience and depth. The technical column is headed the same way, that the software is poor and difficult to maintain. The project management column is headed differently. It says that while the project controls were in place, the project management and planning struggled with delivery.

That middle header is the interesting one, because it is the only header that has to concede something before it can say anything. It reports a presence and then reports an effect, and the two point in opposite directions.

Follow the delivery approach column from top to bottom and the same shift happens inside a single column. The first finding is that supplier relationship management was done well at senior management level, however delivery did not succeed in reciprocating. The second is that the statement of work and contract were in place, but lacked the measures needed to enforce pre-selection on quality, experience and depth. The third is that the quality of delivery remained poor throughout, and that a lack of capability and depth created a backlog the vendor was never able to recover.

Three sentences, descending. The first two are written as presences with a qualifier attached. The third is written as an outcome with no presence to soften it. The page is not being inconsistent. It is reporting honestly on instruments that measured different things at different heights.

The one finding that named the client alone

Count the brackets and a second pattern appears.

Across all thirteen findings, the vendor is named in twelve. The client is named in six. In the six technical findings, which are the ones describing what the software actually did, the client does not appear once. Every technical finding is attributed to the vendor alone.

Exactly one finding, out of thirteen, names the client and no other party. It is the first one in the first column: relationship management was done well at senior level, delivery did not reciprocate.

That is the review's own attribution, and it is defensible. The vendor wrote the code, so the code findings are the vendor's. What follows from it is my reading rather than the page's. The only thing the client owned outright, by the review's own allocation, was the layer that read healthy. Every control function the client could name, sourcing, governance, project control, appears in the upper two columns and nowhere else. The client's instruments and the client's attributions occupy the same two-thirds of the page, and the failures occupy the bottom third.

Supplier Relationship Management was done well at a senior management level, however delivery did not succeed in reciprocating.

The same seam, broken in both directions

Two of the thirteen findings carry a split at function level rather than a shared tag, and both sit in the project management column.

One says that project management and planning were in place but not sufficient to meet delivery goals, and splits it between the client's control function and the vendor's planning and execution. The other says that governance measures were taken but there was a clear gap between senior level escalations and execution level to resolve them, and splits it between the client's governance function and the vendor's execution.

Both of those describe one interface. On one side, senior people raising things. On the other, the people holding the keyboards. The review found that interface failing downward: an escalation reached the senior layer and did not convert into resolution at the execution layer. The first finding in the deck describes the same interface failing upward: the senior layer was in good health and the delivery floor was not, and the senior layer's reading did not update.

A seam that leaks in both directions is not a diligence problem. Nobody in this engagement was idle. It is a routing problem, and routing problems are invisible to any instrument sitting on one side of the seam and asking that side how it is doing.

The commercial layer of the same engagement failed in a related way, which I have written up separately in Do Not Bridge a 1,000 Versus 2,500 Person-Day Gap With a Profit-Share Clause.

Why the top layer keeps reporting well

The senior relationship is the only layer of a supplier engagement that both parties produce jointly and both parties want to survive. It is the layer that gets renewed. It also happens to be the layer that is easiest to evidence: meetings held, escalations raised, contract signed, governance forum convened, minutes filed.

Every one of those is a presence reading, and every presence reading in this engagement came back positive. Controls in place. Contract in place. Governance measures taken. Relationship management done well. None of that was false, and none of it touched the question of whether the software worked.

So the honest description of the gradient is not that senior people were told a comfortable story. It is that senior people were given an accurate answer to a question about the relationship, and were reading it as an answer to a question about the build.

The measurement to add, and the harder half

The instrument half of the fix is now cheap and I will not pretend otherwise. Test coverage, authorisation findings from a security scan, design-principle breaches, performance behaviour under load: all of that can be produced by the build itself, on every build, without asking anyone how they think it is going.

The harder half is the route. A code-level signal that is collected by the delivery team, summarised by the account lead and presented at the steering forum has travelled through the exact layer it was built to bypass. Four rules make the difference.

Emit the signal from the build, not from a person. If a human assembles it, the assembly is the filter.

Deliver it into the governance pack unmediated, with both parties reading identical numbers, and give nobody in the account relationship the right to reword it before it lands.

Give every escalation a named owner at the execution layer and a resolution clock measured at that layer. The governance finding in this review was not that escalations went unraised. It was that raising them at the top did not produce resolution at the bottom, which is a question about who catches the escalation, not about who throws it.

Keep reporting relationship health, and keep it in a separate field. It is genuine information about whether the commercial arrangement will survive. It is not information about the software, and the failure mode here was one number being asked to carry both.

13

Numbered sub-findings on one summary page

12 of 13

Findings naming the vendor

6 of 13

Findings naming the client at all

0 of 6

Technical findings naming the client

There is a 2026 version of this gradient and it has new vocabulary. The relationship layer now hosts claims like our platform handles quality, or the agents generate the tests. Those are unfalsifiable at the layer where they are asserted and entirely checkable at the layer where the code lands, which is the same asymmetry this page recorded a decade earlier in different words.

Agentic delivery also makes presence controls cheaper to satisfy than they have ever been. A coding standard, a design document, a test suite: each of those can now be produced quickly and look complete. Presence readings will inflate. The distance between what is present and what works is going to widen, not narrow, which is precisely why the signal worth routing upward is the one measuring effect.

Drawn from the summary findings page of an independent post-mortem review of a failed offshore application build at a European banking group's IT services subsidiary, commissioned after the statement of work was terminated. That review produced findings and recommendations, not a recovered project. The finding counts and attribution tags are the page's own. No rating levels are reported here, because each finding's rating is carried as colour on the page rather than in its text. Reading the page as a picture of where the client's instruments stopped is ours.