“I thought that went out last week.” That’s how the conversation about a lost item usually starts. The contract never reached the client, the new person’s access was never set up, the fix didn’t make it into the release. Nobody blocked it and nobody forgot on purpose. At some point it simply stopped belonging to anyone.
A lot has been written about why things get lost. I’m more interested in the second question: who found it, and how. In most projects lost tasks do eventually turn up. The only question is whether it’s a week after the deadline or the day before.
Where things get lost most often
Before we get to catching, a short catalogue of the places where tasks disappear. There’s nothing spectacular in it, and that’s exactly why it’s so hard to watch.
“I’ll send it after the meeting”, said by two people at once. Each assumes the other will send it. If this sounds familiar, it’s the same mechanism behind commitments that evaporate a week after the standup.
A forwarded email as delegation. Someone forwards a message with “can you take a look?”. The sender thinks they’ve handed over a task, the recipient thinks they’ve received information.
A task assigned to a team, not a person. The board says “backend” or “legal”. Everyone can see it, so nobody feels it’s theirs.
Holidays without a handover. Someone leaves for two weeks, their items wait in the inbox, and the project assumes they’re moving.
An agreement made in the corridor. Something was promised over coffee and never made it to where the project keeps its tasks.
The “waiting for” loop. A task is stuck because it’s waiting for an answer from someone outside the team. Nobody checks whether the answer arrived, because the ball is in the other court, after all.
Who usually catches it
If you asked teams who caught the last lost item, the answer is rarely “the tool”. Usually a person catches it, and usually by accident.
A tester preparing an environment who notices an access is missing. A client asking where the document is. A sponsor asking at a review about something everyone forgot. A new team member reading the notes from the beginning and asking about an item with no owner.
That’s good news and bad news at the same time. Good, because people on a project have a natural habit of checking. Bad, because that habit works by chance. If the client is asking about the document, the lost item has already left the team, and that is the most expensive place to find it. It’s also how status reports stay green right up until they turn red.
Planned catching instead of accidental catching
Since we know where things get lost, we can put someone there to catch them on purpose. You don’t need a new system for that, just a few fixed moments.
A name instead of a team. Every task has one person, even if several people work on it. That one person doesn’t have to do everything, they just have to know whether it’s done.
A “waiting for” list reviewed once a week. Everything stuck waiting for someone outside goes on a separate list. Once a week someone goes through it and asks: did it arrive or not? If not, who’s making the call?
A handover before holidays as a planned step. Not a courtesy, a fixed element: before every longer absence, fifteen minutes for a list of open items and the name of the person taking them over.
The corridor goes into the notes. If something was agreed outside a meeting, the person who agreed it adds it to wherever the tasks live. One sentence is enough.
None of these moments is difficult. The only difficult part is making someone feel responsible for them. In most projects that person will be the PM, and that’s fine, because the PM is the one who hears about the lost item first, or last, anyway.
One question for this week
Think back to the last thing that fell through the cracks in your project. Who caught it? If it was the client or the sponsor, think about which of the places in this article it got lost in, and set up one fixed catching moment there.
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.
