A vendor post-mortem usually has one roster. The client's people sit for interviews, the supplier's weekly reports get read, and what comes out is fluent, internally consistent, and built almost entirely from one party's memory of a contract that bound two. It reads like a case for the prosecution because that is structurally what it is. Nobody set out to write one. The evidence base simply had one side of the room in it.
A European banking group's IT services subsidiary had outsourced the first phase of a new web application to an external development supplier. The build ran into quality trouble and then schedule trouble, the work was brought back in house unfinished, and an independent review was commissioned to establish what had happened. What is worth publishing is not what it concluded but how the evidence was gathered, because the gathering design decides whether a review can be believed by the party it criticises.
The challenge
Three questions sat at the front of the report. Whether it was wise to outsource this particular piece of work at all. Whether the delivery model was the right one. Whether the over-run was justifiable, commercially and technically.
Not one of those can be answered from a single roster. Whether outsourcing was wise is a question about a decision taken before the delivery team existed, by people who may no longer hold the role. Whether the over-run was justifiable is a question about what the supplier was asked for and what it believed it had agreed to, which lives in the supplier's estimating and its internal escalations, not in the client's frustration.
The contract made the same point on its own. Obligations ran in both directions: the client committed a project manager, business analysts, a system architect and technical application managers of its own to the joint team, and the supplier committed a planned headcount with an agreed ramp above it. A review that samples one signatory's memory can assess one side's compliance and can only infer the other's.
The approach
The interview list was mirrored. On the client side: the director of sourcing, the head of the sponsoring business area, the project manager, the technical architect, the technical application manager. On the supplier side: the technical lead, the technical architect, the delivery manager, the relationship manager, the project manager, the business analyst, the testing manager and a developer. Architect against architect. Project manager against project manager. The supplier's testing manager had no opposite number on the client list, because what the client had committed to the joint team was project management, analysis and architecture, so that interview stood on its own.
That pairing is the whole instrument. When two people holding the same job on opposite sides of a contract describe the same fortnight differently, the difference is the finding, and it is invisible if only one of them was booked. A single-roster review does not report a smaller version of that difference. It reports none of it, and reports what remains as though nothing contradicted it.
Then the part that took the most effort for the least obvious return. The sourcing director who had already left the role was interviewed alongside the one who held it. One of the three questions was whether outsourcing this work had been wise at all, and that question reaches back before the delivery team existed, into a period whoever holds the role today may have had no part in. Interviewing only the incumbent produces a clean and entirely sincere account, and nothing in the transcript shows what is missing from it. The predecessor came out of the project's own governance record, which set out the committees and the approved decision makers, rather than out of the current org chart.
Documents were read in pairs rather than in sequence. Both parties filed weekly progress reports throughout the build, and the two sets were read against each other rather than the client's first and the supplier's as a check. Sequence produces a chronology. Parallel produces the months where two accounts of one project stop agreeing, which is where the questions come from.
That is exactly what happened. A client-side account of how status was reported prompted a month-by-month analysis of both parties' ratings across the build, and that analysis set the line of questioning for the supplier's project manager. The working finding it produced was that the two parties did not share a definition of what a red status meant, nor of the degrees of severity beneath it. Neither roster contains that on its own. It exists only in the comparison, and the comparison only exists because someone scheduled both interviews.
Attribution ran on the same principle. Every interview summary naming the person it came from was held out of the draft until that individual approved their own account. That is slower, and it is the only way to write a report the people quoted in it will stand behind rather than dispute, which matters when half of them have no obligation to cooperate at all.
The whole design was scoped into five weeks: a week to prepare and request documents, two weeks of interviews and diagnosis, a week of analysis and findings workshops against a checkpoint, a final week to report. The plan said in writing that the five weeks might have to be extended depending on stakeholder availability, which is the honest name for the pressure. The second roster is always the one that gets cut when time runs short, because its cooperation has to be negotiated rather than instructed. Symmetry is a scheduling decision taken in week one, or it is not taken.
The outcome
What this engagement produced was a draft report of findings and recommendations. Not a recovered project, and not a verdict. The status definitions it put forward were aimed forward rather than backward: a template for both parties to agree up front on the next engagement, not a ruling on whose ratings had been right on this one. Where a recommendation points is most of the difference between a review and a case.
Two findings show what the symmetry bought. Escalation had been called early and rightly, and hearing both sides suggested that calling it early may also have made the supplier more hesitant about admitting timeline trouble later. And the supplier volunteered that it should have spent more time training its team on the unfamiliar development framework before starting to build. Neither reaches the page from one roster. The first needs a party willing to say a correct action carried a cost. The second needs a party willing to give evidence against itself, which people do more readily once they believe the review is not a case being built against them.
What would be done differently now is worth saying plainly. Some of the analysis above was hand-built from documents, and most of that material is machine-readable at source today: issue trackers, change logs, defect logs, commit history and build records are all events with timestamps and authors. Process mining over those events rebuilds the month-by-month picture with a record attached to every step, and does it for both parties at once, because the supplier's tickets and the client's sit in the same system. Lineage from a finding back to its record is the part worth paying for. The Platform work we do starts there, because a finding nobody can trace back to a record is an opinion with a chart on it.
Interview evidence is heading the same way. Transcription is cheap, and the cautious language-model pilots our clients are running this year already summarise a long conversation well enough for a first pass. The cost of getting the second side's testimony into the record is falling toward nothing. What does not fall is the decision to go and get it. No pipeline will tell you your roster has one side on it, because a one-sided corpus looks complete from the inside: consistent, well sourced, fully cross-referenced, and wrong in a way that leaves no trace in the data. Our Consult engagements start by listing who is missing before listing what is known.
The interview that cost the most here was the one with the person who had left the role. Nothing in a document store flags that the author of a decision is no longer its owner. That is still a human noticing that the org chart in front of them is the current one, and the decision under review was taken against a different one.