Signs of a Digitalisation Project Headed for a Stall

There’s a meeting that comes back to me now and then, and not because it was particularly dramatic. The opposite—it had gone perfectly. Polished slides, the right words, that “this time we mean it” tone. We were talking about transformation, operational efficiency, the future.

Everyone was nodding. The budget was approved.

Three months later, the project was gone.

It isn’t a rare story. 84% of Italian SMEs run into trouble executing digital projects, and 15.8% report a complete failure. Globally the music is similar: roughly 84% of digital transformation initiatives don’t reach their expected results, often for reasons that have little to do with technology.

The point, though, isn’t only that projects fail. It’s that some projects are born dead. The signs are there from the start, only they’re discreet, almost polite. And if you don’t know where to look, you mistake them for ordinary complexity.

The sponsor who “supports from a distance”

The first sign is the one that looks least serious. On paper, the project has an important sponsor: founder, CEO, someone “putting their face on it”.

Then you never see that face.

The sponsor delegates, sends an endorsement email, maybe opens the kickoff with a five-minute motivational talk. And then disappears from the operational meetings, the ones where the real knots get untied. The result is fairly predictable: the moment the first internal resistance shows up, the resistance wins. Not because it’s stronger, but because it’s more patient.

In many SMEs the resistance isn’t even malicious. It’s routine, urgency, “let’s close the month first”, “we’ll talk after the trade fair”, “we can’t stop the warehouse right now”. If the sponsor isn’t there when choices need to be made, the implicit message is simple:

This project can wait.

And things that can wait, wait forever.

It isn’t only a feeling. 56% of digital transformation projects don’t get real support from senior leadership.

Goals written by copy-paste

“Improve efficiency”. “Optimise processes”. “Increase digital competitiveness”.

When I read goals like that, I always wonder: are they describing something they actually want to do, or are they just looking for a phrase that sounds right in a document?

The problem isn’t that they’re false. It’s that they’re not verifiable. They don’t help you understand, six months in, whether the project worked. And they especially don’t help you decide what to do tomorrow morning.

A line like “reduce order fulfilment time by 30% within six months” changes everything. It forces you to pick a scope, find a baseline, understand where to act. “Digitalise the company’s processes” is a fog. Everything fits inside it, which means nothing does.

Not surprising that 64% of digitalisation projects start without a clear roadmap. The main cause might be exactly this difficulty in turning generic ambition into measurable goals.

And there’s a slightly toxic side effect: vagueness makes it easy to declare success without having achieved much. You just have to tell the story well.

No one knows who decides

This sign is sneaky, because at the start it looks like collaboration. Lots of people involved, lots of departments invited, lots of opinions gathered.

Then, when a real decision arrives, no one knows who has the final word.

Who approves the technology choices? Who resolves the conflict between sales and operations? Who decides whether to accept a scope change proposed by the vendor? Who says “OK, we do it this way” when both alternatives are inconvenient?

If there’s no clear answer, something I’ve seen recur often happens: decisions don’t get denied, they get postponed. They turn into email loops, meetings that end with “we’ll sync up”, shared documents full of comments.

And the project doesn’t collapse spectacularly. It dissolves. A little at a time.

The literature is less romantic than we’d like: effective governance requires an internal owner who can coordinate technology choices, vendor relationships, and outcome monitoring. Without one, the project drifts.

The stack picked by the vendor

This is the one that makes me most uncomfortable, maybe because it’s the hardest to recognise when you’re inside the company.

The vendor arrives with a ready-made solution. It might even be a good solution, in its own context. But they propose it as the natural answer to the company’s problems, and the company accepts because it hasn’t done a real needs analysis.

Sometimes it happens out of haste. Sometimes because “they’ve been doing this for years, they’ll know what’s needed”. Sometimes because no one internally has the skills or the time to question the proposal.

The result tends to be the same: an expensive technology gets bought that doesn’t fit existing processes, or upends them in ways the organisation isn’t ready to absorb.

The right sequence would be banal, yet it’s extremely rare: first you understand what you want to solve, then you pick the technology.

When the stack has already been decided before the first strategic meeting, something is off.

KPIs that can’t be measured

The last sign often shows up when time, energy, and reputation have already been spent.

The KPIs get defined. Everyone is happy because “at least we’re measuring”. Then no one asks a very simple question: does the data to measure them exist?

“Customer satisfaction improvement” is a KPI only if you have a consistent way to measure satisfaction before and after. “Operational cost reduction” works only if you know which costs you’re tracking, and you track them cleanly.

When KPIs get defined to reassure the budget approver and not to steer the project, they become elastic numbers. And if a number can be interpreted a thousand ways, it will never plainly say the project is failing.

There’s an interesting point here: sometimes measuring becomes a kind of theatre—a practice that looks serious but doesn’t change decisions.

The PO: the role no one called

If you think about it, all five of these signs share something. They aren’t technical problems. They’re problems of clarity, accountability, communication.

And there’s a role that, in theory, was created precisely to govern that kind of chaos: the product owner.

In an SME, often no one has time for the “boring” part of the project. The part made of repeated questions, definitions, boundaries, priorities. And yet that’s exactly where it’s decided whether a project really starts.

A PO doesn’t accept “improve efficiency” as an answer. They insist, sometimes too much. Which process? Which metric? From when to when? Who’s putting their hands on it? What changes for the people who today do that work a certain way?

On the weak-sponsor problem, the PO can’t replace leadership—it would be naive to think otherwise. But they can make leadership more effective. They can prepare decisions that force the sponsor to choose between concrete options, instead of nodding along to vague presentations. In practice, they reduce the cognitive friction for the person who’s supposed to lead and often doesn’t know where to start.

On governance, the PO brings structure almost by definition. They manage priorities, make explicit what’s in and what’s out, keep track of commitments. They don’t eliminate internal politics, but they make it visible—and that alone sometimes changes the game.

On vendors, perhaps it’s the most valuable function. The PO sits in front of the vendor not as a naive customer but as an interlocutor who understands what they’re buying. They can tell a proposal built around the company’s needs from one built around the vendor’s catalogue.

I wonder whether the real problem is that in Italian SMEs this role is still seen as a luxury—something for big companies or funded startups. I have the opposite impression. Where resources are limited and mistakes are expensive, having someone who asks the right questions at the start is worth as much as not throwing six months away on a project that, fundamentally, wasn’t going to ship anyway.

And maybe the most useful question, before picking software at all, is this: who takes responsibility for making the project real, day after day? If there isn’t a credible answer, maybe better to stop there. Not out of cynicism, but out of respect for everyone’s time.