Almost no implementation fails in a single dramatic moment. There is rarely a day where the project lead walks into your office and says, “This is over.” That would actually be a mercy. It would give you a decision to make, a budget to reclaim, and a logical story to tell.
What happens instead is quieter and much more expensive. The engagement bleeds. One slow cut at a time, over months, until the thing you signed for and the thing you are living with have almost nothing in common. The scope is the same on paper. The people are different. The velocity is gone. Your team has stopped asking questions because the answers stopped changing anything.
If you have been through this once, you already know the pattern. What follows names each cut precisely, because vague frustration cannot be fixed. Specific failure modes can.
What death by a thousand cuts looks like in practice
Successful journeys depend on tracking the distance still to run. Forward motion on its own proves very little.
The ship that drifts half a degree
Think about a ship crossing an ocean. The crew can be busy, the engines can be running, and every daily report can show steady progress. If the ship drifts half a degree off course each day, none of those individual deviations looks alarming. The problem becomes obvious only when the destination is no longer where the ship is headed.
Implementation projects drift the same way. No single deviation justifies an escalation.
The deviations nobody escalates
- A consultant rolls off. That is normal staffing.
- A change request adds two weeks. That is how projects work.
- A design decision gets deferred to phase two. Reasonable.
- Discovery runs a little long. They are being thorough.
- A workshop slides by a week because a stakeholder is travelling. Calendars are hard.
- A test cycle gets compressed to protect the go-live date. Everyone agrees.
Stack forty of those together and you get the outcome the buyer describes as a disaster while every status report stayed green.
The status reports were not lying. They were measuring activity, while the ship kept drifting.
Activity and forward motion are easy to count. Continuity is harder, and continuity is what decides whether the project still arrives at the thing you thought you were buying.
The first cut: the A-team wins the deal, then disappears
You met the architects. They were sharp. They asked about your quoting process before you brought it up, named the failure mode in your order-to-cash flow from two screenshots, and pushed back on one of your assumptions in a way that earned trust. That is who you bought.
Then the statement of work is signed and those people become “executive sponsors.” Their calendar touches your project once every two weeks for a steering committee. The actual build goes to a delivery team you have never met.
This is the bait-and-switch, and it is the economic engine of the traditional systems integrator model. Senior people are scarce and expensive, so they are deployed where they generate the most revenue per hour, which is selling rather than building. The margin is manufactured in the gap between who sold it and who delivers it.
Restaurants would never survive this. Imagine the chef walks the dining room, describes the tasting menu in loving detail, takes your order, then hands the ticket to someone who has never cooked the dish while the chef moves to the next table. You would call that fraud. In software delivery we call it “resourcing.”
The second cut: the revolving door of resources
Now the bleeding starts in earnest. The functional consultant who finally understood why your distribution business treats a “customer” differently from a “ship-to account” rolls off to another project. A new one joins. You explain it again. Four months later a developer rotates in, asks why the pricing logic works the way it does, and someone on your team spends a day reconstructing a decision that was already made twice.
What a resource change actually costs
- Re-education, funded by you. Every rotation resets a portion of your business context to zero, and your own people pay for the reset in hours that never appear on an invoice.
- Decisions made to be defensible. When nobody owns a decision from design through deployment, the safe choice beats the correct one.
- Parallel logic instead of extended logic. The new consultant does not know why the original approach was chosen, so they build alongside it rather than extending it.
- Overlapping automations. Three flows fire on the same object, each written by someone who did not know the other two existed.
- Documentation that describes intent nobody remembers. The artifact survives, the reasoning does not.
That is Revenue Debt accumulating in real time: the compounding cost of technical debt on the systems your pipeline runs through. Your revenue becomes dependent on a set of interconnected decisions whose individual impact is almost impossible to see.
The third cut: inexperienced consultants learning on your org
There is nothing wrong with being new to consulting. Everyone starts somewhere. The question is where the learning happens and who funds it.
The problem begins when an early-career consultant is staffed and billed as a seasoned expert. They may be learning the platform in your production org, on your timeline, with your revenue operations as the practice field. They know the feature. They have not yet accumulated the same knowledge of its failure modes, and anticipating failure modes is much of the job.
A seasoned architect knows how a design breaks in eighteen months: when volume triples, when a bulk data load fires every automation at once, when governor limits turn a clean design into a nightly error digest nobody reads.
The signature of inexperience
You can spot it without being technical.
- Everything is possible, and nothing is ever recommended against. Experienced people know when to say no.
- Requirements are transcribed rather than challenged. You get exactly what you asked for, including the parts that were wrong.
- Automation is always the answer. Deleting something is never proposed.
- Design decisions arrive as a menu of options for you to choose from, with no recommendation and no stated tradeoff.
- Estimates are confident and uniform. Nothing is flagged as risky, because nothing has bitten them yet.
That fourth one is the tell. When a partner hands you three options and asks which you prefer, they are transferring architectural risk onto the person least equipped to hold it: you. You hired them for the recommendation.
The fourth cut: the offshore hand-off
Distance is survivable. Specific, structural things break in a hand-off, and it is worth being precise about which.
Three things that break in a hand-off
- Context loss. Requirements get written down to cross a time zone. Written requirements are a lossy format: they capture the what and lose the why. Your business logic lives in the why.
- Latency compounding. A question that would take ninety seconds in a working session takes a full day. A design clarification that needs four rounds of question and answer takes a week. Nothing is broken. Everything is slow.
- Accountability diffusion. When the person doing the work reports to a delivery manager who reports to an account lead who talks to you, nobody in that chain can say yes or no on their own. You escalate to get a decision that one senior person would have made in the room.
This is what buyers mean when they say they are done babysitting engagements. If you have to be the integration layer between your partner’s own people, the partner has sold you a staffing arrangement and called it a solution.
How to tell a senior-only partner from a bloated one
You cannot verify seniority from a pitch deck, because every deck shows the same architect bios. You verify it with structural questions during the sales cycle.
- “Who on this call will be doing the work with their own hands?” If the answer includes a role you have never met, you already know the shape of the engagement.
- “What would you delete in the first thirty days?” A senior architect gets specific fast: redundant automations, unused objects, duplicate approval paths. A junior team will talk about what they would build. The fastest path to a healthy org runs through removal, and we call that Delete-First. It is the cheapest velocity you will ever buy.
- “What will you tell me I should avoid?” Seniority is mostly the ability to say no with a reason attached.
- “What happens to my project if someone rolls off?” Listen for whether continuity is a promise or a process.
- “When do I see something working?” Weeks, not quarters. A long discovery followed by a multi-month build hides risk until it is too expensive to act on. Working software in weeks is the only honest status report.
Why this matters more now
For years, implementation followed the same model: senior people shaped the solution, then handed it to a larger delivery team to execute. With every handoff, context thinned. Decisions became requirements, requirements became tickets, and the people doing the work drifted further from the people who understood why it mattered.
That tradeoff has expired.
A modern execution layer allows senior experts to stay close to the work while technology extends their capacity. Their judgment flows directly into design, configuration, testing and documentation rather than disappearing into a handoff. Knowledge stays connected from discovery through delivery, and the repetitive assembly work stops consuming the hours that should go to architecture.
This changes the economics of implementation. Layers of coordination are no longer required to turn expertise into output. Fewer handoffs mean less context loss, faster decisions, and less architectural risk pushed back onto the buyer. The better model gives experts the reach to stay accountable for what actually gets built.
The same logic applies to whatever AI you are planning on top of the platform. Agentforce and any orchestration layer you add will act on the data model exactly as it exists, so the foundation decides the outcome.
The way out is structural
The instinct after a bad engagement is to write a better contract: tighter acceptance criteria, harder penalty clauses, more detailed scope. It rarely works, because the contract was never the failure point. The delivery model was. You cannot draft your way out of a structure that earns money on re-explanation and change orders.
What that structure looks like
- The people who assess your org are the people who design it and the people who build it. There is no hand-off, because there is nobody to hand off to.
- Senior-only staffing, because the failure modes are the job.
- Delete-First, because your org is already carrying more than it needs.
- Working outcomes in weeks, so a wrong assumption gets caught while it is still cheap.
- One accountable owner from discovery through deployment, so decisions get made once.
Senior ownership. Continuous context. No excuses. That is the structure that keeps a thousand small cuts from ever starting.