AI Driven PM: S2e12 - PACE - Predictability and Cadence Engine

The Question Executives Are Actually Asking

Here's the question I get from every executive sponsor in every agile transformation I've ever run:

"Are we predictable?"

Not "are we busy?" Not "are we shipping features?" Not "is velocity trending up?"

Are the commitments we make to the business actually holding up?

That's the whole game. And yet — after 30 years and 150+ implementations — I can tell you that almost no team is measuring predictability directly. They're measuring velocity. They're tracking story points. They're running burn down charts.

And then they're wondering why leadership still doesn't trust the sprint.

This episode is about PACE — the Predictability and Capacity Engine. The third AI agent in this series. And it answers that question directly.

---

The Problem With Agile Metrics As We Know Them

Velocity is a lagging indicator. So is burn down. So are story points.

They tell you what happened. They don't tell you why stories slipped, whether you're getting better or worse over time, or what to do about it.

Here's the contrarian truth: velocity going up doesn't mean you're getting better. It might mean you're getting faster at moving unfinished work to the next sprint.

I've seen teams with 40% velocity growth and deteriorating stakeholder trust. Because the metric wasn't measuring what mattered.

---

The Distinction That Changes Everything

PACE makes one critical distinction that most agile tools completely ignore:

Is the problem capacity — or readiness?

Capacity is team size, sprint commitment, available hours. Readiness is whether stories enter the sprint with clear requirements, complete designs, resolved dependencies, and defined acceptance criteria.

You cannot fix a readiness problem by adding people. You cannot fix a capacity problem by tightening story quality. These are different problems with different solutions — and confusing them is expensive.

PACE separates them. Every sprint, every team, over time.

---

Two Metrics That Actually Matter

Slide Rate — the percentage of stories committed to a sprint that don't finish in that sprint.

Benchmark: under 15%, ideally under 10%. Consistently above 20%? You're either over-committing or accepting unready work. Probably both.

Readiness Debt — the percentage of stories that entered a sprint without meeting readiness criteria: requirements unclear, designs incomplete, dependencies unresolved, acceptance criteria undefined.

Here's why readiness debt is the more important metric: it's a leading indicator. It predicts slide rate before the sprint closes.

Forty percent readiness debt will cause slide. Not if. How much.

---

The Real Client Story

Large financial services company. Two years of agile. Forty-three sprint cycles. Nearly 50,000 user stories.

Surface metrics? Fine. Velocity trending up. Cost per story point trending down. Team getting more efficient by every standard measure.

But leadership had this persistent feeling that commitments weren't holding. They couldn't quantify it. They just knew something was off.

I pulled 48,621 Jira issues and ran them through PACE.

The finding wasn't what anyone expected. The team wasn't getting worse at execution. They were getting worse at readiness — and it was accelerating.

Slide rate had climbed from 11.8% to 18% for Team A, and the newer team was sitting at 28%.

The instinct in the room was to ask: "How do we increase velocity?" PACE revealed the real question: "Why are we accepting unready work into sprint?"

One story stayed with me. Marked complete. But couldn't be tested — undiscovered dependencies surfaced mid-sprint. The entire team spent that sprint discussing what to do with the ticket. Should have been resolved pre-sprint.

That's not an execution failure. That's a readiness failure. And you'd never see it in a velocity chart.

---

How PACE Works

Export your sprint history from Jira, Azure DevOps, Planner, or even a spreadsheet. PACE ingests it, normalizes the data, identifies committed, completed, and slipped stories, and calculates slide rate and readiness debt per sprint — then trends them over time.

Four deliverables come out the other side:

Sprint dashboard — color-coded by health. Green: slide rate under 10%, readiness debt under 15%. Yellow: 10–20% / 15–30%. Red: above that. You see the trend at a glance.

Best and worst sprint identification — best sprints are benchmark proof that the team can be predictable when conditions are right. Worst sprints are investigation targets. What happened? What entered unready?

Trend analysis narrative — "Slide rate increased from 10% to 25% over 12 months. The team isn't getting worse at execution. They're being asked to execute unready work." That distinction is critical — it tells leadership this is a process problem, not a people problem.

Action recommendations — targeted to what the data actually shows. Capacity recommendations for capacity problems. Readiness recommendations for readiness problems. Retrospective targets for the worst sprints.

Minutes to run. Months of insight.

---

The Cost Per Story Point Metric

This is my signature metric. Sprint by sprint, it shows team efficiency over time — not just "did velocity go up?" but "did we get more done per dollar?"

When you add three people, PACE shows whether you actually got more efficient, or whether you just added cost. When you split a team, PACE shows the productivity impact on both resulting teams — because splitting a high-performing team often tanks both for months before they stabilize.

The portfolio-scale version of this question: "If I add 40 people, how do I know we're more productive?"

PACE answers it. Trending cost per story point and velocity across the full backlog over time. Metrics that were previously impossible to calculate without a data science team and six months of work.

---

The Discipline Paradox

Here's the thing about discipline: it feels like friction. It feels like you're slowing down to do readiness checks, to enforce acceptance criteria, to push back on stories that aren't ready.

But discipline is what makes you fast.

When stories enter ready, they complete on time. When sprints finish clean, velocity stabilizes. When commitments hold up, stakeholders trust you. When stakeholders trust you, you get more autonomy, more resources, more runway.

PACE doesn't just measure output. It measures discipline.

And discipline compounds.

---

Portfolio Scale

Run PACE across 10, 20, 100 teams. Now you have a portfolio-level view: which teams are predictable, which are degrading, which have chronic readiness debt.

Compare Team A — 8% slide rate — to Team B — 30% slide rate — on similar projects. What's different? Spread what works. Identify where coaching is needed before the team hits a wall.

That's organizational learning at portfolio scale. Most organizations have the data for this already sitting in their sprint tools. They just don't have the engine to surface it.

---

PACE and ARIA: Better Together

ARIA — the risk intelligence agent from Episode 10 — operates at the project level. Health scores, risk indicators, executive dashboards.

PACE operates at the team execution level. Sprint discipline, readiness, predictability.

Together, they answer the two questions every delivery leader needs answered: Is this project healthy? (ARIA) and Is this team predictable? (PACE).

PACE's health check looks forward at the current sprint — how many stories are committed, how many have entered unready, what the projected slide rate is if current trends hold. Leadership doesn't wait until sprint close to know there's a problem.

Early warning. Portfolio-wide.

---

Next Up: Gatekeeper

Episode 13 is the finale — Gatekeeper, the portfolio intelligence agent that decides which projects should even start.

Most organizations say yes to too many things. When everything is a priority, nothing is. Gatekeeper reality-checks the portfolio, surfaces impossible dates, shows where capacity doesn't exist, and forces the hard conversations before commitment — not after.

That one's going to challenge some deeply held organizational habits.

For more resources: PMThatWorks.com

— Rick A. Morris

  

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

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]