The contract is signed. The kickoff happened. Then it went quiet, and now you are paying monthly for something nobody uses.
This is common enough to be a category of problem rather than bad luck.
Implementations stall at the boundary, not inside the product
Almost always, one of four things:
Your data was messier than the scoping assumed. Every statement of work is written against clean data. Nobody has clean data.
An integration nobody owns. Two systems that have to talk, through an API neither vendor documents for your case.
A process that was never written down. The vendor asked how it works, someone described how it should work, and the gap surfaced during configuration.
Adoption. The product is configured and the team does not use it. No vendor can fix this for you, and most do not try.
Notice that three of the four sit outside the vendor's product, where they have neither access nor mandate.
The question that decides your next move
Is the remaining work inside their product or outside it?
Write the list of what is left. Mark each line as inside or outside. The shape of that list tells you which of the four options below is yours.
The four ways out
1. Push the vendor. Right when the remaining work is genuinely theirs. Ask for a written list of scope, delivered, and remaining, with an owner per line. Even if you go another route, that document is the most useful thing you will get from this phase.
2. Buy their professional services. Reasonable for depth inside their product. Useless for anything outside it, and that is where the stall usually lives.
3. Bring in an independent implementer. The right answer when the remaining work is your data, your integrations and your process. Someone accountable for the outcome in your environment rather than for the software working.
4. Do it internally. Viable if you have a person with the time, the access and the decision rights. The reason this is rare is not skill. It is that the person who could do it already has a job.
What not to do
Do not buy a second platform to escape the first. The work that stalled is your data, your integrations and your process, and all three travel with you, plus a migration.
Do not restart the scoping from zero. Whatever exists has value. The first job of anyone who comes in is to inventory what is built and what it actually does, not to redesign.
How to brief whoever finishes it
Give them four things and the first week goes to work rather than to discovery:
- The original scope and what was delivered
- Access to the systems, on day one
- The list of what is left, marked inside or outside the product
- One person who can make decisions without a committee
What finished should mean this time
Not configured. In production, with a named owner, a runbook someone else has followed, an error route, and a business result you can verify by opening a record rather than by reading an execution log.
Agree that definition before anyone starts, because the vague version of done is how the first attempt stalled.
