If your Salesforce go-live has slipped twice, start here. If your org is live but stuck, the same three tests apply. The question is not whether the team failed. It is which of three calls fits the org you have today: finish it, cut it back, or rebuild it. This is not for you if no one owns the org yet, or if you only want more hours from the same plan.
Why is the money already spent not part of the decision?
Because most of it is paid whichever way you go. Salesforce's standard Global Online Master Subscription Agreement says, in section 5.1, that "payment obligations are non-cancelable and fees paid are non-refundable," and that "quantities purchased cannot be decreased during the relevant subscription term." Your order form may say something different. We do not give legal advice, so read yours, and ask your account executive for the answer in writing.
If that sentence holds for you, the licence and the hours already billed are the same on every path. They tell you what it cost to get here, and whether the seats are worth keeping is a separate question (license optimization). They do not tell you which path is cheaper from here.
The cost is real, and it can run long. Marcus Smith of Cloud Trailz, a Salesforce consultancy, wrote about licences his own company stopped getting value from: "We've carried those licenses far longer than we wanted to. In our case, the timeline will end up approaching 2 years." He keeps calendar reminders for the notice window, "Because if you miss the window, the clock starts all over again." That is a good reason to write the call down early. It is not a reason to keep building.
Which process week do you still need?
One week of real work, run through the org, by the people the org was bought for. Name it in a single sentence before you read anything else. For a sales team it might be a lead arriving, being qualified, quoted and handed over. For a service desk it might be a case opened, answered and closed. Those two are examples. Yours is the week your team already runs in spreadsheets, inboxes or chat.
Everything built so far either serves that week or it does not. That is the only sorting you need. A feature that serves a week nobody runs is cost, however finished it is. A half-built piece that serves the week your team lives in is the part worth saving.
How do you tell finish, cut and rebuild apart?
With one test each. This is our rule of thumb, not a study, and we have not measured how often it is right.
Run the tests in that order. The counts come from your own org: an object list, a flow list and a licence report, each read against the one-sentence week. Try cut before rebuild. A rebuild is the most expensive call, so it has to earn the name: the same defect, fixed more than once, coming back. One bad week is not that.
A call can also be "stop", and a cut often leaves technical debt to clear first. If the process week does not exist yet, or no one owns it, no amount of finishing helps. That is the honest answer, and it is a cheap one.
What do the two slips say about the plan?
They say something about what the plan rewards. Two practitioners wrote this in public this summer, and both are consultants who sell this work, so read them as opinion.
David Giller wrote: "A Salesforce implementation scoped at 8 weeks quietly becomes 16, then 24, while the budget follows and the team's energy doesn't." His advice: "ask who has financial incentive to keep discovery moving fast." John Hamon described two banks that bought the same software, and told buyers to ask a partner two questions: "What will be live and in daily use in 60 days, with real bankers entering real prospects? And what does your contract make expensive: shipping early, or shipping late?" He disclosed that his firm runs one of the accounts.
Put both questions to every plan on your desk, including ours. Our part of the answer is on our rescue page: we will not fix-price a rescue we have not assessed, and the first thing you get is a written call on finish, cut or rebuild, with the reasons. If a plan cannot answer them, that is a finding about the plan.
What does a week in the org read?
Five things, in the order we read them (the same read sits behind our failed project rescue work). On day 1, read-only access to the flows, permissions, integrations, licences, and who is allowed to see which data. In the first days, anything that is hurting data is switched off, with a note saying what and why. At the end of the week, a written call: finish, cut, or rebuild, with the reasons and the first fix. After that, we fix what costs your team the week before anything new is built.
Another firm published what a read of an inherited org turned up, which shows the kind of finding to expect. It scored 61 out of 100 on Salesforce Health Check, had multi-factor authentication switched off, ran 19 percent of users as System Administrators, and had one object firing 12 record-triggered flows on save. That is one org, written up by Sapota, and not a benchmark. None of it says finish, cut or rebuild on its own. It becomes a call only when you hold it against the process week.
You can see a sample read, on an invented org, before you send us anything.
What would we do first?
We have been a Salesforce consulting partner since 2010, and we would write the call down before buying any more build. Our first read of an org is free: a short look and a written note. The rescue week below is the longer read, and this page does not state its price. Five steps, none of which need us.
- 01Write your process week in one sentence, and name the person who runs it today.
- 02List what is built. Mark each item as serving that week, or not.
- 03List every defect that came back after a fix, and where it came back.
- 04Ask whoever planned the work who profits from a longer plan, and what the contract makes expensive.
- 05Write the call, finish, cut, rebuild or stop, with three reasons. Share it before you approve more hours.
If no one owns the org yet, name an owner first. Then the three tests above can give you an answer.
