I’m Krzysztof Nyrek
a Project Manager Storyteller Writer

Scope Creep Doesn’t Arrive as a Decision. It Arrives as a Sentence.

No project I’ve ever run grew because of a decision. Nobody ever called a meeting and said: “we’re expanding scope by three weeks of work, do you accept?” If it had happened that way, we’d probably have said no, or at least priced it, and had the conversation about scope versus value that a change like that deserves.

Scope grows differently. It grows through sentences dropped in passing, sentences that sound so harmless that nobody stops the conversation to take a closer look.

Sentences I know by heart

After all these years I have a whole collection. A few of them come up in every industry.

“Since you’re already in there, maybe you could also…”
“That’s just a small thing, right?”
“I thought it was obvious that this would be included.”
“The client only asked whether it would be possible to…”
“Just do it this way for now, we’ll sort it out later.”

None of them is a problem on its own. The problem is that at the moment it’s said, nobody treats it as a scope change. We treat it as a question or a request for a favor, and favors don’t get priced.

Why we don’t catch it the moment it’s said

The first reason is simple: we don’t want to look like the people who count every minute. The relationship with the client, or with the business side, matters, and a reply like “that’s a scope change, I need to price it” lands like a cold shower in the middle of a pleasant conversation.

The second reason is less obvious. Often, when the sentence is said, we genuinely don’t know what it costs. “One extra report” can be an hour of work or a week, depending on where the data has to come from. So we say “we’ll see” and go back to the agenda. And to the other side, “we’ll see” sounds like “yes.”

I remember a project where eleven of these “small things” piled up over two months. Each one was reasonable on its own. Together they pushed the deadline back by three weeks, and at the wrap-up meeting nobody could point to the moment when we decided on that delay, because there was no such moment.

One sentence in reply

You don’t need a fifteen-page change management procedure to catch this. You need one sentence, said in the same conversation, at the same moment.

I use something like this: “Fine, I’m writing that down. I’ll check what it costs and what it pushes back, and get back to you by tomorrow, before we start.”

That sentence does three things at once. It doesn’t refuse, so it doesn’t damage the relationship. It names the request as something with a cost, which changes its status from a favor to a change, and it sets a deadline, so the other side knows the topic won’t vanish.

The most important part is “before we start.” Without it, the team hears the request and starts working, because it’s just a small thing, and you come back with a price for something that’s already half done.

What to do with the estimate

When you come back, you don’t bring just a number. You bring a choice. “The extra report is four days. We can do it now and move the deadline by those four days, we can do it in the second phase, or we can swap it for something we haven’t started yet.”

Most of the time the answer is “second phase.” Not because the other side got scared, but because for the first time they saw what the request costs. Over coffee, it looked free.

Sometimes the answer is “do it now, move the deadline.” That’s a good outcome too. Scope grew, but it grew through a decision, not a sentence, and three months from now everyone will know where the delay came from.

Holding the line doesn’t take authority

Plenty of PMs tell me they don’t have the authority to defend scope, because the client matters more and the boss will agree anyway. I understand that, I’ve been on projects like that myself.

But that sentence doesn’t require authority. You’re not saying “no.” You’re saying “it costs something, I’ll check how much.” You don’t need anyone’s permission for that. You only need the habit of saying it in the same minute the request is made, not a week later, when everyone already considers it part of the project.

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.

The Meeting That Writes Its Own Action List (and Why PMs Still Don’t Trust It)

For a while now, most of my meetings have had an extra attendee. It says nothing, promises nothing, and an hour later sends everyone a summary with a list of tasks, owners, and deadlines. Clean, fast, no typos. Exactly what a well-run project meeting is supposed to leave behind.

The first weeks with a tool like that were pure relief. No more taking notes mid-conversation, no more reconstructing from memory who said what. Then came a meeting where the summary was flawless and the project still turned the wrong way. That’s when I understood what the tool doesn’t do.

What’s genuinely solved

Credit where it’s due: recording what was said is no longer a problem. The transcript is more accurate than my notes. The task list pulled from the conversation is complete more often than mine would be, because during the meeting I’m running the conversation, while the tool is only listening.

If your pain was that nobody knew what had been agreed after a meeting, that pain really does shrink. Take the win, and don’t pretend the old pen-and-paper method was better.

What no summary will capture

Back to that meeting. We were discussing a delay to one module’s delivery. The summary read correctly: “The vendor team will deliver the module on the new date. Owner: vendor-side manager.”

What wasn’t in it? That the vendor-side manager said “we’ll try,” not “we’ll deliver.” That after he said it, there was a moment of silence and his boss looked out the window. That nobody asked what happens if “we’ll try” isn’t enough.

The tool recorded the task. It didn’t record that the task had a weak owner. Catching that was my job, and for a few weeks I didn’t do it, because I had the sense that “it’s all in the notes anyway.”

A note is a record of the conversation, not a verdict on the decision

That’s the core of it. The summary says what was agreed. It doesn’t say whether it was agreed well.

Does the task owner have the real authority to get it done? Does the deadline come from the plan, or from someone wanting to end an uncomfortable conversation? Does the decision everyone nodded through quietly push the problem onto someone who wasn’t in the room? Those questions get answered by the PM, not the transcript.

I’ve also noticed a side effect few people talk about. When notes arrive automatically, people stop reading them critically. Writing notes by hand forced me to pause for a moment: what actually matters here? Automatic notes arrive finished and look complete, so it’s easy to skim them and tick them off.

How I use it today

I didn’t turn the tool off. I changed what I do after the meeting.

Before the summary goes any further, I read the task list with one question for each item: do I believe this will happen? Wherever the answer is “I’m not sure,” I add one sentence of my own. Sometimes it’s a question for the owner, sometimes a note to myself to come back to it in a week.

The second habit: for decisions that cost something, I add to the summary who made the decision, not only who will carry it out. The tool doesn’t tell the two apart, because in conversation they sound alike. In a project they are two very different things, especially when, three months later, someone asks why we did it this way and not another.

Trust moves, it doesn’t disappear

PMs who don’t trust automated notes are right, but for a slightly different reason than they usually give. It’s not that the tool will get the record wrong. It will get it wrong less often than we do. It’s that the record was never the hardest part of the job.

The hardest part was always sensing which of the agreed things won’t happen. You can’t hand that to any tool, but you can have more time for it, now that you no longer have to take notes.

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.

Status, Consequence, Options, Recommendation: The Only Structure a Sponsor Update Needs

For my first years of running projects, I sent sponsors lists. What’s done, what’s in progress, what’s running late. Carefully, every week, color-coded, and every week I got the same reply: “thanks, got it.” Nothing more, or no reply at all.

For a long time I took that as a good sign. Only when one sponsor stopped me in the hallway to ask whether the project had any problems, while those problems had been described in the last three reports, did I understand that he wasn’t reading my reports as information to act on. He was reading them as proof that someone had the project under control. Or he wasn’t reading those emails at all.

Let me save you those years. A sponsor doesn’t need to know what you’re doing. A sponsor needs to know what you need from them.

Why a list of delays leads to no decision

A list of delays is honest, but it leaves all the work to the reader. The sponsor sees “integration pushed back two weeks” and has to answer three questions on their own: is that a lot, what follows from it, and do I need to do something about it. Usually there’s no time to think it through, so they respond with the simplest thing available: nothing. And a decision that never gets made has its own cost.

From my side, it looked like I had raised the problem. From their side, it looked like the problem was under control, because if it weren’t, the PM would have written more. And you know what? We were both right, each in our own head.

Four parts, in this order

For years now, every message to a sponsor where something is moving has followed the same layout.

Status. One or two sentences about what happened. No backstory, no excuses. “The vendor moved the test environment handover from mid-month to the end of the month.”

Consequence. What this means for the things the sponsor cares about: deadline, budget, scope, people. Not for the schedule in the tool, but for their world. “If we do nothing, go-live slips by two weeks, which puts it after the date you promised the board.”

Options. Two or three real paths, each with its price. Not one option dressed up as a choice, and not seven, because seven is handing the decision straight back. “We can start testing on substitute data and run integration tests later, which costs two extra days of team time. We can move the deadline. We can cut the reporting module from the first release.”

Recommendation. Which option I would pick and why, in one sentence. “I recommend the first, because it protects the deadline, and the integration testing risk with this vendor is low.”

That’s it. It usually fits in eight to ten sentences.

The recommendation is the most important part, and the one most often skipped

In conversations with other PMs, this last point meets the most resistance. I hear: “it’s not my decision,” “I don’t want to stick my neck out,” “the sponsor knows better.”

The sponsor will indeed make the decision. But you are the person who knows the project best, and if you don’t say what you would do, the sponsor decides on less knowledge than yours. A recommendation doesn’t take their authority away. It gives them a starting point they can accept with one word or reject with a reason.

There’s also a less noble reason, but a true one: a sponsor who gets a recommendation replies faster. With a list of delays, I’d wait several days for an answer. With the four parts, I often get it the same day, because the answer is “ok, the first one.”

What this structure doesn’t tolerate

It doesn’t tolerate beating around the bush. If in the “status” part you start explaining who’s to blame, the sponsor stops reading halfway and remembers the culprit, not the problem.

It doesn’t tolerate fake options either. I once sent a sponsor three options, two of which were so weak the choice was obvious. The reply was short: “if you already know what needs to be done, why are you asking me?” Fair point. If there’s only one sensible path, say so directly: status, consequence, what I’m doing, and by when you can stop it.

And it doesn’t tolerate mixing several topics in one message. Three problems means three short blocks of four parts each, not one long paragraph where the sponsor has to match the options to the problems themselves.

A small test for your next update

Before you send your next message to a sponsor, read it and answer one question: what decision can they make after reading it? If the answer is “none,” it isn’t a sponsor update. It’s a project diary you happen to be emailing them.

A diary has its place too, but let it sit somewhere the sponsor can look when they want to. Their inbox should get what requires them to move.

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.