Salesforce Project Estimation: A Defensible Scoping Method with AI

“We received an estimate of 10 days. Does that seem reasonable?”

That question was posted to r/SalesforceDeveloper three months ago by someone trying to sanity-check a quote for a multi-object CSV import. The thread drew more than ten comments. The question itself is the finding: someone holding a ten-day number had no way to test it, because the number arrived without the scope that produced it.

That question exposes the real problem with Salesforce estimation. Nobody was disputing the estimator’s competence. The buyer simply had no way to interrogate the number, so the only available move was to ask strangers whether it felt high.

An estimate that cannot be interrogated cannot be defended. That is the difference this page is about.

An estimate earns trust by naming the range it cannot remove

Most Salesforce estimates arrive as a single figure. Forty days. Eighteen weeks. One hundred and sixty hours.

A single figure makes an implicit claim: that the estimator knows the answer. Every experienced delivery lead knows that claim is false at the point it is usually made, which is before the sharing model has been decided and before anyone has opened the client’s org.

Defensibility works the other way around. A defensible estimate states what is known, states what is assumed, and states how wide the number could still move. Counterintuitively, publishing the uncertainty makes the estimate harder to attack, because the buyer can no longer discover the uncertainty later and treat it as a surprise.

Two bodies of published research support that position, and neither appears in the Salesforce estimation content currently ranking.

Boehm’s cone puts the honest early range at four times in both directions

Barry Boehm published the underlying data in *Software Engineering Economics* in 1981. Its finding, now known as the cone of uncertainty, is that estimate accuracy is bounded by how much of the solution has been decided. Construx, which maintains the reference treatment of it, is careful about what that bound means: the cone describes the best case accuracy available to a skilled estimator at each point in a project. Doing worse than the cone is easy. Doing better is not on offer.

At initial concept, an estimate can be wrong by a factor of four in either direction. Honest ranges at that point run from 0.25 times to 4 times the eventual figure, which is a total spread of sixteen times. By the time a technical specification is signed, that range has narrowed to roughly 0.9 to 1.1 times.

Read that as a constraint on what you are allowed to promise. An estimator who gives a fixed number at the discovery call is not being confident, they are concealing a sixteen-fold spread. Construx names the failure directly, observing that organizations sabotage their own projects by committing too early, while still carrying a two to four times error.

Two consequences get missed. Narrowing the cone is not an estimating activity, because the only way to reduce variability in an estimate is to reduce variability in the project itself. That makes the request every estimator eventually hears, give it another week and sharpen the number, impossible to deliver. The narrowing is also front-loaded: most of it occurs within the first 20 to 30 percent of calendar time, which is the window where decisions, not analysis, buy accuracy.

Salesforce projects map onto the cone at recognizable moments.

Method, from here, is about moving down that table deliberately, and refusing to quote a tight number from a wide row. Configure against build is the decision that moves the range most, which is why a fit-gap analysis belongs before a firm proposal rather than after one.

IT cost overruns follow a power law, and Salesforce orgs supply the mechanism

The second finding is more uncomfortable and more useful.

Bent Flyvbjerg, Alexander Budzier and four co-authors analyzed 5,392 IT projects and published the result in the *Journal of Management Information Systems* in 2022. Their paper on IT cost overruns establishes that overruns do not distribute normally, which is the assumption most contingency planning quietly rests on. They follow a power law: many projects overrun slightly, and a fat tail overruns enormously.

Averages mislead as a result. If you contingency-plan against a typical overrun, you have planned for the wrong shape of risk, because the distribution has no meaningful typical case in its tail.

The study covers IT projects broadly rather than Salesforce specifically, so the figure is context and not a Salesforce statistic. What transfers directly is the mechanism the authors propose, and that mechanism is why this matters here. They attribute the fat tail to interdependencies among technological components, where a problem in one component triggers chain reactions through everything connected to it.

A Salesforce org is close to a pure example of that structure. One object carries validation rules, record-triggered flows, sharing rules, page layouts, report types and integration mappings at the same time. Tighten Account sharing and you have changed access to everything that inherits from it, which on standard objects means Contact, Opportunity and Case, and on custom objects means anything in a master-detail relationship. Reports built on those records shift with it, and so does every integration that assumed the old access. Three days was the estimate for the Account change. Its chain reaction was never estimated, because nothing in the scope document named it.

Estimation practice should respond to that mechanism directly. Estimate the component, then separately estimate the blast radius, and record which existing automations and integrations touch each object in scope. An unbudgeted chain reaction is the single most common route from a good estimate to the fat tail. The broader catalogue of how these projects come apart sits in the nine causes behind failed Salesforce programs.

A scoped workbook turns an opinion into lines a buyer can argue with

That r/SalesforceDeveloper poster could not challenge ten days because ten days was atomic. Defensibility comes from decomposition, and the artifact that holds the decomposition is a workbook rather than a document.

Workbooks differ from proposals in one respect that matters. Every number in it is traceable to a named scope item, and every scope item carries its assumptions in an adjacent column. When a buyer challenges the total, the conversation moves immediately to a line, and a line is arguable in a way a total never is.

Four columns carry most of the defensive weight.

Scope item, named at the level work actually happens. Not “Account configuration” but “Account record type for partner accounts, with page layout and two validation rules.” Vague line items are where estimates hide from scrutiny.

Assumption that makes the number true. “Assumes existing sharing model is unchanged.” “Assumes client supplies mapped data in the agreed template.” An assumption written before the work is a protection; the same sentence written after a slip is an excuse.

Dependency, naming what the item touches. This is where the power-law mechanism gets priced instead of ignored.

Confidence marker, tied to the cone row. An item estimated from a signed design carries different weight from one estimated from a discovery note, and the workbook should say which it is.

What a workbook does not need is more precision than the stage supports. Estimating in half-days when the cone row permits an order of magnitude is false accuracy, and buyers who have been through one implementation can smell it. T-shirt sizing exists for the wide rows, and converting a size into a level of effort belongs at the point the design is signed, not before.

Once scope is fixed this way, it transfers cleanly into the contract. The assumption column becomes the assumptions register, which is the section that decides whether a change request is payable, covered in the Salesforce SOW template.

Reference-class forecasting corrects what bottom-up estimation cannot see

Bottom-up estimation has a structural blind spot. It sums the work you thought of. It cannot include the work you did not think of, and the omissions are not random: they cluster in the integration, migration and access-model work that nobody remembers at the discovery stage.

Flyvbjerg’s prescribed correction is reference-class forecasting. Instead of building up from tasks, you locate the current project in a class of comparable completed projects and start from what that class actually delivered.

For a Salesforce practice this is more achievable than it sounds, because the reference class is your own delivery history. Three questions extract it.

How many days did your last four projects of this shape actually consume, measured from timesheets rather than from memory? What percentage did each exceed its original estimate by? Which scope areas produced the overrun in each case?

A firm that can answer those three questions has a reference class. A firm that cannot is estimating from optimism, and the research says optimism loses.

The strongest form of estimate combines both views. Build bottom-up, then test the total against your reference class, and when the two disagree by a wide margin, investigate before splitting the difference. Bottom-up tells you what the work contains. The reference class tells you what you habitually forget.

Three audiences challenge an estimate, and each needs different evidence

An estimate gets tested by three people who want three unrelated things. Sending the same document to all three is why estimation conversations stall.

Buyers want comparability, which the reference class supplies. Delivery leads want feasibility, which the workbook supplies at role level. Finance wants bounded downside, which the cone row and the power-law shape supply honestly. One artifact can serve all three if it carries ranges and assumptions, which single-figure estimates cannot do.

Note what is absent from that table. None of the three challengers is asking for a lower number. They are asking to understand the number. Estimators who hear every challenge as price pressure discount work that was correctly priced.

GetGenerative.ai agents change what the estimator starts from

Everything above assumes the estimator has a decomposed scope to work from. In practice, estimates get produced from a discovery call recording, a half-filled requirements sheet and whatever the architect remembers about the client’s org. The method fails at the input, not at the arithmetic.

That input gap is what GetGenerative.ai addresses. Six agents cover the delivery lifecycle, and three of them change the estimation starting position directly.

The Discovery Agent converts workshop sessions into structured scope, schedule and a resourcing plan, which is the decomposition the workbook needs rather than a transcript nobody rereads. The Metadata Agent reads the client’s org, so dependencies get named from the configuration actually present instead of from what the sales call implied. That matters more than any other single input, because org-reality dependency mapping is precisely what the power-law mechanism punishes you for skipping. The Design Agent turns scope into solution outlines and stories, which moves the estimate down the cone table from a discovery row to a design row before anyone has signed anything.

These economics favor estimation specifically. Estimation is presales work, so it is unbilled, and unbilled work gets compressed whenever delivery is busy. A practice that wants defensible estimates has to make producing them cheap, or the method gets abandoned on exactly the proposals that most needed it. Teams can review what the platform costs per month.

Agent scope breaks the assumption that effort equals cost

Estimating agent work exposes an assumption buried in every traditional estimate: that the cost of a feature is the effort to build it.

For configuration, that holds. Build it once, pay once, run it indefinitely. Agents do not behave that way. An Agentforce deployment carries build effort and then a consumption cost that scales with how often the agent runs, so a correct effort estimate can still yield a loss-making engagement.

Two consequences follow for anyone estimating agent scope.

Estimate build and run separately, and state the usage assumption in the workbook as explicitly as any technical assumption. “Assumes 500 agent conversations per month” is a scope line. Without it, the client’s successful adoption becomes your margin problem. The cost mechanics themselves are set out in how agent usage is metered and billed.

Treat the run-cost model as unsettled. A metering category named Headless Platform Interactions is on its way, covering agent traffic that reaches Salesforce over MCP or the API, and its per-interaction multiplier has not been published. Thirty days of warning are promised before that meter switches on. Only live production orgs are in scope for it, which keeps sandbox and scratch work free and means the cost appears after go-live rather than during the build you estimated. Nobody can price against an unpublished multiplier, so a workbook written today needs an assumption and a repricing trigger where the figure would otherwise sit.

The market is still finding its level here, sometimes visibly. A thread posted to r/salesforce on 23 September 2026, titled around a client offering 800 dollars for three Agentforce agents plus a solution, ran to thirty-seven posts within days. Buyers have no reference class for agent work yet. Neither do most sellers, which is the condition under which ranges and stated assumptions matter most.

Salesforce keeps its estimation templates behind the partner login

Searching for Salesforce estimation guidance produces a revealing set of results, and the shape of that result set explains why good estimation practice stays rare.

Page one is dominated by tools, not method. There are AppExchange estimator listings, vendor calculators, a PSA product priced per user per month, and a Trailhead community post about an estimation tool that dates to 2016. Salesforce does publish an estimation tools and templates trailmix, and its listing is marked for partners only.

Two things follow from that pattern. Estimation is treated as a calculator problem by most of the market, when the hard part is deciding what goes into the calculator. And Salesforce’s own accumulated guidance is gated, so a consultancy outside the partner portal is left assembling a method from first principles.

Google’s own uncertainty shows in the results. Questions it surfaces alongside this query include whether Salesforce is a CRM or a CMS and whether SAP is bigger than Salesforce, which is what a search engine produces when no page has established itself as the canonical answer.

A buyer’s pushback tests the assumption log, not the total

“That is too high” is the most common response to a Salesforce estimate, and it is usually not a statement about the price.

It is a statement about the gap between the number and the buyer’s mental model. Buyers arrive with an internal figure, formed from a competitor’s proposal, a board conversation or a half-remembered article, and your estimate violates it. Discounting the total concedes a point nobody made.

A better move holds the number and opens the workbook. Which lines does the buyer believe are overstated? That question is answerable only because the workbook exists, and it almost always relocates the disagreement from price to scope, where it belongs. Frequently the buyer discovers an assumption they can remove, which legitimately reduces the estimate without cutting rate or hope.

Where the gap survives that conversation, the honest options are scope reduction, phasing, or a different risk allocation. Shifting risk is the lever most often forgotten, and it is a pricing decision, not an estimating one, examined in how to price Salesforce projects. What the estimate should never do is absorb the gap silently, because an estimate quietly cut to win a deal is the fat tail arriving by invitation. If the duration rather than the fee is the sticking point, the levers that actually compress a calendar are covered in the Salesforce implementation timeline.

Six estimation questions carry most of the confusion

How accurate can a Salesforce estimate be before discovery?

Not accurate enough to commit to. Boehm’s cone of uncertainty puts estimates at the initial concept stage within a factor of four in either direction, a sixteen-fold total spread. Before discovery you can defend an order of magnitude and a range, and nothing tighter.

What makes a Salesforce estimate defensible?

Decomposition into named scope items, an explicit assumption against each, a dependency list recording what each item touches, and a stated range tied to how much of the solution has actually been decided. A single figure with no visible basis cannot be defended because it cannot be interrogated.

Why do Salesforce projects overrun so badly when they overrun?

Because IT cost overruns follow a power-law distribution rather than a normal one, as established across 5,392 projects by Flyvbjerg and co-authors. The proposed mechanism is interdependency between components, where one change triggers chain reactions. Salesforce orgs are densely interdependent, so a change to a single object can propagate through automations, sharing, reports and integrations that the estimate never named.

Should Salesforce estimates use story points or days?

Use whichever unit the receiving audience can act on, and never mix them in one artifact. Story points work for internal capacity planning within a stable team. Buyers, finance and procurement need days or currency, because a point has no meaning outside the team that calibrated it.

How do you estimate an Agentforce project?

Estimate build effort and run consumption as two separate lines, because agent cost scales with usage after the build is finished. State the assumed interaction volume in the workbook as a scope item, and include a repricing trigger, because a new metering category for agent traffic arriving over MCP or the API is coming and its multiplier is unpublished.

What is reference-class forecasting in estimation?

It is the practice of estimating from the outcomes of comparable completed projects instead of summing tasks. For a Salesforce team the reference class is its own timesheet history: what the last several projects of similar shape actually consumed, how far each exceeded its estimate, and which scope areas caused it. It catches the omissions that bottom-up estimation cannot see.