Salesforce Project Estimation: The Honest Guide

Why Every Salesforce Estimate Is Wrong

The estimate is wrong before it leaves the room. This is not a reflection on the people who produced it — it is a structural property of how Salesforce estimates are created, what information is available when they are created, and the commercial dynamics that shape them.

Understanding why estimates fail is not an academic exercise. It changes how you present them, how you protect them, and how you have the early conversations with clients and sponsors that are the only reliable way to avoid the cost overruns and schedule delays that define most Salesforce programmes.

The Optimism Bias in Consulting Estimates

Consulting firms produce estimates in a competitive context. The estimate is part of a proposal. The proposal is evaluated partly on price. There is a structural incentive to produce an estimate that is compelling — which in practice means an estimate that is low enough to win the work. This incentive exists not because consulting firms are dishonest, but because the people producing the estimate are often genuinely optimistic. They are estimating against a requirements document that describes what the client wants, not what the client actually needs. They are drawing on experience from previous projects where the happy path was followed — not from the projects where the surprises happened. And they are producing the estimate in a period of two to four weeks, before any discovery has been done, when the unknowns genuinely cannot be quantified.

The result is not deliberate misrepresentation. It is optimism bias applied systematically by people who are incentivised to win work and who don't yet know what they don't know.

Discovery Estimates vs Build Estimates vs Production Estimates

There are actually three estimates in any Salesforce programme, and confusing them is the source of enormous misalignment.

The discovery estimate is produced before any discovery has been done. It is based on a high-level requirements document, previous project analogies, and assumption-heavy order-of-magnitude thinking. It is the number in the proposal. It can be right to within 50% in either direction and still be considered a reasonable estimate at that stage — because the information needed to be more precise does not yet exist.

The build estimate is produced after discovery, when user stories have been written, technical architecture has been agreed, and the integration landscape is understood. This estimate can realistically be accurate to within 20%. This is the estimate that should be used for project budgeting and contract scope.

The production estimate — the one that reflects what the project actually cost — is known only at the end. On well-managed programmes, it is within 10-15% of the build estimate. On poorly managed programmes, it can be twice the discovery estimate.

The problem occurs when clients treat the discovery estimate as if it were the production estimate. They budget for it, get board approval for it, and hold the delivery team accountable to it. When the build estimate comes in 40% higher after a proper discovery, it is not because the delivery team has inflated their numbers. It is because the discovery revealed complexity that was genuinely unknown when the first number was produced. Managing this expectation proactively — before discovery begins — is one of the most important things a delivery manager can do.

The Things That Always Take Longer

Three workstreams consistently take longer than estimated, on every project, regardless of how experienced the team is.

Data migration always takes longer because the source system is always more complex than the data dictionary suggests, the data quality is always worse than the business believes, and the volume is almost always higher than the initial record count indicates. This is covered in depth in section four.

Integration always takes longer because the downstream systems are documented at a higher level of abstraction than the actual API reality, because API rate limits and authentication edge cases are discovered during build rather than design, and because integration testing requires the cooperation of teams who have their own delivery pressures and don't treat your integration as their priority.

User acceptance testing always takes longer because the business users who conduct UAT are doing it alongside their day jobs, because UAT reveals requirements gaps that were not visible during design, and because the defect resolution cycle in UAT has a non-linear relationship with the number of defects found.

The Things That Always Get Underestimated

Change management, training, and hypercare are estimated as a percentage of the technical build cost in most proposals. This approach consistently underestimates the effort required. A complex Salesforce implementation that touches five hundred users across ten business functions requires a change management and training programme that is a significant delivery workstream in its own right — not a bolt-on activity that one person can manage alongside the technical delivery. The typical underestimate is 50% of what is actually needed. The typical consequence is a technically successful go-live followed by a adoption failure that damages the programme's perceived success for twelve months.

The Anatomy of a Salesforce Estimate

A complete Salesforce programme estimate has eight components. Most estimates that I have reviewed are missing at least two of them — usually data migration and change management, which are, not coincidentally, the two workstreams most likely to overrun.

The following breakdown is based on mid-sized Salesforce programmes: typically twelve to twenty months in duration, one to three clouds, fifty to three hundred users, three to eight integrations, and a data migration from one or two legacy systems. The percentages represent realistic ranges from programmes that tracked actuals against estimates.

Two things are worth noting about this breakdown. First, the build phase — the thing most people mean when they say "the project" — is typically only 25–35% of the total budget. Second, the three consistently underestimated phases (data migration, training and change management, and hypercare) together represent 23–43% of the total. If your estimate is missing them or treating them as minor line items, your estimate is wrong by definition.

Why Sprints Are Not a Reliable Estimating Unit

Agile delivery has encouraged the habit of estimating in sprints. "We think this will take about twelve sprints" is a common form of estimate on Salesforce programmes. The problem is that sprint velocity is not stable across a programme. Sprint velocity in the first quarter of a build — when the team is establishing working patterns, discovering integration complexity, and iterating on design decisions — is consistently lower than sprint velocity in the middle of the build. And sprint velocity in the final quarter drops again, as testing, rework, and scope management consume capacity that was nominally allocated to build. An estimate expressed in sprints without a velocity assumption and a velocity trend adjustment is not an estimate — it is a guess with a structured appearance.

The Configuration vs Customisation Trap

The single most common source of Salesforce estimate overruns — beyond data migration, which is its own category — is the misclassification of work as "configuration" when it is actually "customisation." The financial and schedule implications of getting this wrong are significant.

Why "It's Just Configuration" Estimates Are Dangerous

Configuration — point-and-click setup of standard Salesforce features — is fast. An experienced Salesforce administrator can configure a standard Sales Cloud implementation, including custom fields, page layouts, workflows, and basic reports, in a matter of weeks. When an estimate is built on the assumption that the majority of the build is configuration, the daily rate and effort assumptions that underpin it are administrator-level, not developer-level.

The problem occurs when those configuration assumptions encounter the reality of the client's requirements. Business processes that involve complex conditional logic, dynamic screen behaviour, real-time integration responses, or non-standard user interface requirements cannot be delivered through point-and-click configuration. They require custom development — Lightning Web Components, Apex classes, platform events, or custom APIs. Developer effort is typically two to three times slower than configuration effort for equivalent functional output, and developer day rates are 30–60% higher. An estimate that assumed configuration and encounters customisation is wrong in both effort and cost.

Lightning Web Components vs Point-and-Click

The boundary between standard Salesforce UI and custom Lightning Web Component development is not always visible in a requirements document. A requirement that says "the user should be able to see a summary of related records in a dynamic panel on the account page" sounds like a configuration task. It may be achievable with standard Related Lists — or it may require a custom LWC that queries multiple objects, handles conditional rendering, and integrates with an external API for real-time data. The difference in effort between these two approaches is substantial: the first takes hours, the second takes days or weeks.

The right approach in estimation is to classify every UI requirement explicitly as standard, declarative (Flow, standard components), or custom development — and to validate that classification against a technical architect before the estimate is finalised. Requirements that remain classified as "TBD" or "configuration" without technical validation are estimation risks, not estimates.

Managed Packages: The Estimate Multiplier Nobody Mentions

Many Salesforce programmes involve managed packages — third-party applications installed from the AppExchange. Field Service Lightning, nCino, Veeva, Vlocity (now Salesforce Industries), and Copado are common examples. The presence of a managed package in the solution architecture is an estimate multiplier that is almost never adequately accounted for.

Managed packages introduce their own data models, their own configuration paradigms, their own governor limit implications, and their own release cycles. Configuration work that would take a day in standard Salesforce may take a week in a managed package whose documentation is incomplete and whose support response time is measured in business days. Integration work that involves managed package objects is subject to the package vendor's API design choices, which may be significantly less straightforward than standard Salesforce APIs. And managed package bugs — of which there are always some — cannot be fixed by the delivery team. They require a support case with the vendor, which has its own timeline entirely outside the delivery team's control.

Integration Complexity: Where the Real Work Hides

Integration estimates are among the most variable in Salesforce programmes. A straightforward REST API integration with a modern system that has well-documented endpoints, reasonable rate limits, and responsive technical support from the downstream team can be completed in one to two weeks. A bidirectional integration with a legacy ERP system using SOAP APIs, requiring custom transformation logic, with a downstream team that has limited availability and a change control process that takes four weeks, can consume two to three months.

The factors that determine integration complexity — and therefore integration effort — are not always visible in the requirements document. They are discovered through direct conversation with the teams who own the downstream systems: what is the API documentation quality, what are the rate limits, what is the authentication model, what is the availability of a sandbox environment, and who is the named technical contact. An integration estimate produced without these answers is an assumption, not an estimate.

Data Migration: The Budget Killer

Data migration is the workstream most likely to blow your budget. It is also the workstream most likely to be underestimated at proposal stage, underresourced during the project, and underplanned until it becomes a crisis. Understanding why it consistently overruns is essential to managing it.

Why Data Migration Always Takes 2x Longer Than Estimated

The root cause is that data migration effort is not primarily a technical challenge — it is a data quality challenge. And data quality is almost always worse than the business believes it to be. The business's assessment of their own data is typically based on how the data looks to users in the legacy system interface, not on what is actually in the database. Legacy systems often have been modified over years to hide data quality problems from users — screens that filter out null values, reports that exclude incomplete records, processes that route around bad data. When you extract the raw data and look at what is actually there, you find things that nobody in the business knew existed.

The second cause is that initial volume estimates are usually based on "active" record counts. In practice, data migration requires decisions about historical data, archived data, soft-deleted records, and data that was never properly closed out. A legacy system with 500,000 "active" accounts may have 2.3 million total account records when historical data is included. The business decision about what to migrate, what to archive, and what to discard takes time — and it is never as simple as it sounds.

Source System Complexity

Legacy systems were designed to serve the needs of their era, not to export cleanly to a modern CRM. Common source system complications include: multiple instances of the same data (the same customer exists in three regional instances of the legacy system), non-standard field encodings (status codes that mean different things in different business units), relationships between records that are not formally enforced at the database level (parent records that reference child records that no longer exist), and data that exists in attached files, notes, or email threads rather than structured fields.

Each of these complications requires a decision about how it will be handled in Salesforce — and each decision requires input from the business. The volume of decisions required in a complex data migration is consistently underestimated. A typical enterprise data migration requires hundreds of explicit business decisions about data handling — decisions that cannot be made by the technical team alone and that take time to work through with stakeholders who have limited availability.

Data Quality Remediation

Once the source data has been extracted and profiled, a data quality remediation exercise is almost always required before migration can proceed. This typically includes: deduplication of customer and contact records, standardisation of address and phone number formats, backfilling of mandatory fields that are blank in the legacy system, resolution of orphaned relationships, and correction of encoding errors. This work is underestimated in virtually every programme I have reviewed, for a simple reason: until the data has been profiled, the scale of the problem is unknown. Estimating data quality remediation without a data profiling exercise is like estimating a building renovation without a structural survey.

The Only Safe Approach

Estimate data migration as a separate workstream with its own budget and its own ring-fenced contingency. Do not fold it into the build estimate or treat it as a percentage of the technical delivery cost. The two have different cost drivers, different risk profiles, and different dependency structures.

The minimum estimate methodology for data migration is: data profiling exercise (two to four weeks, depending on source system complexity), data quality remediation estimate based on profiling findings, mapping specification effort (based on object and field count, not record count), migration tool build and testing, and a minimum of three full dress rehearsals timed against the go-live window. Each of these components should be estimated independently and summed — not estimated as a total and then allocated backwards.

How to Build an Estimate That Survives Scrutiny

A robust Salesforce project estimate has five components beyond the phase-by-phase effort numbers: a methodology, an assumptions log, a contingency structure, a change control framework, and a communication approach. Most estimates have the numbers. Most are missing the other four.

Bottom-Up vs Top-Down Estimation

Bottom-up estimation means estimating each user story, integration, and data migration component individually and summing the results. It is the most accurate approach, but it requires detailed requirements — which means it can only be done after discovery. Bottom-up estimates are appropriate for the build estimate and for formal contract commitments.

Top-down estimation means estimating at the phase or workstream level based on project analogies and experience benchmarks. It is faster, requires less information, and is appropriate for the discovery estimate and for initial budget planning. The risk is that top-down estimates anchor expectations before the bottom-up analysis has been done, creating a situation where the discovery estimate becomes the budget target and the build estimate is treated as an overrun.

The right approach is to use top-down at proposal stage with explicit, visible caveats about the information that is not yet available, and to commit to a bottom-up re-estimate after discovery before any formal budget or contract commitment is made.

Story Points vs Hours vs Days

The delivery manager's perspective on estimation units is different from the developer's perspective. Story points are useful for sprint planning and velocity tracking. They are not useful for budget conversations with clients and sponsors. When you present an estimate to a CFO, "this programme will take approximately 1,400 story points" means nothing. When you say "this programme will take approximately 18 months and cost £X," that is a number they can work with.

The translation from story points to hours to cost requires: a velocity assumption (stories per sprint), a sprint duration, and a team composition (number and seniority of resources, and their day rates). Each of these introduces variance. When presenting estimates to stakeholders, be explicit about what assumptions you are making and what would cause those assumptions to change.

Contingency: How Much, Where, and How to Defend It

Contingency is the most contentious element of any estimate. Clients perceive it as padding. Delivery teams know it is essential. The way to make contingency defensible is to make it specific rather than generic.

A "10% contingency" appended to the bottom of an estimate is not defensible — it looks like padding because it is padding. A contingency that is broken down by risk — "5% data migration contingency against the risk that data quality profiling reveals remediation requirements beyond the current scope; 3% integration contingency against the risk that downstream API documentation does not reflect current system behaviour; 2% scope contingency against the risk of requirements elaboration during design" — is a risk-informed reserve, not padding. It can be defended because each component can be traced to a specific risk that the client will recognise.

A realistic contingency for a mid-sized Salesforce programme with reasonable discovery is 15–20% of the total build and testing cost, declining to 5–10% by the start of the build phase as risks are resolved. Any estimate with less than 10% contingency on a first-pass discovery estimate is dangerously exposed.

The Assumptions Log

The assumptions log is the document that protects both the delivery team and the client. It is a written record of every assumption that the estimate is built on. It serves as the baseline against which scope change can be identified: when the project reality differs from an assumption in the log, that difference is a change control item. Without an assumptions log, every scope discussion is a negotiation based on memory and interpretation. With one, it is a factual question: does the current situation match the assumption? If not, what is the impact?

The assumptions log should cover: the scope of included and excluded functionality, integration assumption (including system, protocol, and team availability), data migration assumption (source system, object and field scope, data quality expectation), team composition and availability, client responsibilities (who provides access, who makes decisions, who does UAT), and environmental assumptions (sandbox availability, release windows).

Change Control

Without change control, estimates are meaningless. This is not an exaggeration. A project that begins with a well-structured estimate and no change control process will almost inevitably end with a significant cost overrun, because scope additions — even small, individually reasonable ones — accumulate. The cumulative effect of fifty "small" scope additions, each of which takes two days to deliver, is one hundred days of unplanned effort. At a blended day rate of £800, that is £80,000 of cost that was not in the original estimate.

Change control does not mean refusing to change scope. It means making scope additions visible, estimating them explicitly, and obtaining approval before the work begins. A delivery manager who allows scope additions to be absorbed without change control is not being flexible — they are consuming their contingency and then their margin without the client's awareness that this is happening.

Defending the Estimate to Stakeholders

Building a rigorous estimate is one skill. Presenting it under commercial pressure and defending it against challenge is a different skill — and it is the one that determines whether the rigour you applied in production translates into a project that is set up to succeed.

The Commercial Pressure to Compress Estimates

The pressure to compress estimates comes from two directions. From the client side, it comes from budget constraints, internal comparisons with previous projects, and the natural tendency to negotiate any quoted price. From the consulting firm side, it comes from the desire to win the work, the concern that a high estimate will lose the bid, and sometimes from senior stakeholders who override the delivery team's estimate based on commercial appetite.

The most important thing to understand about this pressure is that accepting it has asymmetric consequences. If you accept a compressed estimate and the project delivers on time and budget, the commercial team looks smart. If you accept a compressed estimate and the project overruns — which is the more likely outcome — the delivery team owns the problem. The people who pushed for the compression are rarely held accountable for the consequences. This asymmetry means that the delivery manager has a professional obligation to maintain the integrity of the estimate, even under pressure.

Presenting a Range Rather Than a Point Estimate

A single number is not an estimate — it is a target. A range is an estimate. For a discovery estimate, the range should be explicit: "Based on what we know now, this programme is likely to cost between £X and £Y, with the range reflecting the following unresolved uncertainties." The upper bound should represent what the project would cost if the key risks materialise. The lower bound should represent the cost if conditions are favourable.

Clients who push back on ranges and demand a single number are asking you to remove the uncertainty from the estimate without providing the information that would reduce it. The right response is to explain what would be required to narrow the range — typically, a properly scoped discovery phase — and to be clear that providing a single number before that discovery is done would not be an accurate estimate, regardless of what that number is.

When to Walk Away

There are briefs where the commercial terms make delivery success impossible. A fixed-price contract at a price that does not cover the realistic cost of delivery is not a challenging project — it is a loss-making contract that will damage the client relationship, the delivery team's wellbeing, and the firm's reputation. The signals that a brief is commercially impossible include: the client's budget is fixed at a level below the bottom of your realistic range; the client is not willing to fund a discovery phase before committing to a fixed-price build; or the timeline is fixed at a duration that is physically incompatible with the scope. In these situations, the professional response is to describe clearly what can be delivered within the constraints, and to be honest that the full scope cannot be delivered at the quoted price and timeline. Firms that sign commercially impossible briefs and then manage the consequences have a survival strategy, not a delivery strategy.

The Post-Project Estimate Review

Most firms produce estimates at the start of projects and never formally compare them to actuals at the end. This is one of the most significant missed learning opportunities in professional services delivery. The data that a post-project review generates is the foundation of accurate future estimates — and it is the only way to move from optimism-based estimation to evidence-based estimation.

Tracking Actuals vs Estimates Per Phase

The comparison should be done at phase level, not just at total project level. A project that came in on total budget but ran 40% over in data migration and 30% under in change management has not performed as estimated — it has had two significant misses that cancelled each other out by accident. Phase-level tracking reveals where your estimation methodology is systematically wrong.

The data to capture: estimated effort per phase, actual effort per phase, variance, and the primary cause of the variance. The cause classification should be at least three categories: scope change (the brief changed from the estimate), estimation error (the original scope was estimated incorrectly), and execution issue (the scope was correctly estimated but executed less efficiently than planned). Most overruns contain elements of all three — but separating them is essential for improving future estimates.

What the Data Tells You After Three Projects

After three projects with tracked actuals, patterns become visible that are invisible in a single project's data. You will find that your data migration estimates are systematically 70% of actual cost. You will find that integration effort for legacy SOAP systems consistently runs 150% of estimate. You will find that your UAT estimates assume a defect density that is consistently half of what you actually encounter. Each of these findings is a calibration point for future estimates.

The value of this data compounds over time. A firm that has tracked actuals across twenty projects has a significantly better basis for estimation than a firm that estimates from first principles each time. It can provide ranges with genuine statistical confidence, not just intuition. It can show clients the variance distribution from historical projects, which turns the contingency conversation from a negotiation into a data presentation.

Building Your Own Benchmark Estimates

Industry benchmark estimates — "a standard Sales Cloud implementation takes X weeks" — are not reliable for your team. They are averages across all firms, all team compositions, all client environments. Your team's velocity at a given scope and complexity is specific to your team's experience, tooling, and working practices. The only estimates that are genuinely predictive for your team are estimates calibrated against your team's own historical performance.

The investment required is not large: a consistent time-tracking discipline across projects, a phase taxonomy that is consistent across projects, and a quarterly review of actuals vs estimates. The return on that investment — in the form of bids that win on credibility rather than price, projects that deliver on their estimates, and client relationships that survive the delivery phase — is substantial.

The Estimate Conversation You Should Have at the Start of Every Project

At the start of every project, before any work begins, have an explicit conversation with the executive sponsor about the estimate's basis, its assumptions, and its limitations. Cover three things: what information the estimate was based on, what has changed since the estimate was produced, and what the process will be if scope or assumptions change during delivery. This conversation takes thirty minutes. The alternative — discovering mid-project that the sponsor thought the estimate was fixed-price when it was time-and-materials, or that they thought data migration was included when it was excluded — can consume months of relationship repair.