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