When Everyone Has a Different Version of the Truth

Most PM writing assumes a clean stakeholder model: one client, one team, one shared understanding of what has been agreed. The reality of multi-party projects - two or more technical organisations working toward the same deliverable for a shared client - is messier. Not because anyone is dishonest, but because each organisation has incomplete information about the other, different incentives about what to emphasise, and genuine differences in what they believe the agreement said.

When those differences surface - and they always surface, usually at the worst moment - the PM's job is not to pick a side, not to mediate between competing narratives, and certainly not to let the client hear two contradictory accounts and draw their own conclusion. The job is to find out what is actually true and establish it as the shared record before anyone communicates anything.

That sounds obvious. In practice, it requires a specific discipline: the willingness to bypass everyone's account of events and go directly to the primary source. Not the meeting notes. Not the other team's status update. Not your own team's version of what was delivered. The production system. The transcript. The SOW against the actual work log. The code against the spec. Primary sources do not have a perspective. They just are what they are.

The natural response to a disputed delivery is for each party to present their case. Team A sends an update saying they built what was agreed. Team B sends a rebuttal saying they did not. The client, who cannot independently verify either account, is now managing a dispute rather than a project. Whichever party makes a more compelling case wins - not because they were right, but because they were more convincing.

This is the worst possible outcome for a PM in the middle. If your organisation wins the argument, the other team's relationship with the client is damaged and the project becomes adversarial. If your organisation loses the argument despite being right, you have been misrepresented and have no way to recover. If the client stays neutral, the project stalls while everyone waits for the dispute to resolve.

The claims-and-counter-claims approach also has a compounding problem: once a dispute enters the claim-and-counter-claim cycle, every subsequent communication is read through the lens of the dispute. An update from Team A is read as advocacy, not information. A question from the client is read as suspicion, not curiosity. Trust corrodes quickly and takes a long time to rebuild.

The only way to break the cycle early is to replace both parties' claims with something that neither party produced and neither party can dispute: verified evidence from a source that predates the dispute.

On a project I managed where two technical teams had conflicting accounts of what had been delivered - one team claiming the other had not built what was agreed, the other team asserting they had demonstrated it weeks earlier - I had roughly 48 hours before a client call where both teams would be present.

The instinct was to ask my own team for their account, compare it to the other team's account, and synthesise a position. I did not do that. Instead I went directly into the production API and tested every claim that was in dispute. The system under dispute was a regulatory compliance engine that was supposed to return one of three outcome states - Allow, Deny, or Defer - when processing a clinical event. The claim from one team was that the other had not delivered on these outcomes. I ran all three fixtures against the live production endpoint myself.

All three returned verified decisions with production timestamps and decision IDs. The claim of non-delivery was factually incorrect, and now there was evidence - produced by me, from the production system, with specific identifiers - that nobody could dispute. Not because I said so, but because the system said so.

I also found two genuine discrepancies in my own team's documentation during the same testing session - evidence fields missing from the fixture document, a count that did not match the live API response. I flagged those too, immediately and proactively, in the same communication. Not to undermine my own team. To demonstrate that the goal was accuracy, not advocacy. That distinction matters enormously in a dispute.

What primary sources look like in practice

• For delivery disputes: The production system. Test it yourself. Production timestamps, response payloads, and decision IDs are unimpeachable in a way that meeting notes and status updates are not.
• For scope disputes: The original SOW against the actual work log, not either party's summary of what the SOW said. Line by line. Every discrepancy documented with the specific clause and the specific deviation.
• For timeline disputes: Meeting transcripts, not meeting summaries. A summary is someone's interpretation. A transcript is what was actually said, with timestamps and speakers attributed.
• For commitment disputes: The original written communications - emails, Slack messages, the decision log if one exists. The phrase "I think we agreed on the call" should never close a multi-party dispute. The call recording or the follow-up email should.

Evidence alone is not enough. The second move in a multi-party truth problem is to establish a shared record going forward - a single authoritative source that all parties reference so that the next dispute has a paper trail to resolve against.

On the project described above, that meant producing formal Minutes of Meeting documents from every call - grounded strictly in the transcript, with no inference, no embellishment, and every unresolved item explicitly flagged. The format was specific: a header block, Key Decisions, Action Items with owner/due/details fields, an Ownership Summary, and Unresolved items. Every action item named, owned, and dated. The discipline was absolute: if it was not in the transcript, it was not in the minutes.

The MoM documents served two functions. Immediately, they gave all three parties a single written record of what had been said, decided, and committed to - replacing three different memories of the same call with one shared document. Over time, they created a paper trail that made subsequent disputes faster to resolve because the answer to "what did we agree?" was a link to a document, not a conversation.

The SOW discrepancy analysis followed the same principle. Six discrepancies between the proposed Phase 2.2 SOW and the meeting record, documented with specific clause references and severity ratings. The goal was not to torpedo the SOW. It was to surface the gaps before anyone signed something that contained commitments that were already contradicted by the meeting record. A signed SOW with internal contradictions is not a contract - it is a future dispute waiting to happen.

Once you have evidence and a shared record in place, the communication challenge is different from what most people expect. The temptation - especially when your own organisation has been wrongly accused of something - is to lead with the evidence that proves the accusation wrong. That is still the wrong move. It frames the communication as a rebuttal, which means the recipient reads it as advocacy and discounts it accordingly.

The right framing is: here is what we verified, here is what we found, here is what needs to happen next. The evidence comes first, before any interpretation. The gaps - including your own team's gaps - come in the same communication. The next steps are framed as a joint effort to establish clarity, not as a demand for the other party to acknowledge they were wrong.

In practice this means: share the production test results with the decision IDs. Share the fixture documentation gaps you found in your own team's work. Note the transcript reference where the disputed demo occurred. Propose the Thursday call agenda as a shared working session to establish ground truth, not as a verdict delivery. The client - and the other technical party - can then draw their own conclusions from evidence that nobody produced and nobody curated.

The tone that works in multi-party disputes is not warm and not cold. It is precise. Precise about what was tested, what was found, what is still unresolved, and what needs a decision before the project can move forward. Precision is the signal that the goal is resolution, not victory.

The specific situation described above - a regulatory compliance platform with a three-party delivery breakdown - is unusual. The underlying pattern is not. Any project with two or more technical organisations working toward a shared deliverable will eventually hit a moment where the parties have different accounts of what has been agreed, what has been built, or what has been committed to. The pattern is structural, not coincidental.

The transferable principle is: when a multi-party dispute arises, stop collecting accounts and start collecting evidence. The accounts will reflect each party's interests and incomplete information. The evidence will reflect what is actually true. The sooner you replace the former with the latter, the shorter the dispute.

Three practical moves that work across most variations of the pattern:

• Test before you communicate: If the dispute is about whether something works, test it yourself before speaking to either party. Your test result is evidence. Their claim is testimony. Evidence closes disputes faster.
• Surface your own gaps in the same breath: If you find problems with the other party's account, find problems with your own too. Proactively. In the same communication. This signals that you are pursuing accuracy, not defending a position, which changes how the other party receives everything else you say.
• Build the record going forward, not retroactively: Formal minutes, decision logs, and written commitments are not bureaucracy. They are the infrastructure that makes the next dispute shorter. Every project that produces a shared written record from the start has fewer disputes and faster resolutions than the ones that document after the fact.

The multi-party truth problem is one of the situations where the PM's role is most clearly defined and most clearly valuable. When two technical teams are presenting competing accounts of reality to a shared client, someone has to find the truth. In the absence of a PM doing that job deliberately, the client will find the truth eventually - but later, more expensively, and with more damage to the working relationships on both sides.