Why collaboration fails before projects do.
By the time a project is in trouble, the behaviour that put it there is a great deal older than the problems it is producing.
What the post-mortem misses
Post-mortems find causes near the end. Scope moved, a dependency slipped, a decision took too long. Those are real, but they are downstream of something that started much earlier and left no artefact: the point at which two groups stopped putting effort into being understood by each other.
That point rarely coincides with anything a retrospective can pin to a date. There is no meeting where collaboration formally ends. There is a slow substitution of assumption for confirmation, in which each side stops checking whether the other has the context it needs. By the time a project is visibly in trouble, that substitution is usually months old, which is exactly why it never appears in the write-up: nobody present remembers it as an event, because it was not one. A post-mortem is a search for a cause with a date attached to it, and this kind of drift does not have one.
Two teams agree a shared roadmap. In the first few weeks, each raises questions freely, because the working relationship is new enough that nothing is assumed. A few months in, the same two teams have quietly stopped asking, because asking has started to read as distrust, or simply because clarifying a small ambiguity now costs more attention than living with it seems to. Nothing about either team has failed. The habit of checking has eroded, in a direction neither side chose and neither side would defend if asked directly.
Why each side blames the other, correctly
The shape this takes is recognisable. Each group rates its own communication highly and the other group poorly, and both are describing the same events. This is not two groups reporting in bad faith. It is the fundamental attribution error operating across a boundary: the other group's delay gets explained by what they are like, where the same delay on your own side gets explained by what you were dealing with — because the circumstances behind your own are the ones you can actually see (Ross 1977). Neither group is lying. Each is collecting evidence that confirms it, because the other side's failures are the ones you notice from the outside and your own are the ones you have the context for.
There is no meeting where collaboration formally ends.
This has a second, cumulative effect beyond the finger-pointing itself. Disagreement about the work, not about people, has been shown to damage performance and satisfaction more often than the popular account of good conflict suggests (De Dreu & Weingart 2003), and misattributed friction accumulates in exactly this way: a disagreement about scope becomes, from inside either group, indistinguishable from a disagreement about competence. By the time anyone names it, the two have merged.
A second mechanism sits underneath the first. Once someone understands their own part of a problem, they reliably underestimate how much of that understanding the other side lacks (Camerer, Loewenstein & Weber 1989). A handover written by an expert routinely omits the context a non-expert would need, not from carelessness but because the expert has genuinely forgotten which parts of their own knowledge are not obvious to anyone else. The gap is not in how work is done. It is in what a piece of work is expected to carry when it crosses a boundary.
Knowledge does not travel the way documents do
Brown and Duguid argued that knowledge moves through practice and community more readily than it moves through documents (1998), which is why a handover document can be complete on paper and still fail in practice: reading a specification is not the same as having done the work it describes. And what looks like withholding is frequently structural rather than personal. People hold onto the knowledge that makes them relied upon, in organisations that offer them no other secure way of being relied upon (Davenport & Prusak 1998). Both findings point to the same conclusion. The failure is not a character problem waiting to be improved. It is a design problem in what is expected to cross the boundary, and design problems have design solutions.
This recurs at the same boundary, project after project, whoever staffs either side, for a structural reason. Conway's observation was that what an organisation builds tends to mirror how its people are grouped to communicate (1968): if the working relationship between two teams is thin, the interface between what they produce will be thin in the same place, again and again, regardless of who is standing on either side of it. Rotating people through the boundary treats a structural gap as a personnel problem, which is a reasonable first guess and usually why it does not close the gap for long.
This is easiest to see across many projects rather than one. The same interface, between sales and delivery, say, or between product and engineering, fails in a similar shape each time, regardless of who currently sits in either seat. When the same failure recurs across different people, the explanation is very rarely that the organisation keeps hiring the same kind of difficult colleague twice. It is that nobody has changed the thing the boundary is actually carrying.
The fix is a definition
This is unusually tractable, because the fix is a definition rather than a reorganisation. Agreeing explicitly what a handover must carry, meaning context, constraint, open question and named owner, leaves how each group works internally untouched. Neither side has to adopt the other's process, or trust the other's judgement any more than it already does. It only has to agree, once, on what a piece of work owes the next person who touches it.
That agreement, once made, tends to outlast the people who made it, which is not true of most fixes to this kind of problem. Rebuilding trust between two groups has to be redone whenever the people change. A definition of what a handover carries survives the turnover, because it was never attached to the individuals in the first place. It changes nothing about who does what — only what travels between them.
The obvious limit is that a definition only binds where somebody checks it. Agreeing what a handover carries and then never looking at whether it did is a familiar way of appearing to have fixed something.
It is a low-trust intervention, deliberately: it does not ask either group to believe the other is well-intentioned, only to agree on what a specific artefact contains before it moves. That is a lower bar than repairing a relationship, which is the main argument for trying it before anything more ambitious.
The research library lists the published work this draws on.