Data Quality Roadmap: 16-Week Template With Rules, Owners and Scorecard
9 min read ยท 2026-10-25
A data quality roadmap is a plan that tells you which data to fix first, how you will measure its quality, who owns each fix and when the business will see results. It turns a vague complaint like "our data is bad" into a short list of critical data elements, measurable rules, named owners and a scorecard that improves month by month.
The template below runs 16 weeks in six phases. It starts small, with the few fields that break the most important reports and processes, and ends with monitoring and a monthly review that keeps quality from sliding back. You also get a filled-in example for customer master data, a roles list, the scorecard to show leadership and the mistakes that make data quality programs fade after the first cleanup.
The roadmap at a glance
Goal: The critical customer and product data elements have agreed quality rules, named stewards, automated monitoring and a monthly scorecard that leadership reviews. Duration: 16 weeks
Scope and business impact (Weeks 1-2)
Link data quality to the business problems people already feel.
- Collect the last few months of data complaints: failed invoices, returned mail, wrong reports, duplicate customer records.
- Ask the heads of finance, sales operations and customer service which processes break when data is wrong.
- Choose one or two data domains to start with, such as customer and product.
- Name an executive sponsor who will settle disputes about data ownership.
Milestone: A one-page scope that names the domains, the business processes affected and the sponsor, signed off by that sponsor.
Critical data elements and owners (Weeks 3-4)
Narrow the work to the fields that matter most and give each one an owner.
- List the critical data elements in scope, such as customer legal name, billing address, tax ID, product code and unit of measure.
- For each one, write a plain definition, the system of record and the processes that use it.
- Assign a data owner (a business leader) and a data steward (the person who handles day-to-day issues) for each domain.
- Record everything in a simple data catalog or a shared sheet that everyone can find.
Milestone: A list of critical data elements with definitions, systems of record, owners and stewards, approved by each owner.
Profiling and baseline (Weeks 5-7)
Measure how good or bad the data is today.
- Profile each critical element for blanks, invalid formats, duplicates and values that disagree between systems.
- Group the findings by quality dimension: completeness, validity, uniqueness, consistency, accuracy and timeliness.
- Write each measure as a score, such as the share of active customers with a valid billing address.
- Share the baseline with the stewards and confirm that the measures match what they see in daily work.
Milestone: A baseline scorecard with one or more measures per critical element, reviewed by every steward.
Rules, thresholds and root causes (Weeks 8-10)
Agree on what good looks like and why the data goes wrong.
- Turn each measure into a rule with a target threshold agreed with the data owner.
- Trace the biggest issues back to their source: a free-text field, a missing validation, a bad integration or an unclear process.
- Rank fixes by business impact and effort, then pick the top five.
- Write a short fix plan for each, naming who changes what in which system.
Milestone: A ruleset with thresholds approved by data owners and a ranked fix plan with owners and dates.
Fix at the source and clean up (Weeks 11-14)
Stop new bad data from coming in, then clean what is already there.
- Add validation at the point of entry, such as required fields, drop-down lists and address checks in the CRM or ERP.
- Fix the integrations that overwrite or drop values between systems.
- Run a one-time cleanup of existing records, starting with active customers and products.
- Merge duplicate records with a documented survivorship rule that says which value wins.
- Update the data entry instructions and train the teams that create the records.
Milestone: Top five fixes live in production and the cleanup finished for active records, with scores rechecked against the baseline.
Monitoring and operating rhythm (Weeks 15-16)
Keep quality from sliding back once the project team moves on.
- Schedule the rules to run automatically and send alerts to the steward when a score drops below its threshold.
- Set up an issue log where anyone can report a data problem, with a target response time.
- Start a monthly data quality review with owners and stewards.
- Pick the next domain for the following quarter.
Milestone: Automated monitoring live, issue log open and the first monthly review held with the scorecard.
Example: a data quality roadmap for customer master data
Picture a B2B company where invoices bounce because billing addresses are missing, sales and finance disagree on how many customers they have, and the same customer appears three times in the CRM. The CFO wants it fixed before the next audit.
Here is how the 16 weeks could look. Each line names the owner and the milestone that proves it happened.
- Weeks 1-2 (owner: data governance lead): scope set to customer data in the CRM and ERP, with failed invoices as the main business impact. Milestone: scope signed by the CFO.
- Weeks 3-4 (owner: finance controller as data owner): twelve critical elements defined, including legal name, billing address, tax ID and payment terms. Milestone: element list approved.
- Weeks 5-7 (owner: customer data steward): profiling shows many records with no billing contact and many likely duplicates. Milestone: baseline scorecard reviewed.
- Weeks 8-10 (owner: CRM administrator): root cause found: sales reps create accounts in the CRM without a tax ID, and the ERP sync creates a new record each time. Milestone: fix plan approved.
- Weeks 11-14 (owner: CRM administrator and integration developer): tax ID made required, duplicate check added before account creation, sync rule fixed, duplicates merged. Milestone: duplicate score back under threshold.
- Weeks 15-16 (owner: data governance lead): rules scheduled weekly, alerts go to the steward, first monthly review held. Milestone: scorecard shared with the CFO.
Who owns what
Data quality is a business problem with a technical side, not the other way around. If IT owns everything, rules get written that nobody in the business agrees with, and fixes stop at the database.
Use these roles and write them next to each domain in your catalog. In a small company, one person can be the steward for several domains.
- Executive sponsor: funds the work and settles disputes about who owns a data domain.
- Data owner: a business leader who approves definitions, rules and thresholds for a domain.
- Data steward: handles daily issues, reviews alerts and coordinates fixes with system owners.
- Data governance or data quality lead: runs the roadmap, the scorecard and the monthly review.
- System owners and administrators: change validations, forms and integrations in the CRM, ERP or other source systems.
- Data engineers: build the profiling, rule checks and alerts.
How to write data quality rules people accept
A good rule is specific, testable and tied to a business use. "Customer data must be accurate" is not a rule. "Every active customer has a billing address with a valid postal code" is. Write each rule with the element it checks, the condition, the records in scope and the target.
Set thresholds with the data owner, not alone. A threshold that is too strict creates constant alerts that people ignore. One that is too loose hides real problems. A common starting point is to set the first target a little above today's baseline and raise it each quarter as fixes land.
- Completeness: required fields are filled for records in scope.
- Validity: values follow the format or list allowed, such as country codes.
- Uniqueness: no duplicate records for the same real-world customer or product.
- Consistency: the same value matches across systems, such as payment terms in CRM and ERP.
- Timeliness: data is updated within the agreed time after a change.
The scorecard and how to present it to leadership
Leadership does not need every rule. Show one score per domain, the trend since the baseline, and the two or three issues with the biggest business impact. Put the scorecard on one slide with domains as rows and the last three months as columns.
Tie every number to a business effect people recognize, such as invoices sent back or orders held for missing data. End with the decisions you need, for example making a field mandatory in a sales process or giving a steward time each week. Leave the full rule list and profiling details in the appendix.
Risks and dependencies
Data quality work depends on other teams changing their systems and habits. List the risks at the start and give each one an owner and a fallback.
Review this list at every monthly meeting and add new risks as the scope grows.
- Source system changes need a release slot: owner, system owner. Fallback: run the cleanup first and add validations in the next release.
- Sales or service teams resist new required fields: owner, data owner. Fallback: start with a warning before making the field mandatory.
- No clear owner for a shared domain: owner, sponsor. Fallback: sponsor names an interim owner until it is settled.
- Cleanup takes longer than planned: owner, steward. Fallback: clean active records first and archive the rest.
How to adapt it
If you are preparing a migration to a new ERP or CRM, put this roadmap before the data migration, not after. Clean and deduplicate the data in the old system so you do not move the problems into the new one.
In a larger company, run one domain per quarter and keep the same rhythm: scope, elements, baseline, rules, fixes, monitoring. In regulated industries, map your rules to the reporting or audit requirements that depend on the data, and confirm those requirements with your compliance team.
Common mistakes to avoid
- Trying to fix all data at once spreads the team thin, so start with the few critical elements that break key reports or processes.
- Running a one-time cleanup without fixing the source means the bad data comes back, so add validation at the point of entry first.
- Letting IT set rules alone produces targets the business ignores, so have each data owner approve definitions and thresholds.
- Reporting quality scores with no business effect gets no attention, so link each score to a process people care about, like invoicing.
- Assigning stewards with no time to do the work leaves alerts unread, so agree a few hours per week for the role with their manager.
- Treating data quality as a project that ends leads to slow decay, so keep the monthly review and the scorecard after the roadmap finishes.
Frequently asked questions
What is a data quality roadmap?
It is a phased plan to measure and improve the quality of the data a business depends on. It names the critical data elements, the rules and targets, the owners and stewards, the fixes and the monitoring. It turns data quality from a complaint into tracked work.
What are the main data quality dimensions?
Commonly used dimensions are completeness, validity, uniqueness, consistency, accuracy and timeliness. Most teams start with the first four because they are easiest to measure automatically. Pick the dimensions that match how the data is used rather than tracking all of them.
Who is responsible for data quality?
The business owns it. A data owner in the business approves definitions and targets, and a data steward handles daily issues. IT and data engineers build the checks and fix the systems, and a governance lead runs the process.
How do you measure data quality improvement?
Take a baseline score for each rule before you fix anything, then rerun the same rules on a schedule. Report the trend per domain and link it to business results such as fewer failed invoices. Keep the rule definitions stable so the trend means something.
How long does a data quality program take?
A first domain can go from scope to monitoring in about a quarter if owners are named early. After that, most teams add one domain per quarter. Data quality never fully ends, because new systems and processes keep creating new data.