← Back to blog

The Estimate Should Be Right, Not Probably Right

What actually makes a number defensible

A number of the CPQ and estimating tools built for consulting and implementation firms are adding the same feature right now: an AI-powered estimate assistant. The pitch is usually some version of "tell us about the deal and we will tell you the hours." It sounds like it should make estimates better. It is worth asking what it is actually built on.

What the AI assistant is actually estimating from

It is not estimating from your delivery history, because on day one it does not have any. It is estimating from an aggregate: patterns pooled across whatever customers the vendor already has, blended with benchmark figures that other firms typed into a setup wizard, and some amount of marketing copy about how "data-driven" the model is. Some of that aggregate is real delivered work. Some of it is one firm's optimistic self-report. The tool cannot tell you which parts of its answer came from which, and neither can you.

That matters because of what the number is for. It becomes the staffing plan, the payment schedule, the margin you are managing to for the next six months, the thing you put in front of a client and are expected to stand behind. "The model said so" is not a defense of that number. It is a restatement of the same problem one layer removed.

The uncomfortable part: hand estimates have the identical gap

This is where it is easy to let a vendor comparison turn into a false contrast: AI estimating bad, careful human estimating good. It is not that clean. Ask most senior estimators to defend a number by hand and, past a certain point, the honest answer is "this is roughly what I have seen before on deals like this." That is real expertise. It is also vague, it lives in one person's head, and a client, or an auditor, or the delivery team six months later, cannot inspect it. An AI assistant trained on someone else's aggregate and a veteran's gut feel have the same failure mode: neither one can show its work.

So the actual question is not AI versus no AI. It is: what would make a number defensible at all, for either one?

What a defensible number requires

A number is defensible when you can point to where every hour in it came from, and the answer is your own delivered work, not a blend of other firms' inputs and not "trust me, I've done this before." That requires capturing what your own people know at a granular level, role by role, scope item by scope item, instead of a blanket t-shirt size for "integration" or "testing."

That is the problem JungleOS Scope's estimation engine is built to solve, and the mechanism behind it is plain, not a black box. Hours start from quantity times a unit-hour rate for every scope item a firm selects, and that unit rate is shaped by three things the firm configures once: where the requirement is coming from, how demanding the expected response is, and the skill level doing the work. None of that is a lifecycle curve or a bundle of activity multipliers borrowed from somewhere else. It is the firm's own rate logic, written down once and applied the same way on every deal, instead of kept in the head of whoever has been doing this longest.

Deterministic, and able to be revisited

Running that rollup is plain math, not a model guessing at the number. Same configuration in, same hours out, every run, which is what keeps the captured knowledge usable once it is written down. If the number could drift between two runs of the same inputs, writing the knowledge down would not have bought you anything.

A scenario pins its configuration when you create it, so the numbers you are reviewing do not quietly shift under you while you work through it. A draft that has not been locked down yet can still fall back to whatever the live configuration says at that moment, which is worth knowing if you are comparing two estimates built weeks apart against a rate card that changed in between.

Capturing what people know once is not the end state either. The configuration a firm starts with is a snapshot of what it knew on day one, and it will be wrong in places: too high here, too thin there, missing a scope item nobody thought to model. When a project wraps and the testing phase ran heavier than the plan said, you do not edit history to make the old number look right. You open the configuration itself and adjust the unit-hour rate or skill mix for that scope item based on what the actuals showed, and every estimate drawn from that configuration afterward starts from the corrected number instead of the one that missed.

That only works if the knowledge lives somewhere structured enough to revisit. A number memorized by a senior architect does not get refined. It gets reused until that person leaves, and then it gets re-derived from scratch by whoever is next. A configuration that captures hours at the role and scope-item level, that an estimator can open, fork, and edit as the firm's ways of working evolve, is the thing that actually compounds.

The honest tradeoff

None of this makes an estimate right on day one. No estimating method gets to claim that, by hand, by model, or by configuration. What it changes is what you can say when someone pushes back on a number. "This is what I've seen before" is not an answer anyone can check. "Here is the configuration this came from, here is who touches it, and here is what we are changing for the next one" is a different kind of answer, and it is the only kind that gets better over time instead of staying exactly as vague as it was the first time you said it.

If your estimates still defend themselves with "this is what I've seen before," see how Scope's estimation engine works.

Jeremy Amos, Founder, JungleOS