AI Driven PM: S2E11 - Atlas - The Estimation Engine

The Estimate That Haunts You

Every PM knows the moment. Someone catches you in the hallway — or worse, in a meeting with the CFO — and asks, "How much is this going to cost?"

You don't have the requirements. You haven't talked to the team. You barely know what the project is. But you open your mouth anyway, because that's what PMs do. You give a number. And from that moment forward, that number is no longer an estimate.

It's a commitment.

I've spent 30 years watching good project managers get buried by bad estimates. Not because they were bad at math. Not because they were careless. Because they were asked to make a precision commitment at the exact moment they knew the least about the project. That's not a skill problem. That's a structural problem.

And it's one I built Atlas to solve.

---

The Real Problem with Estimation

Here's what makes estimation so maddening: most organizations already have the data they need to estimate well. They've delivered similar projects before. They know roughly how long certain types of work take. They have rates, roles, and historical actuals sitting somewhere.

The problem is that data isn't structured. It's not accessible. It lives in the heads of senior consultants, in old SOWs buried in SharePoint, in tribal knowledge that walks out the door when people leave.

So every estimate starts from scratch. Different PMs give different numbers for the same work. One person is optimistic. Another is conservative. Neither is grounded in a consistent baseline. The result is variance — and variance destroys credibility.

Most organizations think the answer is better estimators. What they actually need is a better system.

---

Meet Atlas

I named her Atlas after the Titan who carries the weight of the world. Because that's exactly what estimation feels like — and because Atlas the agent actually carries that weight so you don't have to.

At her core, Atlas does three things:

She maintains a practice library. Every service type your organization delivers — structured, versioned, and accessible. Service definitions. Phases. Modules and components. Roles and rates. Three-scenario effort estimates per module, per role. Assumptions and constraints baked in. When a project closes, actuals update the library. The system learns. It doesn't forget.

She guides PMs through a structured conversation. Module by module. She asks the right questions in the right order, validates your inputs, and builds the estimate as you go. You're not staring at a blank spreadsheet trying to remember everything. You're having a conversation with an agent who knows your practice library cold.

She produces three-scenario PERT estimates. Optimistic, most likely, pessimistic — with a fully formula-driven Excel workbook. Not a single number. A range. With the math visible and defensible.

---

Two Ways to Work

Atlas runs in two modes, depending on what you're starting with.

Standard workflow: You know the project shape. You know you're doing a CRM implementation with a data migration, a handful of integrations, and some custom reporting. You tell Atlas, she pulls from the practice library, walks you through component counts, validates assumptions, and builds the estimate. Fast, consistent, grounded in your organization's actual delivery history.

Discovery mode: You don't know the shape yet. Maybe you've got an RFP. Maybe you've got a requirements document that's 200 pages of "the system shall." You hand it to Atlas, she analyzes it, suggests component counts, and asks you to validate. "I'm seeing 4 data objects, 11 workflows, 20 custom scripts, 13 reports. Does that match your read?"

That second mode is where things get interesting. And honestly, it came from me hitting a wall.

---

The Insight That Changed Everything

When I first built Atlas, I designed her around the practice library. You know the service type, you pick the components, you build the estimate. Clean. Simple. Effective.

But then I started working on complex projects — ones where the requirements were dense and the component counts weren't obvious. I realized something uncomfortable: I had become constrained by my own thinking.

The practice library, which was supposed to help, was actually limiting me on complex engagements. I was anchoring to familiar component counts instead of letting the requirements drive the numbers.

The breakthrough was a two-phase approach. Use Atlas first to analyze the requirements and count components. Then feed those counts into the estimate. Let the requirements tell you what you're building before the practice library tells you how long it takes.

That realization unlocked discovery mode. And it led directly to the demo that still gets the best reaction when I show it.

---

500 Requirements, One Hour

Real project. Salesforce implementation. The client handed us a requirements document with 500 line items.

Old approach: senior architect spends two or three days doing line-by-line review, trying to group requirements into estimable components, hoping they don't miss anything. Best case, you get a first draft in a week. You've already introduced human variance and fatigue into the process.

New approach: I handed the document to Atlas.

She ran all 500 requirements through discovery mode. Came back with component counts: 4 data objects. 11 workflows. 20 custom scripts. 13 reports. 23 custom fields. And more. She also generated an assumptions document — a structured list of what she assumed to be true about each component — formatted for the architects to review and validate.

We went through two revision cycles based on architect feedback. Total time from document to validated estimate: about one hour.

The PERT output came back with a range of 5.7M, with an expected value of $1.8M.

Now, I know what you're thinking. That's a big range. 5.7M? How is that useful?

Here's the thing — that range is honest. And honesty is more valuable than false precision.

---

Why Three Scenarios Beat One Number

When you give a client a single number, you create false precision. You're telling them you know something you don't know. You're compressing all the uncertainty, all the risk, all the unknowns into one figure that will be wrong — and then you'll spend the rest of the project defending why it's wrong.

Three scenarios do something different. They communicate uncertainty explicitly. They show the client that the outcome depends on decisions that haven't been made yet — requirements that are still fuzzy, risks that haven't materialized, scope that could go either way.

The PERT expected value gives you a defensible anchor. The range gives you room to navigate. And the assumptions document gives you the conversation: "We estimated 11 workflows. If there are actually 17, here's what that means for the number."

That's not hedging. That's professional rigor.

And it sets up something even more powerful: scope control that's evidence-based, not subjective. When scope creep shows up — and it always shows up — you're not having a feelings conversation. You're having a math conversation. "We estimated 11 workflows, we're seeing 17. Here's the delta. How do you want to handle it?"

That's a completely different dynamic with a client.

---

The RFP That Needed an Answer by Friday

Let me give you one more scenario, because this one happens all the time.

Client comes back mid-project — or sometimes before the project even starts — and says they need componentized pricing. It's Wednesday. They need it by Friday. The requirements are still vague. And they have a very specific format they want the response in.

Old approach: PM and sales team spend two days frantically trying to reformat the existing estimate, guess at component breakdowns, and produce something that looks professional but was mostly assembled under pressure.

New approach: I gave Atlas the original RFP, the existing estimate, and the client's requested format. She produced a structured response with assumptions documented, PERT parameters shown, best/most likely/worst case added — in the client's exact format.

Wednesday to Friday. Done. With more rigor than the original estimate.

That's the shift. From scrambling to authoritative. From variance to consistency. From "I think it's around this" to "here's what it costs, here's why, here's the math."

---

The Loop That Makes Both Systems Smarter

I've talked about Atlas and ARIA in separate episodes, but I want to be clear about how they work together — because the loop is where the real organizational value lives.

Atlas builds the estimate at the start. ARIA protects it during execution. Atlas says "we estimated 11 workflows." ARIA watches for the 17th workflow and flags it as a risk.

But here's what happens at the end: when the project closes, actuals flow back. The practice library gets updated with real delivery data. ARIA's risk database gets updated with what actually happened versus what was estimated. Both systems get smarter.

Most organizations have lessons learned processes that nobody reads. What Atlas and ARIA do is encode organizational learning into systems that don't forget, don't retire, and don't walk out the door. Every project makes the next estimate better. Every execution feeds the next risk assessment.

That's not just efficiency. That's institutional memory that actually works.

---

What This Means for You

If you're a PM who's ever felt that knot in your stomach when someone asks for a number you don't have — this is what changes.

Estimation goes from four hours to ten minutes. From gut feel to structured conversation. From variance across your PM team to consistency grounded in your organization's actual delivery history.

And when you walk into that room with a client, you're not hedging. You're not apologizing. You're presenting a range with documented assumptions and visible math. You're saying: "Here's what it costs. Here's why. Here's what changes the number."

That's the difference between a PM who manages projects and a PM who commands the room.

---

Next Up: PACE

Episode 12 brings us to PACE — the Predictability and Capacity Engine. If you're running agile at portfolio scale and your sprint commitments are all over the place, PACE is what brings discipline back. We're talking predictability scoring, readiness debt, and what it actually takes to make portfolio-level agile work.

It's a good one. See you there.

— Rick A. Morris
PMP, PMI-ACP | R2 Consulting | Author | Host, Work-Life Balance with Rick A. Morris

---

---

EPISODE DESCRIPTION

Episode 11: Atlas — The Estimation Engine

You gave a number in a hallway once. Maybe a conference room. Maybe a Zoom call with the CFO. You didn't have the requirements. You didn't have the team's input. But you gave a number — and from that moment forward, it wasn't an estimate anymore. It was a commitment.

Bad estimates don't happen because PMs are bad at math. They happen because we're asked to make precision commitments at the exact moment we know the least. And then we spend the rest of the project defending a number we never should have been asked to give.

In Episode 11, Rick introduces Atlas — the AI estimation agent he built and deployed in production to solve the estimation problem at its root.

What Atlas does:

• Maintains a versioned practice library — every service type your org delivers, with roles, rates, phases, modules, and three-scenario effort estimates per component
• Guides PMs through a structured estimation conversation, module by module, grounded in your delivery history
• Produces three-scenario PERT estimates (optimistic, most likely, pessimistic) with fully formula-driven Excel workbooks — not a single number, a defensible range

Two modes. One engine. In standard workflow mode, you know the project shape — Atlas builds from the practice library. In discovery mode, you hand Atlas an RFP or requirements document and she analyzes it, suggests component counts, and asks you to validate before a single hour is estimated.

The 500-requirements demo: Rick walks through a real Salesforce implementation where Atlas ran 500 requirements through discovery mode, returned component counts (4 data objects, 11 workflows, 20 scripts, 13 reports, 23 custom fields), generated a structured assumptions document for architect review, and produced a third-revision estimate — in about one hour total. PERT output: 5.7M range, $1.8M expected value. What used to take days of senior-architect line-by-line review.

Why three scenarios beat one number: A single estimate creates false precision. Three scenarios communicate uncertainty honestly, give clients room to understand what drives the number, and set up scope conversations that are evidence-based — not subjective. "We estimated 11 workflows, there are 17" is a defensible conversation.

The RFP scenario: Client needed componentized pricing in their specific format by Friday. Atlas took the RFP, the existing estimate, and the client's format — and produced a structured response with assumptions, PERT parameters, and best/most likely/worst case. Wednesday to Friday. Done.

The Atlas-ARIA closed loop: Atlas builds the estimate at the start. ARIA protects it during execution. When the project closes, actuals update the practice library AND feed ARIA's risk database. Both systems get smarter. Organizational learning encoded into systems that don't forget.

The transformation: Estimation from 4 hours to 10 minutes. From PM-to-PM variance to organizational consistency. From hedging to authority. From "I think it's around this" to "here's what it costs, here's why, here's the math."

Next episode: PACE — the Predictability and Capacity Engine. Portfolio-level agile predictability, sprint commitment discipline, and readiness debt. If your agile portfolio feels like organized chaos, this one's for you.

 

AI Driven PM - S2E10 - Introducing ARIA—The AI Agent That Turns Your Organizational Memory Into Defended Risk Intelligence

For nine episodes, we've talked about how to use AI as a thinking partner.

How to prompt better. How to ask Socratic questions. How to stop commanding AI and start coaching it.

That's half the story.

The other half is showing you what happens when you actually build with it.

So for the next four episodes, we're changing gears. No more theory. We're showing you what I've built—real agents, production systems, tools running right now on real client projects.

And we're starting with the one that's most personal to me.

Her name is ARIA. The Advanced Risk Intelligence Agent.

The Vision I Wrote in 2008

Back in 2008 and 2009, I wrote two books where I described what I believed was the future of project management.

Not better Gantt charts. Not more sophisticated scheduling algorithms.

I described systems—actual systems—that could take everything we learned from completed projects and automatically apply them to new ones.

Systems that could look at a project before it started and say: "Based on everything we know, here's where you're going to get into trouble."

I laid out a vision of organizational memory. A database that captured not just what went wrong, but why it went wrong, and how often that same pattern showed up across different projects. A system that weighted lessons by severity and repeatability, so the most dangerous patterns surfaced first.

People loved it.

Here's what killed it: the manual effort.

You needed someone to interview every project team member after every project closed. Someone to categorize the lessons. Calculate the weights. Update the database. Run the queries. Build the reports.

And when that person left? The system died with them.

The theory was sound. The technology just wasn't there yet.

Fast forward to 2024. I'm watching large language models get better and better at structured reasoning. And I realized something:

Technology finally caught up to the idea.

What you're about to see is what happens when you take that 2008 vision and rebuild it with AI.

The Problem We've Been Ignoring for Decades

Let me describe how most organizations handle project risk.

New project starts. You open the kickoff meeting. Someone pulls up a risk register template—probably the same one that hasn't been updated in 20 years.

You ask: "What could go wrong?"

Budget overruns. Scope creep. Resource constraints. Vendor delays.

The usual suspects.

You assign probability scores. Low, medium, high. You assign impact scores. You multiply them. You get a number. You use that number to decide how much contingency to request.

And here's the question nobody ever asks: Where did those scores come from?

They came from someone's gut. Someone's intuition. Maybe someone who's been around long enough to remember a similar project. Maybe someone who's new and has no idea—they just pick medium because it feels safe.

And when the project closes—whether it succeeds or fails spectacularly—you do a lessons learned session. You write down what happened. You file it away.

And six months later, when the next project starts, nobody remembers any of it.

Right now, there are treasure troves of lessons learned sitting in Excel documents and SharePoint folders. Untouched. Unleveraged. Forgotten.

We've been doing this for decades. It's absolutely insane.

What We Should Be Doing Instead

Here's the vision. Here's what ARIA makes real.

We should be capturing every variance that matters—every schedule delay over a threshold, every cost overrun, every scope change that rippled through the project.

We should be structuring that data. What was the cause? What was the effect? What category does this belong to? How severe was it? Has this pattern happened before?

And then, when a new project starts, we should be able to say:

"This project shares characteristics with these five historical engagements. Those projects had these specific failure patterns. Based on that, here's your risk profile—not a guess, but a calculation."

That's exactly what ARIA does.

Why ARIA Is Different from Asking ChatGPT

You might be thinking: "Rick, I can already ask ChatGPT about project risks."

Sure. And it'll give you a perfectly reasonable list pulled from PMBOK and every PM article ever published on the internet.

But it won't know that your vendor management process breaks down consistently on projects over $2 million.

It won't know that your design phase always runs 30% longer than planned with remote teams.

It won't know that your change control process only works when a specific executive sponsors it.

ARIA knows—because ARIA is built on your lessons learned, your project history, your organization's DNA.

This isn't AI giving you generic advice. This is AI making your institutional memory operational.

And here's the part that changes everything for executive conversations:

Instead of walking into a budget meeting and saying, "We think we need a 15% contingency buffer because... it feels right"—

You walk in and say:

"This project shares characteristics with 12 historical engagements in our database. Those engagements slipped an average of 68 business days, driven primarily by requirements and scope failures. Based on that pattern, ARIA recommends a contingency of 129 business days and approximately $1.43 million. Here's why."

That's not a guess. That's a defended position.

The Math Behind ARIA: PERT

ARIA is built on the PERT methodology—Program Evaluation and Review Technique. This was developed by the US Navy in the 1950s during the Polaris missile program. They needed a way to estimate completion times when there was massive uncertainty.

Here's how it works:

For any risk exposure, you define three scenarios:

• Optimistic (O): Best case. Risk doesn't materialize. Exposure = zero.
• Most Likely (M): What you actually expect. ARIA uses a baseline of five days.
• Pessimistic (P): Worst case. ARIA pulls this from your historical database—the actual delay when this risk materialized in past projects.

Then you calculate:

Expected Value = (O + 4M + P) ÷ 6

This gives you a statistically sound estimate that accounts for uncertainty. Not a wild guess. Not a simple average. A weighted probability.

And then ARIA takes it further. She calculates exposure—the combination of expected delay, probability you assign, impact you assign, category weight, and how much your organization historically suffers from this type of risk.

That exposure number, measured in both days and dollars, is what ARIA uses to rank your risks and calculate your contingency.

And here's the beautiful part: When a project closes and ARIA ingests the lessons learned, she updates the pessimistic scenario values. The database learns. The next estimate gets smarter.

ARIA's Six Modes

Mode 1: Lessons Learned Ingestion The fuel that powers everything else. Bring ARIA a completed project—closeout documents, status reports, post-mortems. She extracts variances over your threshold, structures them, asks you to confirm before writing to the database. No garbage in, no garbage out.

Mode 2: Risk Assessment The flagship. A new project starts, you give ARIA the basics, she runs your database against it using fuzzy matching, scores the top 20 most relevant historical risks, asks you two questions per risk (probability and impact), and generates a fully formatted Excel workbook with an executive summary, risk register, and PERT calculations. Presentation-ready in minutes.

Mode 3: Risk Coach Targeted guidance in the moment. You come to ARIA with a question—"We're about to start vendor negotiations. What should I watch for?"—or you feed her a status report that feels off. She analyzes it against the database and gives you a narrative memo: preventative questions, mitigation suggestions, early warning indicators, evidence signals to monitor.

Mode 4: Project Closeout When a project ends, ARIA walks you through a structured interview. What happened? Where did you deviate? What caused the variances? She captures it, flags anything volatile for the database, and ensures lessons actually get recorded for the next team. This feeds Mode 1. It's a closed loop.

Mode 5: Project Health Check For projects going sideways—or when leadership wants an honest read. ARIA analyzes your project documents, tracks sentiment over time (are updates getting more hedged? is tone shifting from confident to defensive?), and produces a color-coded assessment across eight dimensions:

Schedule trajectory. Budget integrity. Scope stability. Team dynamics. Stakeholder engagement. Risk posture. Delivery confidence. Process adherence.

With course correction recommendations prioritized by urgency.

Mode 6: Maintenance Behind-the-scenes database management. Category weight updates, metadata management, quality control. The housekeeping that keeps everything else trustworthy.

Watching It Work: A Live Risk Assessment

Let me show you what ARIA actually does.

The project: Dynamics 365 implementation for a manufacturing client. 2.7M—a 22% reduction). Nine months. Fixed price. Client wants a "like for like" replication of their current ERP. Thin requirements.

I gave ARIA those details and let her run.

Within two minutes, before she even asked me a question, ARIA flagged something:

"Two characteristics you've noted—a like-for-like replication with thin requirements, combined with a fixed-price contract that was cut 22%—align almost exactly with the single highest-severity record in the entire database."

She had seen this before.

Then she loaded the questionnaire—12 risks, in batches of five—each one with plain-language descriptions of what 0, 1, 2, and 3 mean, so you're scoring with context, not guessing.

The first question referenced a real historical engagement:

"An integrator never ran formal requirements gathering and configured the ERP to mimic legacy green screen behavior. UAT failed completely after two years. The systems integrator was removed. The project slipped 240 business days."

Then it asked: Is this likely to happen on this project? What's the impact if it does?

I scored it a 3 on both.

Four minutes later, ARIA generated the Excel workbook.

Executive Summary:

• Total recommended contingency: 129 business days
• Confidence band: 91 to 167 business days
• Contingency dollar value: $1.43 million (approximately 68% of contract value)
• Top 5 risks by exposure score
• Executive narrative ready to present

PERT Calculations Tab: Full transparency. Every risk, every scenario, every multiplier, every formula. No black box.

Risk Register: Full scored list with probability, impact, exposure in days and dollars, source project references, and AI-generated mitigation strategies.

That workbook was ready in under 10 minutes.

Not a template. Not a guess. A mathematically grounded, historically evidenced risk assessment.

What This Really Means

For 30 years, I've been saying that project managers should be dream makers—not administrators. That our job is to clear the path so teams can do their best work.

ARIA takes one of the most time-consuming, highest-stakes activities we do—risk management—and makes it faster, smarter, and grounded in evidence.

That's time you get back.

Time to coach your team. Time to build stakeholder relationships. Time to think instead of calculate.

And that defended contingency number? That's your credibility.

Walking into an executive meeting and saying "here's what the data says we need, and here's why" is a completely different conversation from "I think we should add a buffer."

ARIA doesn't replace project managers. She amplifies us.

She gives us the organizational wisdom that used to walk out the door every time someone retired or changed jobs. She is your organization's memory—one that doesn't forget, doesn't get promoted, and gets smarter every time a project closes.

This is what I described in 2008.

This is what technology finally let us build.

---

Next time: Meet Atlas—the estimation engine. If ARIA protects you from risk on the back end, Atlas builds your estimates on the front end with the same rigor. Practice libraries, three-scenario PERT modeling, fully formatted Excel workbooks generated in minutes. Production ready. Running on real engagements right now.

— Rick A. Morris

AI Driven PM: S2E9 - Coach First, PM Second

 

Or: Why the Best PMs in the AI Era Coach First and Manage Second

I almost skipped the coaching certification.

When I joined the John Maxwell team, the coaching program was part of the package. And honestly? I wasn't that interested. I was doing well in my career. I had built successful PMOs. I had a reputation for getting results.

What did I need a coaching certification for?

But I went. And a trainer named Christian Simpson changed everything.

He was talking about directive leadership—how most leaders just answer questions, tell people what to do, and keep everyone dependent on them for direction.

That was me. I was a directive leader. And I knew it, because the proof showed up every time I tried to take a vacation.

My phone would ring constantly. I'd come back to disaster areas. Everything waited for me because I had built a team that couldn't function without my answers.

I thought I was being helpful. I was actually being a bottleneck.

And then Christian said the thing that rewired how I lead:

"If you give somebody the answer, you rob them of a lifetime of learning."

That hit me.

If you give someone the answer, they'll ask the same question next time. Because they didn't learn—they were just told.

But if they find the answer? If they work through the problem, make the connections, arrive at the solution themselves?

They'll never forget it.

From Manager to Coach: The Shift That Changes Everything

There's a debate I've been in a hundred times about whether project management is "command and control."

When I went through my first Agile training, they described project management like Godzilla stomping through cities. Commanding. Controlling. Dictating.

And Agile? It was communal living, group hugs, servant leadership, butterflies everywhere.

I always pushed back on that.

I was never a command-and-control PM. Even before my personal development journey, I believed in enabling people over directing them. I just didn't have the language for it.

But here's the real distinction that matters:

Old PM role: Here's the plan. Here's your task. Go do it.

New PM role: What do you need to succeed? How can I remove the obstacles in your way?

One extracts work from people. The other builds capacity in people.

And in the AI era, that difference has never mattered more.

Here's why:

AI can automate task management. It can build schedules, generate reports, write requirements, summarize meetings. All the things that used to justify our existence as schedulers and documenters?

Gone. Or going.

But what AI cannot touch is the emotional side of project work.

Conflict between two senior engineers who both think they're right and neither is wrong.

A team member withdrawing quietly because scope keeps changing and nobody's noticing.

A junior PM who doesn't know how to push back on a sponsor without getting their head taken off.

That's where we live now. That's the new PM value zone.

And you can't navigate that by giving answers.

You navigate it by asking the right questions.

The Coaching Mindset vs. The Management Mindset

Manager	Coach
Provides the answer	Asks questions to surface the answer
Directs action	Creates space for discovery
Extracts work	Develops people
Tells people what's wrong	Helps people see what they haven't seen
Creates dependency	Builds capability

The shift isn't about being softer. It's about being smarter.

People own the solutions they create. When the answer comes from them—when they worked through it, wrestled with it, arrived at it—they execute it with conviction, not compliance.

And remember what we covered in Episode 8? Compliance leads to resistance. Resistance leads to revenge. Revenge leads to resentment.

Coaching is the antidote to all three R's.

The Core Coaching Skills Every PM Needs Right Now

Active Listening: Not just hearing words—hearing what's not being said. The fear underneath the frustration. The confusion beneath the compliance. The real blocker hiding behind "everything's fine."

Powerful Questions: Questions that help people think differently, not just answer you. "What options have you already considered?" beats "Have you tried X?" every time.

Holding Space: Creating safety for the hard conversations. Pausing. Sitting in the silence instead of rushing to fill it.

Capability Building: Developing people, not just extracting work from them. Asking "what would help you grow through this?" alongside "what do you need to ship this?"

Accountability with Empathy: High standards AND high support. Both. Not one or the other.

The Story That Made It Click

Let me tell you the best coaching moment I've ever been on the receiving end of.

I was building out the GrowthDay platform for Brendan Bouchard. And I was having a real problem with one of my team members. I was frustrated. Genuinely frustrated.

So I called Brendan.

And I went. I vented. I laid it all out—every frustration, every grievance, everything this person had done that was driving me crazy.

Brendan just listened. The whole time.

And when I was finally done, he asked me one question:

"Huh. Well, what did he say when you told him all this?"

Silence.

What did he say... when I told him.

I hadn't told him.

Not one word of what I'd just spent ten minutes telling Brendan had ever been said directly to the person I was frustrated with.

And in that moment I realized: I had been complaining to the boss about someone I hadn't even attempted to talk to myself.

Brendan didn't tell me that. He didn't say, "You need to go have that conversation." He didn't lecture me about going around someone.

He asked one question.

And I arrived at the answer myself.

That's a lifetime of learning in a single sentence.

I've never forgotten it. And I've never again brought a complaint to someone's supervisor without first having the conversation directly.

That's coaching.

Now Let's Use AI to Get Better at It

Here's the beautiful irony: The tool that people worry will replace human connection is actually one of the best tools I've ever found for preparing for human connection.

AI won't coach your team for you. But it will help you show up to coaching conversations more prepared, more thoughtful, and more focused on the right questions.

Let me show you three prompts I use.

---

Prompt 1: Coaching Conversation Planner (Your Non-Negotiable)

The situation I gave it:

Sarah—a senior back-end engineer on the Social Wishing project—has been withdrawing. She used to drive planning discussions and code reviews. Now she's quiet, says "whatever the team decides," works late but doesn't surface blockers, and gives short answers in one-on-ones.

Her velocity is still fine. Her engagement is not.

What ChatGPT gave me:

"Sarah still delivers. The risk sits in disengagement—senior engineers influence architecture, team energy, and decision quality. If she withdraws, the team loses signal."

Powerful questions by theme:

• "What have the last few sprints felt like from your perspective?"
• "When scope changes come up, what goes through your mind?"
• "What are you carrying that the team doesn't see?"

Claude's opening:

"Sarah, I wanted to carve out some time that isn't about tickets or sprint status. How are you actually doing?"

And then: Full stop. Don't add qualifiers or softeners. Let her decide how much to give you.

If she says "fine" or "busy," Claude told me:

"Follow with: 'I believe that you're busy. What I'm asking is whether busy feels okay right now—or whether it's starting to wear on you.'"

That's not a script. That's a doorway.

Claude also gave me the question sequence:

1. Energy and load
2. Work experience
3. What she needs
4. What adjustment to watch for if she deflects

This took me two minutes to generate. The conversation itself might be the most important one I have this week.

---

Prompt 2: Powerful Coaching Questions Library

This one builds you a reusable toolkit organized by situation type.

Common PM situations:

• Team member stuck and escalating
• Two team members in conflict
• Team member underperforming but unaware
• Team member wants career growth
• Team member resistant to change

My favorite questions from what the AI generated:

For a stuck team member:

• "If you had to make this decision without me, what would you do?"
• "What's the smallest step you could take to test a direction?"

For conflict:

• "What outcome do you actually want from this situation?"
• "What part of this disagreement is about facts versus preferences?"

For underperforming but unaware:

• "What are you most proud of from the last month—and what would you do differently?"
• "Is there anything getting in the way of your best work that I don't know about?"

The most important coaching principle the AI surfaced:

Don't lead the witness.

❌ "Don't you think we should handle the architecture this way?" ✅ "What architecture options do you see?"

❌ "Do you think it would help to talk to them directly?" ✅ "What options have you considered?"

Same destination. Completely different journey. And the journey is where the learning lives.

---

Prompt 3: Conflict Coaching Facilitator

The scenario: Two senior engineers at an impasse. Sarah wants microservices from day one (scalability). Tom wants monolith first (speed to MVP). Both are dug in. The debate is getting personal.

Claude's diagnosis:

"Architecture debates between senior engineers rarely stay technical this long unless something else is driving them. This conflict has three layers: 1. Risk tolerance and time horizon 2. Identity and credibility 3. Decision authority ambiguity

Until you address layer three, layers one and two will keep feeding each other."

ChatGPT's framing:

"Sarah sees Tom as cutting corners. Tom sees Sarah as slowing the team with unnecessary complexity. Both are trying to protect the project from risk—but they can't see that in each other.

The goal of your conversation is to reframe the debate from personal positions to shared project outcomes."

Questions for Tom:

• "What risks do you see if we start with microservices?"
• "What assumptions are you making about future scale?"

Questions for Sarah:

• "What specifically makes you confident a monolith won't become a problem at scale?"
• "What's your read on where the product is heading in 18 months?"

What the AI surfaces that's most valuable:

What's not being said.

Tom isn't saying, "I'm scared we're going to miss the launch date and I'll be blamed."

Sarah isn't saying, "I've seen monoliths become nightmare refactors and I can't watch it happen again."

Those are the real conversations. And you can't get there by asking about architecture.

---

Your Non-Negotiable Experiment This Week

Use the Coaching Conversation Planner to prepare for a real coaching conversation this week.

Then ask at least three coaching questions—and resist the urge to answer them yourself.

Here's what I want you to notice:

1. How does the person respond to questions versus directives?
2. Do they arrive at solutions you hadn't thought of?
3. Does coaching build capability and ownership in a way that managing doesn't?

Because here's the thing:

The tasks are getting automated. The human side of projects—the conflict, the fear, the ambiguity, the growth—that's becoming our entire job.

If you're still managing in a world that needs coaching, you're optimizing for a role that's disappearing.

But if you learn to ask the right questions?

You become the person no AI will ever replace.

---

Next time: Work-Life Balance 2.0—how AI changes the always-on PM trap. Excited to share some different ways of using AI to help us become not just better PMs, but better humans.

Want these prompts ready to copy/paste? Head to PMThatWorks.com for the full library.

Now go prepare for that coaching conversation. Somebody on your team is waiting for the right question.

— Rick A. Morris

---

The Prompts (Copy/Paste Ready)

Prompt 1 - Coaching Conversation Planner

You are an executive coach training project managers to coach their teams effectively.

First, ask me 4–6 questions about the team member, the situation they're facing, what I've observed, and what outcome I want from the conversation.

Then provide a coaching conversation plan answering:

1. What is the coaching goal for this conversation?
2. What powerful questions should I ask to help this person think through the situation themselves?
3. What am I listening for? (underlying concerns, assumptions, blind spots, emotions)
4. How do I balance support with accountability?
5. What's my opening? (How do I set the tone and create safety?)
6. What's my closing? (How do I ensure clarity and commitment to action?)

Team member situation: [Enter Context]

---

Prompt 2 - Powerful Coaching Questions Library

You are a professional coach creating a question library for PMs to use in team conversations.

Ask me 2–3 questions about common situations I face with my team (performance issues, conflict, low morale, ambiguity, or resistance).

Then provide a library of powerful coaching questions organized by situation type answering:

1. What are 5–7 coaching questions for each situation type?
2. What is each question designed to unlock? (self-awareness, ownership, options, or commitment)
3. When should I use open-ended questions vs. more directed questions?
4. How do I avoid leading the witness and let people arrive at their own insights?

Situations I commonly face: [Enter Situations]

---

Prompt 3 - Conflict Coaching Facilitator

You are a conflict resolution coach helping PMs facilitate team conflicts.

Ask me 4–5 questions about the conflict, the people involved, what each person wants, and what I've observed about the dynamic.

Then provide a facilitation strategy answering:

1. What is the underlying conflict? (goals, values, communication styles, resource scarcity, or misunderstanding)
2. How do I create a safe space for the conversation?
3. What coaching questions do I ask each person to help them articulate their perspective and needs?
4. How do I guide them toward mutual understanding—not just compromise?
5. What agreements or commitments do we need to leave the conversation with?
6. How do I follow up to ensure the conflict is resolved and not just paused?

Conflict situation: [Enter Context]

 

AI Driven PM: S2E8 - Resistance, Revenge, Resentment

 

Stop Counting. Start Leading.

Let me tell you something I learned that changed the way I lead.

Around 2012, I got serious about personal development. I joined the John Maxwell team. I had phenomenal coaches and mentors around me. And one teaching from Paul Martinelli hit me in a way I wasn't expecting.

He was talking about relationships. And he said:

"The danger in relationships is counting."

Once you start counting—that's the third time they've done that, that's the fourth time that's happened—you've started keeping score.

And once you're keeping score, three things happen. He called them the Three R's.

Resistance. You start pulling back. Cutting the person off a little. Creating distance.

Revenge. You start doing the same thing back to them. They're going to do that to me, I'll do it to them.

Resentment. And this is the dangerous one. This is emotional withdrawal. Leadership doesn't care. Nobody's paying attention. I'm done.

Once resentment sets in, that relationship is over.

Here's what hit me: I'm data-driven. I count everything. And when I traced the roots of some of my most difficult client relationships, I could see exactly when I had started counting their failures instead of solving their problems.

I was tracking the wrong metrics. And it cost me relationships.

But that's not why I'm telling you this story.

I'm telling you this because those same Three R's? They're happening on your change initiative right now.

Your Tool Isn't Failing. Your Change Management Is.

Three months after rollout, 60% of people are still using spreadsheets.

Teams are calling the new PM tool "Rick's surveillance tool."

Two departments are openly hostile. Leadership announced the rollout and then disappeared. Training was a 90-minute session with no follow-up.

Sound familiar?

Here's the sequence:

• Resistance: Passive non-compliance. "I'll just keep using spreadsheets until this blows over. Every few years they try something new. I'll wait them out."
• Revenge: Active demonstration that it doesn't work. "You want me to use this? Fine. I'll use it. And I'll make sure everyone knows how painful it is."
• Resentment: Emotional withdrawal. "Leadership doesn't actually care. Nobody reads these reports anyway. I stopped doing it six weeks ago and nobody noticed."

And here's the painful truth that Claude told me in our live demo and I couldn't have said it better:

"This is not a training problem or a tool problem. It is a trust problem with a workflow mismatch layered on top."

You didn't fail at selecting technology.

You failed at managing the human side of change.

People Don't Resist Change. They Resist Being Changed.

This is where DISC blew my mind.

I mentioned DISC in Episode 7. But here's the stat that changed the way I think about every rollout I've ever managed:

69% of the population is High S.

High S personalities love routine. They thrive on predictability. They come in, everything is in its place, and they do their best work.

They will change. But they don't like being changed.

And most organizations manage change initiatives like High D personalities designed them—fast, decisive, bullet point, done.

You announce it. You train them. You expect adoption.

And then you wonder why 60% of people are still using the old system three months later.

Here's the other piece nobody says out loud: People won't change unless they hurt enough that they have to, or care enough that they want to.

That's it. Those are the only two change levers.

Most change initiatives activate neither.

Why Change Initiatives Really Fail

It's almost never about the tool.

Here's what I've seen in 150+ implementations:

We focus on the WHAT. We ignore the WHO.

New tool. New process. New org structure. We spend 90% of our time configuring, integrating, testing, and training on the what—and about 10% on the people who have to actually change their behavior.

And then when adoption fails, we schedule more training.

More training on a tool people don't trust won't fix a trust problem.

What actually triggers the Three R's:

• Change is done to people, not with them
• No clarity on why the change matters
• No voice or input in how the change happens
• Broken trust from past change initiatives that went nowhere
• Leaders who disappear after the kickoff

And I want to call out one thing that kills me in every large-scale implementation I've ever seen:

They cut training. They cut change management. They cut project management.

The ERP costs 2 million. The configuration runs over. And when they need to find money, they cut the things that ensure the whole thing actually works.

"We have people internally who can handle that."

No. You don't. Not because your people aren't capable—but because change management is a discipline, not a checkbox. And it requires time, intentionality, and someone who isn't also trying to do their day job.

AI Change Management Is Different

Here's what makes the current AI rollout wave particularly dangerous:

AI change is personal in a way that a new PM tool isn't.

When you roll out monday.com, people are annoyed. When you roll out AI tools, people are scared.

They're wondering: Is this the beginning of my replacement? Are they tracking my productivity to justify headcount reduction? Am I being automated out of relevance?

I've answered some version of "Will AI replace project managers?" dozens of times. The answer is the same every time: AI won't replace project managers, but you will be replaced by a project manager who knows how to leverage AI.

But when you're rolling out AI to a team that doesn't believe that? When leadership is absent, training was insufficient, and people don't see "what's in it for me"?

The Three R's hit faster and harder than with any previous technology adoption.

If you're not actively managing the people side of your AI rollout, you're watching the clock count down to resentment.

The Clarity Tool Lesson

Let me tell you one more story.

I used to do a lot of project rescue work. Organizations would call me when their implementation had gone wrong and they needed someone to come in and fix it.

For years, I supported CA Clarity—one of the most powerful PPM tools on the market. You could automate almost any process imaginable. Incredibly configurable.

But I'd walk into these organizations and feel the resentment the moment I walked in the door.

The tool hadn't been deployed well. The adoption had failed. People hated it. And the damage was done.

We could rebuild it. We could redesign it. We could deploy it properly this time, do real training, proper change management.

But the resentment gap was nearly impossible to overcome.

People had already decided. The tool was garbage. Leadership couldn't be trusted. Nothing would change.

So I had to transition my business from rescue work to implementation work.

Because trying to recover from resentment? That's a nearly impossible project.

This is why I say: Catch resistance early. Address it at resistance. Don't let it become revenge. And don't let revenge become resentment.

The Three Prompts That Help You Diagnose and Act

I ran three prompts live today using a scenario most of us recognize: A PM tool rollout three months in, with 60% still using spreadsheets and two departments calling it "Rick's surveillance tool."

---

Prompt 1: Change Readiness and Engagement Diagnostic (Your Non-Negotiable)

What it does: Assesses where your team sits on the change readiness spectrum, identifies what stage of the Three R's you're in, surfaces root causes, and gives you a 30-day action plan to shift sentiment and build ownership.

What the AI told me:

ChatGPT's change readiness diagnosis:

• Most of the organization: between understanding and acceptance (they know the tool exists but don't believe in its value)
• Hostile departments: at awareness only (they know it exists and actively reject it)

Three R's signals:

• Resistance: Monday.com is being used as a reporting layer, not a system of work. Spreadsheets still run the actual business.
• Resentment: Calling it "Rick's surveillance tool" signals distrust of leadership intent. They believe this serves leadership control, not team productivity.
• Revenge: Double work creates visible friction. Teams signal frustration through inefficiency without open confrontation.

Claude's action plan:

Move 1: Co-creation with resistant departments.

"Do not push more training or communications into hostile departments. Go in and listen first. Facilitate working sessions where they redesign their monday.com boards to match how they actually work. Give them ownership of the configuration.

This is the only credible counter to the surveillance narrative. When they build it, it stops being yours."

That last sentence is everything.

Move 2: Activate the 40%.

"Identify two or three visible, respected people per department who are already using it effectively. Make them peer coaches—not ambassadors. Peer-to-peer adoption is faster and more credible than top-down instruction. Document one concrete time-saver or meeting eliminated per team as a proof point."

And the metric I loved most from Claude:

Number of times leadership references monday.com data in informal settings.

Because if leadership doesn't use it publicly, nobody believes it matters. That's not a usage metric. That's a trust metric.

---

Prompt 2: Resistance Root Cause Analyzer

The behaviors I gave it:

• People say yes in meetings, then don't change behavior
• Slack is full of "this tool is stupid" comments
• One manager told their team: "Just keep using the spreadsheet. This will blow over."
• Multiple IT tickets requesting to be removed from the system
• Poor training participation (multitasking, minimal questions)
• One senior engineer said publicly: "This is just another fad. Remember when we tried [previous tool]?"

What the AI diagnosed:

Type of resistance:

• Passive: Yes in meetings, no behavior change
• Active: Slack complaints and vocal opposition
• Avoidance: Low training engagement
• Sabotage: The manager telling their team to keep using spreadsheets

Underlying fears:

• Fear of demonstrated incompetence (low training engagement = they don't want to look like they can't figure it out)
• Fear that this change signals something about their future (Big Brother tracking)
• Fear of workload increase without compensation ("You're increasing what I have to do without increasing what you pay me")

Unmet needs:

• Need for input and co-authorship
• Need for competence and psychological safety
• Need for a manager who's actually aligned

The senior engineer's comment is the most important signal of all. When someone says, "Remember when we tried [previous tool]?"—they're not complaining about this tool. They're telling you: "I've been through this before. Nothing changed. Why would this be different?"

That's broken trust from past failures. And no amount of training fixes that.

---

Prompt 3: Co-Creation and Ownership Strategy

Here's the key reframe Claude gave me before building the strategy:

"The worst version of participatory change is pretending people have input they do not have. Name the constraint honestly before you invite collaboration."

What I could actually open up for input (even though the tool decision was final):

• How boards are configured
• What the required fields look like
• Automation rules and permission structure
• Update frequency and check-in norms
• Who owns each board

That's not a small thing. When people design how their system works, it becomes their system. Not the tool leadership forced on them.

The pilot experiment approach: Run a 30-day experiment with one willing team, not to prove the tool works—to learn what actually makes it work for them. Then share those wins peer to peer.

The communication principle: Don't claim you're listening if you're not prepared to act on what you hear. Performative co-creation is worse than no co-creation. It validates the cynicism.

---

Your Non-Negotiable Experiment This Week

Run the Change Readiness and Engagement Diagnostic (Prompt 1) on a current or recent change initiative.

Then take one action: either invite co-creation or directly address a root cause of resistance.

Here's what I want you to notice:

1. Does giving people a voice shift sentiment—even when the change itself is non-negotiable?
2. Do you discover root causes you hadn't seen before?
3. Where on the Three R's spectrum is your team, really?

Because here's the truth:

You can have the best tool in the world. If you skip the people side, it will fail.

And once resentment sets in, you're not doing a rescue. You're doing a replacement.

Catch it at resistance. That's where change is recoverable.

Stop counting their failures. Start co-creating their success.

---

Next time: Coaching First, PM Second—why facilitation is one of your most valuable skills in the AI era, and how to lead without being the one with all the answers.

Check out the live episode on YouTube: 

Now go find out where your change initiative really is.

— Rick A. Morris

---

The Prompts (Copy/Paste Ready)

Prompt 1 - Change Readiness and Engagement Diagnostic

You are an organizational change management consultant.

First, ask me 5–7 questions about the change initiative, the people affected, their current behavior and sentiment, past change history, and leadership engagement.

Then provide a diagnostic and strategy that answers:

1. Where is the team on the change readiness spectrum? (awareness, understanding, acceptance, adoption, or advocacy)
2. What signs of resistance, revenge, or resentment am I seeing?
3. What are the root causes of resistance? (lack of clarity, fear, broken trust, no input, poor execution)
4. What change management strategy should I use? (communication, co-creation, small wins, leadership modeling)
5. What specific actions should I take in the next 30 days to shift sentiment and build ownership?
6. How do I measure progress in change adoption beyond the number of people trained?

Change initiative context: [Enter Context]

---

Prompt 2 - Resistance Root Cause Analyzer

You are a behavioral psychologist specializing in organizational change.

Ask me 3–5 questions about specific resistance behaviors, what people are saying or not saying, and what happened leading up to the resistance.

Then analyze the root causes by answering:

1. What type of resistance am I seeing? (passive, active, avoidance, or sabotage)
2. What are the underlying fears or concerns driving the resistance? (fear of job loss, loss of control, incompetence, increased workload)
3. What unmet needs are people expressing through resistance? (clarity, input, support, or trust)
4. What past experiences are influencing current resistance? (previous failed changes, broken promises)
5. How do I address root causes rather than just symptoms?

Resistance behaviors observed: [Enter Context]

---

Prompt 3 - Co-Creation and Ownership Strategy

You are a change management facilitator specializing in participatory change.

Ask me 3–4 questions about the change initiative, who's affected, and where I could invite input or co-creation.

Then design a co-creation strategy answering:

1. Where in the change process can I invite people to shape HOW—not just accept WHAT?
2. What decisions can I delegate or open up for input?
3. How do I identify and empower change champions within resistant groups?
4. What pilot or experiment can I run WITH the team (not TO the team) to build ownership?
5. How do I communicate that input is genuinely valued and not just performative listening?

Change initiative and constraints: [Enter Context]

 

AI Driven PM: S2E7 - The Greatest Lie Ever Told in Project Management

Why Influence Is the Only Skill That Actually Matters

Somebody told me early in my career that I owned my project.

Owned it. Like it was mine.

Like I could make decisions, adjust budgets on the fly, tell people what to do, and hold the team accountable because—hey—it's my project.

Let me tell you what I actually owned:

The blame. When things went wrong, I owned that.

Here's the reality of project management that nobody puts in the job description:

• The people don't report to me
• It's not my money
• It wasn't my idea
• I don't set the timeline
• I don't control the strategy

And yet somehow, when the project goes sideways, everybody looks at the PM and says, "Why didn't you see this coming?"

That's the contradiction at the heart of our profession. And it's exactly why influence is the number one skill you need to develop.

Not scheduling. Not risk management. Not Agile certification.

Influence.

You Can't Make Anyone Do Anything

Let me be really clear about something:

As a project manager, you cannot make anyone do anything.

You can't make your team work faster. You can't make your sponsor change the date. You can't make your executive adjust the budget. You can't make your stakeholders show up prepared.

All you can do is influence the outcome.

Here's how I describe our actual job: We increase the percentage chance of hitting a date or budget by doing analysis, building plans, framing decisions, and then influencing whoever we're speaking with—team, sponsor, executive, customer—toward the outcome the project needs.

PMs operate in the influence space between silos.

We're the connective tissue. We're the translators. We're the ones standing between engineering's reality and the sponsor's dream, trying to close the gap without anyone getting hurt.

That's not authority. That's influence. And they require completely different skill sets.

The Three Currencies of Influence

If you haven't read Cialdini's Influence: The Science and Practice of Persuasion, go get it today. It feels like a sales and marketing book. But think about what we do every day:

• Selling a position to move a date
• Marketing the case for a budget adjustment
• Persuading a skeptical stakeholder to trust the process

We are in sales. We just don't call it that.

From my experience, PMs work primarily in three influence currencies:

1. Credibility

People trust your judgment because you've earned it.

Not because of your title. Not because of your certification. Because of your track record, your preparation, your follow-through.

Credibility is the currency you build over time. And it's the one that gets spent fastest when you overpromise, underdeliver, or show up unprepared.

2. Reciprocity

You help others achieve their goals—and they help you achieve yours.

I think this is the most powerful influence lever PMs have access to. When you go to bat for someone, cover for them, solve a problem before they ask, create opportunities for them to shine—you build something that no org chart can give you.

Real influence is banked through real acts of service.

One important note though: Don't explicitly remind people of what you did for them and then ask for something back. I'll come back to this—Claude made this mistake in our live demo, and it's worth discussing.

3. Vision

You paint a picture of success so compelling that people want to contribute.

This is why we develop dream statements, mantras, and team motivation stories. We covered this in Episode 1. The reason I invest so heavily in clarifying the why behind every project is because people don't get inspired by Gantt charts.

They get inspired by a destination they believe in.

When they can see the win—when they can feel what success looks like—influence becomes almost effortless.

Three Common Influence Mistakes (That Kill Your Credibility)

1. Over-Relying on Logic

You build the perfect case. The math is airtight. The risk analysis is complete. You walk into the meeting absolutely certain that any reasonable person will see it your way.

And then the sponsor says, "We're making that date no matter what."

Logic without emotional intelligence isn't influence. It's a monologue.

2. Positional Pleading

"The CEO said so." "This is what the executive team wants." "I have authorization from leadership."

That's not influence. That's borrowed authority. And it erodes trust every time you use it, because people know you're not actually speaking for yourself.

3. Passive Aggressive Escalation

"I guess I'll just have to escalate this to the executive team." "I'll let them know we're going to miss the date."

This is an influence killer. Nobody rallies around a PM who threatens escalation. They shut down, get defensive, and you lose the relationship.

Real influence doesn't require threats. It creates alignment.

The DISC Secret Weapon

Here's something that transformed how I communicate with stakeholders:

One message. Four different ways to say it.

DISC is a behavioral assessment framework with four communication styles:

• High D (Dominant): Bullet points, get to the point fast, no fluff
• High I (Influential): People-focused, enthusiastic, what's exciting about this?
• High S (Steady): Change-resistant, needs context, what's the impact on the team?
• High C (Conscientious): Data-driven, detail-oriented, show me the facts

If you bring a five-paragraph explanation to a High D, they check out at sentence two.

If you lead with data and logic for a High S who's worried about their team, you miss the real concern.

Meeting people where they are isn't manipulation. It's respect.

And when you combine that with Socratic AI prompting—where you give the AI context about the stakeholder's style and ask it to help you craft the message—you unlock something powerful.

The Three Prompts (And What the AI Actually Gave Me)

I ran three influence prompts live using our Social Wishing app scenario: We need to cut three MVP features—AI recommendations, in-app messaging, and payment integration—to protect the launch date and save the team from burnout.

---

Prompt 1: Influence Network Mapper (Your Non-Negotiable)

What it does: Maps the key influencers and decision makers, identifies their positions and motivations, recommends influence tactics for each, and builds you a conversation sequencing strategy.

What I got:

ChatGPT opened with:

"You're not trying to win an argument. You're trying to align incentives around a shared risk. The hidden risk isn't feature loss. It's execution failure."

That reframe alone is worth the price of admission.

The sequencing strategy it gave me:

1. Engineering manager first — Meet privately, turn frustration into structured input. Ask them to quantify velocity trends, estimate burnout risk, and calculate realistic delivery probability. "I need your help protecting the team and protecting the date. I don't want this to become an engineering versus business fight."
2. Product owner second — Pre-align before the CEO meeting. Convert engineering evidence into risk framing.
3. Marketing director third — Build the narrative that gives the CEO something to say publicly.
4. CEO last — Walk in with the engineering risk doc, the product owner's alignment, and the marketing director's framing already in hand.

And then Claude gave me the closing guidance that absolutely nailed it:

"You're not building consensus. You're building a sequence of aligned conversations so that by the time you reach the CEO, the decision feels inevitable rather than contentious. Each conversation should leave the stakeholder feeling heard—not managed. The goal is that no one walks into the CEO meeting as a surprise voice of opposition."

That's the playbook. Pre-wire every conversation so the final meeting is a confirmation, not a confrontation.

---

Prompt 2: Stakeholder Persuasion Message Crafter

The specific situation: Convincing the executive sponsor—who loves AI and sees it as a market differentiator—to launch without AI recommendations.

What the AI gave me:

The core message:

"Launching AI recommendations before the user base exists to train them guarantees this feature underperforms at the exact moment it needs to impress the board."

The analogy:

"Netflix didn't launch with a recommendation engine. They launched with the catalog. The recommendation engine came after they had enough viewing data to make it work. An AI feature trained on zero user behavior doesn't differentiate you—it could embarrass you."

And then the strategic opportunity flip:

"A post-launch AI reveal gives you two press moments instead of one. We launched clean. We proved traction. Now we're releasing AI 1.1 with real usage data. That's a story—not a patch."

ChatGPT offered a different analogy:

"Launching without data-driven AI is like launching a Tesla without Autopilot enabled."

Both are strong. Both give the sponsor something to say in the boardroom. Leaders love a reference story that makes their decision sound precise, not reactive.

---

Prompt 3: Reciprocity & Coalition Builder

Here's where I want to be honest about the tool differences—because one of the most valuable things I can do in this series is show you where AI gets it right and where it gets it wrong.

Claude's suggestion for the engineering manager:

"I backed their QA resource request. Now I need to go to them first, privately, and name it directly: 'I went to bat for you on QA. I need you to go to bat for me—and for the team—now.'"

I pushed back on that.

Don't explicitly call out the favor. The moment you say "I did this for you, now you do this for me," you've turned reciprocity into a transaction. And the next time you do something generous for that person, they'll wonder what you're banking it for.

Real reciprocity doesn't need to be verbalized. It should be felt.

ChatGPT handled it better:

"You backed their QA request. That built trust. What they want now is team stability and credibility. Help them by making sustainable scope the official position—not a quiet concern. If you carry the political weight, they don't have to."

That's the difference. You're not reminding them of a debt. You're aligning your ask with their interests and removing a burden from their plate.

That's influence.

---

The Big Picture

Here's what I want you to take away from this episode:

You'll never have authority over the things that determine project success. Budget, people, strategy, timeline—none of it is yours.

But influence? That's entirely within your control.

Map your influence network. Understand what each person cares about. Sequence your conversations. Build reciprocity through genuine acts of service. Craft messages that meet people where they are.

And then watch what happens when a PM walks into a final decision meeting where the outcome is already inevitable.

That's not manipulation. That's masterful leadership.

---

Your Non-Negotiable Experiment This Week

Use the Influence Network Mapper (Prompt 1) on a real decision you need to influence this week.

Then have at least one conversation using the strategy or message AI helps you design.

Here's what I want you to notice:

1. Did mapping the influence network reveal leverage points you hadn't considered?
2. How did stakeholders respond when the message was framed around their priorities?
3. Did the sequencing strategy change how the final conversation landed?

Because here's the truth: The most effective PMs I've ever met don't win by being the loudest or the most technically correct. They win by knowing exactly who to talk to, in what order, with what message.

And now you have a thinking partner that helps you figure all of that out in minutes.

---

Next time: The Three R's—Resistance, Revenge, and Resentment. Why change initiatives fail, what happens when people get caught in the Three R's, and how to use AI to navigate your way out.

Want these prompts ready to copy/paste? Head to PMThatWorks.com for the full library.

Now go map your influence network. The decision is waiting.

— Rick A. Morris

---

The Prompts (Copy/Paste Ready)

Prompt 1 - Influence Network Mapper

You are an organizational influence strategist and stakeholder engagement expert.

First, ask me 4–5 questions about the decision I need to influence, who's involved, what their interests are, and what resistance I expect.

Then provide an influence strategy answering:

1. Who are the key influencers and decision makers in this situation?
2. For each person, what do they care about, what motivates them, and what concerns might they have?
3. What is each person's current position? (supporter, neutral, or blocker) and their level of influence?
4. What influence tactics should I use with each person? (credibility, reciprocity, vision, data, coalition building)
5. What is my sequencing strategy? Who do I approach first, and how does that set up the next conversation?
6. What message framing will resonate most with each stakeholder type?

Decision and context: [Enter Context]

---

Prompt 2 - Stakeholder Persuasion Message Crafter

You are a communication strategist specializing in persuasive stakeholder messaging.

Ask me 3–4 questions about the stakeholder, the message I need to deliver, their priorities, and what objections I expect.

Then craft a persuasive message by answering:

1. What is the core message in one sentence?
2. What framing will resonate most with this stakeholder's priorities? (data, vision, risk mitigation, opportunity)
3. What story or analogy makes the message memorable?
4. What objections will they raise, and how do I preempt them?
5. What ask or call to action do I make, and how do I make it easy for them to say yes?

Provide the message in an email or conversation script format.

Stakeholder and situation: [Enter Context]

---

Prompt 3 - Reciprocity & Coalition Builder

You are a relationship strategist helping PMs build reciprocity and coalition.

Ask me 3–4 questions about the people I need to influence, what they care about, and how I've helped or could help them.

Then provide a reciprocity and coalition strategy answering:

1. What have I done (or could I do) to help each stakeholder achieve their goals?
2. How do I frame my ask as aligned with their interests—not just my project needs?
3. Who are the natural allies I should recruit first to build a coalition?
4. How do I leverage early supporters to create momentum with skeptics?
5. What specific conversation should I have this week to build reciprocity and alignment?

Situation and key people: [Enter Context]