Data Quality Without a Budget: Starting with a Small Win
No budget for data quality? You don't need one to start. See how to begin with one table, one check, and one small win.
Why Your Data Contracts Are Useless (And How to Fix It)
Many data engineering teams already have a contract.yaml sitting in their repository. It has a schema, types, maybe even descriptions. The problem is that nobody enforces it. The contract lives in Git, while data keeps flowing: with nulls in a required column, negative order_id, or a birth date in the future. The contract is documentation,…
Principles of Data Quality – Definition, Detection, Cleansing
Data quality principles are straightforward: define what constitutes bad data, detect data issues, and remediate those issues. These three principles might seem intuitive, yet many data teams find it challenging to implement them effectively. The core difficulties often stem from a lack of shared understanding regarding the definition of data quality and the practical application…
Many data quality teams have no budget. No dedicated platform, no team of data stewards, no business sponsor who sees ROI from checks. What they do have is data that breaks every day, and consumers who are losing trust in it. In that situation, the question “how do we convince the organization to invest in data quality” is the wrong question. A better one is: what can we do this week, without a budget, that someone will actually notice?
This article shows how to start with a small win instead of waiting for a budget that may never come.
Table of Contents
Why a small win works better than a business case
The traditional approach to data quality assumes you prepare a business case: identify problems, estimate the cost of bad data, compare it to the cost of fixing it, get budget, implement a platform. That works in organizations that already have a data quality culture. In others, it ends on a slide deck.
The problem is sequencing. Budget usually appears after someone sees a concrete, measurable result. So instead of a year-long plan, you need to start with one table, one check, and one person who notices the difference. In our article on building a use case for data quality, we state that “initial data quality initiatives should focus on quick wins” and target areas with low reliability and high business impact.
Step 1: Find the one table that hurts the most
Do not start with an inventory of every data source. Do not start with interviews across the entire business department. Start with the question: which table or report generated the most “the numbers don’t match” complaints this month?
That is your starting table. It does not have to be critical to the entire company. It just has to be visible, and someone has to make decisions based on it. In the DQOps table prioritization framework, we classify tables as critical, high, normal, and low priority. To start, one table from the “high” or “normal” category that generates real operational pain is enough.
Step 2: Run free profiling before you ask for anything
Before you ask for budget, you need evidence. Not opinions, not “I think,” but concrete numbers: what percentage of values in the email column are empty, how many rows have a future date, how many records have a duplicated identifier.
DQOps can be run locally or on-premises without a SaaS license . That lets you profile data and show results before anyone approves any spend. In a LinkedIn post, Piotr Czarnas puts it plainly: “Because data profiling comes before getting a budget for a data quality project, you will need a free data quality platform to profile the data” .
The output of this step is not a board report. It is a few sentences and one screenshot: “In table X, 23% of records have a non-empty email, but the format is invalid. Here are five examples.” Concrete examples work better than abstract metrics.
Step 3: Configure one check and connect it to a notification
A small win does not require a hundred checks. It requires one check that actually catches something. Pick one rule most closely tied to the pain from Step 1:
nulls_count on a column that should never be empty
text_match_date_format_percent on a date column with inconsistent formatting
duplicate_count on a column that should be unique
DQOps defines checks as YAML files, so you can version them alongside your pipeline. Run the check daily and route the notification to a channel the team actually reads: Slack, Teams, email, whatever. The goal is not a dashboard nobody opens. The goal is for someone to learn about the problem on the day it appears, not three weeks later.
Step 4: Measure the difference and show it to one person
After two weeks of running the check, you will have a history: how many times it failed, what the invalid values were, whether the problem recurs. This is the moment when the “small win” becomes an argument.
Do not try to convince the entire organization. Show the result to the person who felt the pain from Step 1 most acutely. If it is an analyst who manually corrected the report every week, show them the check caught the problem before publication this week. If it is a data engineer who lost hours debugging, show them how many times the check pointed to the source of the error.
In a post about ownership, Piotr writes that data quality is a “team effort” and that “whoever can improve data quality on their side should do it” . A small win is not about convincing everyone. It is about convincing one person that the next step is worth taking.
Step 5: Expand only when someone asks “what about table Y?"
The most common mistake in data quality projects without a budget is trying to do everything at once. You end up with 200 checks, half of which generate false alerts, and the other half of which were disabled after a week.
Instead, wait until someone on the team asks: “Does this check also work on table Y?” That is the signal that the small win worked. Then expand by one table, not by an entire platform. The DQOps prioritization framework helps decide which table should come next, but the decision belongs to the team that already sees the value .
Summary
Data quality without a budget is not impossible. It is just different. It does not start with a platform, a business case, or a sponsor. It starts with one table, one check, and one person who notices the difference. The budget, if it ever comes, will come later. And if it does not, you will still have less bad data than you had last month.
Data quality best practices - a step-by-step guide to improve data quality
- Learn the best practices in starting and scaling data quality
- Learn how to find and manage data quality issues
What is the DQOps Data Quality Operations Center
DQOps is a data quality and observability platform designed to monitor data and assess the data quality trust score with data quality KPIs. DQOps provides extensive support for configuring data quality checks, applying configuration by data quality policies, detecting anomalies, and automatically finding patterns using machine learning. DQOps supports over 150+ data quality checks, which cover all popular formats used in data conformance testing.
DQOps is a platform that combines the functionality of a data quality platform to perform the data quality assessment of data assets. It is also a complete data observability platform that can monitor data and measure data quality metrics at a table level to measure its health scores with data quality KPIs.
You can set up DQOps locally or in your on-premises environment to learn how DQOps can monitor data sources and ensure data quality within a data platform. Follow the DQOps documentation, go through the DQOps getting started guide to learn how to set up DQOps locally, and try it.
You may also be interested in our free eBook, “A step-by-step guide to improve data quality.” The eBook documents our proven process for managing data quality issues and ensuring a high level of data quality over time. This is a great resource to learn about data quality.
