I’m Krzysztof Nyrek
a Project Manager Storyteller Writer

The Last Time Something Fell Through the Cracks: Who Caught It, and How

“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.

Every Project Runs a Different Way, Depending on Who Runs It

“So where do you record decisions here?” That’s the question a developer asks after moving on Monday from one project to another in the same company. In the old project, decisions landed in a note after every meeting. In the new one, nobody can give him an answer, because decisions live in email threads, on the board and in the PM’s head, depending on who remembers what.

Nobody neglected anything here. Both projects are run by good PMs. Each of them simply runs it their own way.

Variety that looks like freedom

In many companies, differences between projects are treated as natural, sometimes even as an advantage. Every PM has their own style, every project is different, a rigid procedure would kill flexibility. All of this is partly true.

The problem is that the cost of this variety doesn’t fall on the PM who creates it. It falls on everyone around them.

Who pays for everyone doing it their own way

People who move between projects. A developer, tester or analyst working on two projects at once has to remember two sets of rules: where the current scope lives, how a change is raised, who signs off. Every switch costs a few days of learning things that have nothing to do with the work itself.

The sponsor who reads several status reports. If amber means “we have a problem, but we’re handling it” in one project and “we need your decision this week” in another, the sponsor is comparing things that can’t be compared. Usually without knowing it, so they react to the colour rather than the situation.

The PM’s successor. When a PM leaves or moves to another project, their way of running it leaves with them. The successor gets a project in which half the knowledge of how things work was never written down, because it didn’t need to be. Everyone knew how the predecessor did it.

It’s not about one methodology for everyone

The reflex response to this problem is a single mandatory methodology and a thick handbook. That usually ends with PMs filling in the handbook for show while carrying on their own way, only now also in secret.

What works better is a short list of things that must be the same in every project, plus a clear statement that everything else stays in the PM’s hands. The list should be short enough to remember.

What has to be shared

In my experience, five things are enough.

1. What green, amber and red mean. One definition for the whole company, ideally described by what the status requires from the reader, not by how bad things are. It’s the same idea behind a sponsor update built on status, consequence, options and recommendation.
2. Where decisions are recorded. One place per project, in the same format in every project. A new person should know where to look before they have to ask. A meeting can write its own action list, but only if everyone knows where that list lives.
3. How risk is escalated. When the PM decides alone, when they go to the sponsor, and how quickly they expect an answer.
4. How a scope change is raised. It doesn’t have to be a form. It has to be clear that a change doesn’t enter the project as a sentence dropped in a meeting.
5. What “stage complete” means. How we know we can move on, and who confirms it.

Everything else, meaning the meeting rhythm, the tools, the planning approach, the style of working with the team, can differ. That’s where differences genuinely come from the project and the people.

A simple test

Take someone from one project and sit them in another for an hour. After that hour, ask whether they know where the decisions are, what the current status is and who to go to with a problem. If they don’t, the differences between projects have stopped being style and have become a risk.

One question for this week

If someone took over your project tomorrow, what would you have to explain to them because you never wrote it down? The first thing that comes to mind is the best candidate to write down this week.

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.

Zero-Based PMO: What Happens When You Stop Optimizing and Start Over

“We send this report because we’ve always sent it.” That is the honest answer to the question of why roughly half of what the PMO asks of project managers exists at all. Nobody says it out loud, but every PM who has filled in the same template in three versions for three audiences knows that sentence.

A PMO is rarely built in one go. It grows in layers. One project went off the rails, so a new review was added. The board once asked for a summary, so the summary became permanent. A new director brought their own template, and nobody switched off the old one. A few years later you have a structure in which every element once had a good reason, only nobody remembers what it was.

Optimization won’t help

The typical response to an overloaded PMO is optimization. We cut the template from twelve pages to eight. We merge two meetings into one. We automate the data collection for the report. All of this is reasonable, and all of it assumes that the element should exist in the first place.

The zero-based approach flips the question. You don’t ask “how do we make this report faster?” but “if we were building the PMO from a blank page today, would this report exist?” If the answer is no, optimizing it is work put into something you don’t need.

It’s the same logic as zero-based budgeting: every line has to justify itself today, not because it was in last year’s budget.

Three questions for every element

Take any element of the PMO’s work: a report, a gate, a template, a weekly meeting. Ask it three questions.

Who reads it and what do they do with it? Not “who receives it”, but who actually reads it. A report sent to fifteen people, none of whom has replied in a quarter, has zero readers in practice.

What decision does it feed? Every PMO element should, at some point, lead to a decision: let the project continue, add people, shift a priority, close it. If you can’t point to the decision this element feeds, it is an archive, not a management tool.

What happens if it disappears for a month? This is the simplest test and the most painful one. If nobody asks where the report is after a month without it, you have your answer.

What usually goes first

In my experience, three kinds of things drop out fastest in a review like this.

The first is duplicated reports. The same project status described three times, in three formats, for three audiences who in practice sit on the same committee. One version is enough, if it’s a good one.

The second is gates without decisions. A stage review where nobody has ever stopped a project isn’t a gate, it’s a ritual. The project always passes, so its only effect is a week of preparation.

The third is templates filled in for the template’s sake. Fields the PM completes because they’re mandatory, not because anyone needs the information. You’ll recognize them because they have held the same content, copied from the previous project, for years.

What stays

After a reset like this, surprisingly little remains, but what remains is solid. One place where you can see all projects and their priorities relative to each other, which is exactly where the priority gap between the PMO and the board becomes visible. A clear risk escalation path, meaning everyone knows who decides and how fast. A few decision points where a project can genuinely be stopped. A shared definition of what green, amber and red mean.

The rest are things that may exist, but don’t have to. It’s good if someone checks from time to time whether they still have to.

What if you’re not the head of the PMO?

Most PMs don’t have the authority to rebuild the PMO. They do have authority over their own project, and projects grow layers too. A meeting that once made sense. A spreadsheet you keep alongside the tool. A status you write for someone who no longer works on the project.

Walk through your project with the same three questions. Who reads it, what decision does it feed, what happens if it disappears. Whatever you throw out gives you time back. Whatever you can’t throw out because the PMO requires it, write down. It’s one of the small moves that separates a PM who administers from a PM who thinks strategically: if someone ever asks what in the PMO gets in the way of projects, you’ll have a list instead of an impression.

One question for this week

Which report or meeting in your project exists only because it has always existed? Try not doing it this week and see whether anyone notices.

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.