The bad number went up on the screen, and the sponsor hadn’t seen it coming.

A few years back, before Covid, I was in benefits realization review at a government agency, watching one of the team present the result of a document scanning project. The system was supposed to scan paper applications and check the supporting documents against the criteria on its own, to automate the work that had been entirely done by hand. The charter promised it would automate the vast majority of the manual work.

But when they tested it against real applications, most of the automated scans failed and bounced straight back into the manual queue. The staff were still doing the data entry and manual work as before.

So the presenter put a number on the screen that was a small fraction of what the charter had promised. First there was surprise, then the embarrassment as people did the subtraction, and then the defensiveness. No one could say where the charter’s number had come from in the first place.

The PMO hadn’t done anything wrong. They followed the benefits realization guidance to the letter: define the outcome, measure a baseline, deliver, measure again, report the outcome.

But doing it right is exactly what left the sponsor exposed in front of her peers.

None of it went wrong at the review. It went wrong much earlier, in the steps themselves.

The benefits realization steps are fine. The assumptions under them aren’t.

The first time I read a benefits realization method, I found it completely reasonable, and I suspect you did too. Define the business outcome you’re after. Measure the baseline before you start. Deliver the project. Measure again afterward and compare. It’s basic arithmetic.

What the steps leave out is that each one rests on an assumption that can fall apart in a real organization.

• Defining the outcome assumes the outcome is cleanly measurable.

• Measuring the baseline assumes someone captured it before anyone touched the process.

• Comparing afterward assumes a person still cares about the number when it arrives, which can be months later.

The first assumption breaks before the project even starts, back when someone had to sell it to get the budget.

Pitfall #1: The aspirational number that won the budget was never meant to be measured

The expected benefits on a charter always sound confident, and there’s a reason for that. A charter has to get approved, and everyone writing one knows the bolder the number, the smoother the approval goes.

When you start doing benefits realization, you begin to realize you’re auditing the promise the sponsor made to get the budget approved. The business case was a sales document written to win the budget. Now you come along eighteen months later to hold up a ruler against a number that was aspirational enough to practically guarantee an approval.

If you ask where the original number came from, you’ll get three different answers. The “Projected $4M annual savings” in the charter turns into, “Well, that was always a stretch goal,” and no two people can trace the number to the same source. No one lied. The number did its job to get the approval, but its job was never to be measured later.

What I’ve found works is having the target conversation before you start measuring. While memories are fresh and no one’s reputation is riding on the result yet, people will openly tell you which benefit figures were solid and which were there to get past the approval gate. Write down what you’ll measure against. That agreement is far easier to reach in a low-stakes conversation in month one than right before the high-stakes benefits realization review.

Say you get the target straight. You’ve still got to prove you hit it, and that’s the pitfall I walked into myself.

Pitfall #2: Proving the number is accurate is harder than getting the number

I inherited an automation project mid-delivery, and the baseline metric had never been captured. So I did what seemed reasonable. I reconstructed the baseline number from what data I could find and the recollections of people who’d been there. I and the project team both thought the number was solid.

The benefits review is where it came apart. The outcome had moved in the right direction, and I said so. Then the finance director set down his pen and asked, “How much of that was because of the project, and how much of it would’ve happened anyway?” Because in the same period, application volumes had dropped, a hiring round had filled the vacant positions, and a policy change had simplified many of the cases coming in.

The outcome moved, but so did the whole environment around it. I couldn’t confidently say which part of the gain was the result of the project we delivered, and once you can’t say that, the whole benefit becomes arguable.

One question about the baseline, asked in the first week, would have saved that entire situation. So now I agree on two things in writing before delivery starts:

1. What the baseline metric is, and

2. How we’ll handle attribution when other factors inevitably move at the same time.

Neither has to be perfect. It just has to exist, and it has to be agreed by people who won’t be in a position to reopen it when the number is inconvenient. Otherwise you’re negotiating both under pressure, in front of an audience, which is when you have no leverage.

And suppose you clear all that. The benefit still needs someone left who cares about it, and by the time it arrives, that’s not a safe bet.

Pitfall #3: By the time the benefit arrives, the people who cared about it are gone

Six months after go-live, a calendar reminder I’d half forgotten about went off, and my first move was to scroll through the org chart to figure out who owned this now.

The sponsor who championed the project had been promoted into a different division. The delivery team had scattered across other projects. The business owner who’d feel the benefit had changed roles. I was the last person still holding the benefits measurement plan. In a situation like that, the measurement either gets forgotten, or it gets dumped on someone who inherited the system in a handover and has no idea why the number matters.

If you document the benefit owner up front, most of that goes away: a real person, distinct from the project sponsor, because the sponsor’s incentives evaporate the day the project closes. Then confirm, in writing, that this person is still on the hook when the benefits measurement comes due, not just on the day the plan gets signed. It’s an unglamorous bit of paperwork, but it saves you from measuring a benefit that no one is left to receive.

Suppose you manage all of it, and the number comes back truthful. Truthful is the moment it turns dangerous, which brings us back to that first meeting.

Pitfall #4: An unflattering number can backfire and take the whole practice with it

Go back to that government agency, and the benefits review where the scanning result went up on the screen. The sponsor who’d championed the project was sitting right there, seeing the shortfall for the first time at the same moment as everyone else. The bad number was one problem. What leadership did next was the bigger one.

They watched their sponsor get blindsided in front of the whole room, and they decided they were never going to go through that again. So they stopped doing benefits reviews, not just for the scanning project, but for every project.

The one practice that would have told them if any of their spending was working got switched off, because the first uncomfortable result it produced stung someone senior. They didn’t decide benefits realization was a bad idea. They decided it was a dangerous one, and instead of fixing how the truth got delivered, they threw out the baby with the bathwater.

A practice that leadership decides is “dangerous” doesn’t come back the next quarter. It’s gone, and what people remember is the day the sponsor got embarrassed, not the money no one could account for.

So here’s the rule I hold to now: never let a sponsor see a bad number for the first time in a meeting. Show it to them privately, before it goes anywhere public, early enough that they can sit with it, ask questions, and walk into the review and speak confidently to the number. You’re not softening the number or hiding it; it stays exactly what it is. You’re only deciding whether the person most exposed by it hears it from you first or gets ambushed in front of an audience.

Benefits realization is still worth doing. Where you start it is what determines if the first result helps you or takes the whole practice down.

Start on a project no one’s watching closely

Keep benefits realization away from the flagship project with the whole leadership team watching. That’s the project with the brightest spotlight and the highest stakes, and the worst possible place to make your first mistakes.

Pick a small project that’s already delivered, one where the baseline happens to exist, the outcome is easy to measure, and the original sponsor is still around and reachable. Run the full method there, end to end. You’ll hit smaller versions of all four of these pitfalls on a project where a stumble won’t cost you much, and you’ll learn how the exposure behaves in your organization before you ever do a benefits realization on a major project people care about.

No one has to greenlight a new initiative or fund a capability for you to do this. Take one finished project, run the method, and learn where the light falls in your particular organization. Then decide what to point it at next.

Most PMO leaders go through the same five phases. Phases one through three are what everyone tells you to do, and they feel like progress the whole way through. Phase four is where the PMO you built starts answering to a different audience than the one you built it for. If your dashboards are green and something still feels off, you may already be already in it.

It starts, like most of these things, on your first day.

Phase 1: You’re Hired to Solve a Problem That’s Not Well Defined

Leadership decided the organization needs a PMO. That decision usually follows something that that went wrong, like a program that ran eighteen months past its due date, an audit finding, or a new CFO who couldn’t get a straight answer about where the money was going.

So you ask what the PMO is supposed to solve. The COO tells you it’s about delivery predictability, the CIO says visibility, and the CFO says it’s really about stopping projects that should never have started, and she says it in the tone of a person who’s ready to tell you which ones should have never started.

All three are reasonable, and none of them are the same problem, and no one in the conversation thinks they’re disagreeing with anyone.

You do what any competent person does with an undefined job. You look at what good looks like elsewhere, talk to peers at two other companies, pull down a maturity model, and go back through what worked at your previous job. There’s a lot of material available, and most of it agrees with itself, which feels like confirmation at the time.

What you end up designing is a PMO shaped like other organization’s PMOs. That’s not a failure of judgment. It’s the only reference material anyone handed you.

Then you take it to the people who hired you.

Subscribe now

Phase 2: The Plan Gets Approved Before Anything Has Been Tested

This phase happens almost entirely between you and the executive team.

You present your PMO operating model: intake process, stage gates, a governance cadence, a standard set of templates, the reporting rhythm, who sits on which committee. It’s a legitimately good plan, it’s coherent, it’s benchmarked, and it answers all the question the executives thought they were asking when they decided to hire you.

They approve it. Someone says it’s the first time they’ve seen the whole portfolio described on one page, and you can tell they mean it. The CFO likes the intake process because it means fewer surprises, the COO likes the gates, and you get a headcount you weren’t expecting, or a budget line, and a standing agenda item on the weekly leadership meeting.

That approval is the highest your credibility will ever be. It’s given for a design, presented well, by someone who clearly knows how this is supposed to go, before a single gate has stopped a project or a single report has changed a decision. What leadership approved was the promise of the thing, not the thing.

And that’s a fair thing to approve. But it’s a different thing than the one you’ll eventually be measured on.

Now you have to take it to everyone who wasn’t in that meeting.

Phase 3: Every Number You Track Says It’s Working

This is where the PMO meets the organization, and for a while, the organization goes along with it.

Adoption climbs fast, partly because the framework is genuinely better than what existed, and partly because it’s mandated. Projects come through intake, gate reviews get scheduled, and the templates get filled in, sometimes at 4:45 on a Friday, but they get filled in.

Within a couple of quarters you have portfolio coverage you could only estimate before, a dashboard that’s green in most places, and a maturity model that shows you moved you up a level.

You report on all of it, and the reporting holds up. The coverage is there, the adoption is there, the maturity score is earned.

But every one of those numbers measure the PMO rather than the business and the outcomes they’re working toward. That distinction stays ambiguous while the numbers are going up, and I’ve almost never met anyone who caught it in this phase, myself included.

So the framework holds up, leadership stays pleased, and everyone including you believes it’s working.

For about a year.

Phase 4: You Read the Symptoms as an Adoption Problem

Then things start slipping, and they slip without much fanfare.

Reports get produced on schedule, but people stop referring to them. Gate reviews turn into formalities, because the conversation that mattered already happened somewhere you weren’t. Risk logs go stale between steering committees. Projects pop up that never came through intake, and you hear about them later.

It’s hard to say exactly when these start to happen. Every piece still gets done; it just seems to stop mattering as much as it did before.

Look at which teams are routing around you, though, and it’s not the ones you’d expect. The teams strong enough to deliver without your governance are the first to stop abiding by it. So the projects that slip away from your process are the ones that would have been fine anyway, and the ones that stay are the ones that most need watching.

The numbers on your dashboard might not move, but what they’re counting has slowly gotten worse.

Here’s what took me too long to understand about this phase. The people who approved your PMO aren’t the people who have to use it. You were graded by the first group (the executive team), and now you’re being graded by the second group (the PMO stakeholders), and the two groups want different things from you.

Your PMO framework is doing exactly what it was built to do, which was satisfy the executive team who approved it.

When a sponsor or delivery team routes around your intake, they’re ignoring a process that was designed for the executive review, in a phase where the executive review isn’t the audience anymore. The teams doing the work needed something the plan was never designed to give them.

That’s not the explanation you reach for, though. The simpler one is right there, and it doesn’t require you to have built the wrong thing.

“This is an adoption problem.”

If people just followed the process the way it was designed, everything would be fine. Your framework is sound. You know it’s sound, leadership approved it, and the maturity model agrees.

So you say the things everyone in this phase says. That you need better discipline on the template. That you need stronger executive backing on the gates. That you need to move up to the next PMO maturity level.

And then you do what follows from that diagnosis. You reach for authority: a reaffirmed mandate, compliance reporting so you can see who’s complying, adoption metrics, and an escalation path for the projects that skip intake.

Each of those steps makes the PMO more painful to work with without making it more helpful to work with. Teams comply on paper and route around you in practice, which gives you worse information than you had before, which makes the case for tighter enforcement, which is where the next quarter goes.

Somewhere in here, you stop being the person who helps projects deliver and start being the speed bump sponsors have learned to steer around without slowing down. You can feel the meetings change. People bring you the version of the truth that clears the gate, because you’ve trained them to.

Eventually, somebody weighs what the PMO costs against what it delivers.

Phase 5: The Question You Can’t Answer

The trigger can vary. It could be a new CFO, a cost review, an operating model refresh, a reorg that has nothing to do with you.

Someone asks what the PMO delivers. You have an answer ready, and you can hear it going flat as you say it: reports are produced, gates get held, projects are tracked, coverage is achieved, and the PMO is at maturity model level 4. Every item is true, every item is defensible, but none of them is the answer to the question that was asked.

The question was what the PMO delivers, and everything on your list is what the PMO does. No one in the conversation can point to a decision that went differently because you were there.

You don’t get argued with.

That’s the part that stays with you. There’s no debate, because a debate would need someone to hold the opposite position, and no one does. Your role gets eliminated, or absorbed into delivery, or handed down to someone two levels below you for a fraction of the cost. Your PMO framework stops being enforced within a month, and no one sends an email to announce it.

Then, a year or two later, a program blows up. An executive asks who’s tracking the portfolio. Somebody says it’s time to stand up a PMO.

What Separates This PMO From the PMO That Survives

I read my own coverage numbers as success too, and when adoption started slipping, my first instinct was enforcement, not curiosity. That instinct is the trap, and it’s a sneaky one, because every incentive in phases two and three rewards it.

The genuinely uncomfortable part is that phases one through three look identical whether you’re heading for phase five or not. There’s no sign from the inside. The dashboards look the same, the approval feels the same, the maturity score climbs either way.

You can’t tell the surviving PMO from the doomed one just by looking at what either one produces.

What separates them is what they were producing all along. One delivered governance: gates, reports, project coverage, and a cadence. The other delivered outcomes: decisions that went better because the PMO was involved.

They can look the same on a dashboard for years, because a dashboard counts governance but doesn’t have a column for outcomes.

So here’s the check, and it only takes an afternoon. Start from the business, not the PMO. List the outcomes your organization reached this year that it wouldn’t have without the PMO, the kind a CFO would recognize as a result, not an activity. Then trace each one back to what you actually did. Everything you own that doesn’t connect to one of those outcomes is governance you’re delivering in place of outcomes, and it will only be seen as activity in the one meeting where someone finally asks the difference.

I played string bass in the fifth grade honors orchestra. When I was 17 and a senior in high school.

The fifth graders’ hands were too small to reach the low positions on a full-size bass, so the music teacher asked me, a high school senior, to volunteer and help her that year. At the first rehearsal I played the way I always did, and I overpowered them. I was so loud you couldn’t really hear the rest of them.

The music teacher stopped us and told me to bring it way down. Most of the time she wanted me under everyone, barely on the strings, just holding the bottom so the rest of the orchestra had something solid to sit on top of. I spent the rest of the year as the strongest player there, playing as little as I could.

Most of us got our PMO jobs by being the strongest player.

We were the one who could rescue the plan, run the recovery, and save the project the before the milestone was due. So that’s what we keep doing once we’re handed the whole portfolio. The job pulls you toward the loudest single project, the one you know how to fix.

I’ve had plenty of days that went to one plan, one problem, or one slipped date, while the rest of the portfolio was left to find its own footing.

The dashboard that told me everything except what was important

Early in my PMO career, I walked into an executive meeting with a portfolio dashboard I was proud of. It was almost all green. I remember feeling good about how clean it looked going up on the screen.

One of those green projects did a swan dive into the red about two weeks later because of a materialized risk the dashboard never showed. And when I thought back on it, the dashboard had never once told me anything early enough to do something about it. It told me a project was late after it was already late. I had been reading it like it was radar (showing what was coming), when it was really a rearview mirror (re-capping the past).

A report that tells you a project is green doesn’t tell you if the portfolio is aligned with the enterprise strategy. The PMO doesn’t have a color for that.

The PMO is the one group that could decide where the whole organization spends its effort, and then prove whether or not the investment bets paid off. That’s a strategy role, and many of us never take on that role because keeping the scoreboard current takes up the entire week.

Here are three times I watched the difference between coaching one of the violinists versus conducting the whole orchestra. None of them took a new tool or another meeting. They mostly took someone doing less of the thing that felt productive.

What an audit saw that the organization couldn’t

I once ran a PMO for a government agency that paid commissions to a set of third-party partners. The payments were handled by another department, and every so often a partner would call to say their commission looked wrong. That department would dig in, find the error, correct that partner’s check, and close it out. The complaints came in and they made them go away, one at a time.

Then an external audit looked at the whole population of partners at once and found that a large class of them had been paid incorrectly for a long time. There was one root cause. Every complaint that department had carefully resolved had been a single instance of one defect in how the payment system applied the regulations.

Watching it from the PMO perspective, what struck me was that nobody in that department was wrong to focus on fixing the checks. They just had no vantage point to ask whether the checks were connected, because they only ever saw one at a time, in the order the phone rang. The connection lived above their desks, at the level where you can see all of the hundreds of partners at once, and that level was empty.

After the audit, they paused correcting individual checks and fixed the system itself, and the calls stopped, because the error generating them was gone.

That’s the part of a PMO leader’s job nobody else in the building is positioned to do. When the same kind of problem keeps happening on different projects, the individual teams each solve their own and never know the others existed.

The PMO leader is in the the position to view across all of them.

So when a status report shows a row of separate little fires, don’t reach for the nearest one. Look for the single root cause upstream that’s throwing all the sparks, and put that out instead.

Seeing the pattern is one job. The next one is harder, because it means building something that handles the pattern without you being in the middle of it every time.

How one written rule ended a two-month tug-of-war

I was advising an IT director who owned a scarce, badly wanted staff member: the one senior engineer who best understood the legacy system a third of the portfolio depended on. Two project managers both needed him, and the director had become the referee.

They would each come to her office, make the case for why their project was more urgent, and whoever had spoken to her most recently tended to win. She was spending a lot of time on it and didn’t love it, but she had never questioned the setup. Refereeing was just what the job had become.

I asked her why she was the one making the call at all. She didn’t really have an answer, other than that it had always worked that way. So we talked it through, and she wrote down a simple rule and published it: anything tied to the regulatory filing deadline gets first claim on the engineer’s time, and everything else lines up behind it in priority order. It was plain, visible, the same for everyone.

It got tested within two weeks. A VP wanted the engineer for something that mattered to him but had nothing to do with the filing, and she had to tell him he was in line behind two regulatory items. That was the moment the rule either meant something or it didn’t.

She let it hold. And within a month the two project managers stopped bringing the fight to her at all, because they could both already see where they stood.

She was the orchestra conductor who had been spending her time tuning individual violins.

A conflict would come in, she would settle it by hand, and it would feel like leadership because people needed her to resolve it. The reframe that changed her mind was about what her job really was. Settling conflicts one at a time kept her busy and needed, but the more impactful work was to build the system that made the call without her, and then to protect it when someone with influence pushed back on it.

A good rule is a visible one. It has to hold the first time someone with influence doesn’t like what it says, and that first test is where most rules fall apart, usually because the author folds. Staying liked is easier than maintaining the rule that improves the system.

The $300,000 test that didn’t prove anything

I wish I could tell you I conduct all the time now. I don’t. Last month I lost two days inside one project’s recovery plan, because it was the one I knew exactly how to fix, while three others I should have been watching slid into trouble I didn’t see coming.

The magnetism toward the part you play well doesn’t go away. You just get a little faster at catching yourself doing it again.

A conductor listens past whether each player hit the notes on the page, to the actual sound the audience hears, which is a completely different question. A section can play every note on pitch, and the piece can still be lifeless.

Once when I was consulting at a healthcare organization, one of the directors insisted on a full manual regression test of a large, mature, stable system before open enrollment. I pushed back. The system hadn’t meaningfully changed, the risk was low, and the test carried a price tag around three hundred thousand dollars.

Ten years later, I can still picture (and hear) her pounding the table in the meeting as she yelled that she needed the peace of mind that the system was working designed.

I was overruled, so we ran the full, manual regression testing. It found nine defects. Eight were minor. The ninth was a medium-severity issue we corrected with a hotfix, and it would have turned up on its own within days of enrollment opening. They spent three hundred thousand dollars, and didn’t find anything that needed finding early.

On the status report, that project was green the whole way. On time, on scope, on budget, every note played on pitch. Measured by the only sound that mattered, whether it was worth doing, it was three hundred thousand dollars to confirm what we already knew.

The reason I remember that number isn’t the one project. It is what the number let me do afterward. We carried it into the next planning cycle, and when a full manual regression came up again, the three hundred thousand and the one defect were in the conversation, and the conversation went somewhere different than it otherwise would have.

A status report tells you the work got done. A number like that tells you whether it was worth doing, and it becomes evidence you feed into what gets funded next year.

Once you’re listening for whether the work was worth it, the hardest version of this gets easier to face. Some projects are worth stopping in the middle, once the result they were funded to deliver stops being feasible and everyone keeps playing anyway because the plan still says to.

Stopping a project on live evidence is the same act as refusing a test that won’t earn its cost. Each one is you deciding where the organization’s effort is worth spending, using what really happened as the input. That is the strategy seat, and it has been sitting inside the PMO the whole time, underneath the reporting.

The wobble that means it’s working

When you as the PMO leader step back from the individual projects, the portfolio might wobble for a while. The teams have to carry their own parts, and you can hear that they aren’t used to it yet. That wobble is the sound of the work settling back onto the people who own it, and it passes.

From where you sit, you can hear something none of the individual teams can, which is whether the whole portfolio is aimed in the right direction. You can’t hear it while you’re down in one project, playing over the top of everyone else.

So this week, before you dive into the project that’s calling for you most loudly, stop and ask a different question. What’s repeating across the portfolio that no single team can see, and what would it take for you to fix that instead?

I was consulting inside a government agency PMO, sitting in on their intake sessions, and something felt off. Charter after charter came through, and every one got a green light. There weren’t any hard questions or pushback. Each sponsor would walk through the document, someone would say “looks good,” and it was approved. Every charter followed the same pattern.

I’d been in enough intake meetings to know what a working gate looks like, and this wasn’t it.

So I did what you’d probably do. I assumed the intake gate was broken. I figured the criteria were too loose, the reviewers too passive, and the whole thing was just a formality. I started drafting the case to tighten the intake meetings. I was going to fix it.

Luckily, before I fixed anything, I asked someone why the intake meetings were as they were.

What A Director Told Me That Rearranged My Perspective

I had good rapport with one of the directors, so I asked him, “Why does every charter get automatically approved?” He didn’t hesitate. It was, in his words, a “You scratch my back, I scratch yours” culture.

Everyone in that intake session understood their job was to approve whatever came through. And in return, when they brought a charter of their own, they knew the same courtesy would come back to them.

By approving everyone’s else’s charter, every sponsor know the charter for their pet project would be approved too.

Once he said it, the whole system became clear in my head. Those approvals during the intake meeting were never the decision. The decision had been made long before the meeting started, in a standing agreement between people who’d learned to keep each other’s work moving. Intake was where that agreement got written down and stamped.

I’d assumed the meeting was the place where governance happened. The director was telling me governance had already happened somewhere I couldn’t see.

That somewhere-I-couldn’t-see turned out to have a pattern, and once I learned to look for it, I started finding it everywhere.

Subscribe now

The Governance You Can’t See Is Usually The One That Counts

I call it shadow governance. It’s the decisions that form before the formal governance body convenes. It happens in the hallways, the one-on-ones, and the text messages that circulate the week before. By the time the governance meeting starts, the real work is done. The committee ratifies, but it rarely decides.

I watched it happen on a portfolio review a few years earlier, and I only understood it in hindsight. The PMO had two competing business cases, only enough funding for one, and a committee meeting to choose the winner. I spent days building the prioritization model with cost analysis, benefit timelines, and a scoring model I was proud of.

The meeting lasted about three minutes.

The leader opened by saying he’d “Had a chance to talk it through with a few people,” named the winner, and asked if anyone objected. No one did, because the people who’d have objected were the few he’d talked it through with. My model got a polite nod and never entered the conversation. The decision had been walked around the building the week before, and the meeting was there to record the consensus that already existed.

None of that showed up in the governance documentation. The actual choice got made in a set of conversations that weren’t on any agenda, between people who never called what they were doing “governance.”

I remembered that situation as I was thinking about fixing the intake process. Then I realized the trap I was walking back into with that government PMO.

Why Tightening The Gate Doesn’t Fix Governance

When intake feels broken, the instinct is to reform intake and tighten the gate, add decision criteria, and require better charters. I don’t think I’m the only one whose first draft of a fix looks like that.

In that government PMO, all of that would have accomplished nothing. I could have built the most rigorous scoring model in the sector, and the charters still would have breezed through because the approval wasn’t based on charter content or quality.

A tougher intake gate doesn’t improve decisions that are already made before intake. It would just create an obstacle. The consultant who shows up, declares the process broken, and starts failing charters is the consultant who gets politely thanked and ignored. I’d have lost my credibility by trying to win a fight I couldn’t win.

So the fix I implemented was the exact opposite of what most PMO best practices look like.

Why You Shouldn’t Try To Get Rid Of Shadow Governance

You can’t eliminate shadow governance. And if you somehow did, you’d regret it.

The same invisible pre-meeting that laundered weak charters in that government PMO is also, in a healthier setting, the step that keeps a senior leader from getting ambushed in public. It’s the executive who walks a funding decision past three peers beforehand so nobody’s blindsided in the committee. It’s the director who ends a weak project privately in a hallway so a team doesn’t have to be ripped apart in a formal review.

That pre-work is a pressure-release valve. Organizations that decide everything cold, in the open, in real time, tend to be organizations where people stop bringing hard things forward at all.

I know how this sounds, like I’m blessing backroom deals. I could have walked in, called the gate corrupt, and tried to clean it up. Part of me wanted to do that.

Then I remembered I’d watched formal reform bounce off a pre-meeting before. The pact was a real problem and it did need to change; I just wasn’t going to change it by attacking it head-on. The question was no longer how to abolish it, but how to aim it.

And the lever I found wasn’t a policy. It was five questions.

Five Questions That Changed Nothing In The Meeting And Everything Outside It

I couldn’t confront the pact head-on. An outside consultant telling a government PMO to stop supporting each other’s work would just get my contracted cancelled. I needed to do something they couldn’t reject.

So I proposed the smallest possible thing.

The PMO would start asking the same five questions of every charter that came through. The same five, every time, no exceptions. Nobody had to admit the pact existed to agree that every project answers the same questions. It didn’t single out anyone. It preserved the harmony they were used to and looked like the mildest bit of process you could imagine.

The five questions were:

1. Problem: What are we solving, and what are we explicitly not solving?

2. Outcome: What result will proves this worked, and how will we measure it?

3. Urgency: Why now, and what happens if we do nothing?

4. People: Who has to agree, and where is future disagreement likely to come from?

5. Assumptions: What assumptions and dependencies is the plan resting on?

They may look tame written down, but they aren’t. But I want to be honest about how I used them, because it wasn’t the way you’d expect.

I never stopped a charter. Even when the answers were weak (and I felt like sending the charter back to the drawing board), I’d just say, “Nice, maybe that’s an area we can tighten up as we move forward.” I treated intake as a coaching session, not a gate, because the governance had already happened without me.

Asking the five questions out loud, in front of everyone during intake, was the whole point. A weak answer got waved through, but not before everyone heard how weak the answer was.

What the five questions did, structurally, was leave a trail, a verbal record of which charters had solid answers and which ones skated through. They applied to everyone but weren’t aimed at anyone.

Then something happened that I didn’t plan.

What I Heard Through The Grapevine About The Pre-Meetings

The back-scratching conversations pre-intake didn’t stop. That’s the first thing to understand. They kept happening exactly where they always had, before the intake session, among themselves, in conversations I was never in.

What changed is what they started talking about.

I heard it secondhand, through the grapevine, weeks later: they’d begun working through the five questions among themselves before the meeting. They knew the questions were coming. They knew precisely what would get asked. So to keep the harmony they valued, to make sure everyone’s charter still sailed through without an awkward stall, they started shoring up each other’s charters in advance.

That’s the whole point. The shadow governance system did the work. I never dragged the decision into the light; I couldn’t have, since those pre-meetings were invisible to me by design and still were.

What I did was give the pre-meetings a better target to optimize for.

The name of the game was still reciprocal support. But the price of getting that support went up: to back your charter, I now needed your charter to hold up under the five questions, which meant helping you make it hold up. The pact stayed intact, and the charters got better. And it happened in the one place I supposedly couldn’t reach.

If I’d gone with my first instinct, breaking the pact and forcing every call into the open, I’d have gotten surface-level compliance and worse charters. Because I left the shadow system alone and changed its target, I got better charters and kept the harmony that made the group function.

I’d love to tell you this works everywhere. It probably wouldn’t, and I don’t want to pretend it would.

The Lever Isn’t The Five Questions; It’s Knowing What Your Shadow Governance Wants

This worked for me because that particular pact wanted predictability and harmony badly enough to do the hard work to protect it. What harmony bought those people was the guarantee that their own charter would sail through unchallenged, and they’d trade a fair amount of effort to keep that guarantee. If you give a group like that a clear bar, and they’ll rally to clear it together. That’s a specific condition for some organizations, not a universal one.

The five questions aren’t magic. What made them work was that they fit what that particular pact already wanted, and pointed it somewhere better.

Picture a group that’s protecting turf instead of trading favors. If you hand them the five questions, they’ll nod along in the pre-meeting, and then use intake to ambush a rival’s charter by hammering the weakest of the five answers to sink a project they were never going to support.

Or picture a group that’s simply protecting speed, where the shared goal is getting everyone through the gate fast. If you hand them the same five questions, they’ll arrive with five rehearsed answers thin enough to satisfy the ritual and move on. You’ll have added a step that doesn’t accomplish anything, and the rubber stamp stays exactly where it was.

So I wouldn’t hand you my five questions and tell you to adopt them this week.

I’d tell you to go find your own pre-meeting first: the hallway meetings, the side conversations, the standing agreement where your real decisions really form. Then figure out what it’s protecting. Predictability? Cover? Turf? Speed? Whatever it wants, that’s your lever.

The move is to give it something better to do without asking it to stop being what it is.

You’re in the quarterly review. The portfolio slides are up, someone’s halfway through the compliance project, and a VP leans in with the question that stops the meeting: “So what was that project worth to us?”

The project manager doesn’t blink. “Roughly $400K in avoided penalties.” Heads nod, and the deck advances. And nobody pushes back, because nobody knows how they’d check it.

The number sounded like a number. That was enough.

I’ve made that number up too. Not because of malice, but because of a template.

The business case a cell labeled “Financial Benefit ($),” it was empty, and an empty cell in front of a steering committee looks worse than a wrong one. So I put something plausible in it and got on with the meeting. I don’t think I even flinched. By the time it was on the PowerPoint slide, I half-believed it myself.

Two failure modes live in that cell.

1. One is the invented financial, the dollar figure reverse-engineered to fill a template.

2. The other is the vague retreat like “improved alignment,” “increased efficiency,” or “better collaboration,” words that survive a review precisely because they can’t be checked either.

There’s a question that gets you out from being stuck between the two. Stop asking, “What is this worth?” and start asking, “What would we expect to see if this project really delivers its business outcome?”

You might be thinking your benefit is the exception, that some outcomes are intangible by nature, that “better morale” or “reduced risk” won’t reduce to a number no matter how you ask the question. That worry is fair, though it’s usually aimed at the wrong thing.

Intangible almost always means the benefit is hard to put a price on, not that it’s impossible to see.

Morale that improved shows up in fewer people quitting. Risk that dropped shows up in fewer near-misses reaching the incident log. Asking “What would we expect to see if this were real?” points you straight at those changes, the ones you can watch happen and check again a year later, which is more than the invented dollar figure ever gave you.

The Four Steps, Same Every Time

That question is the start, and underneath it there’s a sequence I run the same way every time, four steps, nothing you’d need to write on a card.

1. Say what you’d expect to see if the benefit were real: one thing, stated plainly enough that a skeptic could check it.

2. Pick the operational version of it, something you could watch change: a count, a clock, a queue.

3. Write down where it stands today, before the project starts, because a baseline you didn’t capture is a baseline you’ll invent later.

4. Set the date you’ll read it again, before the team scatters and nobody owns the number.

The first time I did this on purpose, the surprise was how little of it was new work. The numbers were already lying around in someone’s files. I’d just never written down the before, so I had nothing to stand on when the after showed up.

The four example projects below are the same sequence, worked four times, in the four places people reach for an invented number most. Watch what changes and what stays the same.

Compliance: The $2M Spreadsheet Nobody Opened Twice

I once watched a colleague build a beautiful cost-avoidance model for a compliance program. It had twelve tabs, sensitivity ranges, and a summary line that landed on $2M in avoided fines and remediation. He presented it once, and it got a slow, approving nod. And as far as I know, no one opened that file again.

The problem wasn’t the math. The $2M counted fines that never arrived, and you can’t audit an absence. If you come back in a year with no penalty on the books, you still can’t say why. Maybe it was the project, or maybe it was a year that was never going to bring one. That’s what made the number safe to invent.

So start with what you’d expect to see if the program worked, and make it something an auditor could watch. Last year, when the auditor asked for the access logs, someone spent a week digging through four systems to assemble them. This year the same request gets a folder opened in ten minutes. That’s evidence retrieval going from a week to a morning, the operational version of “we’re in better shape,” a clock instead of a dollar amount. The finding count dropping year over year is another, and the exceptions thinning out of the process you tightened a third. Counts and clocks are both confirmable.

The rest is easy if you do it early. Before the project starts, you pull last year’s audit results, count the findings, and clock how long the evidence gathering took (ask the person who lived it, they’ll remember to the day). That’s the baseline, and it’s the step everyone skips and nobody can fake later.

Then you set the date you’ll run the same numbers again, while the team that owns them is still assembled. What’s left is attribution: showing the findings dropped because of your project, and not because the auditor was gentler this year or a reorg shuffled things around. Get the baseline written down before you start, and the attribution mostly holds itself together.

Experience: When “People Seem to Like It” Isn’t an Answer

The city council approved the park renovation, it got built, the mayor cut the ribbon, the photos went up, and everyone felt good about it for a quarter or so. Then a council member asks the question every capital project meets at some point: “Was it worth what we spent?”

The answer that usually comes back is the satisfaction survey: 4.2 out of 5, and everyone exhaled. But it doesn’t tell you anything. Not whether one person changed what they did, not whether the park pulled anyone off the couch, not whether the new intake form saved a single phone call, only that the people who bothered to answer were mildly pleased. It lets everyone treat “Was it worth it?” as answered without anyone having to answer it. “People seem to like it” is where the conversation loses steam: true, warm, and unhelpful in a budget discussion.

The survey and the counter both claim to measure the same thing, and only one of them can be watched. You’d expect a park worth the money to pull people in, so you pick the version you can watch: bolt a counter to the trailhead before the ribbon comes down.

Six weeks later, say it’s logging a few hundred crossings a day where the old path saw a handful, and that climb, unlike a 4.2, means people changed what they do. The rest follows along behind it: the pavilion classes fill, the maintenance tickets shift from vandalism to ordinary wear, the same faces come back on weekends.

The corporate version is similar: complaints drop, wait times fall, and callers start solving their own problems before they reach a human.

Pick that one indicator before the project closes, something readable within 90 days that shows behavior changing, and pin it down while the team’s still assembled, because after handover nobody owns the measurement and it withers. Track something people do, not something they rate.

Data: The Two-Day Task That Now Takes Two Hours

Start here, with the people who consume the data. Ask them, “What used to take you two days that now takes two hours?” If they can answer without pausing, you’ve got your evidence, and it’s better than anything you’d have built in a spreadsheet.

This works because decision speed is something people feel constantly and rarely measure. The report that used to finish on Thursday now finishes on Monday. The question that used to need a week of reconciliation gets answered in the meeting where it’s asked. Those before-and-afters are usually dramatic enough on their own that translating them into dollars starts to look like a downgrade. You’d be converting a thing everyone remembers into a thing nobody can verify.

I think of the analyst I worked with who spent every Monday morning fixing the same data set before the dashboard was safe to show. That was the cost, and everyone had stopped seeing it because it had become the routine, just what Mondays were for. When a project makes that Monday morning effort disappear, that’s the benefit, and you can prove it by asking her what she does with her morning now.

Her answer beats any figure you’d have modeled, for a reason that runs backwards from instinct: a dollar number invites the reviewer to argue with the number, while “I get my Monday mornings back” invites them to recognize it. You can watch them picture getting their own Monday back for the first time.

If you want it firmer than a quote, watch the workflow, and write down where it stands before you start. Count how often the “Can you re-pull this, I don’t trust the last version?” request lands in a month, then count again after the project ships. Behind that sit two more: how long the monthly report takes to produce, and how many manual corrections a dataset needs before it’s safe to show leadership.

Standardization: The Team Still Calling the Old Version “The New Process”

“Seven of eight teams are on the standard process, and exception tickets are down by a third.” If you can say that sentence and mean it, you’ve got a benefit. Most standardization projects report a different one: “We rolled it out,” and that describes a day, the day everyone got trained and the email announcement went out.

Look at what “rolled it out” is covering for. You delivered the new standard process six months ago. Three regions adopted it. Two built workarounds that technically comply while doing more or less whatever they did before. And one is still running the old version, with a straight face, and calling it “The new process.” Delivery was the day you shipped it. Adoption is what you were after, and adoption keeps shifting for months after someone declared the project done.

You’d expect a process that took hold to show fewer workarounds, so the operational version is the exception queue. Every workaround throws an exception, and within a month they cluster under the one region that never really switched. Behind that sit two more: the real count of teams on the standard process, a smaller number than the rollout attendance sheet, and the escalations that stop once every group quits solving the same problem its own way.

This is why the date you read it matters. The launch is where everyone measures, and the launch is the one moment guaranteed to look good. So build in an adoption check at 30, 60, and 90 days, a query and a short conversation with each team lead, easy enough that nobody objects. The real test comes weeks later, when the training wears off and people decide for themselves whether the new way is worth keeping, and if you weren’t watching then, you measured the wrong week.

The Whole Method

Four stories, one sequence, and you’ve now watched it run four times in four examples. Pick a benefit on a current project, the one where someone’s either inventing a number for it or avoiding the subject without saying so, and take it through the same four steps.

Say what you’d expect to see if that benefit were real. Pick the operational version, the one you could watch change. Write down where it stands today, before you go any further. Set the date you’ll read it again. That’s it, and there isn’t a step five. Every project needs all four, in whatever order they come to you.

Then picture next year’s quarterly review. The portfolio slides are up, the same VP leans in, and the same question lands on the compliance project: so what was that one worth to us? This time the project manager pulls last year’s findings up against this year’s and shows the evidence-retrieval time cut from a week to a morning, the thing she said she’d expect to see, written down before the project started, read again on the date she set.

It’s a smaller claim than $400K. It’s also one she can look the VP in the eye and stand behind.

The PMO’s job was never to put a dollar sign on everything that came through it. It was to make sure the organization could tell the difference between a benefit that happened and one that didn’t.

The meeting ends, and fourteen people close their laptops. Someone says, “good discussion,” which is what people say when they can’t point to anything the meeting accomplished.

The AI notetaker gives you the minutes, complete with every part captured. You scan it for what got decided and there’s nothing to pull. The transcript is full, but the outcomes section is empty.

I’ve run that meeting. I’ve also scheduled it, invited the wrong people, and let it run on autopilot because it was already on the calendar and had been for a year. The reflex is to blame the discussion, or the two people who talked too long. None of that is the cause. The meeting stumbled before it started, because nobody decided what it was supposed to produce.

A meeting you can’t define can’t succeed, because there’s no version of “done” to reach.

So the first question is what this meeting is for.

One Meeting Can Carry One Goal, or Five

Sometimes a meeting has a single goal. You’re there to pick the launch date, and once it’s picked, you leave. Other times, one hour contains several goals: the first ten minutes to share the migration status, the next twenty to work through a defect, and the last fifteen to lock the vendor choice. Both are fine.

The trouble starts when you run the second kind like the first, where the status update, the defect, and the decision all melt into one long “discussion,” and the decision that needed the hour gets four rushed minutes at the end.

When you know which goal an agenda item is serving, you know how to run it. You know whether the two people who can approve the budget have to be there, or whether this is fine to handle async. You know what to type on the agenda line. And you know the thing most agendas never say, which is what has to be true before you move to the next item.

If you leave that unsaid, the same three failures will show up every week.

This week, you’ve probably multitasked your way through all three of them.

The Three Ways a Meeting Goes Wrong Before Anyone Speaks

The Discuss Trap

The agenda line says, “Discuss Q3 roadmap.” Discuss tells you what you’ll be doing for an hour but not what you’ll have when it’s over, so the hour fills with good conversation and ends with nothing accomplished. I wrote agendas full of “discuss” for too long. They felt safe. Each one was a decision I didn’t know how to facilitate, hidden behind a word that let me put off learning how to lead it.

The Stowaway Decision

The invite says “Information sharing,” and twenty minutes later, the group hits a real decision nobody scheduled. It gets dodged, because the people who could make it aren’t all here, or someone makes it on the spot and two others leave believing something different was agreed. The decision needed its own slot with the right people in it. Instead, it rode in on the coat tails of a meeting called for something else, and you find out it was never settled when it comes up again next week.

The Status Parade

Eight people take turns reporting what they did since the last meeting. Each update is fine. None of them needed the other seven people in the call to hear it live, and nothing in the hour required anyone to be in the same place at the same time. It’s a document read aloud, slowly, on everyone’s calendar every week. The reality is if no one in the meeting has to respond to what’s being said, it doesn’t need to be a meeting.

If you put the real goal on the agenda line, out loud, all three of these failure modes lose their cover. This assumes you know what a meeting goal can really be.

It turns out there are only five.

TEAMS: The Five Goals a Meeting Can Have

Five goals. Some meetings have just one, while others move through three before the hour is up. None of this asks you to redesign how your company runs, or to sit through a workshop about meetings, which is its own special punishment. Each goal has a verb, because a goal is something you do together, and a finish line, because a goal you can’t reach isn’t worth setting.

T: Tune Teamwork

Strengthen how the team works together. It’s done when something between people is better than it was.

E: Exchange Information

Share or gather what people need to move. It’s done when everyone has what they came for, and not a slide more.

A: Align the Work

Get everyone holding the same goals, priorities, and sequence. It’s done when two people describe the plan the same way.

M: Make a Decision

Choose a path and write it down. It’s done when the decision is recorded and the owner is named.

S: Solve a Problem

Find the cause of a blocker and agree on the response. It’s done when you know the next action and who owns it.

The five look similar on a list. Inside the meeting, they behave nothing alike, and treating them all the same is how the hour gets wasted.

What to Do in the Hour, One Goal at a Time

Five goals, five ways to run an agenda item in a meeting. Each one below gives you the agenda line, the steps that get you to the finish line, and the trap that can sabotage you. The first is the one that breaks the moment you try to run it like the rest.

Tune Teamwork: The Meeting That Works Better the Less You Talk

The agenda line: “Retro: what’s slowing us down that we keep not saying. 30 min.”

If you run this one like the others, you’ll spoil it, because the part worth hearing is the part people are reluctant to say, and the moment you tighten the structure, they retreat to the safe version. So you do less, not more:

1. Ask one question you don’t have the answer to, then stop talking. The first ten seconds of silence feel like failure and are usually the question working.

2. When the safe answer comes, ask what’s underneath it once, then let it sit.

For a long time I filled that silence myself, because ten seconds of nothing felt like the meeting failing. All it did was turn the session into green-status updates and teach people to keep the real concern to themselves. The pause was the opening; I kept closing it.

You know it’s done when someone says the thing they’d otherwise have saved for the hallway after.

Exchange Information: Are You Broadcasting or Collecting? Pick One

The agenda line: “Vendor migration update: share status, take questions. 10 minutes.”

Before you send the invite, decide whether you’re broadcasting information or collecting information, because they’re run differently, and most of these meetings fail by being neither.

If you’re broadcasting, send the document the day before and spend the meeting on questions. Reading slides aloud to people who can read is the most common way to lose a half-hour, and they can read faster than you can talk.

If you’re collecting, send the prompt a day ahead so people show up with something better than what they’d invent on the spot in front of nine colleagues. Then go person by person so the people who hang back don’t get skipped.

You know it’s done when every open question has either an answer or a name next to it, and the people who came to learn something can say what they learned.

Align the Work: Why a Head-Nod Isn’t Agreement

The agenda line: “Q3 priorities: confirm the order and who owns each. 15 minutes.”

The danger here is that agreement and a polite head-nod look identical in the moment, so you leave thinking you’re lined up and find out in two weeks that you weren’t. The goal is to make people show you the disagreement before the meeting ends:

1. Put the plan where everyone sees the same words on the same screen. Spoken-only alignment is where people hear different things and all nod.

2. Ask two people to say the priority order back in their own words. This is where you learn they’d been carrying different orders the whole time.

3. Go looking for the gap the polite people won’t raise. Ask who’s holding a concern they haven’t said yet, then wait longer than is comfortable.

The trap is the alignment that feels best in the moment: quick, friendly, and no pushback, because silence sounds like agreement when it can be just politeness or people multi-tasking. The meeting that ends early with everyone nodding could be the one you’ll be re-aligning next week.

You know it’s done when the playback matches and the people who never talk have said something out loud.

Make a Decision: Why Decisions Made in Meetings Don’t Stick

The agenda line: “Launch sequence: decide between Option A and Option B. Decider: Priya. 20 minutes.”

Write the choice and the decider into the invite before the meeting, so nobody arrives thinking it’s a brainstorm. Then, in order:

1. Put both options on the screen with the tradeoff under each, one line each. If you have a recommendation, say it now, not at the end.

2. Review the objections before the vote, not after. Ask what breaks if we pick A, then what breaks if we pick B. An objection raised now gets handled; the same objection raised next week reopens the whole decision.

3. Write the decision on the screen while everyone’s still there: one sentence, the chosen option, the owner’s name, and the date. Read it aloud.

The thing that derails this one is the slide from deciding back into diagnosing: someone reopens the underlying problem mid-decision, the group follows them, and twenty minutes later you’ve had a rich conversation and still haven’t chosen. When it starts, say “Are we deciding or re-opening this?”, and pick one.

You know it’s done when there’s a written line with a decision, the decider, and a date ready for the decision log.

Solve a Problem: The Question to Ask Before Anyone Proposes a Fix

The agenda line: “Checkout errors spiking: find the cause, agree on next step. 30 minutes.”

Do these in order, because the instinct in the moment is to start naming fixes before anyone has agreed on what’s broken, and a fix aimed at the wrong cause just creates the next meeting.

1. Spend the first third on symptoms only. What are we seeing, where, since when. No solutions allowed yet, and say that out loud so people stop reaching for them.

2. Ask what would have to be true to call this solved. That sentence is your target, and it keeps the fix tied to the real cause instead of the loudest one.

3. Only now open the floor to responses, and end on one next action with a person’s name on it.

I once watched a team spend forty minutes debating which vendor to switch to before anyone asked whether the vendor was the cause. It turned out It wasn’t. We’d skipped step one and were solving a problem we hadn’t found yet.

The trap is the agenda line that crams “Find the cause” and “Approve the fix” into one item, so the group swings between diagnosing and deciding for half an hour and doesn’t do either cleanly. Those are two goals. Give the decision its own line.

You know it’s done when you leave with a next action and an owner, not a richer description of how stuck you are.

The One-Line Habit That Changes the Meeting

Put the goal on the agenda line. “Q3 roadmap” becomes “Q3 roadmap: decide the launch sequence, decider: Priya, 20 min.” Then say it out loud when you reach that line, so the fourteen people know whether they’re there to inform you, line up with each other, or help a decision get made.

It might look too minor to change a meeting. But it works anyway, because everyone there finally knows what the finish line looks like for the next twenty minutes.

So pick the meeting you dread most this week. Before you send the invite, write the goal beside each line. The lines you can’t fill in are the ones you might be able to cut, because those were never going to produce anything, and now you can prove it before the meeting instead of after.

If you’ve spent any time around project advice, you’ve heard the same lesson I had: get clarity. Turn the fog into a decision, the discussion into an owner and a date, and the ambiguity into something a person can act on. It’s good advice. I’d taken it to heart, and most of the time it served me well.

A few years ago I led a process improvement project for a call center on exactly that principle. We left the kickoff meeting with every box checked. The decision was made, everyone nodded, and we were moving.

Two months later, everything was falling apart in slow motion, and nobody on the team was surprised but me.

The sponsor and project team committed in the kickoff and then drifted back to the work they cared about more. The dates slipped one week at a time. When I went looking for what happened, the plan had nothing to do with it. The damage was in everything the plan didn’t ask about: who was unconvinced, who was apathetic, and who really didn’t want the project to succeed since it would change their work habits they were accustomed to.

I’d answered one question well. Clarity: What should happen next? I’d answered it crisply and on time. I just hadn’t noticed the project was asking me three other questions at the same volume, and I wasn’t tuned in to any of them.

That’s the failure I want to talk about. It wasn’t a competence problem; it was a hearing problem.

Clarity is the answer to one question, what should happen next?, and I’d been treating it like the answer to every question. Most of us are good at one or two of the questions a project asks, but half-deaf to the rest.

Learning to hear which one a project situation is really asking is the part no one put on a slide for me.

Four Questions Hiding Inside Every Stuck Project

Every stuck project is asking one of four questions. They spell DIAL, which is convenient, but the order is a mnemonic, not a sequence. You don’t march through them D to L. You keep all four in mind and figure out which one the situation in front of you is demanding right now.

1. Decide: What should happen next? This is the question of action, priorities, and the next concrete step. If you answer it well, you create momentum. If you lean on it too hard, you act before you understand what you’re acting on.

2. Investigate: What’s really driving this? Root causes, dependencies, and the assumption nobody checked. If you answer it well, you understand the thing instead of just its symptoms. If you overdo it, you analyze a problem to death while it just gets worse.

3. Align: Who needs to agree, decide, or commit? The stakeholders, the owners, and the explicit yes on the record. If you answer it well, the decision sticks. If you overdo it, you chase consensus until the people suffocate.

4. Lead: What’s shaping people’s behavior? Trust, incentives, fear, and the things that decide whether people do what they said they’d do. If you answer it well, you change what happens on the ground. If you only get it half-right, you understand people beautifully while nothing about the outcome changes.

Four questions, and four ways a project can be stuck. The catch is that a stuck project usually doesn’t directly tell you which one it needs. It hands you a symptom, and the symptom usually points at the wrong question.

Subscribe now

How to Tell Which Question the Project Is Really Asking For

Knowing the four questions is the easy part.

The hard part is diagnosing which one is needed right now, because the visible problem will often mislead you. A missed deadline looks like a Decide problem (push harder, set a firmer date) when it’s just as often an Investigate or a Lead problem instead.

So here’s what I look for now. These are the signs that point me to the question I’m really dealing with.

It’s a Decide problem when:

• The same topic comes back meeting after meeting with no owner and no date attached

• People keep saying “We should probably…” and nobody turns it into a committed step

• The team has stalled waiting on a yes from you that you didn’t know they needed

It’s an Investigate problem when:

• You’ve “fixed” this exact thing before and it keeps coming back

• Everyone’s confident about the cause and nobody can point to the data behind it

• Every proposed fix is aimed at the deadline, and none of them ask why the work keeps arriving late

It’s an Align problem when:

• A decision gets reversed by someone who was never in the meeting that made it

• Two people each assume the other one owns the same piece of work

• The work is moving along, but the one person who can veto it has never said yes

It’s a Lead problem when:

• People agree in the meeting, then their calendars and their focus go somewhere else

• A decision everyone signed off on keeps reopening, and no one will say why out loud

• People do exactly what you asked and not one thing more

The rule of thumb I’d give my younger self is that the real question a project is asking is rarely the one it’s broadcasting loudest. Study the symptom, then ask which of the four is sitting underneath it. Tuning your ear to hear the question underneath the one being asked out loud is the skill I’m still working on.

A quick caveat before we walk through the four questions. Save this for the projects that resist the obvious move: the stuck ones, or the ones where pushing harder keeps not working. Most decisions in a project week are small and reversible, and the right call is to make them and move on.

This article is for when the project fights back. We’ll take the four questions one at a time, starting with the one most of us reach for first.

Decide: What should happen next? The Question We Reach for Too Soon.

Decide: What should happen next? is the question of momentum. What’s the next step, who owns it, and when’s it due. When it’s working, a circling conversation turns into something a person can pick up and go do. It’s the most satisfying of the four to answer, which is exactly what makes it dangerous.

I once sat in an executive status meeting that had gone in circles for three weeks, got tired of it, and forced the decision. Owners assigned, dates set, done. It felt like leadership. Two weeks later, the work was scrapped, because the circling wasn’t indecision. It was the team sensing a broken assumption no one had pulled into the open. I’d applied a Decide answer to an Investigate problem and just brought us more rework.

Momentum is only worth something when it’s pointed the right way, and sometimes the most useful thing you can do is refuse to decide yet and ask what’s really going on.

Investigate: What’s really driving this? The Question That Looks Like Slowing Down.

Investigate: What’s really driving this? is the question underneath the symptom. What’s really driving this: the dependency nobody owns, the assumption everyone inherited, the data nobody pulled. It feels like slowing down, but it’s usually the thing that prevents the next three slowdowns.

A forensics system release I worked on kept slipping, and the easy story was that engineering was slow. I ran with that story longer than I should have. I pushed the team, tightened the standups, and watched it slip anyway. It was only when I gave up on pressure and went through the sequence of events that every slip traced back to one approval step with no owner. One fix to that handoff, and the slips stopped. The visible problem was slow velocity. The real one underneath was a gap in ownership I’d spent a week making worse before I looked for it.

But understanding a problem clearly is its own trap, because a decision still has to get made, and the next question is who gets to make it.

Align: Who needs to agree, decide, or commit? The Question That Decides if the Decision Sticks.

Align: Who needs to agree, decide, or commit? is the question of the formal yes. Who has to agree, who owns what, and who needs to commit on the record before the work gets done. A decision made by the people in the meeting and a decision the people not in the meeting will honor are two different things.

A data management team I supported locked a technical direction in a well-run meeting and started building the next day. Three weeks later, the one director who skipped that meeting reversed the decision, and the three weeks went with it. Nothing was wrong with the decision itself. The wrong people had made it. A five-minute yes from the right person beforehand would have saved the entire rebuild.

But the formal yes is only half of it. People can agree on the record and still not move, and that gap is where the last question lives.

Lead: What’s shaping people’s behavior? The Question About What People Do After They Agree.

Lead: What’s shaping people’s behavior? is the question of what’s shaping behavior below the line. Trust, incentives, fear, and the unspoken thing that decides if the yes in the meeting becomes action in the week. Align gets you the agreement. Lead determines if anyone acts on it after they’ve left the meeting. This is the one many frameworks skip, and it decides more than any of the other three.

I had a system implementation project where everyone kept agreeing in planning, and then the work would stall anyway. It took me too long to notice that the senior engineer went silent every time timelines came up. Not resistant, just unconvinced and unwilling to say so in front of the group. I caught him after a meeting and asked what I kept missing. He said, “Every time I push back on the date, it sounds like I’m the one who can’t deliver. So I stopped pushing back.” He’d been sitting on a real schedule risk for weeks, and the structure of every meeting had taught him to keep it to himself. The plan only moved once people felt safe enough to tell me the truth about it.

Once you can hear all four at once, the kind of project that fell apart at the start of this article looks completely different.

The Loudest Symptom Is Rarely the Real Problem

Projects get stuck when they’re asking a different question than the project manager is answering. The missed deadline looks like it wants a firmer date. The circular meeting looks like it wants a faster decision. More often, the real question is hiding one layer deeper: a root cause that’s still hidden, a stakeholder nobody asked, or a disagreement two people haven’t resolved.

The process improvement project I lost at the start of this article had plenty of clarity: clear owners, clear dates, and clear next steps. But the three questions crouching under that clarity are where it came apart. Clarity answers what should happen next. It was never going to answer the other three.

So when the dates start slipping now, the slip isn’t the thing I respond to first. I go looking for which of the four questions the project is asking me, and most of the time, it isn’t the one that’s loudest.

The enterprise analytics platform implementation cleared the intake gate on a Wednesday. It had a clean charter, a risk register with the usual entries, and a sponsor who’d shown up to every intake session and wanted this badly. The sponsor was our CFO.

Nobody in the intake committee had a real objection, and they approved the charter. They brought me on as project manager the week after.

It passed every check during intake, and then it unraveled two months later on something that was already true on the day it was approved. The charter named a vague, unspecified budget source for the work.

The CFO didn’t really have the money in his budget.

He figured he could scrape it together from a few places before the first vendor payment came due. The time came to write that check, and the budget wasn’t there.

I remember the call with the vendor to reschedule a payment I already knew wasn’t coming. Two months of planning and work, gone.

I read that funding line as a fact, same as everyone else. That’s the trap. The big risk is the project that clears intake and then falls apart in execution on a flaw that was in the charter the whole time. Passing intake and surviving delivery are two different tests. Most organizations are funding work that’s approval-ready, not delivery-ready, and intake is where the two get mistaken for each other.

If your intake process would have approved the analytics platform project too, and most would have, the helpful question is why.

What Your Intake Process Is Built to Check, and What It Skips Without Noticing

Start with the mechanics, because none of this is anyone’s fault.

The intake process is built to produce a defensible record. Finance and risk functions design it so the organization can show an auditor or a board that it did its due diligence before investing funds. So intake checks that the artifacts exist and the boxes are filled in. Is there a business case? Yes. A risk register? Yes. A resourcing plan, a benefits projection, a sponsor signature? Yes, yes, yes.

That’s a real job, and intake does it well.

The trouble starts because “The artifact is filled in” and “The thinking inside the artifact is sound” are two different tests, and intake focuses on the first one. A charter with a budget source passes. Whether that money is real goes unasked. The analytics platform funding line was right there in section 3 of the charter. It just wasn’t true, and nothing in the intake process was looking for true.

I’d sat on the committee side of that table before, too, and signed off on charters the same way, checking that the section was filled in, not whether the answer in it would hold.

That’s why the gap is so durable. It’s structural, not a training problem and absolutely not a lazy governance team.

Picture the audit that intake is built to survive: someone comes back a year later and asks whether the charter existed, whether the sponsor signed, whether the benefits case was attached. They never ask whether the information inside was valid. An intake optimized to pass that review rewards completeness, because completeness is what holds up when someone checks.

Validity is slower to test and doesn’t photograph well in a review meeting, so it gets assumed.

A working intake process confirms the charter is complete. Adding four questions covers the part it skips: whether the charter is true.

The Four Questions That Separate Looking Ready From Being Ready

Everywhere a plan can be complete and wrong at the same time, you ask one question: is this verified, or just written down? Here are four places where that question earns its keep.

Subscribe now

Assumptions: what’s written as settled that nobody confirmed.

Plans rest on assumptions that have to be true for them to work, and most plans bury them as flat statements of fact: funding is in place, the new platform supports our volume, the vendor’s API is stable. A guess and a confirmed fact look identical in the assumptions section, and the intake committee can’t always tell which is which.

Here’s the move, and it’s the question I’d spend the most time on. Ask the team for the handful of assumptions the whole project rests on, then ask which ones they’ve verified and which ones they’re hoping hold. A delivery-ready team answers without flinching: “These three we’ve confirmed, this one we haven’t, and here’s what we’re doing about it.” An approval-ready team treats every assumption as settled because writing it down felt like settling it.

When you hit a load-bearing one that’s a guess disguised as a fact, don’t just flag it. Make verifying it a condition of intake approval.

And yes, confirming an assumption doesn’t make it certain. Some you can pin down (is the budget committed, or not, go ask). Others you can’t know yet, and those stay bets no matter how hard you look. The point isn’t to turn every assumption into a fact. It’s to stop the unconfirmed ones from sitting in the charter disguised as facts, so the ones that can be checked get checked and the ones that can’t get watched.

The project gets conditional approval, but the unconfirmed assumption gets an owner and a due date, and it isn’t closed until someone comes back with proof. One question on my analytics platform project. “Is the budget committed, or is the CFO still assembling it?”, would have turned a charter line into the open risk it always was, and either firmed up the money or stopped the project two months earlier than I did.

Start asking which assumptions are confirmed, and you find out fast how much of the plan is resting on the readiness question next.

Readiness: whether the people and dependencies are real or just named.

A resourcing plan names a lead architect, two senior engineers, and a SME from the data team. Intake checks that the names are there. It doesn’t check that the architect is already committed at 200 percent across two other projects.

The first time I called the names on a resourcing plan instead of trusting the document, half of them turned out to be aspirational: the right people on paper, none of whom anyone had asked. Named on a plan and available in week three are two different things, and the gap between them doesn’t show until the project manager reaches out and finds a calendar full of other people’s deadlines.

So go down the list and ask one question per named person and dependency: when this plan reaches for you, will you be there? Push on the dates while you’re at it. Is the upstream system ready by the date the schedule needs, or is that just the date the schedule needs it to be?

Anyone who can’t give you a straight yes goes on the open-items list as a staffing or dependency risk before the project starts, not after it’s three weeks behind.

The next failure mode hides in time instead of headcount.

The first thirty days: whether anyone agrees what happens at the start.

If this were approved today, what happens in the first month, and does the team that has to do it agree with that answer?

A delivery-ready project has a concrete, already-agreed-upon view of the opening weeks. People have debated over sequence, landed somewhere, and can tell you what week one looks like. An approval-ready project has a milestone chart that gets specific around month four and stays vague before then.

Make them walk you through the first thirty days out loud, in the review, without the slides. If the answer comes back smooth and detailed, that’s good. They’ve done the hard part already.

The one time I pushed on this and got two team leads narrating two different first weeks, that disagreement was the whole project’s risk in miniature, out in the open in a five-minute conversation instead of in month four. When you get that, it’s your cue to pause and get the team aligned on the opening sequence before the project starts.

The last question is about the document that’s supposed to catch all of this and usually doesn’t: the risk register.

Failure: whether the risk register names what really sinks a project like this one.

Open most risk registers and you’ll find the same entries: scope creep, resource constraints, stakeholder alignment, timeline pressure. They’re real, and they’re also boilerplate, copied forward from the last project and the one before that. They show up on every register for every project because they’re safe to write and almost impossible to be wrong about. They’re risk theater, added so the field isn’t blank, and they don’t tell you anything about this project.

So set the register aside and ask one direct question: what’s the single most likely way this particular project fails, and what in the plan addresses it? A team that’s thought hard about delivery answers in one sentence: “Honestly, if the funding the sponsor’s counting on doesn’t come together, we’re dead the day the first invoice lands.”

That one sentence is worth more than a register full of generic entries, because it’s specific and it forces a decision. And this is the test where you don’t just log the answer and move on. If the most likely failure is something the plan has no response to, that’s the moment to make the call in the meeting: approve with a hard condition attached, send it back to address the gap, or decline to fund it until the gap is closed.

On my analytics platform project, that one question would have turned the funding from a line nobody questioned into the condition the whole approval hung on.

Four questions, one idea underneath all of them. The catch is they only help if they happen before the money’s committed.

Where These Four Questions Go in an Intake Process That Already Works

The good news is that this fits inside the process you already run. These four questions become part of what a project answers before it passes:

1. State the assumptions you’re leaning on and mark which ones aren’t confirmed.

2. Show that the people you’ve named are available when the plan needs them.

3. Walk through the first thirty days.

4. Say the one way everything most likely fails.

The team answers these four as they put the charter together, not in a new meeting. It’s part of preparing to submit, the same as any other intake field. Then the intake review you already have spends its time pressure-testing those answers instead of re-confirming the boxes are filled. It’s the same meeting, just better use of it.

What you’d write down is short: the unconfirmed assumptions, the dependencies that aren’t real yet, the single most likely failure. It rides alongside the approval rather than blocking it, so the project gets funded with its eyes open.

When I started doing this, the surprise was how much the good projects liked it. A team that’s genuinely ready clears these four questions in minutes, because they already have the answers, and they walk out with their readiness on the record instead of just assumed.

The questions slow down the projects that need slowing and let the solid ones through clean. That’s a better deal for the strong teams than an intake that treats everyone the same.

And once you’re asking them, the job you’re doing changes shape.

The Job Is Bigger Than Approving Projects

Run my analytics platform project back through those four questions, and it doesn’t get rejected. It gets approved with one hard condition: the funding source is named but not committed, so nothing kicks off until the CFO confirms the money is real. Same project, same intake committee, same Wednesday.

The flaw that was going to end it in month two becomes a question the CFO has to answer in month zero, while he still has room to answer it, instead of one line in the charter that everyone read as a fact. Maybe he firms up the budget and the project lives. Maybe he can’t, and we never waste the two months.

Either way beats the version I lived through.

That shift is yours to make, because you own the intake process. An intake that only checks completeness leaves the PMO processing approvals: stamping projects that looked ready and inheriting the ones that weren’t. Add the four questions and you start catching the optimism before it gets funded, which beats fighting the same fires after the money’s committed.

I started small, on the next project in my queue. I asked the team for the one assumption that, if it turned out false, would sink the whole thing, then asked whether they’d confirmed it. That single question told me which kind of ready I was looking at, approval-ready or delivery-ready, and it took about a minute.

You can ask it of the next charter in your next intake meeting.

I once sat in a one-hour meeting where a man told me he was a director at a Big Four firm seven times. I wasn’t keeping score on purpose. By the fourth time, I was.

I worked with another person for a full year before I found out she’d graduated from Harvard. It came up nonchalantly, the way real things do, in a conversation that wasn’t about her. By then I already knew she was the person I’d want on anything that was going badly.

Two credentials. One announced itself every nine minutes, and the other waited a year and would’ve waited longer if the subject hadn’t come up on its own. I trusted the second person before I knew her credential and the first person less every time he repeated his.

Conan O’Brien Explains This Better Than I Can

Conan O’Brien gave a commencement speech at Harvard where he closed by telling the graduates,

“My wish for you is not that Harvard becomes the last thing people know about you, but instead that Harvard becomes the least important thing people know about you.”

Think about the difference between those two words. Not the last thing people learn about you, the least important. A good project manager’s certification isn’t the final fact anyone discovers; it’s the one that matters least once they have the rest.

The woman I worked with had pulled it off. The Big Four director was still working on it, the way a lot of us are for longer than we’d like to admit.

We have our own version of that line in this profession, and it’s three letters long. PMP.

I led with mine once. Early in my career, in a meeting where I was the youngest person in the meeting and the least sure I belonged, I worked the PMP into my second sentence. Nobody had asked. I said it because I didn’t yet trust the rest of myself to earn everyone’s respect, and the certification was the one thing I could point to that I thought would land. I wasn’t bragging. I was reaching for a railing.

Later, I began to notice that the people I respected in those meetings never reached for theirs, and that the reaching itself was the sign.

Subscribe now

The PMP gets your resume past the HR filter. It gets you into the conversation with a stranger who can now assume you know what a critical path is without you proving it. That’s important, and it’s worth having.

But it’s never once been the thing people say about you in the meeting you’re not in. Nobody in that meeting says she’s PMP-certified. They say she’ll tell you the truth, or things don’t come apart when she’s running them, or she’s the one I’d want if the project goes sideways.

That’s the credential that makes you successful, and it isn’t printed on anything.

The Credential Is the One Thing You Can Prove in an Hour

It’s worth being fair to the Big Four director, because his mistake is one we all make for an understandable reason. The credential is the one thing about yourself you can prove in a room full of strangers. Your judgment, the way you handle a project coming apart at the seams, whether you’ll tell a sponsor the truth they don’t want, none of that is visible in an hour. It takes months to show, and a stranger doesn’t have months. The cert takes a sentence.

So the man who’s been in the meeting for ten minutes reaches for the thing he can hold up fast, and the more he wants to be taken seriously, the more often he holds it up. Call it the gap between how good you are and how long it takes anyone to find out. Vanity has nothing to do with it.

If you don’t have a PMP yet

You might be the most capable person on your team and not have the certification. I’ve worked with people like that. They successfully run the project and make it look easy, while the ones with a PMP always seem to be struggling. The work is real, and anyone who’s watched them for a week knows it.

Here’s the part that stings anyway. The recruiter who sets up the filter at 8am with forty applications in the queue will never see any of that. She sees a field that either has the cert or doesn’t, and she’s screening for reasons to make the pile smaller.

The PMP isn’t a verdict on whether you can run a project. It’s a key to a door, and the people on the other side of that door can’t watch you for a week until you’re already through it.

So get the PMP. Not to prove anything to the people who already know your work, but to reach the ones who’ll never get the chance to.

If you just got it

You earned it, and it was hard, and you should enjoy the week. Then put it away.

The freshly certified are the ones most at risk of becoming the Big Four director, and it isn’t vanity that does it. It’s that the PMP is the most recent hard thing you pulled off, and recent hard things have a way of becoming the headline.

I watched a sharp young project manager open a kickoff once by telling a room full of clients she’d just earned her PMP. They nodded, politely, and then spent the next hour judging her on how she ran the meeting, whether she kept it on time, whether she caught the scope problem hiding in the third agenda item, and whether she pushed back when the client tried to squeeze in additional scope for free.

The certification bought her about sixty seconds of goodwill. The next fifty-nine minutes she had to earn, and the PMP exam hadn’t prepared her for a single one of them.

The certification is the floor you stand on, not the story you tell. The story is what you do in every meeting and in every conversation, while the certificate sits in a drawer. A year from now, nobody you work with will be impressed that you passed an exam.

They’ll have formed an opinion about you that has nothing to do with it, built entirely out of how you showed up every day.

If you’ve had it for years

At some point you stopped mentioning it. You might have to think for a second to remember the year you passed the exam. It’s on the resume in the same font as everything else, and it hasn’t come up in a real conversation in a long time.

But there’s a version of this that goes wrong. It belongs to the person who treated the PMP as the destination instead of the entry, who stopped building anything once the certificate was on the resume because it felt like enough. Five years later, they’re the most-certified person on the team and still the one nobody fights to get on their project. Same tenure, same credential, and when their name comes up in a room they’re not in, the conversation goes quiet for a second because nobody can think of the sentence.

The PMP kept its original promise; they just never built anything on top of it.

But that’s not the only way the years go. There’s a good ending too, and if you’ve stopped mentioning your PMP because better things crowded it out, you’re already living it. The PMP did its job years ago, got you through some door you don’t even remember now, and then it receded the way scaffolding comes down once the building stands on its own. What grew in its place is the thing people reach for when someone asks them, in a meeting you’re not in, whether you’re the one for the job.

I was in one of those meetings a while back, the kind where leaders are deciding who gets handed the project that cannot fail. Someone said of a project manager, “I trust her to do the right thing and to tell us about it before we have to ask.” That was the entire endorsement. No certifications, no methodology, no track record of on-time delivery. Just that she’d do the right thing and say so early.

She got the project in under a minute. That sentence is worth more than any letters you can put after your name.

That’s the version of you the woman I worked with had already become by the time I learned where she went to school. The Harvard fact was true the whole time. It just wasn’t the point.

Write Down the Sentence You Want Them to Say

Here’s one thing worth doing this week. Picture the meeting you’re not in, the one where someone’s deciding who’s going to manage the project that can’t fail. Your name comes up. Somebody at that table says one sentence about you.

Write it down, the sentence you’d want them to say. Not your title, not your PMP. The one about what you’re like to count on when the work gets hard. Then go look at your last month and ask whether you’ve been earning that sentence or just renewing the credential.

The director said his seven times and I left knowing nothing else about him. The woman never mentioned hers, and I’d have followed her anywhere. One of them I’d put on the project that can’t fail.

Your sentence already exists. Someone, somewhere, would say it about you today. Make sure it’s one you’d be proud of.

Two years ago, a project charter arrived in my inbox from a project manager I’d never worked with - a different organization than where I am now. I’d blocked twenty minutes before our intake meeting to read through it. Before I finished the first paragraph I knew. The business case was generic enough to be about any project at any company. The risks were the standard five (scope, stakeholder alignment, resource constraints, dependencies, and “communication”), the same five risks I’d seen on the last three charters that had come my way. The risk response language read like it had been written for nobody in particular.

I finished the charter. I formed an opinion about the project manager. The opinion was not generous.

The project manager hadn’t done anything unusual. It was 1:47pm somewhere. The charter was due at 2pm. Generative AI wrote something that looked like a charter. A few words got swapped. It got sent to the group, including me.

The Receiving Side: What AI-Written Documents Look Like to Everyone Else

Most of the writing about AI and project management focuses on the sending side: better prompts, faster drafts, more output per hour. The receiving side gets less attention. When a charter, status report, or post-mortem looks like it came out of a vending machine, the reader can tell. A generic prompt goes in, generic output comes out, with no thinking visible in between. In the small way, the reader’s view of you shifts down a notch and doesn’t easily shift back.

What follows are four prompts I run on my own work before I send it out. Each one takes a few seconds to paste in and a couple of minutes to read what comes back. They’re the few minutes between a charter that becomes an example for future charters to emulate and a charter that gets kicked back to the curb.

I’ll start with the one I reach for most. One of the four has changed my work more than the others, and I’ll tell you which when we get there.

The Scorecard Prompt: The ten-second check that catches the lazy draft

This is the prompt for the moment your weekly status report has to land before the Monday leadership sync, or the executive update is going out at 4:55pm, and you want a quick read on whether to send it. It takes longer to refill your coffee than to run it. There’s no judgment required from you. You’re just asking AI to grade its own homework against criteria it would otherwise skip.

Two things make this prompt work. The first is giving AI specific dimensions to score against, so the rating means something. The second is asking it to define what a 10 looks like for your specific reader before scoring. Because without that, AI rates against its average sense of the document type, and that’s the same generic baseline you’re trying to escape.

The “Be direct, not encouraging” line does more work than it looks like. Without it, AI will tell you the document is an 8 and suggest you “consider adding more detail.” With it, you get something closer to “This is a 6 because the risk register lists three risks without saying which one would delay the program,” or “This is a 7 because the next-steps section uses passive voice in four places and your sponsor won’t be able to tell who owns what.”

Subscribe now

The Scorecard prompt catches the obvious problems. The next prompt is for the documents that have to survive the steering committee.

The Skeptical Reviewer Prompt: The criticism your sponsor would give you, before they give it to you

This is the strongest of the four prompts, and if you only try one, try this one.

Use it when the document is going to someone who will push back: a sponsor, a steering committee, the senior project manager who’s been at the company for sixteen years and has watched this exact kind of project fail four times before.

You want the AI to give you the criticism before they do.

Generic critique prompts get generic critiques. The more specific you make the reviewer (their role, their seniority, what they’ve seen go wrong, and what they’re optimizing for), the more useful the output. AI is great at impersonating archetypes when you give it enough to work with.

The output is uncomfortable in the right way. You’ll get things like “The mitigation plan for the vendor integration risk reads as boilerplate and doesn’t reference the specific integration approach. A steering committee will read this as cover, not planning,” or “You’ve committed to a legal review window of one week, which has never happened at a company this size in my experience.”

Run this prompt once, and you’ll get back things you already half-knew alongside things that hadn’t occurred to you. A typical response might say that your “success criteria” section uses verbs no one can measure, that your communication plan assumes the change management lead has bandwidth she’s already told you she doesn’t, or that the milestone you marked as “on track” depends on a vendor decision you haven’t received written confirmation of.

That gets your project document ready for the people who’ll see it. The next prompt catches what’s wrong with the plan the document describes.

The Absent Stakeholders Prompt: What the people not on the email would say if they were

This is for anything where the impact lands somewhere other than the inbox you’re sending it to: plans, proposals, change communications, or the cutover plan that affects three teams who aren’t on the distribution list. Different audiences see different gaps, and the gaps they see are the ones that show up later as escalations, change requests, or that one chat thread that goes for forty-seven messages.

Be explicit about which audiences. And give AI one sentence of real context about each one: what they’re dealing with right now, what they’ve been burned by, what they care about this quarter. Generic “imagine three stakeholders” prompts produce generic results. Specific stakeholders with specific situations produce critiques you can act on.

You’ll find the dependency you buried in week six of the schedule, the budget assumption that’s load-bearing but unstated, and the cutover-weekend question you hadn’t thought about because operations was going to be the one fielding the calls.

By now the artifact is clear, it’s been pressure-tested, and it considers the people it affects. That covers most of what you deliver in a week.

The last prompt is for the work that will still be open on someone’s screen six months from now.

The Ceiling Breaker Prompt: The prompt that catches what “good enough” is hiding

I ran this prompt on a project charter a while back. The opening paragraph started with, “This project will modernize our customer onboarding platform to improve efficiency and user experience.” I would have shipped it. AI’s response pointed at that exact sentence and called it a throat-clearing opener that wasted the most valuable real estate in the charter. It asked what specific business problem the charter was solving.

I rewrote the opening. The next version started, “Today, sixty-two percent of new customers abandon onboarding before completing setup. This project is the work required to change that number.”

My sponsor referenced that second sentence in three later meetings. It became the version of the program leadership held in their heads. The first version would have died on the vine.

I write that kind of opening on every first draft. The prompt is what stops it from leaving my desk.

Use this prompt when you catch yourself thinking, “This is good enough.” That thought is the sign. “Good enough” is the ceiling you accept when you’ve stopped at version one and the deadline is two minutes away. I don’t run it on every artifact. I run it on the ones that will get read for a long time: the charter that sets up six months of work, the executive update that shapes how your sponsor thinks about the program, the post-mortem the team will pull up the next time something goes sideways.

Reading the output of that prompt stings when you thought you’d done a good job on the document. What stings more is realizing what people would have thought if you’d sent the version you almost shipped.

What changes when you stop accepting first drafts

When you run those prompts enough times, you start spotting the same gaps before AI does: the boilerplate mitigation in your first draft, the milestone built on the optimistic version of a conversation, the dependency you marked as managed but haven’t chased.

That’s what the prompts are for. They build a habit of pressure-testing your own thinking. Over time, you start to notice the gaps before you even enter the prompt.

The few minutes a day in these prompts are an investment in the project manager you’re becoming.

You’ve seen this failure a dozen times. You just never had a word for it.

Engineers have what they call technical debt, and I describe it as letting dirty dishes pile up in the sink. Let them sit, and you’ll deal with it eventually. Project managers have something nastier, and it isn’t the dirty dishes. It’s the water leak under that sink. The dishes wait. The leak doesn’t.

The shortcut here isn’t code, it’s people - the right stakeholder not consulted at the right moment.

It’s the decision-maker looped in three weeks late, who reopens what the team thought was closed. It’s the subject matter expert pulled in after requirements freeze, whose first question cracks an assumption the whole plan is standing on.

At the time, leaving these stakeholders out feels like you’re moving faster. But the water’s already leaking under your sink, and by week six, what would’ve cost a five-minute conversation costs three weeks. Now you’re not consulting one person; you’re tearing out everything the team built while the floor rotted under the sink.

I call this stakeholder debt: the price of every decision the project team makes without the stakeholder who should’ve been there.

It compounds the way water damage does, slow and out of sight and ruinous by the time it’s obvious. And you’ve felt it coming for years without a word for it:

• The unease that made you re-confirm a “settled” decision before a launch when you couldn’t say why you didn’t trust it,

• The stomach-drop at a senior stakeholder you didn’t recognize showing up in a meeting in week five.

You already knew how to sense it. You just couldn’t manage it on purpose because you didn’t have a name for it.

You built the stakeholder list on the right day, but the project moved, and the list didn’t. Catching that is the project manager’s job, but nothing warns you when the gap opens, so it opens unnoticed, and the cost stays hidden until it’s huge.

Subscribe now

Why You Never Connect the Rework to the Decision That Caused It

The hard part about stakeholder debt is that the bill always arrives weeks after you signed for it, long enough that you’ve forgotten you signed anything at all.

It’s week two. The team makes a call on how customer data gets retained: a reasonable call, made by reasonable people, in a meeting that was mostly about something else when the data question came up sideways.

Susan, who runs compliance, isn’t there. Nobody decided to leave her out. The decision just happened faster than the invite list could keep up, the way they do when a meeting wanders somewhere productive and you follow it.

Weeks three, four, and five are good weeks.

The team builds on that decision the way you build on anything that looks settled; requirements get written against it, a vendor conversation gets going, someone starts the first real draft. Every bit of it feels like progress, which is exactly the problem.

Then week six arrives, and so does Susan, finally looped in, asking the question that was always going to get asked, just four weeks too late to be cheap. Now, you’re pulling apart a month of work that was built on top of it.

When you do the postmortem, you’ll write down “requirements got changed.” But the requirement didn’t change. The data-retention call from week two was always going to run into compliance. Compliance just wasn’t in the conversation when it got made, so the collision showed up in week six instead of week two.

The postmortem calls it a change in scope. It wasn’t. The problem was there from the start, fully knowable, just invisible to the people in the meeting, because Susan, who’d have caught it in five minutes, wasn’t one of them. That’s the lie stakeholder debt tells every retrospective: “Requirements changed” instead of “We decided without the person who’d have known better.”

Susan’s question in week six was always coming. The only thing you can change is whether it reaches you in week two, while it’s still cheap to answer. Everything below is about pulling that question forward.

The Two Habits That Catch the Debt Before It Compounds, and the One Move for When You Were Too Late

All three habits come from the same place. The first two keep the stakeholder debt from piling up at all, by organizing your stakeholders around the project’s decisions instead of around the project itself. The third is for the debt you’ve already got, because some weeks you’ll have some, and pretending otherwise is how it compounds.

Habit One: Let the Decision Pull in the Right Person, Not the Calendar

Most of us check our stakeholders on a cadence: weekly status, the phase gate, the monthly steering review And that’s the trouble, because stakeholder debt starts to accrue the instant a decision gets made, not do a calendar date.

So tie the check to the decision, not the date. Every time the project makes a call that something real depends on, ask one question before you move on: who has to live with this decision, and were they in the conversation when it got made?

That’s the whole check.

You’re not auditing the org chart or rebuilding the stakeholder list. You’re confirming, one decision at a time, that the person who inherits the outcome got a say before the team starts building on it.

The lightweight version lives inside a document you may already keep. In your decision log, add a column next to each entry. You probably have decision and date already. Add who owns the consequence and consulted? (Y/N). When that last column says no, you’ve found a stakeholder debt the moment you took it on, instead of in week six. It takes about fifteen seconds per decision, and it works because it’s just one more column in a place you’re already looking.

And when the answer is “No, and we’re going ahead anyway,” which is a legitimate call because waiting for everyone is its own kind of expensive, write that down too. Log it as a deferral: we decided X without Y, on purpose, and here’s when we’ll close the gap.

That single line turns a stakeholder debt you’d have discovered by accident into one you chose with your eyes open and can pay down on your own schedule. Most of the damage from stakeholder debt comes from the debts nobody decided to own.

The column catches what slips past you in the moment.

But there’s a way to see the slip coming weeks before it happens.

Habit Two: Map Your Stakeholders to Decisions Instead of to the Project

The column from Habit One catches stakeholder debt the moment you take it on. The stakeholder map can catch it before you take it on at all. It tells you in week one that the data-retention decision is coming in week five, and that compliance needs to be in the conversation when it does, while you can still get them there.

The reason it works is the order you build it in. A normal stakeholder list is organized by person: a roster of names attached to the project. It tells you who your stakeholders are, but it never tells you when each one is needed.

So organize it by decision instead. List the decisions the project is going to make, and write next to each one the person who has to be there when it gets made.

To get the list started, ask the team one question, and ask it in the most uncomfortable way possible: it’s launch day, and somebody is furious they weren’t consulted. Who is it, and about what?

People are remarkably good at naming the person who’s going to be angry. They’re much worse at building an exhaustive roster from scratch. The angry-person question gets you the politically obvious name that might not make the formal list, the director who “doesn’t do detail” right up until the detail touches their headcount.

What you end up with is short and looks like this:

Three columns. Maybe eight rows. It takes an hour or two, and it converts your stakeholder list into something that can warn you. You stop asking, “Who are my stakeholders?”, and start seeing “Legal is needed before week five” while it’s still week one. That’s the whole game: getting the person into the discussion one week early instead of three weeks late.

The stakeholder map and the column handle the stakeholder debt you can still prevent.

But they don’t help you with the debt you’ve already got, and sooner or later you’ll find some.

Habit Three: Reopen a Closed Decision Without Looking Like You Lost Control

This is the hard one, and it’s the one most people don’t write about, so stay with me.

You find stakeholder debt after the fact. The decision’s made, the team’s built on it, and now the person who should’ve been there shows up with the input that changes everything.

You’ve got two bad instincts to resist.

1. The first is to bury it, keep moving, and hope it works itself out, which is just letting the leak under the sink continue to drip.

2. The second is to come in hot, reopen the thing clumsily, and watch your own credibility take the hit, because now you’re the project manager who can’t keep a decision closed.

There’s a cleaner way through, and it starts with separating the decision from the new information. The decision wasn’t wrong when it was made. It was made with the facts available at the time, and the facts have since changed, which happens on every project that runs longer than a week.

So you don’t walk in and say “We got this wrong.” You walk in and say something closer to this:

“Compliance flagged something about how we’re storing customer data that the original decision didn’t account for. If we adjust it now, before the build is underway, it’s about two days. If we wait until we’ve launched, we’re not just changing a setting anymore. We’re going back through everything we built on top of the old approach and redoing it. That’s three+ weeks, not two days.”

Then you put the two numbers next to each other and let the gap between them make the case. Reopening a decision on your authority turns into a fight about judgment, and judgment fights get political fast. Reopening it on the cost is a different conversation, one a team can have without it turning personal. All you’re doing is showing them a bill that gets bigger the longer it sits, and asking whether they’d rather pay the small version now.

The trick that keeps this from ever becoming a crisis is to do it early and small, the first time a decision looks slightly off, before the team has built much on top of it. Reopen one small thing on the cost while it’s still cheap, and reopening becomes routine. The team reads it as you doing your job, not as the floor giving way. They keep their faith in the project manager who catches things while they’re cheap.

They lose it watching a problem sit for six weeks before anyone calls the meeting.

What Watching the Right Place Really Looks Like

The goal is never zero stakeholder debt. Chasing a perfect, fully-updated roster is its own kind of waste, and some weeks you’ll take the debt on purpose, because a project that stops to consult everyone about everything will never ship.

What changes is that now you take it on purpose. You see the decision going by without the right person, and you choose whether to stop it or let it go, instead of finding out in week six that you let it go without noticing.

The projects that fall apart are rarely the ones that started a stakeholder short. Every project starts a stakeholder short. They’re the ones that let the leak drip for weeks because nobody was watching for it, and by the time the floor under the sink gave way, the five-minute conversation had already become a three-week repair.

You knew how to feel this coming long before it had a name. Now it has one, stakeholder debt, and a name is the thing you can put on a list, build a column for, or raise in a meeting without sounding paranoid.

So go look under the sink on the project you’re managing right now, and find the decision coming up that you’re about to make without the person who’ll have to live with it. That’s the one to stop.

I’ve watched some version of this meeting at several different organizations, and the details rhyme more than they differ. A senior director opens with a slide tagged to whatever strategic theme leadership announced six weeks earlier. The benefits slide cites a percentage reduction in something, and the assumption underneath is that adoption will hit some number in year one.

Nobody asks where the numbers came from. Nobody asks what the team will stop doing to build it. The committee approves the funding in under 10 minutes, and the CFO nods and says, “Good, what’s next.”

I knew the business case wasn’t strong. I’d reviewed it the day before. I had three questions ready and didn’t ask any of them, because the senior director outranked me and the theme was the theme and the meeting was already moving.

Two quarters later, the project was at 140% of budget, and the team I needed to launch the customer retention initiative, the one tied to the metric the board was closely tracking, was fully committed to the senior director’s project instead. The senior director got promoted that fall.

Every sponsor in the organization learned the lesson: tag your project to the shiny new strategic theme, skip the financial work, and the committee will approve it. The next quarter’s funding cycle had three more projects just like it on the agenda.

The lesson the organization took was the opposite of the one it should have.

That’s the pattern, and once you see it, you start noticing how often it runs.

What’s really doing the convincing when the business case can’t

Three forces decide funding, and the business case isn’t usually one of them.

1. Sponsor seniority does most of the work. A VP’s project clears a bar a manager’s project doesn’t, and the case often gets written after the decision has already been made, not to test the idea, but to justify it.

2. Strategic theme wrapping is the second force. Tag a project with AI, customer experience, or efficiency, whichever theme leadership picked this year, and it feels aligned even when the math doesn’t hold up. The theme does the convincing the numbers can’t.

3. The third force is the missing alternative. When nobody asks, “What else could this money do?”, the approval is about the sponsor and the theme. The case was never really weighed.

Picture the committee meeting. The agenda has the VP’s project third, after two smaller asks that get approved in five minutes each, which sets the rhythm for the meeting. The deck opens with the theme on the title slide. The benefits slide uses last year’s adoption numbers as proxies, and the assumption list is in an appendix nobody opens.

The CFO asks one clarifying question about timing. The strategy lead nods. Somebody says “This feels right.”

The consequence shows up two quarters later. Capacity is fully committed to the projects with the loudest sponsors. The work that would have moved the strategy is waiting another quarter for funding that’s already gone.

The committee meeting is where the decision gets recorded. It’s not where the decision gets made.

Subscribe now

Why your leverage isn’t where you’ve been spending it

Once the committee meeting starts, sponsor gravity is already in the air. The committee will weigh the case against the sponsor’s title unless something else exists to weigh it against. And that something else has to be in place before the meeting, agreed by finance and strategy, written down, and the same for every ask.

By the time the VP presents their business case, the decision-shaping work is done or it isn’t. The questions you ask in the committee meeting won’t change the answer; they’ll only register your objection for the record. The work that moves the decision happens in a different meeting, with a different group of people, on a different day, and a lot of PMOs don’t have it on their calendar.

The fix is to put it on your calendar. The next section is what goes on the agenda when you do.

Five moves that shift the conversation from “Approve this” to “Is this the best use of the money?”

A fair question at this point is if the PMO already calls the intake meeting at most organizations, why doesn’t this already happen? Because the intake meeting is usually treated as a status check. The CFO drops in for ten minutes, the strategy lead sends a delegate, and the criteria conversation gets a “looks good” that nobody refers to again until the next quarter starts and the same thing happens.

The work is making the intake meeting load-bearing, which means most of the agreement happens before the meeting ever starts. The five moves that follow are what you do before the meeting to get there.

These five moves are ordered roughly from easiest to hardest to install. The first and last are commitments that come out of the intake meeting and take a few weeks to put in place. The middle three are artifacts and meeting mechanics you can ship next Monday.

1. Set funding criteria before any project gets proposed

The criteria one-pager is what you publish to define the bar. It’s a single page, agreed with the finance lead and the strategy lead in the intake meeting, and it lives wherever your portfolio view lives. Every funding ask links to it.

The page has three sections. The first is the minimum financial bar: payback period, NPV threshold, whatever finance already uses, written in their language so they own it. The second is the strategic-fit definition for this quarter, in plain language a sponsor can read in thirty seconds. The third is the capacity check that confirms the team to deliver the project exists, which is the constraint that invalidates half the asks that clear the first two.

Here’s what those three sections sound like when they’re written.

1. The financial bar reads something like, “Projects under $250K must show payback within 18 months; Projects over $250K must show payback within 36 months and a benefit-cost ratio of at least 1.5.”

2. The strategic-fit definition reads something like, “This quarter, strategic fit means the project moves one of three board-tracked metrics: customer retention, gross margin, or time-to-revenue. Projects tied to other outcomes can compete, but only for residual capacity after the metric-tied projects are funded.”

3. The capacity check reads something like, “The sponsoring team must name the lead, the core team members, and the percentage of their time the project will require. Those names must not appear on more than one other active project.”

The criteria apply to every ask, regardless of who’s presenting. That’s the whole point. When the VP is presenting, the case gets weighed against a document the finance lead and strategy lead already signed, and the document doesn’t care about job titles.

The failure mode is the criteria get written once and never updated. Review them at the start of every quarter before the intake meeting, even if nothing changes. The act of reviewing is what keeps them load-bearing, and it’s what makes the intake meeting feel routine instead of political.

2. Standardize how every funding request gets framed

The funding request one-pager is the document sponsors submit, and every sponsor fills out the same one: same fields, same order, same length, one page, not a deck. Think of it as the business case in summary form: the page the committee reads, with the longer business case and its appendices sitting behind it as supporting material. You own the template, and finance and strategy review it and bless it.

The required fields are the outcome in one sentence, the investment, the benefits with named assumptions, the alternative considered and rejected, and what the project displaces if approved. If a sponsor needs more space, they’re describing the project, which is fine, but it belongs in supporting material, not on the page the committee reads.

The funding request one-pager flattens the playing field. The VP’s ask and the manager’s ask show up looking the same, which makes it harder for the job title to do the convincing. You’ll know it’s working when sponsors start complaining that the template is too constraining. That’s the response that tells you the template is doing its job.

The failure mode is sponsors submitting a deck “alongside” the one-pager. Don’t accept it. The one-pager is the ask, and anything else is supporting material that no one in the committee meeting is going to read anyway.

3. Make every funding request specify what it displaces

The displacement field on the ask one-pager is the move that changes the conversation. Every funding request states what it pushes out: which project, which team’s quarter, which planned spend.

If the answer is “Nothing, we have the capacity,” the funding request has to show where that capacity is coming from and why it wasn’t already committed to something else. Usually it was, and the sponsor either doesn’t know or hopes you won’t ask.

The trade-off question changes the committee meeting’s center of gravity. “Do we approve this?” becomes “Is this better than what it displaces?”, which is the question that helps the committee make better investment decisions.

The failure mode here is one you’ll recognize. The sponsor lists a displacement that’s already dying: the initiative no one was going to fund next year anyway, or the workstream that’s been winding down for two quarters. The displacement reads as a real trade-off and isn’t one. Push back in the template review, before the committee meeting.

Watch for ambiguous displacements. The sponsor lists “the analytics modernization workstream” as the displacement, and when you check, the workstream has one half-time analyst and no budget approved past March. That’s not a trade-off, it’s a write-off the sponsor is taking credit for. The displacement has to be a project with a real team and a real budget, or it doesn’t count.

4. Turn every approval into a bet with a checkpoint

Every approved project gets a 90-day checkpoint baked into the approval itself. A status review asks how the project is going, but the 90-day checkpoint is a decision review, which asks whether the project should still be running.

The checkpoint takes thirty minutes. The original committee attends in the same configuration as the approval meeting, and the agenda has three questions.

1. Is the original case (and assumptions) still true?

2. What have we learned that we didn’t know at approval?

3. Would we approve this again today with what we know now?

You run the meeting, and stopping the project has to be a real option. If “stop” is off the table, the checkpoint becomes theater, and word travels fast that the checkpoints don’t mean anything.

The failure mode is checkpoints get scheduled and then skipped because the project is “going fine.” Put the checkpoint date in the funding decision itself, not in a separate tracker.

The first time someone tries to skip a checkpoint, it’ll be by email the week before, framed as, “The team is heads-down on delivery and a 30-minute review would be disruptive.” That’s the email you reply back with the approval document containing the checkpoint review date attached.

5. Log every funding decision so the pattern becomes the argument

The decision log captures one row per funding decision, recorded the day the committee meets. The fields are project, sponsor, amount, strategic theme cited, alternatives considered, criteria met or waived, and the reasoning if criteria were waived. You own the log, and it doesn’t need broad distribution to be helpful.

Update it at 90 days and again at 6 months with what delivered against what was promised. Over time, you have something nobody else in the organization has: a record of which sponsors’ projects landed where they said they would, and which themes attracted funding that didn’t pay back.

When the sponsor wins anyway, and sometimes they will, because politics is real and you don’t always have the criteria in place yet, the log is how you make sure that decision shows up in the next conversation. Six months of waived criteria becomes the agenda for the next quarterly meeting with the finance lead. The log lets you show the pattern of the last four quarters, and patterns are harder to dismiss than opinions.

The failure mode is the log becomes an artifact nobody looks at. Bring it to the intake meeting. That’s where the patterns earn their keep, and that’s where the next quarter’s criteria get sharper because of what last quarter’s log showed.

Five moves, two documents, one recurring meeting. The mechanics fit on a page. The hard part is running the intake meeting in Q3 when the CFO wants to waive the criteria for a project the CEO already mentioned in a town hall.

What to do this week, before the next funding cycle starts

The PMO’s leverage at the funding gate shows up before the meeting starts: in the intake meeting that sets the bar, in the funding request one-pager that shapes how every case gets framed, and in the decision log that turns each quarter’s calls into next quarter’s evidence.

Most PMOs spend their energy on execution discipline once projects are running, when the bigger lever is the decision to start them in the first place.

Pick one move this week. The easiest place to start, if you don’t already have it, is the criteria one-pager because it’s the document the other four moves lean on, and because it gives you a reason to schedule the intake meeting with the CFO and strategy lead. Draft the one-pager on Monday. Send it to finance and strategy on Tuesday. Get it agreed by Friday. By the time the next funding cycle starts, you’ll have the page you need.

Funding is the first of four portfolio decisions you make every quarter, and the one where your PMO has the most leverage and the least practice using it. The five moves above are how you start changing that.

The sponsor finishes the pitch with “We just need to get started, and we’ll figure it out as we go.” Behind them, the slide lists four benefits and not one of them has a number next to it. Someone in the back asks what problem this is solving, and there’s a pause before the sponsor answers with a slightly different version of the pitch they just gave.

Everyone nods. The project gets approved.

A few months later, the team rebuilds the integration plan because the partner API doesn’t support bulk export. Then the training rollout hits its attendance numbers and changes nothing about how anyone works. Eventually, somebody on your team is writing a status update that uses the word “generally” three times, because the truth is the project is delivering what it scoped, but the scope was wrong.

That’s the rework, and every dollar of it lands on your portfolio.

Everyone in that room could’ve stopped it. Nobody did, because the conversation that would’ve stopped it wasn’t on anyone’s calendar.

Why most PMO charters describe only the second half of the work

Most PMO charters describe what happens after a project gets approved: track the work, report the status, govern the gates, and escalate the risks. The charter is written for the half of the project that’s already moving.

The half before that, where a project gets shaped into something worth funding, usually isn’t anyone’s job. The sponsor writes the business case. The finance director reviews the budget. By the time the PMO is involved, the question is “Do we fund this?”, not “Is this the right thing to fund?”

That’s the half where the decisions that shape everything else get made, and it’s where the PMO isn’t usually in the conversation.

The farther upstream, the more leverage the PMO has

Upstream means before the business case is written, not after it lands in your intake queue. By the time a project shows up at intake with a sponsor, a budget ask, and a slide deck, the decisions are already done. The PMO running intake at that point is reviewing a decision somebody else already made.

Earlier looks like a thirty-minute conversation with the sponsor before they brief their leadership team. It looks like a coffee with the ops lead before the scope document gets drafted. It looks like a call with the finance director the week the budget request is being shaped, not the week it’s being approved.

Those conversations are uncomfortable because they require you to have an opinion, and to be willing to send a project back when the answers aren’t there yet. They’re also where the leverage is. An hour of conversation before the business case is worth more than a month of governance after kickoff.

The earlier the PMO is in the conversation, the more of the project is still negotiable. That’s what the five questions are for.

Here’s how the conversation runs.

Five questions, sixty minutes, one piece of paper

You’re sitting with the sponsor and one or two people closest to the work before the business case is written. Sixty minutes. Five questions, in order. The conversation produces one page that will shape every artifact the project generates after.

Subscribe now

Problem: What problem are we solving, and what problem are we not solving?

The sponsor will say, “We need a new CRM” in the first thirty seconds. That’s the answer to a different question. Solutions are easier to talk about than problems, and most sponsors have been rehearsing the solution for weeks.

What you want is the underlying thing the project is actually trying to fix. “Sales reps are losing two of every five enterprise deals because the proposal process takes nine days, and the competitor is responding in four. We’ve lost three deals this quarter that finance had already forecasted.” Or for a process project: “Month-end close runs four days longer than it should because finance is reconciling numbers across three systems by hand. The team has worked the last three weekends, and two analysts are interviewing elsewhere.”

Then the harder question, and it’s the one most sponsors haven’t thought about: what problems will this project not solve? Two or three specific exclusions. “This project won’t address how we re-engage the deals we’ve already lost, even though improving proposal speed will help future enterprise deals.”

If you skip this, the team builds the wrong thing competently, and scope creeps in week three because nothing was ever explicitly excluded.

Outcome: What measurable result will prove this project worked, and what are you giving up to get it?

You’ve sat through the post-mortem where the project shipped, the ribbons got cut, somebody declared success, and six months later nobody could tell you whether anything changed. That’s because the outcome got defined as activity. “Launch the platform.” “Complete the training rollout.”

Activity always completes. The outcome is often the part that doesn’t.

A helpful answer is a business outcome metric, a baseline, and the date you’ll read it. “Time-to-quote drops from nine days to under four by end of Q3, measured from the CRM timestamp.” Training is the one to watch. Most training projects get measured by attendance because behavior change is harder to measure, and harder to measure means easier to skip.

Sometimes the sponsor genuinely doesn’t know the baseline. That’s fine. The usable answer in that case is a metric, a date you’ll have the baseline by, and a date you’ll read the result. “We don’t know current time-to-quote yet. Ops will pull it by the fifteenth, and we’ll measure again at end of Q3.” A baseline you don’t have is a dependency, and dependencies belong on paper.

Then the trade-off. What attention, what other work, what relationships get deferred so this can happen. If you ask, “What are you giving up to do this?”, you get a real answer. Ask “what will this cost?”, and you get a budget number you already have.

Urgency: Why now, and what happens if we do nothing?

This is the question the sponsor will answer with strategy language. “It aligns with our priorities.” “It supports the transformation roadmap.” Those answers don’t tell you when, and they don’t tell you what changes if you wait.

What you’re listening for is a date, a cost that’s accruing, or a window that’s closing. “Our top three customers renew in March, and two of them have flagged response time as a renewal risk.” That’s a helpful answer. There’s a deadline, a consequence, and a name attached.

The harder version of this question separates real urgency from secondhand urgency. Real urgency comes from the work. Secondhand urgency comes from an executive who mentioned something at a leadership meeting last week.

The way to tell the difference is to ask what changes if the executive who raised it left tomorrow. If the answer is “Nothing, the deadline is still the deadline,” it’s real. If the answer is “We’d probably reprioritize,” you’re staffing somebody else’s preference, and that project will get deprioritized the moment a louder voice with a different preference shows up.

Six months later, the team is working on something else, the project is on hold, and the urgency that funded it has moved on to whatever the executive mentioned at the last leadership meeting.

People: Who has to agree for this to move forward, and where do you expect disagreement?

The first answer is always a list. Sponsor, project manager, steering committee, maybe a name from finance. A list is the start of an answer, not the whole one.

What you want is the people whose work changes whether they asked or not, and where the disagreement is going to come from. “The change will land on the regional sales leads, and at least two of them are going to push back because they don’t trust the forecasting numbers the new system will produce.”

Sponsors will say “Everyone’s on board” and mean it sincerely while being wrong. The follow-up that gets at the truth is small and specific: Who pushed back when this was first floated? Which adjacent team will be least excited about it? “Where do you expect resistance?” gets you a real answer. “Who’s going to fight this?” gets you a sponsor who suddenly remembers everyone is aligned.

If you skip this, the affected team finds out at go-live, and your next quarter is change management nobody budgeted for.

Path: What must be true for the team to deliver the outcome?

The team rebuilt the integration plan in month three because the partner API didn’t support bulk export. The assumption was real. It was just nowhere on paper, which means nobody could challenge it until it broke.

What you want from the sponsor is everything the plan rests on that isn’t written down. “This plan assumes the partner API supports bulk export by April, and the data team can spare two analysts in Q2.”

Path is assumptions and dependencies only. Approach, sequencing, and phasing are planning work, and they happen later. The two get conflated all the time, and the failure modes don’t look the same. An assumption is something the team believes is true and hasn’t verified. A dependency is something the team needs from somebody else. Assumptions break when reality shows up. Dependencies break when the other party is late.

They’re two different problems, with different responses, so it’s worth writing them down separately.

What this looks like on paper

One page, five headers, with two or three sentences under each, in the sponsor’s language. Here are two examples:

• Under Problem: “Sales reps are losing two of every five enterprise deals because the proposal process takes nine days, and the competitor is responding in four. This project addresses proposal cycle time. It does not address how we re-engage the deals we’ve already lost, even though improving proposal speed will help future enterprise deals.”

• Under Urgency: “We’ve lost three deals this quarter that finance had already forecasted. Two more are in flight with the same competitor, and the proposal-cycle gap is the variable we can change before the next round closes.”

Include the sponsor’s name, the date, and the names of everyone who joined the conversation. Someone could read the page in three minutes and know what this project is, why it exists, who has to agree, and what it depends on.

What to do with the projects already in flight

Most of the projects on your portfolio right now never got these questions asked. You can’t unwind that. You can pick the three that worry you most (the ones with vague outcomes, sponsors you’re not sure are real, or assumptions you’ve been hearing about secondhand) and run the conversation with the sponsors anyway.

Some of those conversations will go well because the sponsor has been waiting for someone to ask. Some will stall because the answers aren’t there yet, and the sponsor hadn’t noticed. The five questions sharpen a project. They don’t fix a paper sponsor, and the retrofit conversation is where you find out which sponsors are which.

You’ll learn fast which projects have answers and which don’t. Some you’ll keep. Some you’ll fix. And some you’ll hand back to the sponsor with a clearer picture of what they actually funded, and let them decide whether the project still makes sense. That last conversation is the hardest one in the section, and it’s the one the framework most needs you to be willing to have.

Running the questions on a brand new project is easier. The retrofit work is where you’ll find the rework you can still prevent.

What changes when the questions get answered first

The portfolio review stops being a list of green-yellow-red and starts being a conversation about which projects are still solving the problem they were funded to solve.

• Status meetings get shorter because the outcome is already defined.

• Scope debates get faster because what’s out is already identified.

• Risks get identified during planning because the assumptions are on paper where someone can challenge them.

• Change management starts earlier because the affected people were named in week one, including the ones who pushed back at the offsite.

• Sponsor handoffs don’t reset the project, because the answers travel with the document instead of living in the head of the person who just got promoted.

The PMO stops being the organization that explains what happened, and starts being the organization that explains what’s at stake.

The five questions aren’t a gate. They’re the version of the project you keep current. Sponsors change. Outcomes that mattered in Q1 stop mattering in Q3. Assumptions that held up in planning fail in week six. The first time something material changes and nobody updates the page, you’ll be back to reporting on a project nobody can quite explain anymore. Keeping the answers current is harder than getting them in the first place.

You’re the project manager who got handed this project after it was already in flight, and you’re three weeks in. It’s Tuesday morning, you’re on the standing weekly check-in, and the team is walking through the work in flight.

Someone, maybe you, maybe a junior teammate, asks who the customer is. The team lead says, “We’ll figure that out as we go,” and everyone nods.

The teammate next to you nods too. She’s been here three weeks longer than you, and she’s already learned that asking who the customer is gets you labeled the slow one.

You look at the charter on your laptop. Two paragraphs, mostly aspirational. No documented requirements, no measurable objectives, no business case beyond a “TBD” placeholder. Nobody has written down what success looks like, what problem this project is supposed to solve, or who’s going to use whatever gets delivered.

The previous project manager’s name is still on the charter, and nobody’s mentioned why she left.

The work is moving. You’re the only person who seems worried, and you can feel everyone else thinking you’re the problem.

What follows is five plays you can run in your first 4 to 6 weeks. None of them stop the work, and none of them require authority you don’t have. Run them in order.

But first, the trap that catches almost everyone at this point.

The Obvious Move Is the Move That Gets You Sidelined

The instinct is to call a halt. Demand a charter, schedule a requirements workshop, send the email that starts with, “Before we go any further, I think we need to align on…”

With sponsor backing and formal authority, that’s the right call. Most project managers don’t have either when they walk in. That email gets you labeled the obstacle within a week and worked around within two.

The job is to run clarification work alongside the work that’s already happening. The team keeps shipping, the clarity catches up, and every play here is something you do while they keep moving. Nobody stops, nobody admits they were wrong, and nobody grants you authority.

The first play is the one everything else depends on, and it starts with you being the new person who needs help.

Play 1: Run a Catch-Up Tour Before You Run Anything Else

You’re new, and being new is the one piece of leverage you’ll have for two weeks. Use it. Nobody refuses a catch-up meeting from someone who just walked in, even the people who’d refuse everything else.

In your first two weeks, book 30-minute 1:1s with every team member. Team lead, lead engineer, designer, product owner, sponsor, two or three downstream stakeholders who’ll inherit whatever you ship. Ask the same five questions every time.

1. What problem are we solving?

2. Who’s the customer?

3. What does success look like in six months?

4. What’s the biggest risk you see?

5. What would you change if you could?

You’re learning, and the contradictions show up on their own. The team lead’s customer looks nothing like the sponsor’s, and the designer’s definition of success is different than the engineer’s. By Thursday of week 1, you’ve heard four different versions of who the customer is, and you’re putting it all in a spreadsheet just to keep it straight.

The trap is to point out the contradictions in the moment. Don’t. You’re gathering, and the contradictions become evidence for plays 3, 4, and 5, not material for week-one debates you’ll lose. The phrasing that does the work here:

“I’m new. Help me understand. When this ships, who’s the customer, and what will they do differently?”

“Help me understand” is impossible to dismiss as bureaucracy. “What will they do differently?” forces a concrete answer where “What are the requirements” never does.

By week 2 you’ve got the data, but data alone won’t change the dynamic.

You need somebody who isn’t you to ask the next question.

Play 2: Find the One Person Who’s Already Half-Convinced

During your catch-up tour, one person stood out. She asked the most “why” questions in standups. She paused longest before answering “What does success look like?” She’s already half-convinced, and you’re giving her permission to say what she’s been thinking.

You ask her for coffee. Not a meeting room, not chat, not a calendar invite that says “Quick chat.” Coffee, in person if she’s local, a video call labeled “coffee chat” if she’s not. The frame is what matters: low-stakes, no agenda, no slides. The kind of conversation where she can think out loud without it becoming a record.

You don’t pitch. You ask her a real question, the kind that doesn’t have a follow-up ready: “You’ve been on this longer than me. What’s the thing you’re quietly worried about that nobody’s talking about?” Then you listen, and you let the pause sit longer than is comfortable, because the real answer usually comes after the first one.

When she answers, you share one concern of your own. Not your full list. You ask what she’d do in your position, and somewhere in that exchange you say the line that does most of the work in Play 2:

“I’m not trying to slow things down. I’m trying to make sure we don’t have to redo this. Does that match what you’re seeing?”

With influence-only authority, one internal advocate changes the physics of every meeting. You’re finding the team member who already shares your concerns and giving her air cover. There will be a moment, maybe tomorrow or maybe a week later, when you’re sitting in a standup and you can feel her deciding whether to say something.

That moment is what the coffee was for.

When she finally says, “Yeah, we should probably define what the business outcome is,” the dynamic shifts. A project team member is now agreeing, and the same question that would have been bureaucratic from you sounds like sound judgment from her.

You have data and an ally. The next step is making the gaps visible without ever saying the word “requirements.”

Subscribe now

Play 3: Hide the Clarification Work Inside a Risk Register

Risk management is unambiguously project manager territory, and nobody objects to a risk log. A log full of clarity gaps becomes the case for clarification, written in a language the team and sponsor can both accept.

By end of week 2, publish a risk log with a few entries. Real technical and schedule risks alongside the clarity ones. Two or three clarity risks among six or seven real ones lands differently than a risk log that’s obviously a complaint in costume.

Log the gaps you found in the catch-up tour as risks with proposed responses:

“If success criteria stay undocumented, then we’re likely to face post-launch rework. Response: 30-min working session to define.”

Each clarity-gap mitigation should take an hour or less of team time. Make the ask small enough that saying yes is easier than explaining the no, because a 30-minute meeting is harder to refuse than “We need to do requirements properly,” and the difference is mostly in how the calendar invite reads.

When you bring a clarity-gap mitigation to the team, like the success-criteria working session, the framing matters. You’re not asking them to stop and think; you’re offering to do the legwork yourself in exchange for a small slice of their time:

“I’ll own this. Just give me 48 hours and a 30-minute meeting.”

Owning the work and bounding the ask is what separates a project manager who’s protecting the project team from one who’s creating overhead.

The register makes the gaps visible to the team. The next play makes them undeniable to anyone above the team.

Play 4: Borrow the Sponsor’s Authority Without Naming It

Somebody approved this project. They had a reason, and that reason is your most powerful and most underused source of authority.

Find whoever signed the SOW. Often the sponsor, sometimes a VP who hasn’t thought about this project in two months and assumes everything’s fine because nobody’s escalated. Ask one question:

“When this was approved, what outcome did we promise? What ROI or business result was expected?”

Sponsors at this stage tend to answer in one of two ways. Either they have a crisp ROI number they’ve been waiting for someone to ask about, or they pause for a beat too long and start with “Generally.” The crisp answer is gold. The “generally” answer is also gold, just a different kind of gold. It’s a risk you log on Monday and a conversation you book for the following week.

Get it in writing if you can. An email reply works. You want something you can quote, not a memory of a hallway conversation that ended when somebody else needed the elevator.

Bring it back to the team as alignment, framed around the sponsor’s expectation rather than your own concern. “I talked to [sponsor]. They’re expecting X by Y. Are we building toward that?”

The conversation shifts. The team is now responding to a deliverable promise the sponsor already made, and you’re the messenger, which is a much safer place to stand than the advocate.

If the sponsor’s answer contradicts what the team is building, don’t dramatize it. Bring it back flat. “Here’s what they said. Here’s what we’re building. I want to make sure I’m reading this right.” The team fills in the implications themselves.

“The sponsor told me they’re expecting X. I want to make sure we’re set up to deliver that. Can we spend 30 minutes mapping what we’re building to what they’re expecting?”

You’ve got the data, the ally, the register, and the sponsor’s words in your back pocket. The team is ready for what happens next.

Play 5: Draft the Launch Announcement Before the Product Exists

This is where everything you’ve gathered gets focused into one 30-minute working session that doesn’t feel like a requirements meeting.

You schedule it as a creative exercise. “Let’s draft the launch announcement together, the post we’ll publish when this ships. It’ll help us align on what we’re telling the world.” Most teams will say yes to this where they’d say no to a requirements review. Writing a launch post sounds like wordsmithing. It’s the requirements conversation in costume.

You open the meeting with the frame: Imagine we’re shipping next month. What does the launch post say?”

Then you open a shared document on screen, you’ve pre-filled the template, and you ask for a headline first. “What’s the one sentence we want customers to remember?” Someone offers one. Someone else edits it. You stay quiet and let them work.

About a third of the way in, the disagreement will start. The team lead’s headline says one thing about the customer. The engineer’s edit says another. The designer points out that neither matches the persona deck from last quarter. It gets uncomfortable, and somebody, usually the most senior person, laughs the awkward laugh that says we should probably have figured this out by now.

That’s the reason the play exists.

You write three options on the screen and ask the team to pick one. Not “Do we have requirements?” Just “Which headline is right?” They pick.

By the end of the half hour, you read back what’s in the document. You ask if anyone disagrees with what’s now written. Nobody does. You’ve got the customer, value, and outcome, roughly 60% of what a charter would have given you, written in the team’s voice, all done in 30 minutes.

You didn’t ask for it. They wrote it themselves.

Don’t run this in week 1. You need a few weeks of catch-up tour data first, an ally who’ll speak up if the conversation stalls, and a sponsor outcome specific enough to point to. Run it in week 4 or 5 when the disagreements will be productive instead of philosophical.

But sometimes, none of this works.

When the Plays Stop Working, You Stop Playing and Start Recording

Sometimes the resistance wins. You publish the risk register and nobody engages. You bring sponsor data back to the team and it gets a polite nod and nothing else. The response to every move is “Thanks, we’ll figure it out as we go.”

When that happens, the team has decided that shipping anything is more important than shipping the right thing, and your influence won’t change that. Your job shifts from clarification to documentation.

Log everything plainly. Risks, gaps, decisions made without input. Log it as a record, not as a weapon. Date everything. The point is that six months from now, when somebody asks what happened, there’s an answer that isn’t a memory.

Tell the sponsor in writing. One paragraph. “Here’s what’s unclear, here’s what I’ve tried, here’s what I recommend.” It’s their call from there. You’ve done your job by putting the decision in front of the person who can make it.

Then protect the next project.

This one may ship and miss its mark, and that’s not your failure if you’ve done the above. It’s the failure of an organization that decided speed was worth more than direction, and that’s not something you can always fix on a project you inherited weeks or months after kickoff.

Most articles about inherited projects end with a line about resilience or grit. Influence has limits, and learning where your influence ends is part of the work. The next project might be the same as this one. It might be worse. It might be the one with a complete charter, SMART requirements, and a sponsor who knows what they want. The plays still apply.

Three weeks after the strategy offsite, the quarterly portfolio review is on the calendar. The project list is the same one from last quarter, with the same sponsors defending the same milestones.

Halfway through, someone asks about a project that doesn’t clearly connect to any of the new priorities. The sponsor gives a version of “We’re already three quarters in.” Someone else says, “We’ll revisit that next quarter.” The group moves on. The project keeps its green status.

The PMO lead is the one presenting the deck, and the one who knew walking in that this project shouldn’t still be on the list.

Leadership changed the strategy in January. The portfolio is running exactly as it was in December, and nothing in how it gets reviewed will close that gap.

Why the Quarterly Review Never Asks If the Portfolio Matches the Strategy

Does the portfolio match the strategy leadership chose? The question rarely gets asked in the quarterly review, and when it does, nobody in the meeting is accountable for the answer.

Reporting and governance describe work already in progress, and the functions tracking that work each see a different piece of it. Finance tracks spend against budget. Delivery tracks milestones against plan. Strategy tracks announcements against the calendar.

None of them are accountable for the portfolio-to-strategy match, because none of them see the whole picture.

Without someone accountable for the match, the PMO becomes a translation layer between the teams doing the work and the executives asking about it.

And translation layers get cut when budgets tighten.

The PMO is the only function positioned to see the whole picture. It sits between finance and delivery, between strategy and execution, between the plan leadership announced and the portfolio actually running. That position is a structural accident, but it’s also the opening. The question nobody else is accountable for defaults to whoever is willing to claim it, and the PMO is the one function in the organization that can.

That opening shows up in the same four places every quarter.

Subscribe now

The Four Decisions Your Portfolio Makes Without You

Every quarter, the portfolio makes four decisions, whether the PMO shapes them or not: what gets funded, sequenced, stopped, and staffed.

1. Funding Projects

Finance owns the dollars. Strategy owns the priorities. The handoff is where “strategic fit” gets a checkbox instead of a conversation. The business case gets written against last year’s strategic pillars because that’s what the template had. Projects enter the portfolio because the numbers worked and the sponsor was credible, not because anyone asked whether this is what the strategy calls for.

2. Sequencing Projects

Delivery optimizes for team throughput. Finance optimizes for the fiscal year. Strategy assumes everything it prioritized is happening in parallel. The portfolio ends up with six number-one priorities running at the same time, and the actual sequence gets set by which team has capacity this month and which sponsor complained loudest in the last steering committee. The project plan still shows the original Q1 order six months after the business re-prioritized.

3. Stopping Projects

Nobody owns this. There is no stop-a-project meeting, no stop-a-project artifact, no stop-a-project owner. What happens instead is projects get starved by attrition. The team shrinks from six to four to two. The status report starts coming every other week, then monthly, then not at all. Six months later someone asks what happened to that project and nobody quite remembers.

4. Staffing Projects

HR sees headcount. Delivery leads see allocation against their own projects. Sponsors see whether their project has the people they asked for. Nobody is looking at the portfolio-level question: are the best people on the work that matters most? Your strongest engineer is on the project she’s been on for two years because moving her is disruptive. The new strategic initiative gets the people who happened to be available.

All four decisions happen upstream of delivery. All four sit in gaps between functions. All four default to whoever shows up with a point of view. Most PMOs shape one, report on two, and miss one entirely.

Which brings up the first question worth answering.

Three Questions That Expose Which Decision Your PMO Is Missing

For each of the four decisions, answer three questions. Strong answers are specific, a named person or committee, a named venue, a named artifact. Weaker answers are anything vague, “it depends,” “various people,” “we sort of talk about it in a few places.”

Funding Projects

If the right column looks familiar: Funding is usually the cleanest of the four, so a weak answer here is notable. The most common failure is that the meeting and the decider are clear, but the business case is being written against last year’s strategy.That’s a one-quarter fix, rewrite the strategic fit section of the business case template against the current strategy, and require sponsors to answer it for every new case.

Sequencing Projects

If the right column looks familiar: Project sequencing is the decision most often made by default. The fastest move is to put the current sequence on one page and bring it to the next portfolio review with a single question: “Is this the order leadership wants?” You’ll learn more from the answer than from three months of status reporting.

Stopping Projects

If the right column looks familiar: This is the most common weakest decision, and the one with the most room for a first move. Build a one-page candidates-to-stop list with two or three projects on it. Include original business case date, current strategic fit, cost to continue, and capacity freed if stopped. Bring it to the next portfolio review. The artifact itself creates the conversation.

Staffing Projects

If the right column looks familiar: Staffing is the decision most distributed across the organization. The first move is visibility, one view that shows who’s on what, sorted by strategic priority. You’re not trying to move people yet. You’re trying to see where the mismatches are. The staffing spreadsheet with a tab called “v3_FINAL_updated” that three people are editing simultaneously is a common symptom.

What to do this quarter

The decision with the most hedged answers is where to start. Do one concrete thing in the next two weeks.

Not a new framework. Not a new governance layer. One artifact or one question, brought to one meeting that already exists. The artifact suggestions above are starting points. Rewrite the business case template, put the current sequence on one page, build the candidates-to-stop list, or create the portfolio staffing view. Pick the one that matches your weakest decision and build it.

The deep dives on each of the four decisions will come in future articles. This piece is for figuring out which one to read first, and for putting one thing in motion before the next article publishes.

The Meeting Matters More Than the Artifact

Run this diagnostic and you’ll find a decision your PMO doesn’t shape. That’s not a comfortable finding.

It’s also the starting point.

The first artifact is how you enter the conversation. The temptation after that is to keep building, a new template, a new meeting, a new governance layer, and call it the fix. That’s the administrative reflex, and it’s what got most PMOs into the reporting-heavy posture in the first place.

The shift happens in the meeting, not in the artifact. The first time you walk in with a candidates-to-stop list, or a sequencing recommendation the sponsor didn’t ask for, the group treats you differently for the rest of the quarter.

Reporting still has to happen. Governance still has to hold. What changes is where you’re sitting in the conversation. The PMO stops being the translation layer and becomes the function that makes the strategy real.

There’s a customer data platform initiative sitting in your intake queue. Projected ROI north of 3x, a sponsor who’s ready, a cross-functional team identified.

It’s been waiting for two quarters because three other projects are absorbing every available team and dollar at phase gates where nobody is asking whether those projects should still be running.

One of them is a platform migration scoped at $1.4M eighteen months ago. At the most recent gate review, the cost-to-complete had climbed to $1.1M, nearly double the last projection. The value case hadn’t kept pace. Everyone in the review could see the math. The meeting ended with “Let’s revisit next quarter.”

That phrase buys ninety more days of spending without a decision, and the project in the intake queue keeps waiting.

Every organization has a process for approving projects. Very few have a process for stopping them.

Getting support to start something shiny is easy. Getting support to stop something that’s stalling takes a different kind of conversation, and a structure that most organizations haven’t built yet.

The 3P check-in is that structure.

What a 3P Check-In Is, and the Math Behind It

A 3P check-in is a structured decision point embedded in your phase gates. At each gate, the governance committee reviews the project’s cost-to-complete against its projected value and agrees on one of three next steps:

1. Persevere: Continue full speed. The project is delivering on its value case and the business landscape hasn’t changed enough to reconsider.

2. Pivot: Change the scope. The original value case has shifted, but there’s a version of this project that still delivers more than it costs to complete.

3. Preserve the Capital: Cancel the project and redeploy the remaining budget and capacity to a higher-value project. The remaining cost-to-complete exceeds the projected value, or the organization has a better use for the investment.

The decision metric is a simple comparison: remaining cost-to-complete vs. projected value still to be realized. It’s a forcing function that puts two numbers in front of the steering group so the conversation starts with data.

When projected value drops below remaining cost, that’s a data point. It doesn’t automatically mean cancellation, but it shifts the burden of proof. The recommendation now needs to explain why persevering or pivoting will close the gap.

Framing it as three options makes the conversation workable in a way that “Should we cancel this?” never does. “Preserve the Capital” reframes cancellation as a stewardship decision. You’re protecting the portfolio’s capacity to deliver value, not issuing a verdict on the team’s work. It gives the group a vocabulary that separates the decision from the people who’ve been working on it.

One more thing to put on the table early: the money already spent is gone regardless of the next decision. The question for the steering group isn’t whether the first $2M was a good investment. The question is whether the next $800K will be. That reframe belongs in the 3P brief, stated plainly, so the committee doesn’t spend 15 minutes re-debating the past.

The framework gives you a vocabulary. The next question is where and when to use it.

When to Run Them: Tying 3P Check-Ins to Phase Gates

Don’t add a new meeting to the calendar. Embed the 3P check-in in the phase gates you’re already running. Gate reviews carry decision authority, and the right people are already in the meeting, or should be.

The natural 3P moments are the gates you’d expect: end of planning (before committing execution budget), mid-execution (when enough work is done to validate or challenge the original assumptions), and pre-launch (when the remaining investment is mostly go-to-market and the value case should be at its clearest).

Add one line to your gate criteria: “Recommendation: Persevere, Pivot, or Preserve the Capital, with cost-to-complete vs. projected value and rationale.” That’s it. The 3P decision becomes a standing agenda item, not a special event.

For long-running projects, twelve months or more, consider adding an interim 3P check between gates if the business landscape is shifting fast. Market conditions, competitive moves, or internal strategy shifts can change the value equation between gates. Waiting six months to reassess a project that’s already underwater is an expensive way to be thorough.

Getting the cadence right is the easy part. The part that determines whether the check-in produces a real decision happens before anyone walks into the room.

Subscribe now

Socializing the 3P Before It Shows Up in a Meeting

This is the step that most PMO leaders skip. They build the framework, put it on the agenda, and walk into the gate review expecting the room to engage with it for the first time: in front of peers, with their project on the line.

Here’s what that looks like: the PMO Leader presents the 3P brief. The sponsor glances at the cost-vs-value numbers and immediately starts defending the original business case instead of evaluating the current one. Another executive asks, “Wait, are we talking about cancelling this?”, and the temperature in the room jumps from decision-making to damage control.

The conversation spends its remaining ten minutes on reassurance instead of data. The decision gets deferred. Another quarter passes.

The 3P check-in only works if the concept has been socialized before anyone has to make a decision in front of an audience.

Start with your sponsor.

Walk them through the framework one-on-one. Let them react privately. Show them the cost-vs-value comparison for their project. Let them see what the steering committee will see, and talk through the implications before the room is watching. Give them language they can use with their peers. A sponsor who understands the framework going in can help facilitate the conversation instead of bracing against it.

Brief the steering committee.

Introduce 3P as a portfolio health practice. Frame it as, “We’re building this into every phase gate so we make deliberate decisions about where we make our strategic investments.” This applies to every project, not just the ones that are struggling.

Prep the project team.

They need to hear it from their project manager before they hear it in a review. Be direct: this is how the organization will evaluate all projects going forward. It doesn’t mean their project is in trouble.

The goal is that by the time a 3P decision happens in a phase gate review, nobody is encountering the idea for the first time.

Once the concept has landed, you need an agenda tight enough to produce a decision in 20 minutes.

Facilitating the 3P Check-In: A Step-by-Step Agenda

Here’s a concrete agenda for the 3P portion of a phase gate review. It’s designed to run in 15 to 20 minutes within the existing gate meeting.

Pre-Meeting (PMO Leader responsibility)

Prepare a one-page 3P brief with these fields:

• Original value case: expected outcomes and projected value at initiation

• Current projected value: updated for landscape changes, scope shifts, market conditions

• Cost spent to date

• Remaining cost-to-complete: including time, team capacity, and budget

• Cost-to-complete vs. projected value comparison

• Key risks and landscape changes since last gate

• Recommended decision: Persevere, Pivot, or Preserve the Capital, with rationale tied to the numbers

• If recommending Preserve the Capital: redeployment target: which project would absorb the freed capacity, and what its projected value is

That last field is the one that changes the conversation. When the steering group can see the trade, cancel Project A to start Project B, cancellation becomes a portfolio decision with a visible upside, not just a loss.

Distribute the brief 48 hours before the gate review. Nobody should be reading these numbers for the first time in the meeting.

In The Meeting (15–20 minutes)

1. PMO Leader presents the 3P brief (5 min). Lead with the cost-vs-value comparison. Facts and recommendation. No selling.

2. Steering group asks clarifying questions (5 min). Scope it to the data and the recommendation, not solutioning. This is the part that tends to expand if you let it. Keep it focused.

3. Decision discussion (5–10 min). The sponsor leads. The group lands on Persevere, Pivot, or Preserve the Capital.

4. Document the decision and next actions before anyone leaves the room. If it doesn’t get written down in the meeting, it will get reinterpreted by the next morning.

One facilitation note worth keeping close: the PMO Leader recommends, but the steering committee decides. This separation protects the you from owning a cancellation decision that belongs to the business, and gives the steering committee the information they need to make it.

The agenda gets the group to a decision. The recommendation is what determines whether that decision is any good.

What Each Decision Looks Like on Paper

Persevere looks like:

The cost-to-complete is within tolerance of the original estimate. The projected value still exceeds remaining cost by a healthy margin. The business landscape hasn’t shifted enough to change the case. The recommendation cites specific metrics, not just “The project is on track.” “On track” is a status. The steering group needs a rationale.

Pivot looks like:

The original value case has eroded, but there’s a rescoped version that still delivers more value than it costs to complete. The recommendation includes the revised scope, the revised cost-to-complete, and the revised value projection. Be specific. A pivot without new numbers is just optimism with a different label.

Preserve the Capital looks like:

Remaining cost-to-complete exceeds projected value, or the capacity would generate more value on a different project. The recommendation states the redeployment target. This turns cancellation from a loss into a trade.

Watch for the “Let’s just reduce scope” reflex. Sometimes a pivot is legitimate. Sometimes it’s a way to avoid saying the harder word. The test: if the revised scope wouldn’t survive an intake review on its own merits, it’s not a pivot.

That’s what the decisions look like on paper. In the meeting, especially when the paper says “Preserve the Capital”, the human dynamics are where most playbooks go silent.

The Hard One: Navigating a “Preserve the Capital” Decision

The cost-vs-value math can point clearly toward cancellation, and everyone can still freeze. The PMO Leader finishes presenting the numbers, everyone has the brief, and nobody speaks first. Cancelling a project is never just a financial decision. People are attached to the work, reputations feel like they’re on the line, and the politics are real. Pretending they aren’t doesn’t make the decision land any better.

For the sponsor

Their name is on this project. They championed it. They made the case to the steering group, probably more than once. A cancellation can feel like a referendum on their judgment, even when the business case is the thing that changed, not their decision-making.

Have the reframe conversation privately, before the gate review. Show them the cost-vs-value numbers and let the data carry the weight so the sponsor doesn’t have to. The business case changed: that’s the story, and it’s a true one. Cancelling a project that’s absorbing capital without delivering proportional value is a stronger leadership call than letting it run because nobody wanted to have the conversation.

Give the sponsor language they can use in the meeting: “We’re reallocating to where we can generate more value with the same capacity.” That sentence turns the decision into a forward-looking portfolio move. It doesn’t erase the disappointment, but it gives the sponsor a way to own the decision rather than apologize for it.

For the executive team / steering group

The group needs to own the decision collectively. If the sponsor walks out feeling like they were the only one holding the weight, the 3P process has failed, even if the decision was right.

You’ll know the group is hedging when you see it: one executive glances at the sponsor before speaking, another offers a vague “I think we need more data,” and people start gravitating toward a pivot nobody would fund if it were a new proposal. The framework helps here because the decision is institutional. It’s the output of a process with visible criteria, tied to numbers the whole group reviewed.

When the cost-vs-value math clearly favors cancellation, acknowledge it and move to the redeployment plan. The longer the group debates a number that’s already clear, the more the conversation starts to feel like a trial. Name the decision, document it, and shift to what comes next.

For the project team

They’ve been building something. Some of them reorganized their calendars, turned down other assignments, or pitched in extra hours because they believed in the outcome. A few of them probably saw the writing on the wall weeks ago, maybe from a message that said “Have you seen the updated numbers?” or from the way the gate review kept getting rescheduled. A cancellation without acknowledgment will cost you credibility the next time you need a team to commit to a deadline or pick up extra work.

The project manager should deliver the news directly, before the project team hears it through the org chart grapevine. Acknowledge the work. Be specific about what was good, not a generic “great effort, team” but the actual contributions that made a difference. Explain the business rationale without corporate euphemism, including the cost-vs-value data that drove the decision. And give them a clear picture of what happens next: reassignment, timeline, who to talk to.

One thing to avoid is framing the cancellation as a “learning opportunity” in the same breath as the announcement. That reframe can land later in a retro, in a one-on-one, in the kind of conversation that happens once people have had a chance to process. In the first conversation, people need to hear what’s happening, why, and what the next step is. That’s it.

Landing the hard decision once is the test of the framework. Landing it consistently, quarter after quarter, is a different problem.

Making It Stick

The natural decay pattern for 3P check-ins is predictable. The first two quarters produce real decisions. A project gets pivoted. Maybe one gets cancelled. The organization starts to feel like the process is working. Then the discomfort fades, the check-ins get shorter, and “persevere” becomes the default because it requires no follow-up conversation, no redeployment plan, and no uncomfortable phone calls.

Fight the decay by making the process structural.

1. Add the 3P recommendation field, including the cost-to-complete vs. projected value comparison, to your phase gate template. If it’s optional, it will be the first thing that gets dropped when the meeting runs long.

2. Track decisions over time: how many projects persevered, pivoted, or were cancelled to preserve capital at each gate. This becomes portfolio health data. If every project perseveres for three consecutive quarters, the 3P check-in has stopped working.

3. Celebrate good cancellation decisions the same way you celebrate successful project launches: publicly, with the business rationale and the redeployment outcome visible. The team that cancelled a $1.2M project and freed capacity for a $3M initiative made a portfolio decision worth recognizing. If the only decisions that get airtime are the ones that went according to plan, nobody will feel safe recommending the harder call.

Review the 3P practice itself quarterly: are the cost-vs-value numbers being updated with real data, or are they carrying forward stale projections from the original business case? A 3P check-in built on old numbers is just a ritual.

The Project That’s Still Waiting

That customer data platform initiative, the one that’s been sitting in the intake queue for two quarters, is still waiting.

Pick one project in your portfolio that’s been coasting. Run the 3P brief. Put the cost-to-complete vs. projected value comparison in front of the steering group and give them three options instead of one.

That project in the intake queue will keep waiting until the organization builds the mechanism to free the resources tied up in work that’s no longer earning its keep. Organizations that can’t stop projects can’t start the right ones.

You’re twenty minutes into a portfolio review. The priority list is on the screen. You’ve walked through the top five, and everyone has been nodding along, until someone from the business side says, “I don’t understand why the customer portal redesign is ranked below the ERP migration. Our team has been waiting since Q1.”

The sponsor leans forward. Two other project managers go still because they can tell the agenda is about to get hijacked and their updates won’t get airtime.

Someone on the conference line unmutes, thinks better of it, and mutes again. You watch the conversation start to fork: one person is responding to the objection, another is opening a side thread about resourcing, and a third is checking their laptop like they’re already preparing for a priority list that looks different by end of day.

You’ve got about sixty seconds before this meeting belongs to the loudest voice in the room.

You’ve been here before. Maybe you tried to hold the line and it came across as dismissive. Maybe you opened the floor and spent forty minutes on a debate that ended with “Let’s take this offline,” which is corporate for “This will never get resolved.” Either way, you left the meeting knowing the priority list had less credibility than it did when the meeting started.

Objections are useful; they’re how new information enters the process. They only become a problem when they stay vague and everyone tries to resolve them in real time.

When the objection stays vague, the meeting ends without a next step.

Someone says “This doesn’t feel right” or “Our project should be higher,” and instead of treating it like an input to evaluate, the group treats it like a vote to count. The list gets reopened on the spot, and people start making their case. The energy in the room goes from “review” to “negotiation” in about twenty seconds.

The meeting ends without a decision, without an owner, and without a date. The priority list you walked in with is now in limbo. And you’re the one who has to explain to your leadership team why the portfolio order is different from what they approved last month, or worse, why it’s unclear if it changed at all.

The follow-up is even worse. You spend the next two days fielding messages from project managers who want to know if their project moved. The sponsor who raised the objection calls to ask what was decided. You check your notes and realize nothing was decided.

This is where most PMO leaders lose ground, but it doesn’t have to play out that way. There’s a 4-step pattern you can run in the meeting, in real time, that keeps the conversation productive and the priority list intact until there’s a reason to change it.

Step 1: Restate the objection in one sentence before the group starts solving two different problems

The first thing you do when someone pushes back is slow the room down. Take the objection, whatever form it arrived in, and compress it into a single sentence. Say it back to the group.

“You’re saying the customer portal redesign carries a Q2 revenue dependency that isn’t reflected in the current scoring. Is that the concern?”

Subscribe now

You’re not agreeing, and you’re not disagreeing. You’re making sure everyone in the meeting is looking at the same issue before anyone starts solving it. Most objections arrive as broad statements or feelings like, “This should be higher” or “I don’t think the ranking reflects our business needs.” Your job is to turn that into something the group can evaluate.

When you skip this step, you pay for it. The group starts debating two different interpretations of the objection. Someone keeps circling back with “That’s not exactly what I meant.” Ten minutes disappear, and it feels like the group has made more confusion than progress.

Say the one sentence, and confirm it. Then you’ve got something to work with.

There’s a side benefit to this step that’s easy to miss. When you restate the objection clearly, everyone else relaxes. They were bracing for a debate. Instead, they heard a precise question, and now they’re listening differently, less like jurors picking sides, and more like colleagues evaluating an input. You changed the posture of the situation with one sentence.

Once the stakeholder agrees on what the concern is, the next question is whether it connects to anything in your prioritization scoring model.

Step 2: Validate the concern in portfolio terms, without agreeing to change the list.

Take the restated objection and translate it into the language your priority criteria already use: risk exposure, compliance deadlines, capacity constraints, revenue impact, strategic alignment. You’re converting “I feel like our project should be higher” into a specific input the scoring model can process.

“That’s a valid input. If there’s a Q2 revenue dependency we’re not accounting for, that could change the business impact score for this project.”

This does two things.

1. It shows the person who raised the concern that you took them seriously. You didn’t dismiss it or redirect.

2. And it reframes the conversation around the criteria the group already agreed to, which means you’re evaluating the concern on shared terms instead of competing opinions.

Here’s the part that trips people up: validating a concern and agreeing with its conclusion are two different things. You can acknowledge that a revenue dependency is worth examining without changing the priority list on the spot. You took the input, but you didn’t change the output. Those are separate steps, and keeping them separate is what gives you room to manage the process.

Their concern is validated and framed in portfolio language. Now comes the part most people skip: the question that asks the group what they’re willing to give up.

Step 3: Turn the objection into a tradeoff question, and let the portfolio math do the talking

This is the hardest step, and the one that changes the shape of the conversation. Take the validated concern and convert it into a question the group can answer: if this project moves up, what moves down? What else changes? What does the portfolio look like after the swap?

“If we move the customer portal redesign above the ERP migration, the ERP milestone slips to Q3 and we miss the vendor integration window. Is that the tradeoff we want to bring to the steering committee?”

Most people who challenge a priority list haven’t thought through the second-order effects. They’re advocating for one project, not proposing a new portfolio order. When you ask the tradeoff question out loud, you shift the conversation from lobbying to analysis.

This plays out one of two ways, and both of them work.

The concern is real, but the cost isn’t worth it

Sometimes the person who raised the objection hears the tradeoff and pulls back. They didn’t realize that moving their project up meant pushing the ERP migration past a vendor deadline with a penalty clause. The concern was real, but once they see what it costs the portfolio, they withdraw it themselves. You didn’t have to argue the point because the tradeoff did the work for you.

The tradeoff is real, and the room needs more information to decide

Other times, the tradeoff is legitimate and the group sees it. The Q2 revenue dependency on the customer portal is hard, and bumping the ERP migration to Q3 might be the right call. The group doesn’t have enough information to decide in this meeting, but now they’re looking at a specific question with specific consequences, not re-debating the entire list. That’s when you close the loop.

In both scenarios, you’re not the one making the case for or against the change. You’re putting the tradeoff on the table and letting the tradeoff do the math.

Either way, the conversation needs one more step before people start checking the time.

Step 4: Assign a one-pager with a due date, and hold the current order until it’s reviewed.

Close the loop before the meeting ends. Assign someone, usually the person who raised the objection or the relevant project sponsor, to bring back a one-pager that updates the scoring inputs and lays out the tradeoff. Give it a due date and state the default out loud so everyone hears it.

“Sarah, can you have the updated revenue inputs and the tradeoff impact back by Thursday? Until we review that, the current project priority order holds.”

That last sentence is the one that protects the PMO. You’ve given the objection a path forward. But you’ve also made clear that the priority list doesn’t change on a feeling in a meeting. The priority order holds until there’s written analysis that justifies a change. If the one-pager comes back and the tradeoff makes sense, you can update the priority through your standard process. If the one-pager doesn’t come back by Thursday, that tells you something too.

This is the part where your credibility compounds. You didn’t shut anyone down. You didn’t get pulled into a debate. You ran the process: restate, validate, tradeoff, assign, and the meeting ended with a next step, an owner, and a date instead of an open question and a vague plan to “revisit this offline.”

One note worth specifying: the one-pager isn’t a case for why someone’s project should be ranked higher. It’s an update to the priority scoring inputs: the revenue data, the compliance deadline, the capacity constraint, and a clear description of the tradeoff. What changes if we re-rank, and what does the portfolio lose. Keep the format tight: updated inputs, proposed change, tradeoff impact, recommendation. If you let it become a persuasion document, you’re back to lobbying with better formatting.

The third time you run this, the meeting starts running it for you.

The first time you run this pattern, the group might be surprised. They’re used to priority reviews that end with someone promising to “take it offline” or a sponsor escalating because they didn’t get the answer they wanted.

The second time, people start to understand the rules. The third and fourth time, the behavior in the meeting starts to change. Sponsors show up to the review with a one-pager already written. Someone frames their concern in portfolio terms without being asked. A stakeholder objects to the priority of their project, and before you can respond, another leader in the room asks the tradeoff question for you.

You’ll notice it in a small way first: someone starts their objection with “I think there’s a scoring input we’re missing” instead of “I don’t agree with the ranking.” That’s the change. They’ve internalized the criteria, and they’re working inside the process instead of trying to work around it.

That’s when you know the process has taken hold: when someone else runs it and you’re just watching it work.

The charter shows up in your inbox. You open it, scan the objectives section, and find three bullet points describing deliverables and a timeline. No outcome metrics and no measurable definition of success. It’s just activity dressed up as strategy.

Your instinct is to return it with comments: add an outcome metric here, clarify the strategic link there, send it back. But you know what would happen next: the charter would come back with a metric that reads like it was written to satisfy a form field, and the sponsor would move on.

Coaching a sponsor on outcome metrics has to happen before charter submission, not after.

By the time the charter is in your inbox, the sponsor has already decided what the project is. Getting them to reconsider in writing, under deadline pressure, while they’re on to the next thing… that’s the hardest possible moment to have the conversation.

A coaching call before charter submission is when you have more leverage. The sponsor needs your sign-off. The project isn’t public yet. And the conversation can be short, if you know what you’re doing.

What most PMO leaders don’t know going in is which version of “no” they’re about to hear. Sponsor resistance comes in 5 recognizable patterns, and each one needs a different response.

Knowing which pattern you’re facing before you pick up the phone will change what you say first, and how well it will land.

Five Questions That Tell You Which Conversation You’re Walking Into

Before your coaching call, spend two minutes to think about what you already know from previous conversations, the charter draft, or how the sponsor has responded to your outreach so far. Answer the five questions below in order. The first “yes” tells you which type of resistance you’re likely facing, and each type has a specific coaching approach in the sections that follow.

The same sponsor can show up differently depending on the project. Someone who cooperated fully last quarter might resist this time for entirely different reasons. So run the diagnostic fresh each time, even with sponsors you know well.

Question 1: Does the sponsor seem concerned about being held accountable for results they can’t fully control?

• Do they seem wary of committing to a specific number?

• Have they mentioned variables or dependencies outside their influence?

• Have they watched a peer absorb blame for factors beyond their decisions?

Yes: You’re dealing with Type 1: The Accountability Avoider.

No: Go to Question 2.

Question 2: Are they genuinely convinced the project is valuable, and treating the outcome metric ask as beside the point?

• Do they have energy and conviction about the work itself?

• Are they impatient with the process rather than uncomfortable with accountability?

• Do they talk about the project like everyone already understands why it’s important?

Yes: You’re dealing with Type 2: The True Believer.

No: Go to Question 3.

Question 3: Are they claiming strategic alignment but struggling to articulate how the project connects to the enterprise strategy?

• Does their explanation sound plausible but thin?

• Would you struggle to repeat their logic to the governance committee?

• Do they reference departmental goals rather than enterprise priorities?

Yes: You’re dealing with Type 3: The Strategic Bluffer.

No: Go to Question 4.

Question 4: Do they seem pressed for time rather than philosophically opposed?

• No hostility, just no engagement?

• Short replies? Rescheduled meetings?

• Agreeable in principle, but nothing gets done?

Yes: You’re dealing with Type 4: The Capacity-Constrained Sponsor.

No: Go to Question 5.

Question 5: Are they arguing the outcome metrics requirement doesn’t apply to their project?

• Because outcomes like “culture change” can’t be quantified?

• Because it’s a compliance mandate with no choice involved?

• Because it was already approved by the CFO or another executive?

Yes: You’re dealing with Type 5: The Exemption Claimer.

No: Go back to Question 1 and listen more carefully in your next conversation. The pattern will emerge.

The Accountability Avoider: “There Are Too Many Variables Outside My Control”

They’ll tell you there are too many variables outside their control. “If the sales team doesn’t adopt the tool, that’s not on me.” It might sound like obstruction, but it usually isn’t.

This sponsor has probably watched a peer miss a target and absorb blame for factors that had nothing to do with their decisions. Maybe they were that peer. The fear of being held to a number they can’t fully influence is rational, and it’s also the most common version of resistance you’ll encounter. It can soften quickly, but only when you acknowledge it before offering anything else.

Start by normalizing their concern. “That’s a fair concern. A metric shouldn’t become a trap.” Then show them what a well-written outcome metric does for the person whose name is on the charter. It documents the conditions required for success, including the things outside their direct control. External dependencies go in the charter. The target can be expressed as a range. Leading indicators like adoption rates, process compliance, and usage data sit alongside the lagging metrics that take longer to shift.

A sponsor who understands that framing will stop arguing against the metric and start helping you build it. The charter they end up with doesn’t just describe what success looks like. It also puts on record what success requires. That protects them. Most sponsors, once they hear it that way, can work with it.

The Accountability Avoider will likely cooperate once the framing shifts.

The harder conversation comes with the sponsor who already knows their project is a stretch, and submits it anyway.

Subscribe now

The True Believer: “Everyone Already Knows Why This Is the Priority”

You’ll feel this one by the energy. Instead of just avoiding the conversation, they’re annoyed by it. They came prepared. They’ve thought hard about this project. They’re ready to talk about the work, the timeline, the team. What they’re not ready to do is slow down and produce an outcome metric for a process they consider a formality.

“Everyone in the division already knows why this is the priority.” Maybe they do. But the governance committee, the CFO, and the five other sponsors competing for the same budget need more than shared conviction. They need a number they can weigh against the other numbers on the table.

Where the Accountability Avoider is wary, the True Believer is impatient. That distinction changes the coaching conversation entirely. Don’t argue about whether the project is worth doing. Agree that it is. Then shift the frame: “The metric isn’t for you. It’s for the conversation that happens when someone has to decide between this project and the one below it on the priority list. Can you give me something to take into that conversation?”

True Believers usually can. They’ve done the thinking. They just haven’t been asked to translate it into the language of portfolio decisions. When they do, the metrics they produce tend to be specific and credible because the conviction behind them was real. What was missing was the translation.

The True Believer needs a different frame. The next type needs a different question entirely.

The Strategic Bluffer: “Our Goals Roll Up to the Strategic Pillars”

This one needs more care because the resistance is harder to see. They’ll tell you the project aligns to enterprise strategy. They may even walk you through the logic. And the logic will sound plausible, like a chain of connections that holds together right until you press on the links.

“Our departmental goals support the divisional priorities, which roll up to the strategic pillars.” That can be true. It can also be a long way of saying the project loosely connects to something that loosely connects to something the organization cares about.

For the obvious misalignment, ask them to walk you through it themselves: “How would you explain the strategic link if the governance committee asked?” If the connection isn’t there, that will become clear in a coaching conversation rather than in a governance meeting where everyone is watching.

For the plausible-but-thin case, try a resource question: “If we needed to deprioritize one current project to fund this one, which project should we cut?” That reframes the conversation from whether the project qualifies to whether it’s worth the trade-off. Sponsors who are confident in the strategic case can answer that question without hesitation. The ones who can’t tend to get quieter, which is helpful information, and a better outcome than letting it through to governance unchallenged.

The bluffer’s coaching conversation tends to be more direct than the others. The next type needs something different: less pressure, more structure.

The Capacity-Constrained Sponsor: “Yeah, Let’s Circle Back on That”

Their replies are short, and the meeting they agreed to has been rescheduled twice. When you do connect, they’re polite and vague in equal measure. “Yeah, let’s circle back on the metrics piece.” Three days later: nothing.

This sponsor isn’t philosophically opposed to outcome metrics. They’re under water, and your coaching requirement just landed on their list that’s already too long. Their resistance is logistical, which means the solution is to reduce friction.

Come to the conversation with a short menu of plausible metrics instead of an open-ended ask. “Here are three outcome metric options that typically apply to projects like this. Which one is closest?” That’s a ten-second decision, not a thirty-minute exercise. Bring the charter pre-populated with reasonable assumptions they can react to. Make the coaching conversation feel like fifteen minutes and one decision.

Capacity-constrained sponsors will get it done when you make it easy to get it done. What they won’t do is generate it from scratch on your timeline.

The last type won’t ask for a shortcut. They’ll ask why the process applies to them at all.

The Exemption Claimer: “This Was Already Approved by the CFO”

This has three versions, all with same argument. “This was already approved by the CFO.” “You can’t put a number on culture change.” “This is a compliance mandate. We have no choice.” All three are making the case that the PMO’s outcome metric requirement doesn’t apply to their project. It’s a legitimacy challenge, and it’s the scenario most likely to create hesitation in a PMO that’s still building its footing.

This is where executive air cover does its job. If your leadership has already confirmed that every project goes through the same process regardless of origin, you can hold that line without apology: “The outcome metric process applies to all projects. Every project needs to be able to tell its value story when it goes to leadership.” That conversation with leadership to confirm that air cover needs to have happened before this one. If it hasn’t, you have a different problem to solve first.

For the “outcomes are intangible” version, work with the sponsor on proxy metrics rather than accepting unmeasurable as the final answer. Engagement scores, process cycle times, ticket volume, retention rates: something is always measurable. The question is whether anyone has been asked to look carefully enough.

For the compliance project, the metric will shift: what does the organization gain from doing this well, beyond avoiding a penalty? Implementation quality, time to compliance, incident reduction. There’s a story there. Find it with them.

The first few of these conversations will be uncomfortable. The fifth one isn’t. And what changes faster than the discomfort is the quality of charters that come to the PMO, which is the reason to have the conversation in the first place.

What the Coaching Conversation Looks Like

It’s thirty minutes, with one sponsor, scheduled before charter submission, not after.

Open with the diagnostic question you already know the answer to, not because you need the information, but because the sponsor needs to say it out loud. “Walk me through how you’re thinking about measuring success on this one.” Listen for which type shows up in the first ninety seconds. You’ll hear it in the framing: fear, conviction, thin logic, time pressure, or a legitimacy challenge.

Then give them the response that fits. One reframe, one option, one question. You know which type you’re dealing with, so use the approach that matches, and resist the urge to run through all five in case one sticks.

Close with something specific. For the Accountability Avoider: “Let’s put a range of X to Y in the charter, use adoption rate as an early read, and note that sales team participation is a dependency. Does that work?” For the True Believer: “You mentioned the project should cut onboarding time in half. Let’s put that in the charter with a baseline and a review date. That gives the governance committee something concrete to weigh.” For the others, the same principle applies: one metric, one sentence, one confirmation.

That’s the conversation. Short, targeted, and finished before the charter submission deadline. This means the governance meeting can do its real job instead of catching problems the coaching call should have handled.

What to Do This Week

Open your portfolio. Find one active project with no outcome metric. It won’t take long.

Look up the sponsor. Think about the last time you talked to them, or didn’t. Run through the diagnostic questions. Which type do you think you’re dealing with?

Before you send a note asking for an outcome metric, plan your first sentence. Not the email, the sentence you’ll say when you’re talking with them and they push back. If you know what you’re going to say to the resistance before it arrives, the conversation won’t catch you flat-footed.

And once that sponsor has been through it once and sees how the right metric protects their project instead of constraining it, they’ll start writing better charters before you ask. Before long, sponsor will start to call you before they submit, not because you require it, but because they’ve learned it saves everyone a round-trip.

That’s the outcome metric for the work you’re doing right now.

The CRM migration charter lands in your inbox on a Thursday afternoon. Six deliverables, a Q3 go-live date, and a single line about “improving sales team efficiency.” No baseline, no outcome target, and no connection to the revenue growth priority leadership announced in January.

You send it back with comments. The sponsor responds two days later with a revised version that adds the words “strategically aligned” to the first paragraph and changes nothing else.

You’re two days away from the governance committee meeting.

You approve it.

Six months later, the project delivers exactly what the charter described. The CRM is deployed. Two hundred users are trained. The data migration is complete. Whether any of it changed how the sales team sells, or whether it touched anything the business said it cared about, nobody can tell you. There’s no baseline to compare against. There was never a plan to find out.

One bad charter is easy to attribute to one sponsor. The same bad charter, in different project names, from different sponsors, year after year, is a system problem, and the system is working exactly as it was designed to work. By the time a charter reaches the PMO, the sponsor has already socialized the idea, secured informal commitments from their VP, and mentally moved on to staffing the team.

PMO feedback at that stage lands as obstruction for an approval the sponsor was hoping to clear in a hour or two.

The PMO has, over years of approving charters like this one, communicated that activity-based metrics and vague strategic rationale are fine. Sponsors learned that lesson. They didn’t write it down, but they absorbed it.

The charter problem starts weeks before it reaches the PMO’s inbox, in a conversation that most PMOs have never been trained to have, and most sponsors have never been asked to have.

The charter that lands in your inbox looking like that one has been in the making for weeks, and the moment to fix it has already passed.

Subscribe now

The Comment Box That Can’t Fix What’s Already Decided

When a charter arrives for review, the sponsor’s investment in the project is already ahead of the document. They’ve pitched it, chosen the team, and told their VP it’s moving forward. Asking them to rethink the strategic rationale at charter submission is an interruption to something that for them already feels decided.

PMOs know this, and it’s why the feedback tends to be cosmetic and the approvals tend to happen anyway. Reviewing charters after submission is the wrong intervention at the wrong time. The change that will make a difference is moving the conversation upstream: before the sponsor has opened the template, before the project has a name, before anyone has a stake in a specific approach. At that stage, the PMO’s job is to help a sponsor think, before they’ve locked in a scope, a team, a timeline.

Here’s what a sponsor who’s thought carefully about this produces. Two examples, from different project types.

Example #1: The CRM that delivered everything except results

What PMOs typically see: “Deploy the new CRM platform to all sales teams by Q3. Deliver training to 200 users. Complete data migration.”

What the charter should say: “Increase sales pipeline visibility so that forecast accuracy improves from 62% to 75% within two quarters of go-live, to contribute to the Q4 strategic objective of predictable revenue growth.”

The second version tells a different story. It gives the governance committee something to weigh: a baseline, a target, a connection to a stated priority. It creates the conditions for the project to demonstrate its value after delivery, not just at go-live. And it gives the sponsor something to point to when scope pressure starts eroding the work that drives the outcome.

Example #2: The training program that hit every target and changed nothing

What PMOs typically see: “Launch leadership development program. Deliver 12 workshops. Achieve 80% attendance.”

What the charter should say: “Improve manager effectiveness scores from 67% to 78% on the annual engagement survey within 12 months, to contribute to the retention goal of reducing voluntary turnover among high performers by 15%.”

The second version refuses the “outcomes are intangible” argument that transformation projects often rely on. It finds proxy metrics (engagement scores, retention rates) that aren’t perfect but are measurable and directional. It also connects the project to a business outcome that shows up in a quarterly leadership conversation.

Getting a sponsor to produce the second kind of charter is a thinking exercise, and it requires a conversation that happens weeks before submission.

Most PMO leaders who try to have that conversation without organizational backing find out, usually after the first sponsor escalates, that preparation wasn’t optional.

The Backing You Need Before the First Sponsor Says No

The first time a PMO requires outcome metrics aligned to enterprise strategy, at least one sponsor is going to push back. They may go to their VP. They may show up to the governance committee without the metrics and expect approval anyway. They may delay the charter until the deadline forces the PMO’s hand.

If the groundwork hasn’t been done, any of those moves can work. That’s what makes this section the prerequisite, not the follow-up.

Before asking a single sponsor to do anything differently, find one or two executives who care about whether projects deliver strategic value, not just whether they’re delivered on time. This conversation should happen before the coaching model starts.

It doesn’t require a slide deck or a formal proposal. It’s a five-minute ask: “We want to make sure every project the PMO approves can demonstrate its value to the business. We’d like to start having coaching conversations with sponsors before they submit their charters, so they’re better prepared and the governance committee will see stronger strategic rationale. Will you support that?”

Then ask for the thing most PMO leaders forget to make explicit: “If a project sponsor pushes back and escalates, can I count on you to give me backup?” General expressions of support are worth less than a clear answer to that question. Get it before you need it.

Have two things ready for that conversation: a short description of the current state (charters approved without outcome metrics, projects that can’t demonstrate strategic value after delivery), and a one-paragraph description of what the new model would look like in practice.

Keep both short. This is a conversation, not a proposal.

Three mistakes commonly undermine the model before it gains traction.

1. Coaching only the willing sponsors and exempting the difficult ones. That creates a two-tier system where the PMO’s requirements apply to some projects and not others, which is worse than the original problem.

2. Starting with the most resistant sponsor as your first test case. If it goes badly, that story will travel faster than the success stories. Start with someone likely to engage well and let their experience become the reference point.

3. Having the coaching conversation once and never following up to see whether the charter reflects what was discussed. The follow-up is where the process holds or doesn’t, and sponsors learn quickly whether the PMO will check.

With that backing in place, the first coaching conversation will become possible. What makes it work, or not work, is almost entirely in how you open it.

Subscribe now

What to Say When You’ve Never Said This Before

The confidence gap is real and worth calling out before trying to close it. Most PMO leaders built their careers reviewing documents, managing governance processes, and escalating risks. Sitting across from a sponsor before the charter exists and helping them think through strategic rationale and measurable outcomes - that’s a different posture, and it’s fair to feel underprepared the first time.

The good news is that the conversation is more straightforward than it looks from the outside. And there’s a less effective way and a more effective way to approach the conversation.

• “Your charter needs outcome metrics before we can approve it” is the gatekeeper talking. It will put the sponsor on the defensive before the conversation even starts.

• A better approach is to say, “I want to make sure this project gets through governance smoothly and that you have a strong business case when it goes to leadership. Can I spend 30 minutes with you before you write the charter?”

Most sponsors will say yes to help they didn’t know was available.

The coaching conversation should happen as soon as a project enters early scoping, before the sponsor has committed to a specific approach. The PMO initiates it; don’t wait for sponsors to ask. Bring two things with you:

1. Side-by-side metric examples as a reference point

2. A one-page template with three questions. The template communicates that this is a standard process, not a special review created for their project.

The three questions are:

Question #1: What problem is this project solving, and who feels that problem most acutely?

The answer tends to reveal whether the project is strategically grounded or whether it’s solving a problem one person has decided needs solving. If the sponsor struggles to identify a specific person or group who feels the pain, that’s worth exploring before the charter goes anywhere near a template. A project without a clear problem tends to become a project without a clear outcome.

Question #2: Which of our strategic priorities does this connect to, and how would you explain that connection to the governance committee?

This puts the sponsor in the position of making the case. If they can explain it out loud, they can write it. If they can’t explain it out loud, you’ve found what needs more work.

Question #3: If this project succeeds, what will be measurably different 12 months after go-live?

The word “measurably” does deliberate work. It insists on specificity without sounding like an audit. Answers that gesture at general improvement will need a follow-up.

If a sponsor answers question two with “We’ll know it worked when the project is done on time,” don’t correct them. Ask, “And once it’s done on time, what could we measure to show what changed for the business?” Most sponsors can get to a real answer with one or two redirects like that. If they genuinely can’t, the project may not be ready, or the strategic case may not exist yet.

When they do get there, help them translate the answer into charter language. This is where the PMO’s knowledge of the governance committee is most useful. You know what that committee wants to see. Help the sponsor say it in a way that gets approved.

Most of the time, sponsors respond well to that kind of early help. Some won’t, and the pattern of the resistance tends to predict the right response.

When Sponsors Start Coming to You Before the Charter Exists

A few things change when this model takes hold.

Sponsors will start reaching out before they write the charter

They’ll do this because they’ve learned that 30 minutes with the PMO makes the governance process faster and less likely to produce a revision request at the worst possible moment. The governance committee starts seeing charters with real strategic rationale and measurable outcomes, which means it can evaluate what it’s approving rather than nodding at a deliverables list.

Projects that don’t align to the enterprise strategy will get identified early

You’ll be able to do this when it’s still possible to redirect resources or have a direct conversation about whether the project should proceed. Eighteen months in, with a team assembled and a VP’s reputation attached, that conversation doesn’t happen.

The PMO’s relationship with sponsors will change in a way that extends well beyond charters

A sponsor who walks into governance with a strong business case because the PMO helped them build it will bring a different attitude to the next scope discussion, the next risk escalation, the next budget conversation. That reputation will compound, and The PMO will start getting pulled into conversations it was never invited to before.

Bringing It Home

Year one won’t be clean. A senior executive will override the process. A sponsor will go around the PMO and get approved anyway. The governance committee will pass a charter that shouldn’t have passed. All of that is expected.

It’s just friction in a system that’s adjusting, and friction happens before compliance. The measure of year one is whether more sponsors are coming to the PMO earlier than they were six months ago, and whether the charters arriving for review are stronger than the ones that were being approved before.

Moving the work upstream, from reviewing submissions to coaching sponsors, puts the PMO in a different kind of conversation with the business. One where it has an opinion about what the organization should invest, and can help leaders build that case rather than judge it after the fact. That’s a harder role to route around when the pressure is on.

It starts with one project currently in early scoping and a calendar invite that reads “Charter pre-work: 30 min” instead of a draft landing in your inbox with “strategically aligned” dropped into the first paragraph.

A project charter comes into intake. Under “strategic alignment,” it says “supports strategic initiative #3.” The sponsor is already checking their phone. The PMO lead scans the rest of the fields, budget estimate, timeline, staffing needs, and everything has text in it.

The charter gets approved.

Six months later, in an executive review, someone asks how that project connects to the strategy. There’s a pause, the kind where everyone assumes someone else will answer. The project manager pulls up a scope document. The sponsor offers something about “digital transformation.”

The executive nods her head slowly, which is not exactly the same as agreeing.

When the PMO’s job is to be a status report factory

The answer was never there. Just a label that looked close enough to pass through a process designed to check whether the fields were filled in, not whether the project should exist.

This is what intake looks like when the PMO’s job is to make sure the paperwork is complete and the project gets queued.

The system works. Projects get logged, staff get assigned, timelines get built. But none of that tells you whether the portfolio is pointed at the strategy or just pointed at activity.

And by the time you find out, the money is spent and the executive trust you needed is harder to earn.

There must be a better way

The PMO that asks “Does this project produce a measurable business outcome that advances a specific part of the enterprise strategy?” is doing something fundamentally different from the one that checks whether all the charter fields have text in them.

The difference shows up months later, when leadership either has outcome data that shapes future strategy or has a pile of completed projects with no way to explain what they achieved.

Here’s a three-step playbook for turning intake into that strategy conversation, starting with the part most people skip.

The first step has nothing to do with the charter itself.

Step 1: Nobody can find the strategy, and that’s your first problem

You can’t rate a project’s alignment to a strategy if the strategy itself isn’t in a form you can compare against.

Most PMOs don’t have a usable reference document for the enterprise strategy. They have a 40-slide deck from the last offsite, or a set of pillars so broad that any project with a pulse can claim alignment. “Drive innovation.” “Improve customer experience.” “Accelerate growth.”

Those aren’t strategies you can test a project against. They’re bumper stickers.

Distill the strategy into a one-page reference. Strategic themes, each with two or three specific outcomes the organization said it wants to achieve this year. The key word is specific. If “improve customer experience” is a pillar, the usable version could be something like “Reduce onboarding cycle time from 14 days to 7 by Q3.”

That’s a sentence you can hold a project charter up against and get a real answer.

Here’s the part most people skip: you don’t build this alone. Draft it, then validate it with your executive sponsor or whoever owns the strategy. If you publish a strategy summary that nobody above you has signed off on, you’ve created a target on yourself instead of a tool.

The meeting where you walk a strategy owner through your one-pager is the meeting where the PMO starts operating differently. You’re showing that you’ve done the work to understand what the organization is trying to achieve with its strategy, and you’re asking them to confirm it or correct it. That’s a very different conversation than “Here’s this month’s status report.”

Sometimes what you’ll learn is that the strategy is more vague than anyone wants to admit. That’s a finding, not a blocker. Document what you can, flag the gaps, and let intake expose them. The first charter that can’t be rated because the strategy doesn’t say anything specific enough is the moment leadership has to get concrete. You didn’t create the ambiguity… you just made it visible in a place where it can’t be ignored.

This step can break down when your reference goes stale because nobody owns updating it. Pin it to a quarterly review cycle or tie the refresh to whatever planning cadence already exists. If the strategy reference doesn’t have a refresh date, it’s dead within six months, and you’re back to comparing charters against a document nobody trusts.

With a usable strategy reference in hand, the next bottleneck is the charter itself, and what it’s been getting away with not saying.

Step 2: If the charter can’t answer three questions, it’s not ready

Once the strategy is specific enough to compare against, the next problem becomes clear: most charters don’t give you anything to compare.

Look at the charters in your current portfolio. Most of them describe what the project will build or deliver. A new platform. A process redesign. A system migration. What they rarely describe is the business outcome that delivery is supposed to produce: the thing that changes in the organization once the deliverable exists.

A deliverable is “implement new CRM module.” A business outcome is “reduce average sales cycle from 45 days to 30 by Q4.” The charter needs both, but the outcome is the one that gets compared to the strategy.

Without it, you’re approving projects based on what they’ll build, not what they’ll change.

Add a field to the charter (or rewrite an existing one) that asks three questions:

1. What business outcome does this project contribute to?

2. Where are we today?

3. How will we measure the change?

Those three questions do something that most charter templates never get close to.

• The first one forces the requestor to connect the project to a result the business cares about.

• The second one establishes the baseline, the current state you’re measuring from.

• The third one commits to how you’ll know the project worked.

Together, they give the PMO everything it needs to measure business value: a defined outcome, a starting point, and a way to track whether things changed. Without the baseline, you’ll get to the end of the project and have no way to prove it delivered anything. “We reduced the sales cycle to 30 days” means nothing if nobody recorded that it was 45 days when the project started.

The requestor writes it, but a short intake conversation is where all three answers get pressure-tested. Even 20 minutes with the requestor and a PMO lead is enough. “Where are we today on this metric?” is a question most requestors haven’t been asked before. They’ve been asked about scope, budget, and timeline. They haven’t been asked to establish a starting point and commit to what success looks like in terms the organization can measure.

That conversation is where a vague aspiration becomes something you can track, and more importantly, something you can report against when the project closes.

This is also where most resistance lives.

Requestors don’t want to commit to an outcome because then someone might measure it. They’ll push back with “It’s too early to define that” or “We don’t have good data on the current state.” And sometimes they’re right. The outcome needs refining, or the baseline needs a few weeks to establish.

But the conversation itself is the value. A requestor who walks into a project knowing the current state, the target outcome, and how it’ll be measured is in a fundamentally different position than one who gets asked about outcomes for the first time during a benefits review eighteen months later.

This step breaks down when requestors game the system by writing outcomes that technically match the format but don’t mean anything. “Supports growth.” “Enhances efficiency.” “Improves stakeholder satisfaction.” These pass the field validation but fail the comparison test. Keep a short list of outcome examples that pass and a few that don’t, and make it available to requestors before they submit. When the standard is visible, people can self-correct before the intake conversation, and you spend less time coaching and more time evaluating.

Now you have a strategy you can compare against and a charter that tells you what the project is supposed to change. The question is whether those two things connect, and how to make the answer consequential.

Step 3: Rate the alignment so the conversation has teeth

Once you have a usable strategy reference and a charter with a stated business outcome, you can put them next to each other and get an answer.

Use a three-level rating to document how the type of link between the enterprise strategy and the project’s intended outcome: direct, indirect, unclear. Skip the numeric score. Numbers invite negotiation (“Why is this a 3 and not a 4?”), and the conversation devolves into scoring methodology instead of whether the project connects to the strategy.

Here’s what this looks like with a real example.

Direct link to the enterprise strategy

A charter proposes a project to automate monthly financial close reporting. The stated business outcome is “reduce close cycle from 12 days to 6 by Q4.” The baseline is documented: the current average close cycle is 12 days, based on the last four quarters of data. The measurement approach is defined: finance ops will track close cycle duration monthly post-launch. Your strategy reference lists “improve operational efficiency” with a specific outcome of “reduce time-to-insight for financial reporting by 50%.”

The project outcome maps to the strategic outcome almost word for word. The close cycle going from 12 to 6 days is a 50% reduction in time-to-insight for financial reporting. The connection is obvious, the baseline is established, and the measurement approach is in place before the project starts. This project proceeds through intake.

Indirect link to the enterprise strategy

Now change the charter. Same project, but the stated outcome is “Improve team productivity in finance.” That’s indirect. It’s in the neighborhood of operational efficiency, but the connection requires a logical leap. Does “team productivity” mean the same thing as “time-to-insight”? Maybe. Maybe not.

This is where the intake conversation earns its keep. “When you say ‘improve team productivity,’ what changes in a way we could measure in six months?” That question usually gets you to a better outcome statement, or reveals that the requestor hasn’t thought it through yet. An indirect rating means the project needs a stronger justification from the sponsor or a rewritten outcome before it proceeds.

Unclear link to the enterprise strategy

Change it one more time. The stated outcome is “Modernize legacy systems.” That’s unclear. It could connect to any strategic theme or none of them. The charter goes back for rework, and that’s not a punishment. It’s the system working as designed.

Who does the rating is as important as how you rate. The PMO shouldn’t score alignment alone. A small intake review: the PMO lead and one person close to the strategy, whether that’s a planning lead, a chief of staff, or a portfolio sponsor, gives the rating weight it wouldn’t have otherwise. If the PMO rates alignment unilaterally, it gets overruled the first time the rating inconveniences someone with enough authority to skip the process.

Keep the rating visible. Put it on the portfolio view. When leadership asks “How aligned is our portfolio?”, you have a real answer built from the bottom up, project by project, with a clear trail from each rating back to the strategy reference and the charter outcome.

This step breaks down when the PMO rates alignment but nobody acts on the rating, and everything still gets approved regardless. If “unclear” never blocks a project or sends a charter back, the rating system is decorative. Agree with your sponsor, before you launch this, on what each rating triggers. What proceeds, what needs additional justification, and what goes back for rework. Get that agreement in writing, because the first time you hold up a project at intake, someone will test whether you have the backing to do it.

If all of this sounds like a lot of overhead for an intake process, consider what it gives you on the other side.

Subscribe now

Three strategy conversations you can have now you couldn’t have before

Once you have alignment ratings, stated outcomes, and baselines on every project in the portfolio, three conversations become possible that didn’t exist before.

Strategy conversation #1: Show executives where the money is going

In the quarterly portfolio review, you can show leadership that 60% of active projects are directly aligned to the strategy, 25% are indirect, and 15% are unclear or under review. That’s a conversation about portfolio composition, whether the organization’s investment mix reflects its stated priorities. Before this, the best you could offer was a list of projects sorted by status color.

Strategy conversation #2: When something has to give, you’ll have the answer

When resources are tight and a new request comes in, you can recommend which existing project to deprioritize based on alignment ratings, not just timeline pressure or cost. When the PMO can say “Project A is indirect to the strategy and Project B is direct; here’s a trade-off worth discussing,” you’re shaping a strategic trade-off decision in real time. That happens in a specific meeting with a specific recommendation, and it’s the kind of conversation that earns the PMO a seat it didn’t have before.

Strategy conversation #3: Prove the project was worth it, in thirty seconds

When someone asks “Did this project deliver value” at project close, you have a baseline from intake, an outcome that was defined before the work started, and a measurement approach that’s been in place since day one. The benefits conversation starts with the baseline and ends with the outcome data: a comparison that took thirty seconds to pull because it’s been built into the charter since day one.

That’s how the PMO builds a track record of connecting enterprise strategy to project delivery to business outcomes, one project at a time.

Bringing It Home

The first time you send a charter back because the outcome was unclear and nobody could fix it, something shifts. You’ll feel it in the meeting, a mix of discomfort and a new kind of attention. The intake process has consequences now, and everyone in the room knows it. It’ll be uncomfortable the first three times you do it. Then it will becomes the thing people expect from you.