Why 90% of Digitalization Projects Fail

I see it all the time. A company buys new software. Everyone gets excited. The implementation costs hundreds of thousands of euros. And then? Nothing. The software collects dust. Employees go back to paper and spreadsheets.

That's not tragic. That's stupid.

And it's preventable.

Reason 1: No Process Understanding

Here's the thing: Companies try to digitalize broken processes.

It doesn't work. Period.

"I'm automating my manual data entry now!" — No. If your data entry process is already broken on paper, it'll be broken digitally. Just faster.

I've seen this a hundred times. A company has a process. This process is a patchwork of emails, Excel sheets, and "Klaus does it this way every time." Then a consultant shows up and says: "Let me build you a digital solution!"

That's like putting a racecar on a destroyed road.

Before you digitalize anything, you have to understand how it actually works. Not how it should work. How it really works. With all the detours, exceptions, and edge cases.

That takes time. It's uncomfortable. It's necessary.

Reason 2: Big Bang Instead of Iteration

"We want the perfect solution. On day X. For all processes. Immediately."

I hear that constantly. And I already know: It'll be a disaster.

Here's why: Nobody actually knows what perfect looks like. You think you do. Your CEO thinks he does. But your employees? They know first.

Better approach: Start small. One process. One team. Get feedback. Adjust. Move to the next one.

Does it take longer? Maybe. But it works. In the end, you don't have a project that tanks after 18 months. You have a series of small wins.

Small wins motivate. Big failures demoralize.

Reason 3: Nobody Has Ownership

IT builds the solution. Business uses it. Or doesn't.

Here's the problem: When business isn't involved, it doesn't feel responsibility. The solution is "imposed" on them. It's not theirs.

That's fatal.

I always say: The business user, not IT, must be the owner. IT is the technical partner. But the business side must drive the project. Because they're the only ones who really know what's broken.

In every successful project I've seen? A business person always had ownership. A department head. A process manager. Someone who thinks at night: "How do we do this better?"

That person is gold. Keep them close.

Reason 4: Wrong Tools

I see companies with 15 employees implementing SAP.

SAP for 15 people is like buying a tank to drive to work.

Or: 3-person sales team with Salesforce Enterprise.

That's waste. Overkill. And it guarantees failure because nobody will understand the software.

Often — and I say this after 15 years — Microsoft 365 tools are enough. OneNote. SharePoint. Teams. It's not sexy. It's not a big consulting engagement. But it works.

Choose the tool your company needs now. Not the tool it might need someday. And not the tool the vendor advertises loudest.

Reason 5: No Change Management

Rollout without training = 0% adoption.

That's a mathematical equation. I could show you a study, but I just know it.

Your employees worked that way for 10 years. Then new software arrives. And you expect them to love it instantly?

No.

Change management isn't optional. It's not "nice to have." It's fundamental.

That means:

• Training (not just a PDF)
• Super-users who answer questions afterward
• Time to practice (not live on day one)
• Success metrics (so they see: "This actually works")
• Leadership support (the boss publicly says: "We're doing this")

Without these five things? Nobody uses the software.

My Approach: Iterative Quick Wins

I work differently. Here's what works:

1. Quick Assessment (1-2 weeks) I sit with the team. Not with consultants making PowerPoints. With real people. I ask: What works? What's broken? What would be a quick win?

2. Fast Prototype (4-6 weeks) We don't build the Perfect Solution. We build something that works. We use existing tools. We keep it simple.

3. Training & Adoption (in parallel) Before we go live, everyone knows the solution. Everyone's practiced with it. Everyone understands why. That's not optional.

4. Measurement (ongoing) How many people use it? Does it save time? Does it reduce errors? We measure. We adjust.

That's my playbook. And it works.

Look at our cases. The vacation request project — iterative, small, successful. The product configurator in crafts — owner-driven, measured against business results, now part of the DNA.

The Truth

90% don't fail because of technology. Technology is always good enough.

They fail because:

• Nobody understood the processes
• Everyone wanted too much too fast
• The right person wasn't in the driver's seat
• The wrong tool was bought
• People weren't brought along

These aren't technical problems. These are people problems. And people problems are tougher, but also more solvable than technical ones.

The solution isn't a better consultant. Not more money. Not more complex software.

The solution is: Start slower. Be more honest. Involve the right people. Measure. Iterate.

It's not sexy. It's work. But it works.

And that's the only thing that matters.

---

Do you recognize yourself? Is your next project facing the same trap?

I guide companies through this process. With quick assessments, with iterative solutions, with real change management.

Let's talk. I'm listening.