“I thought you were preparing the test data.” “And I thought you were, it’s your system after all.” It’s Tuesday, testing was supposed to start on Monday, and two people are looking at each other with genuine surprise. Neither of them is lying. Each has been certain for three weeks that this one sat on the other side.
Conversations like this rarely concern big tasks. Big tasks have owners, deadlines and a place on the board. What falls through is the thing in between: a small activity at the seam between two roles that nobody named, because it seemed obvious to everyone.
Four seams where it happens
The places where two people each assume the thing belongs to the other repeat from project to project.
Analyst and developer. A requirement turns out to be unclear in the middle of the work. The developer assumes the analyst will go back to the client. The analyst assumes that since nobody came back with a question, everything is understood.
Developer and tester. Someone has to prepare the data and the environment for testing. The developer sees it as part of testing, the tester as part of handing the work over.
Project team and operations. Someone has to write the manual and hand over access. The project assumes operations will ask for what they need. Operations assume they will get the full set together with the system.
PM and sponsor. Someone has to tell the users that from Monday they work differently. The PM thinks it’s a company announcement, so it belongs to the sponsor. The sponsor thinks it’s part of the rollout, so it belongs to the project.
In each of these pairs both sides have a reasonable basis for thinking the way they do.
Why nobody is to blame here
Every role description ends at its own border. The developer is responsible for the code, the tester for the tests, the analyst for the requirements. No description says who is responsible for what happens between them.
As long as two people have worked together for years, habit fills that gap. In a new team, with a new supplier, or after one person changes, the habit is gone and the gap stays empty. Nobody sees it, because everyone looks at their own part and sees it as done.
Looking for someone to blame afterwards fixes nothing. Both people did their job, and the task belonged to neither of them. It is the same mechanism that makes things fall through the cracks, only seen from the inside of the team.
How to close a seam before it costs you a deadline
In my experience three simple habits are enough, and none of them needs a new tool.
A list of the “in between” things at the start. At the first team meeting, next to scope and dates, it is worth walking through the seams and asking one question at each: what has to happen for the work to pass from one pair of hands to the other? Test data, a manual, access, an announcement to users. Each of these gets a name next to it.
The handover said out loud. “I’m handing this to you” and “I’ve got it” sound artificial only for the first week. After that the team notices on its own that a thing nobody accepted is still hanging in the air.
A control question for every task on a seam. Who will be the first to notice if this isn’t there? If the answer is “the client” or “a user on launch day”, the task needs an owner today.
These habits don’t remove every gap. What they do is shorten the time it takes a gap to surface, from three weeks to one meeting. They work inside the team the same way that named channels work between the team and the client.
What to do when the sentence has already been said
If “I thought that was yours” has just been spoken, the worst thing you can do is work out who was right. It is better to ask two questions. Who takes it now? Where else in this project do we have the same kind of seam?
The second question matters more. A gap that showed up once usually has sisters elsewhere in the same project.
One question for this week
Pick one seam in your project, for example between the team and operations. Ask both sides separately what is supposed to happen at the handover and who does it. Did you hear two identical answers?
All situations described in this article are based on real events, but contain no company names, no individual names, and no data from any specific project.
