Estimating Salesforce Project Work

Part 101: Estimating Salesforce Project Work

If you’ve ever watched a Salesforce project go off the rails, there’s a good chance it started with a bad estimate. Not a bad developer, not a bad admin, not even bad requirements — a bad estimate. Someone pulled a number out of thin air during a sales call, leadership committed to it, and the delivery team spent the next eight months drowning.

Estimation is the single most underrated skill in the Salesforce ecosystem. It’s not glamorous. Nobody puts “Expert Estimator” on their LinkedIn headline. But the architects and tech leads who do it well are the ones whose projects actually ship. This post is about how to think about estimation correctly — not the theoretical PMI textbook version, but the messy, real-world version that accounts for humans, politics, and Salesforce-specific gotchas.

What is Project Work Estimation?

At its simplest, estimation is answering the question: how much time, money, and people does it take to deliver this thing?

But that’s deceptively simple. In practice, estimation means:

• Breaking down ambiguous business goals into concrete deliverables
• Identifying every role needed to produce those deliverables
• Accounting for ramp-up, knowledge transfer, and context switching
• Building in buffers for the things that will absolutely go wrong
• Communicating all of this in a way that non-technical stakeholders can understand and approve

A good estimate is not a promise. It’s a range with assumptions clearly stated. If someone asks you “how long will this take?” and you give a single number with no caveats, you’ve already failed. Every estimate should come with a list of assumptions, risks, and dependencies — because the moment one of those changes, the estimate changes too.

The Roles You Cannot Forget

Here’s where most Salesforce estimates go wrong immediately: they only account for developers. I’ve seen SOWs (Statements of Work) that budget for three developers and literally no one else. Then everyone acts surprised when the project has no test coverage, no documentation, no change management, and the users hate the final product.

A realistic Salesforce project needs all of these roles accounted for — even if one person wears multiple hats:

Project Manager (PM): Someone has to run standups, track progress, manage the timeline, escalate blockers, and communicate status to leadership. On smaller projects, the tech lead might absorb this. On anything over three months, you need a dedicated PM or you’re going to lose track of scope and burn through your timeline without noticing until it’s too late.

Business Analyst (BA): The BA translates business speak into technical requirements. Without one, your developers are guessing at what the stakeholders actually want. I’ve watched entire sprints get thrown away because a developer interpreted a vague requirement one way and the stakeholder meant something completely different. A good BA prevents that.

Salesforce Administrator: This is the person configuring the org — building page layouts, permission sets, flows, validation rules, reports, and dashboards. On many projects, people assume the developers will handle this. They won’t, or at least they shouldn’t. Admin work is a different skill set and it takes real time. If you have 50 page layouts to configure, that’s not a footnote — that’s weeks of work.

Developer(s): Apex, LWC, integrations, complex automations. Developers handle the things that can’t be clicked together. But here’s the thing — not all developers are equal, and I’ll get to that in a moment.

QA/Tester: Someone needs to write test scripts, execute them, file bugs, and re-test fixes. If you skip QA, your users become your testers, and they will not be kind about it. Even on small projects, budget at least 15-20% of total effort for testing.

Architect/Tech Lead: On any project with integrations, data migration, or multi-cloud complexity, you need someone making design decisions and reviewing work. This person doesn’t need to be full-time, but they need to be budgeted. Architecture reviews, design documents, and technical debt decisions take real hours.

Don’t forget: training resources, change management, data migration specialists, and potentially a release manager if you’re deploying across multiple orgs. Every one of these roles costs time even if you’re not hiring a dedicated person for them. If your estimate says “3 devs for 6 months,” you’re lying to yourself and your client.

Guarding Against Unrealistic Expectations

Here’s a scenario that plays out constantly: A sales team closes a deal by promising the customer they can have a full Salesforce implementation in 12 weeks. The delivery team inherits this timeline with zero input. Now you, the architect, have to figure out how to make it work — or more likely, how to communicate that it won’t.

Rule 1: Never estimate under pressure in a meeting. If someone puts you on the spot — “just give me a ballpark” — your answer should always be: “I need to review the requirements and I’ll have a range for you by [date].” A “ballpark” given in a meeting becomes a hard commitment in the recap email. Every single time.

Rule 2: Separate the estimate from the commitment. Your estimate is a technical assessment. The commitment is a business decision. Make sure leadership understands that when they cut your estimate by 30% to fit a budget, they are accepting risk — not discovering efficiency.

Rule 3: Pad for discovery. On every Salesforce project I’ve ever worked on, the requirements were incomplete at the start. Always budget 10-15% of total effort for “stuff we haven’t found yet.” If the client pushes back, remind them that the alternative is a change order later, which costs more and delays the timeline anyway.

Rule 4: Document your assumptions in writing. “We assumed data migration includes 5 objects with clean data” is the kind of assumption that saves you when the client shows up with 47 objects and a CSV full of duplicates. If it’s not written down, it doesn’t exist.

Estimate the OOTB Option, Not the Ideal End State

This is a hill I will die on. When estimating a Salesforce project, your first pass should always be: what is the cheapest, simplest out-of-the-box solution that meets the core requirements?

Not the best solution. Not the most elegant solution. The simplest one that works.

Why? Because your job as an architect during estimation is to establish a floor. You’re telling the client or leadership: “At minimum, this is what it costs to solve your problem on this platform.” From there, you can layer on enhancements, custom development, and polish — each with its own cost clearly attached.

If you estimate the dream state first, two things happen. First, the number is huge and scares stakeholders. Second, when they inevitably ask you to cut scope, you have no idea what to remove because you never mapped out the simple version. You end up cutting randomly, which creates a Frankenstein solution that’s neither simple nor elegant.

Start with standard objects, standard fields, out-of-the-box page layouts, and Flows. Then identify the gaps. “Standard Salesforce handles 70% of this. The remaining 30% requires custom development, and here’s what that costs.” That’s a conversation stakeholders can work with.

Estimate to the Median, Not to Yourself

If you’re a senior architect doing the estimation, do not estimate based on how fast you could build something. You are not building it. A mid-level developer is building it, and they’re going to take twice as long as you think.

This is one of the most common estimation failures in the industry. A senior dev says “I could build that integration in two days,” so they write down two days. Then the actual developer — who is perfectly competent but doesn’t have 10 years of institutional knowledge — takes a week. Multiply that across every task in the project and you’re suddenly months behind.

Estimate to the median talent level on your team. If you don’t know who’s on the team yet, estimate for a solid mid-level resource. Someone who knows Salesforce, can write decent Apex, and can figure things out — but isn’t going to intuitively know every governor limit or every best practice. Add time for code reviews, rework, and the learning curve that comes with every new org.

This isn’t about insulting your team. It’s about being honest. Even great developers have bad weeks, get pulled into other projects, or take PTO at the worst possible time.

Working with Broken and Scattered Requirements

In a perfect world, you receive a clean requirements document with user stories, acceptance criteria, and process diagrams. In reality, you get a 47-page Word document written by someone in marketing, a Confluence page that hasn’t been updated since 2019, three conflicting emails from different VPs, and a sticky note someone found on a conference room whiteboard.

This is normal. Your job during estimation is not to fix the requirements — it’s to identify the gaps and account for the effort to fill them.

Practical approach:

1. Inventory what you have. List every document, email, and artifact that contains requirements. Note which ones conflict.
2. Identify the gaps. What processes are mentioned but not detailed? What integrations are assumed but never specified? What data migration needs are hinted at but never scoped?
3. Budget for discovery workshops. For every major gap, plan 2-4 hours of workshops with stakeholders to nail down the actual requirements. This is real work that takes real time.
4. Flag the risks. If a key stakeholder hasn’t been interviewed, if a legacy system hasn’t been documented, if the data quality is unknown — these are risks that inflate the estimate. Call them out explicitly.

Don’t try to estimate what you don’t understand. If a requirement is too vague to estimate, say so. “We cannot estimate the integration with System X until we’ve completed a technical discovery session” is a perfectly valid line item in an estimate.

PROJECT: Estimation Exercise — Mid-Size Company CTA Migration

Let’s put this into practice. Here’s a realistic scenario.

The Scenario

NovaTech Industries is a mid-size manufacturing company with 300 employees. They currently use a legacy CRM (a customized on-premise system) and want to migrate to Salesforce. Their goals:

• Migrate their sales pipeline (Opportunities, Accounts, Contacts) to Sales Cloud
• Build a custom quoting process (CPQ-like, but they don’t want to pay for CPQ)
• Integrate Salesforce with their ERP system (SAP) for order fulfillment
• Migrate 5 years of historical data (~200K records across 8 objects)
• Train 80 sales reps and 15 managers
• Go live in 6 months

Step 1: Identify the Work Streams

Step 2: Estimate the Team

Here’s what a realistic team looks like for this scope and timeline:

Total: 10 people, ~55 person-months of effort.

Step 3: Validate Against the Timeline

Six months is tight for this scope. Here’s the honest breakdown:

• Months 1-2: Discovery, requirements finalization, architecture design, core CRM setup begins
• Months 2-3: Custom quoting development, integration development begins, data mapping
• Months 4-5: Integration testing, data migration dry runs, UAT begins, bug fixes
• Month 6: Final UAT, training, data cutover, go-live, hypercare

The SAP integration is the biggest risk. If NovaTech’s SAP instance is poorly documented or has non-standard customizations, the integration timeline could easily double. This is where your assumptions document matters: “Estimate assumes SAP has a documented REST API and a sandbox environment available by Month 2.”

Step 4: Present the Estimate as a Range

Don’t give one number. Give three:

• Optimistic (everything goes right): 48 person-months, $720K
• Most Likely: 55 person-months, $825K
• Pessimistic (SAP integration is complex, data is messy): 68 person-months, $1.02M

This lets leadership make an informed decision. If they only have budget for the optimistic scenario, they need to understand they’re gambling. If they want certainty, they budget for the pessimistic number.

Final Thoughts

Estimation isn’t about predicting the future — it’s about making uncertainty visible. The best estimates are the ones where everyone involved understands what they’re getting, what it costs, and what could go wrong.

As a Salesforce Architect, your credibility lives and dies by your estimates. Overestimate consistently and people stop trusting your numbers. Underestimate and your teams burn out delivering on impossible timelines. The goal is to be honest, thorough, and transparent — even when that means telling a client something they don’t want to hear.

Start with the simplest solution. Account for every role. Estimate for the team you’ll actually have, not the team you wish you had. Document your assumptions. And never, ever give a number in a meeting without thinking it through first.