You bought the platform. The budget was approved, the vendor was chosen, the project plan was drawn up. Months later the licence is paid, the dashboards exist, and your people are still working the way they always did.
Before you blame the software, or replace it, there is one question worth answering honestly: are you looking at a software problem, an ownership problem, or an adoption problem? They look identical from the boardroom. Telling them apart is the whole job, and it is where most stalled projects are won or lost.
Is Your Digital Transformation Stalled? Three Warning Signs
Most stalled transformations do not fail with a bang. They drift. Three signs tell you it has happened:
- The new system is open in one tab while the real work happens in a spreadsheet nobody officially uses.
- The vendor says the configuration is correct, your people say it does not fit how they work, and both are right.
- Every review, the promised return is real but not yet. The business case has quietly become a hope.
None of these is, on its own, a technical fault. But none of them is automatically an adoption fault either. That is the trap most advice falls into.
Software, Ownership, or Adoption?
It is fashionable to say the tool is never the problem, that adoption is everything. That is mostly true, and occasionally wrong, and the difference costs real money.
Sometimes the software genuinely is the problem: the wrong package was chosen, a customisation broke the workflow, the integrations do not hold, the thing simply cannot do what the work requires. Pretending that away to protect a tidy theory helps no one. The skill an experienced operator brings is not a slogan. It is the read: opening the engine, and seeing whether a delay is technically legitimate or whether something organisational is in the way.
So before the change-management talk, diagnose.
A six-question self-test: organisational or technical?
- Can you name, in one sentence, the management decision this software was supposed to improve? (If not, the problem starts above the tool.)
- Did the people who use it every day ask for it, or did it come down from above to serve a target? (Came down: adoption is at risk from day one.)
- Can the daily user get what they need from it faster than from the old way? (If not, it will not be used, however good it looks in a demo.)
- What do your people open first when they sit down in the morning? (If it is not the new tool, it is not part of the work yet.)
- Does the vendor's "it works as configured" match what the floor actually experiences? (A mismatch is the hinge: this is where a genuine technical or workflow fault hides.)
- Are people entering real data, or keeping a shadow spreadsheet on the side? (Working around it points to adoption or data, not technology.)
Five of these six questions test whether the organisation is set up to use the tool. One, question five, tests whether the tool itself is genuinely broken. That asymmetry is your answer. If your honest unease sits with the other five, the software is not the problem, and replacing it only buys a new logo and a new bill. If it sits squarely with question five, where the vendor's "works as configured" and the floor's experience part ways, look hard at the package, the customisation, and the integrations before you spend another euro on change workshops.
Adoption Starts on the Floor, Not in the Boardroom
Here is the part most digitalisation advice gets backwards. Adoption is far more likely when you start from the bottom: from a pain the people doing the work actually feel, not a metric the top wants to see.
About a decade ago, working inside a creative agency, I picked up a problem the company had already given up on once. They had built their own asset system in-house; it never really got off the ground, and by then it had been shelved and abandoned. I put a digital asset management system in its place. Fifteen thousand objects, most of the metadata added by hand. The premise did not come from the top. It came from the animators who would open that library every day, and whose real question was simple: can I find a usable asset in seconds, instead of scrolling a file server on luck?
The CEO understood the business better than almost anyone in the room. On this, his instinct fell short. He framed it as valuation, an asset library worth putting on the books, and because he could not feel the daily friction the team lived with, he could not value it. He never gave it his backing. We built it anyway, and it was used, because it removed a pain that was real to the people using it.
The standard advice says you need a visible sponsor. Usually true, and worth fighting for. But this is the exception worth remembering: a tool that removes a pain the floor genuinely feels can take hold without one. A tool that exists only to fill a number on a board cannot, sponsor or no sponsor. If a system exists only to feed a KPI, it is already dead.
Why Your Numbers Lie
Now measure adoption, and here is where most SMEs fool themselves.
Go back further, to the early 2000s. A B2B sales organisation I worked in had been stuck for years in a CRM we had built ourselves in Lotus Notes, with no way past it. We moved onto a cloud platform early, when that was still an unusual thing to do. Three teams, one system. Revenue and renewals were easy to measure, and they looked fine. They also said nothing about whether anyone was using the new system. Business can be healthy while the tool sits idle, carried by the same people doing the same things they always did.
I knew what every rep did when they sat down in the morning: they opened their email. Not the CRM. So we put what they cared about into the system's daily view: today's leads, the renewals coming up. Now the platform answered a question they already had every morning, who is worth a call today, and it answered it faster than email could. One team took to it first and started winning visibly. The other two noticed, and envy did more than any mandate could. Once we tailored it to how each team actually worked, they followed.
Back then, measuring use was hard, so I watched behaviour directly: searches per person, what they opened first. Today it is the opposite. You can drop a goal into any platform and track every event before lunch. That ease is the new trap. A dashboard full of clicks tells you there was activity. It does not tell you anyone depends on the tool. Counting events is not the same as adoption, and revenue is not the same as use. The honest question has not changed since the file-server days: does this answer something your people actually need, every day?
How to Rescue a Stalled Software Project
A stalled project can be turned around. It costs more than starting right would have, but it is rarely too late. The moves that matter are part operational, part human, and in this order:
- Name the real problem, not the tool. The question is never "which system did we implement?" It is "which decision is this supposed to make better, and what is in the way?"
- Cut the scope back to what one team can actually use. Most stalled rollouts are carrying three screens nobody needed. Triage them.
- Fix the data going in before you blame the output. A new system inherits old data faster. Reports nobody trusts are reports nobody uses.
- Put the daily trigger where people already look. Give them a reason to open it that answers a question they already have, today.
- Make one team win, visibly, before you touch the others. Adoption spreads by example and a little envy, not by mandate. Tailor it to how each team really works.
- Decide, honestly, who is not coming along. In every change there are people for whom the new way does not fit. Recognising it early is more humane, and more effective, than a year of persuasion.
Where an Interim Leader Fits
The first hour of a stalled project is not about technology. It is about telling apart three problems that look the same from the top: a software problem, an ownership problem, an adoption problem. That read is the work.
By the time I am called now, a first attempt has usually already stalled. I did not learn these patterns from the outside. I learned them from the inside, as the person who had to make the systems actually work, across more than two decades and more than 20 years of CRM. The patterns repeat. The package is usually adequate. The ownership is usually missing: no single person carries the outcome full-time, with the authority to decide and the experience to tell technical friction from organisational friction. And the floor was usually never asked what would actually make their day easier. An interim leader gives you that ownership for exactly as long as the transition needs it, and an honest read you will not get from the vendor or from the team that is already invested in the current plan.
Frequently Asked Questions
Why do tech projects stall in SMEs?
Most stall for three reasons: no single owner of the outcome, poor data going in, and low day-to-day adoption. The software itself is usually functional. The organisation never fully changes how it works, and the project is often measured by business results that hide whether the tool is used at all.
Is a stalled project a software problem or an adoption problem?
Usually adoption, but not always. It is a software problem when the package cannot do the job, the integrations are broken, or the workflow does not match reality. It is an adoption problem when the tool works as configured but people route around it. The fastest tell: are people entering real data, or keeping a shadow spreadsheet?
Do I need to replace the software to fix a stalled project?
Rarely. In most stalled projects the tool is adequate and the failure is in ownership, data, or adoption. Replacing the system without fixing those repeats the same outcome with a new logo and a new bill.
How do you measure whether a tool is actually adopted?
Not by revenue, and not only by event counts. Revenue can rise while a tool sits idle, and a dashboard can fill with clicks nobody depends on. Measure real reliance: how many people use it for real work, how often, and whether it is the first thing they reach for when the task comes up.
If your transformation has stalled, start with a conversation, not a plan. No commitment, no pitch. In an hour we can usually tell whether you are looking at a software problem, an ownership problem, or an adoption problem. That alone is often worth the call. Let us look under the hood.