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.
No comments:
Post a Comment