How to Scope a Salesforce Project So It Ships on Time

A Salesforce project ships on time when the scope prices the decisions the project needs, not the features it will build. Most fixed-scope projects slip because discovery produced a feature list, and a feature list is silent about who has to decide what, and by when. The fix is an outcome, a decision register, and a written list of non-goals.

Why do fixed-scope Salesforce projects slip?

Not because the build was underestimated. Build estimates are usually close. The calendar breaks somewhere else.

The numbers are unkind. In its 2025 CRM failure research, Johnny Grow found that 55% of CRM deployments did not achieve their planned objectives, roughly 30% met their planned timeline, and only 25% hit objectives, timeline and budget together. Seven in ten overran the timeline by 30% or more. Those overruns are rarely engineering overruns.

Here is the actual mechanism. A scope line says "build an approval process for discounts over 15%". The build is three days. The unanswered question underneath it is who approves, at what threshold, in which currency, what happens when that person is on leave, and whether Finance or Sales owns the exception. That question needs four people in a room who are hard to get in a room. It does not go faster if you add developers. The project waits, and the wait lands on the delivery date.

What does it mean to price decisions instead of features?

A feature is work. A decision is a dependency on a human being. Scoping that only counts the work produces an estimate that is right about the build and wrong about the calendar.

Your scope was priced as features if:

• Every line starts with build, configure or migrate.
• No line names a person who has to decide something.
• Integration lines do not say which system is the source of truth for each object.
• Data migration is one line.
• There is no non-goals section.

Each of those is a place where an unmade decision is hiding behind an estimated task.

How do you scope a Salesforce project so it ships on time?

1. Write one outcome sentence, with a number and a date. Not "improve service efficiency" but "cut weekly manual case triage from X to Y by the end of Q2". If nobody will commit to a number, you do not have a project yet, you have an interest.
2. Build a decision register before a task list. Every open question that blocks a build, with a named owner and a date it must be answered. This is the document that predicts your go-live, not the Gantt chart.
3. Split known from unknown. Work you have done before gets an estimate. Work you have not gets a timebox and an explicit exit condition. Never average the two into one number.
4. Write the non-goals down and get them read aloud. See below.
5. Slice to a first release a real user group uses in production. One team, one process, live. A pilot that nobody depends on teaches you nothing about the decisions you got wrong.
6. Fix the cadence, not the scope. Two-week sprints with working software at the end of each is what lets you trade scope without renegotiating the contract. That is how we run engagements at Tekunda, and it is why a fixed date survives a changed requirement.

What belongs in a non-goals list?

A non-goal is something a reasonable person would assume is included, written down as excluded. It is the cheapest artefact in the project and the one most often skipped.

• Things stakeholders asked for that are not in this release, named, not summarised.
• Silent assumptions: historical data beyond a stated cutoff, offline mobile, a second language, a second country's tax rules.
• Processes that stay outside Salesforce for now.
• Integrations that will be one-way in this release even though everyone pictures two-way.

The rule that makes it work: a non-goal only counts if the person who asked for it has seen it in writing and not objected. A non-goals list nobody read is just a defence exhibit for the post-mortem.

How do you handle the request that arrives in week six?

It will arrive, and refusing it outright is usually the wrong answer, because week-six requests are often better informed than week-one requests. Ask two questions:

• Does it change the outcome number? If yes, it is a re-scope and needs the sponsor.
• Does it invalidate a decision already made and built on? If yes, price the rework separately and visibly.

If neither, trade it. Something of comparable size leaves the release and moves to the non-goals list, in writing, the same day. Adding without subtracting is how a date quietly dies.

What does a scope document that survives contact contain?

• One outcome sentence with a metric and a date.
• A decision register: question, owner, due date, status.
• Assumptions, each one falsifiable.
• Non-goals, named and acknowledged.
• Data scope: which objects, how far back, who owns cleansing.
• System of record per object, and the direction of every integration.
• Definition of done for the first release, in user terms.
• What happens after go-live, including who holds the backlog.

Eight items. It fits on two pages, and it will tell you more about your delivery date than a three-hundred-line requirements matrix.

FAQ

How long should Salesforce discovery take?

Long enough to close the decisions that block the first release, and no longer. Judge it by the state of the decision register, not by a fixed number of weeks.

Is fixed-scope always the wrong model for Salesforce?

No, but it only works when the decisions are already made. Fixed scope on an undecided process fixes the wrong variable and the date pays for it.

What is the difference between a non-goal and out of scope?

Out of scope is contractual. A non-goal is communicated. The value is in the stakeholder having read it, not in it being defensible later.

Who should own the decision register?

Someone on the client side with the authority to escalate. If your delivery partner owns it, every overdue decision becomes a vendor complaint rather than an internal deadline.

Can phasing fix a scope that is too big?

Only if each phase goes live to real users. Phases that all land at the end are one project with extra documents.