Salesforce Project Stuck? Your 90-Day Rescue Plan

The Short Answer

Most stalled Salesforce projects aren't stuck due to poor code. They're stuck because no one took the time to ask what's actually changing in users' workflows, who is accountable for each decision, and what happens when something doesn't go as planned. The result: sprint after sprint adding features, without the overall picture improving.

Rescuing a stalled Salesforce project first means stopping the bleeding, and only then deciding what to do with what's already been built. This order is critical: many organizations jump straight to the fixing phase without first diagnosing why the previous process failed, repeating the same mistake a second time. Those looking to understand how to prioritize accumulated debt can delve into Salesforce Technical Debt Prioritization.

Signs of Being Stuck: How to Identify When a Project is Off Track

There's a difference between a slow-moving project and one that's completely stuck. The following signs appear in almost every rescue we've performed:

• Status discussions turn into explanation sessions: A weekly status meeting becomes a justification for why something isn't ready yet, without a reliable new deadline.
• The Backlog grows faster than the closure rate: New items are added every week, but the number of closed items remains constant or decreases.
• No version has been tested with a real user in the last month: Only an internal demo by the technical team, without contact with those who will actually use the system.
• Frequent requirement changes without documentation: Every conversation generates "one more small change" that isn't entered into a structured Scope Document.
• Visible lack of trust: Users are already building parallel Excel sheets "just in case," a sign they've stopped believing the system will work on time.

When four out of these five signs exist simultaneously, it's a stuck project, not a slow one, and this difference changes the entire treatment strategy.

10-Day Diagnosis: What to Check and in What Order

A good diagnosis doesn't require two months. Ten working days, with proper allocation, are enough to get a reliable enough picture for decision-making. Recommended breakdown:

Days 1-2: Interviews and Initial Mapping. Short conversations with the Sponsor, process owner, two or three end-users, and the development team lead. The goal is to collect different versions of "what went wrong," not to reach a conclusion yet.

Days 3-5: Direct Technical Review. Dive into the Org itself: data model, existing automation, permissions, error logs, and slow queries. Here, check if the problem is architectural or operational.

Days 6-7: Compare What Was Promised with What Was Built. Review original documents (SOW, User Stories, Design Docs if available) against the actual state in the Sandbox or Production environment.

Days 8-10: Formulate Findings and Initial Recommendation. A short document classifying each identified problem as Scope, Architecture, or Trust, and presenting a first recommendation: Reset, Refactor, or Continue at a revised pace.

Three Layers of the Problem: Scope, Architecture, and Trust

The most common mistake is treating every project stall as a single problem. In practice, it’s almost always a combination of three different layers, each requiring a different approach.

Scope problems manifest when no one truly knows what's included in the first release. This happens when the original definition was too general ("manage the entire sales process in Salesforce") and wasn't broken down into concrete scenarios. The solution isn't another planning meeting but rather writing a sharp Must/Should/Later list, with an Owner for each item.

Architecture problems are evident in technical choices that don't scale: a data model that doesn't support the volume of records, automation that runs in the wrong order, or integrations that silently fail. This requires in-depth technical review, and sometimes involves a Salesforce System Upgrade as a parallel foundation for the fix.

Trust problems are often a result of the first two but take on a life of their own: users stop reporting issues because "they won't fix it anyway," and management stops funding changes because "we already tried." Trust problems aren't solved with declarations, only with small, consistent proofs.

Diagnosis Table: Symptom, Root Cause, and First Action

Reset vs. Refactor: How to Decide

This is the central and most expensive decision, so it needs criteria, not gut feelings. Three tests help:

1. The extent of technical debt versus what's already working. If 70% of the functionality works reasonably well and only specific parts fail, that's a Refactor. If the problem lies in the fundamental data model, a partial Reset is almost always better.
2. Cost of explanation versus cost of rebuilding. If it takes a new team more than a week to understand why something was built a certain way, the future maintenance cost will likely exceed the cost of a clean build.
3. User trust level. When trust is very low, a focused and transparent Reset (with an announcement: "we're starting a new, improved version") sometimes achieves more cooperation than a quiet fix users don't notice.

In practice, most successful rescues are hybrid: a Reset for the problematic core component (e.g., the Opportunity model or approval process), alongside a Refactor for the rest of the system. A structured comparison of approaches can be found in Rebuilding Salesforce, which details the criteria for each scenario.

90-Day Rescue Plan

It's crucial to plan the "First Wave" phase around a single process that users will feel within weeks, not around the most technically interesting component. Projects that fail for a second time often do so by repeating the same mistake: starting with an impressive capability instead of the real pain point. This phase is also directly related to actual performance, and those experiencing response time issues are invited to read Salesforce Performance Optimization.

Restoring User Trust

Trust isn't rebuilt by a presentation; it's rebuilt by a consistent pattern of small, kept promises. Here are some principles that have worked in practice:

• Declare small victories explicitly. When you've fixed a recurring bug, send a short message explaining exactly what was fixed and who requested it. Such transparency builds more trust than a generic list of achievements.
• Invite users for early testing, not just UAT at the end. Someone who sees an intermediate version and feels their feedback was incorporated becomes a project ambassador to the rest of the team.
• Don't promise a date you're not sure about. A date delayed for the third time harms trust more than a realistic but less optimistic timeline.
• Document failures publicly too. When something didn't work, a brief explanation of what happened and what's changing builds more credibility than silent ignorance.

The trust-building process usually takes longer than the technical fix itself, so it's worth planning it as a parallel track to the 90-day plan, not as an automatic outcome. Organizations seeking structured guidance for this process, including close support for the team and management, can use the Salesforce Health Check service as a complete framework.

Example Organizational Scenario

A financial services company ran a Salesforce project for nine months without going live. Upon review, it was discovered that the Scope had tripled from the original plan, the technical team had built three different versions of the same approval process without documenting why, and key users had already switched to managing their monthly reports in a separate spreadsheet.

The ten-day diagnostic plan revealed that the primary problem wasn't technical: the technical team received conflicting requirements from two different managers who hadn't coordinated. The decision was a partial Refactor, not a full Reset, because most of the code was sound. The first phase focused solely on the approval process, which was the main source of frustration, and within five weeks, a stable version was launched that both managers jointly approved. Only then did they proceed to expand the rest of the processes.

The main lesson: the stall didn't stem from a one-time technical failure, but from the lack of a single entity holding the entire decision map. Such a role, even if temporary, is often the difference between a project that succeeds the second time and one that gets stuck again.

Checklist Before Deciding on a Rescue Operation

• ☐ A 10-day diagnosis was performed, including interviews, Org review, and comparison with original documents
• ☐ Problems were clearly categorized into Scope, Architecture, or Trust
• ☐ A documented Reset/Refactor decision with justifications was made
• ☐ One process was chosen for the first wave based on real user pain
• ☐ A Change Freeze was implemented for the diagnosis and decision period
• ☐ Baseline metrics were established before starting the fix
• ☐ A continuous communication plan for users and management is in place
• ☐ A single Owner holding the entire decision map has been appointed
• ☐ The 90-day plan includes measurable milestones, not just an end date
• ☐ A process for Governance handover and maintenance at the end of the rescue has been defined

Professional Resources

• Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
• HPI Pro – Salesforce Health Check — https://hpi.pro/salesforce-health-check
• HPI Pro – Support & Guidance — https://hpi.pro/support