I’m Krzysztof Nyrek
a Project Manager Storyteller Writer

The Priority Gap: When the PMO and the Board Aren’t Solving the Same Problem

There’s a kind of project that doesn’t fail with a bang. Nobody shuts it down and nobody announces a failure. It just gets a little less every month: less time at the steering committee, fewer people, less of the sponsor’s attention. The PM does everything by the book, reports go out on time, risks are documented, and the project is still slowly being starved.

For a long time I looked for the cause of situations like this inside the project itself. Only with time did I see that it often sits one floor up, in a place the PM usually doesn’t look.

Two vocabularies in one company

In many organizations, the PMO and the board talk about projects in different languages.

The PMO asks whether the project is on plan, whether it’s within budget, whether reports come in on time and whether the agreed methodology is being followed. These are reasonable questions, because the PMO is responsible for keeping the project portfolio predictable.

The board asks something else: does this project move us toward what we care about right now? And what the board cares about changes faster than the project portfolio. Six months ago the priority was growth, today it’s costs. A year ago it was a new market, today it’s keeping the customers we already have.

As long as both vocabularies describe the same projects as important, nobody sees the difference. The gap opens when the board has shifted its attention and the PMO portfolio hasn’t followed yet. A project can then be green in every PMO report, a status that hides more than it shows, and at the same time stop mattering to anyone at the top.

How to tell your project has fallen into the gap

Imagine a project to roll out a new order management system. It started as the board’s pet project, because the company wanted to grow faster. A few months in, the board changes course toward cutting costs. Nobody says the project matters less, but the PM starts noticing small things:

• the sponsor moves the monthly meeting, once, then a second time,
• at the steering committee the project lands at the bottom of the agenda and gets five minutes,
• a request for an extra person for testing sits without an answer,
• in conversations, “how much longer will this take?” comes up more and more often, and “what do you need?” less and less.

None of these signals means anything on its own. Together they say the project has lost its place in the head of the person who decides on resources.

Why the PM is the last to know

The PM looks at the project from the level of the plan. Feedback comes mostly from the PMO: reports accepted, indicators within range. From that perspective, everything adds up.

A change in the board’s priorities is rarely announced. More often you see it in what the board spends its time on, and the PM can’t see that from the project level. The sponsor usually knows, but doesn’t always want to talk about it, because admitting the project has dropped in the hierarchy is also a bit like admitting that they have dropped too.

The PMO often finds out late as well. Not because it does its job badly, but because its tools measure what was planned, not what the board considers important today. The portfolio gets updated at the quarterly or annual review, while the board’s attention can shift in a single meeting.

By reflex, the PM responds to the first signals the way they were taught: they improve the reports, add more detail, describe the risks more thoroughly. All of that goes to the PMO, which is happy with the project anyway. Nothing new reaches the board.

What the PM can do about it

The PM won’t close the gap between the PMO and the board, because that’s not their level of decision-making. What they can do is stop pretending the gap isn’t there, and at least make sure their project isn’t quietly starved.

First step: ask the sponsor directly, one on one, not at the steering committee. The question “is the project still important?” won’t get you anywhere, because every sponsor will answer “of course.” Ask instead: “what is the board focusing on this quarter, and how does our project relate to it?” That’s a hard question to answer with a generality.

Second step: translate the project into the new vocabulary. If the board is talking about costs today and your project was justified by growth, check what the project does for costs. Sometimes it’s quite a lot, only nobody has calculated it, because there was no need at the start. Sometimes it’s nothing, and that’s valuable knowledge too.

It’s worth moving that translation straight into your sponsor update. Instead of another indicator that mostly interests the PMO, add one sentence at the top that connects the project to what the board is talking about today. For example: “the new system shortens order handling time, which with the current team size means we don’t have to hire extra people for the peak season.” That’s a sentence the sponsor can take into a board meeting and repeat without any preparation.

Third step, the hardest one: if it turns out the project has no place in the new priorities, say so out loud before someone else does. Come with a proposal: reduce the scope to what makes sense today, pause, or close. A PM who comes forward with that kind of proposal keeps their credibility and a say in what happens to the team. A PM whose project collapses under them after months of being starved is left with a project everyone remembers as a failure.

One question for this week

Think back to the last three meetings where the board or the sponsor talked about the company’s priorities. Was your project mentioned by name? If yes, you’re in a good place. If it didn’t come up once, this is a good moment for a one-on-one with your sponsor, before the project starts getting less and less.

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.

Can You Send an AI-Written Status Update to Your Sponsor?

The short answer is yes, you can, but not all of it, and not without reading it as if someone else had written it, because in a sense that’s exactly what happened.

The longer answer starts with the moment I first got a finished draft of a sponsor update from a machine. It was correct, well organized and better worded than what I would have written myself on a Friday at six in the evening, and that’s exactly what worried me.

Your sponsor reads the report, and reads you along the way

A sponsor update has two layers. The first is information: what happened, what slipped, what you need. The second, less visible, is a signal: is the PM in control of the project, do they know what’s going on, can they be trusted.

A sponsor who has been reading the same PM’s reports for six months knows how that PM writes. They know when the PM is worried, because the sentences get shorter. They know when something is being skirted, because more generalities appear. They can’t always put a name to it, but they feel it.

When a report suddenly arrives smoother, more even and without those signals, the sponsor may notice nothing, or may notice that something is different and start wondering what changed.

Where the machine genuinely helps

In an earlier article I wrote about the structure I’ve used in sponsor reports for years: status, consequence, options, recommendation. When I held it up against working with AI, the line came out fairly clearly.

The machine does the status well. From notes, email threads and changes on the project board, it can put together two sentences about what happened. It does this faster than I do and often with fewer omissions, because it has no tendency to forget things that are inconvenient for it. I have one condition, though: I check every date and every number against the source, because the machine can build one false sentence out of two true facts.

It can propose options too. Sometimes it suggests a path I hadn’t thought of, because I was too close to the problem. But I always check whether each of them has a real price, because the machine happily lists options that sound reasonable and are simply not doable in this particular project.

Where it doesn’t help, and even does damage

The consequence is the first place where the machine gets it wrong, and in a way that’s hard to catch. In a sponsor update, the consequence isn’t about the schedule. It’s about the sponsor’s world: a promise made to the board, the relationship with the client, their own position in the company. The machine doesn’t know these things, because nobody told it. So it writes a consequence that is generic, correct and useless, something like “the delay may affect the project completion date.” The sponsor reads that sentence and knows nothing more than a moment before.

The recommendation is the second place, and this is where the risk is greatest. The recommendation is your opinion, signed with your name. Sponsors often accept it with a single word, because they trust that someone who knows the project stands behind it. If the recommendation was written by a machine and you simply passed it on, the sponsor is making a decision based on a sentence nobody actually thought through.

Picture a draft where the machine recommends moving the deadline, because it’s the safest of the options. On paper it sounds reasonable. Except you know that last month the sponsor promised that date to their own boss, and moving it is the most expensive option of all for them. The machine doesn’t know that, and you do.

The line I’ve drawn for myself is about exactly these sentences, the ones that lead to a decision. Behind each of them there has to be a person who thought it through and can defend it. Whether a machine helped with the rest matters much less.

Tone is information too

There’s one more thing the machine smooths out by reflex: worry. When I write a report about a project that worries me, it shows. The sentences are shorter, “I need to flag” appears, and the recommendation is sharper than usual. A sponsor who knows how I write picks that up in the first paragraph and often calls before reading to the end.

A draft from the machine always sounds equally calm. It describes a healthy project and a project on the edge in the same measured tone. That’s why, after every draft, I check whether the report sounds the way I actually feel about the project right now. If I’m worried and the text doesn’t show it, I rewrite the first sentences in my own words, because they set how the sponsor will read the rest.

Should you tell your sponsor?

I don’t have one answer for everyone here. There are companies where everyone writes with the help of AI and nobody mentions it, and there are companies where the sponsor would feel deceived if they found out later.

I prefer to say it once, at the start of working together, how I work: that a machine helps me prepare part of the report, and that I write the consequences and recommendations myself. It takes one sentence, and it removes the uncertainty on both sides. If the sponsor asks directly, I answer directly. Few things undermine trust as effectively as discovering later that the PM kept something quiet, even if that something was completely innocent.

A test before you hit send

Before you send a report the machine helped you with, read the consequences and the recommendation one more time. For each sentence, ask yourself one question: could I defend this out loud if the sponsor called in five minutes and asked how I know? If you hesitate on any of them, rewrite it from scratch, yourself.

The rest of the report, once you’ve checked the dates and numbers, can stay the way you got it.

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.

Nobody Remembers What Was Agreed a Week After the Standup

You know the scene. Wednesday, the daily standup, and someone on the team says: “OK, I’ll reach out to legal about that contract.” Everyone nods, topic closed, we move on. The following Wednesday someone asks what happened with the contract. Silence, and then the sentence I’ve heard on every project I’ve ever run: “I thought that was going through you.”

Nobody is lying here, and nobody is dodging. That person genuinely remembers the conversation differently. They remember the topic came up, they remember someone said something. They don’t remember that they were the one who took it on.

A promise said out loud weighs less than you think

The standup is short, fast and spoken. That’s its strength, because people say things there they would never put in an email. It’s also its weakness, because anything that only gets said out loud has a half-life shorter than a sprint.

Over the years I’ve noticed that commitments made at the standup disappear for three reasons.

First, they’re phrased as maybes. “I could take a look,” “I’ll try to get back to that,” “I’ll ping them if needed.” It sounds like agreement, but in practice nobody promised anything. The speaker leaves themselves a way out, and the listeners hear a commitment.

Second, they have no deadline. “I’ll reach out to legal” without “by when” is a task that could be done today or next quarter, and both versions match what was said.

Third, nobody writes them down where the team actually works. Tasks on the project board have an owner and a date. Tasks said at the standup live in the memory of a few people, each in a slightly different version.

Why PMs don’t catch it by reflex

For a long time I was convinced this was a team problem. People don’t keep their promises, so they need reminding. Only when I started watching where exactly things came apart did I realize that a good part of the responsibility sat with me.

At the standup, a PM’s reflex is to guard the clock. Fifteen minutes, blockers, done. When someone says “I’ll handle it,” the PM feels relief, because the topic has an owner, and moves on to the next item. They don’t stop to check whether that “I’ll handle it” is a commitment or just politeness.

On top of that there’s the fear of micromanaging. Asking “by when?” about every little thing sounds like control, so we don’t ask. And a week later we come back to the topic as if it were a surprise, even though it never was one.

The one-line habit

What works for me is so simple that I avoided it for a long time, because it seemed too trivial.

When something at the standup sounds like a commitment, I repeat it out loud in one sentence with three parts: who, what and by when. “So you’re writing to legal about the contract, and by Friday we’ll have their answer, or at least know when it’s coming.”

Right after the meeting, that one line goes where the team looks every day anyway: the project board, the team channel, next to the other tasks. It doesn’t go into my private notebook, because a commitment only I can see is still only my problem. Even if a tool writes the meeting’s action list for you, the line is worth saying out loud first, because the tool records the task, not whether anyone really took it on.

That repetition does more than it seems.

First, it turns a maybe into a statement. When you hear your own “I could take a look” translated into “so you’re checking it by Thursday,” you have two seconds to say “Thursday isn’t realistic, let’s make it Monday.” And that’s a good thing, because that conversation had to happen anyway. Before, it simply happened a week too late, after the deadline had already passed.

Second, the whole team hears it. If someone remembered the agreement differently, they say so right away, in the same meeting.

Third, the deadline stops being something the PM imposes. Someone said it themselves, and the PM only repeated it and wrote it down.

What about micromanaging?

This is the objection I hear most often, and I understand it well. Nobody likes having every sentence repeated back to them.

That’s why I don’t repeat everything. Only what falls outside the project board, meaning things that were born in conversation and don’t have a place yet. Usually that’s one or two items per meeting, and sometimes none.

There’s also one thing worth telling the team once, at the start, plainly: I do this because I forget things myself. It’s true, and it changes how the whole habit is received. The team then sees it as a shared way of making sure nobody has to remember for everyone.

When the line is there, and the task still isn’t

It happens that I did everything right, the line is on the board, and on Friday there’s still no answer from legal. That’s a good result too, because at least I know it on Friday.

At the next standup I don’t ask “why didn’t you do it?” That question frames the conversation as a reckoning, and the answer usually sounds like an excuse. I ask: “what’s changed since Friday, and what deadline is realistic now?” Most of the time it turns out the task got stuck on something nobody saw coming: the lawyer was on vacation, the contract needed a third person’s signature, the answer came back, but with a question. Then I update the line, a new date and possibly a new owner, and we move on.

The most important thing is that a commitment that didn’t happen doesn’t disappear along with its deadline. The old line stays, only the date changes.

A test for next Wednesday

At your next standup, count how many times you hear something like “I’ll handle it” or “I’ll take a look.” Don’t react, just write them down. A week later, check how many of those things actually happened and how many people remember promising them.

If the result doesn’t surprise you, you don’t need this habit. If it does, start with one line at the next meeting.

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.