Data Quality in Mid-Sized Companies: Why Projects Fail in Preparation, Not Execution

“First we need to clean up the data, then we can start the project.” No sentence is more common in steering committees. And no sentence has delayed or quietly killed more projects.

The pattern is always the same — whether it’s an ERP migration, a DATEV integration project, a CRM campaign, or an AI pilot. It is a central theme in my ERP consulting for SMEs. Data quality becomes a precondition. Months are spent cleansing, harmonizing, structuring. Budgets flow. And the actual project never starts.

Four ERP Projects That Failed Due to Data Quality

ERP Migration: “First Clean All Master Data”

A manufacturing company plans to migrate to a new ERP system. The decision: before go-live, all master data will be cleansed — item masters, supplier data, bills of materials. The cleansing project runs for 18 months. During that time, data in the legacy system continues to age because operations keep running. By the end of the cleansing phase, the already-cleansed data is inconsistent again. The migration project starts a year late — cleansing the same data a second time. I’ve detailed the typical mistakes in ERP migrations in my article ERP Migration: 5 Mistakes That Cause Projects to Fail — the data problem is almost always part of it.

DATEV Integration: “First Harmonize All Charts of Accounts”

A company with three legal entities wants to set up a DATEV interface for automated posting data transfer. Precondition: all entities should use the same chart of accounts. The harmonization drags on for two fiscal years — because each entity has special cases, because the tax advisors disagree, because year-end isn’t the right time and neither is the next one. The interface never goes live. Accounting keeps posting manually.

CRM Campaign: “First Deduplicate All Customer Data”

Sales wants to run a targeted existing-customer campaign. The CRM has 40,000 contacts, an estimated 15% duplicates. The directive: cleanse first, campaign later. The cleansing is outsourced. Three months later, duplicates are reduced — but the campaign has missed its window. The competitor was faster.

AI Pilot Project: “First Build a Data Lake”

A mid-sized trading company wants to use AI for demand planning. The IT manager recommends: first build a data lake, connect all data sources, then start with the AI model. The data lake becomes a permanent project. Twelve months later, the infrastructure is there — but nobody uses it because nobody is focused on the original use case anymore. The budget is spent.

Why the Data-First Strategy Hurts ERP Migrations

Nobody would argue that data quality doesn’t matter – Bitkom also emphasizes the central role of clean data in its practical guides. Data quality is critical. Bad data leads to bad decisions, wrong reports, and expensive mistakes. That’s not in question.

The problem isn’t the insight — it’s the sequence.

“Data first, then project” sounds like what a responsible CFO or CTO should say. It sounds like risk mitigation, quality awareness, professionalism. Who would argue against it?

But in practice, here’s what happens:

• Data cleansing without application context is endless. If you don’t know which project will use the data, you don’t know which fields actually matter. So you cleanse everything — or nothing properly.
• Data ages during cleansing. In a running operation, data changes daily. What’s cleansed today is inconsistent again tomorrow if the operational process isn’t adjusted simultaneously.
• Perfect becomes the enemy of good. Data quality will never reach 100%. Anyone who waits for perfection waits forever. There’s always another edge case, another exception, another data field that doesn’t fit.

Running Data Cleanup and ERP Project in Parallel

The solution is neither “ignore data” nor “data first.” The solution is: both at the same time.

Sequential — What Most Companies Do

12 months data cleansing → Start project → Data already outdated again

Result: Double the effort, delayed start, frustrated stakeholders.

Parallel — What Actually Works in Practice

Start project → Improve data quality in project context → Relevant data first

Result: Earlier value, targeted cleansing, data quality improves as a byproduct.

In concrete terms:

• Define a pilot area. Not the entire company, but one department, one location, one process. Start there, learn there.
• Start with available data. The 80/20 rule applies here too: 80% of the data is good enough to get started. The remaining 20% becomes visible once the project is running — and gets cleansed on the spot.
• Make data problems visible through the project. Only when you use a system productively do you see which data issues are truly business-critical. Most problems that look enormous in theory are irrelevant in practice. And some problems that nobody had on their radar only surface in live operations.
• Data quality as a byproduct. When employees use a system daily, they maintain data better automatically — because they see the consequences of bad data immediately. That’s more effective than any cleansing project.

What This Means in Practice

If you’re facing an ERP, DATEV, or digitalization project, ask your leadership team these three questions:

1. Which three processes cost us the most time, money, or margin each month?

The answer shows you where the biggest lever is. Not where the data is cleanest, but where the pain is greatest.

2. Where is data sitting idle — not because it’s missing, but because nobody uses it?

In most companies, 80% of the needed data already exists. It sits in Excel spreadsheets, in the ERP system, in email inboxes. The problem isn’t absence — it’s lack of use.

3. What can we start with using what we have today?

The answer is almost always: more than expected. Imperfect data that’s being used is more valuable than perfect data sleeping in a data lake.

Further recommendations:

• Keep scope radically small. First demonstrable value in 8–12 weeks, not 18 months.
• Include data cleansing in the project budget — not as a separate pre-project with its own timeline, but as an integral part of every project phase.
• Define “good enough.” What data quality do you need to start? Not perfect, but usable. The definition of “good enough” is a leadership decision, not an IT decision.

Data Quality Remains Essential

To be clear: this article is not a license for sloppiness. Migrating an ERP system with completely broken master data will fail. Setting up a DATEV interface without correct account structures will produce chaos in accounting.

The point is different: the best data cleansing happens in the context of a concrete project. Because then you know which fields truly matter. Because employees see why clean data is important. Because the cleansing has a result that someone actually uses — rather than disappearing into a report nobody reads.

Data ownership, governance rules, and quality processes belong inside the project — not as a precondition before it, but as an integral component. Standards like the DAMA DMBOK provide a proven framework for this.

Conclusion

The reflex of “data first, then project” is understandable. But it costs mid-sized companies millions each year in deferred value creation. The alternative isn’t carelessness — it’s a mixed strategy: run project and data quality in parallel. Start, cleanse, improve — don’t plan, cleanse, someday start.

Those who implement this consistently have a running project with improving data quality in three months. Those who cleanse first have an interim report.

Next Step

Facing an ERP migration, DATEV integration, or digitalization initiative — and the data question is holding you back? I help you find the right starting point and steer data quality and project success in parallel.

→ Book a free consultation

→ Or read more first: DATEV Interface Check — Self-Assessment