There is a specific kind of phone call that consulting firms get more often than they'd like to admit. A company has been six months into a Salesforce implementation. Something isn't working, deliverables are late, quality is inconsistent, the team has lost confidence, and the original partner either can't or won't fix it. Can we help?

The answer is almost always yes. But the first thing we tell the client is the same every time: before we fix anything, we need to understand what actually went wrong.

The instinct to move fast is wrong

When a project is in trouble, the natural pressure is to recover time. The program is behind schedule. The business is waiting. Stakeholders want to see visible progress. The temptation is to bring in a new team, take stock of what exists, and start building.

This is usually a mistake.

The problem with rushing into execution on a struggling project is that you inherit assumptions. The existing build reflects a set of decisions, technical decisions, scoping decisions, design decisions, and those decisions had reasons behind them. Some of those reasons were good. Some were wrong. Some were right at the time and are now outdated. Without understanding which is which, you can't make informed decisions about what to keep, what to rework, and what to throw away.

We've seen organizations spend months building on top of a technical foundation that was fundamentally flawed, because the rescue team didn't slow down long enough to assess it. By the time the underlying problem becomes undeniable, the cost of unwinding it is significantly higher than it would have been at the start.

What an honest assessment actually looks like

When M&S Consulting takes on a rescue engagement, the first deliverable is always an assessment report. Not a plan. Not a roadmap. An honest account of where the program is and why it got there.

That means code reviews, not to criticize, but to understand what was built and whether it reflects the stated requirements. It means requirements walkthroughs with both the technical team and the business owners, because the gap between what was spec'd and what was built is often different from the gap between what was built and what the business actually needed. It means stakeholder interviews, including the uncomfortable ones, to understand the delivery dynamics that produced the current situation.

The output of this process is a prioritized list of problems: what is genuinely wrong and needs to be fixed, what is imperfect but workable, and what is actually fine and doesn't need to be touched. That last category is important. Project rescues have a tendency to produce over-corrections, situations where the new team rebuilds things that didn't need rebuilding, because the instinct is to fix everything. The assessment protects against that.

The most common root causes

Across the rescue engagements we've been involved in, the root causes are almost never the technology. They're almost always one of three things:

Requirements were never fully defined. The implementation began with a high-level understanding of what the business needed, and the details were meant to be worked out during delivery. This works when the team has strong business analyst capability and stakeholders who can engage consistently. When either is missing, the build drifts from what was needed, slowly at first, then faster as the program momentum makes it harder to stop and revisit.

The delivery governance was opaque. Milestones were set and tracked, but the signal reaching leadership was filtered: issues were softened, risks were underweighted, and by the time a problem became undeniable, it had been building for months. The fix isn't better reporting software, it's a governance model that surfaces problems quickly and creates a culture where raising issues early is rewarded rather than punished.

The wrong people were in the room. Salesforce implementations require meaningful engagement from the people who will actually use the system. When design decisions are made by project sponsors and IT representatives without the people who own the workflows being transformed, the result is a system that is technically functional and practically unusable. The fix, at that point, requires going back to the business, not forward to deployment.

What recovery actually looks like

Once the assessment is complete, the rescue proper can begin. The work varies by engagement, but the pattern is consistent: stabilize first, then deliver.

Stabilization means addressing the specific technical issues that are creating risk, the components that would fail under load, the data integrity problems that are buried in the existing build, the integration points that are fragile. These get fixed before the delivery engine restarts, because building on top of unstable foundations accelerates the rate at which problems compound.

Then delivery resumes, with a governance model that the business trusts and a scope that reflects what the assessment revealed. Which is usually somewhat different from the original statement of work, because the original statement of work was written before anyone understood the full complexity of what was being built.

The organizations that navigate this process successfully tend to have one thing in common: they accepted, early on, that the original plan was no longer the right plan, and they gave the recovery team the mandate to say so honestly. The ones that struggle are the ones that ask the recovery team to execute the original plan faster.

That's not a rescue. That's the same mistake, repeated more quickly.