A company makes data work by connecting an important decision or service to data that is understood, fit for use, protected and reliably delivered. Buying a warehouse, catalog or dashboard does not create that operating capability. This checklist sequences the work from business questions and ownership through quality, metadata, access, product delivery and measured adoption.
Use it with the data value delivery plan, data operating model FAQ, enterprise data checklist and data usefulness guide. Start with one consequential use case and expand reusable capabilities from evidence.
1. Define the decision, user and outcome
Write the question, decision, actor, cadence and consequence. Identify the current baseline, source records and acceptable delay. The Federal Data Strategy practices begin with identifying data needs for key questions and include governance, inventory, documentation, standards and quality aligned to use. This is a strong sequence beyond government because it prevents tool-first programs.
Define success in business and data terms: fewer stockouts, faster reconciliation, better forecast error, reduced manual correction, or safer access. Name disallowed uses and affected people. Create a small use-case register with sponsor, product owner, data owner, steward, technical owner and risk reviewers. Stop initiatives that cannot name a decision or service outcome.
2. Establish an empowered data operating model
Assign accountability by domain and product. A data owner approves meaning, quality priorities and access policy; a steward maintains definitions and issue workflow; engineering operates pipelines; producers fix defects at source; consumers use data within stated conditions. Governance forums resolve cross-domain conflicts and prioritize investment rather than reviewing every field change.
The EDM Association DCAM framework emphasizes capabilities, engagement, process and auditable evidence. Use a proportionate assessment to identify gaps, but make the roadmap use-case driven. Publish decision rights, escalation and service expectations. Measure whether ownership resolves issues, not whether names fill a matrix.
| Role | Accountability | Evidence |
|---|---|---|
| Business sponsor | Outcome and investment | Baseline, target and review decision |
| Data owner | Meaning, quality and access policy | Approved definitions and exceptions |
| Data product owner | User value and lifecycle | Roadmap, adoption and support |
| Engineering owner | Reliable delivery | Tests, telemetry, recovery and change record |
3. Define meaning, quality and provenance
For each critical element, document business definition, source, grain, keys, valid values, transformations, owner, freshness, retention and quality expectations. The UK Government Data Quality Framework stresses knowing users, assessing quality across the lifecycle, communicating quality and addressing root causes. Fitness depends on use; no dataset is universally “high quality.”
Turn expectations into executable checks at source, interface and product boundaries. Measure completeness, validity, uniqueness, consistency, timeliness and accuracy where reference truth exists. Set thresholds from consequence and baseline. Publish known limitations. Route failures to an owner and capture root cause, correction and recurrence. A green dashboard without coverage and freshness context is misleading.
4. Build discoverable metadata and lineage
Create a catalog around products and decisions, not a field dump. Include description, owner, access, sample, quality, lineage, terms, update cadence and support. W3C DCAT 3 supplies a vocabulary for interoperable data catalogs, while W3C PROV-O supports interoperable provenance representation. Adopt useful standards where exchange matters.
Automate technical metadata from platforms, then add business context through stewardship workflow. Lineage should answer where a reported value came from, which transformations and versions applied, and which downstream products a change may affect. Test lineage during an incident or reconciliation; a beautiful graph that cannot trace a material number is not sufficient evidence.
5. Control access and privacy by purpose
Inventory systems, products and third parties that process data, classify sensitivity and define approved purposes. The NIST Privacy Framework is a voluntary tool for identifying and managing privacy risk. Apply minimization, role and attribute-based access, strong identities, environment separation, masking where appropriate, retention, deletion and review.
Make access requests understandable and time-bound. Record requester, purpose, dataset, fields, decision, approver and expiry. Monitor unusual use and exports. Avoid copying sensitive data into analyst extracts or test systems without control. Data sharing agreements should cover allowed use, security, quality, onward sharing, incident notice and disposition at exit.
| Control | Implementation check | Operating measure |
|---|---|---|
| Quality contract | Rules reflect intended use and consequence | Coverage, breach duration and recurrence |
| Lineage | Material value traces to source and version | Trace success during change or incident |
| Access | Purpose, approver and expiry are recorded | Overdue access and unusual export |
| Product service | Freshness and recovery are tested | Objective compliance and restore result |
6. Deliver a reliable data product
Define the product interface: table, API, stream, metric layer or report. Specify schema, semantic contract, service objective, refresh, history, access, support, change notice and deprecation. Build idempotent pipelines, observable transformations and safe backfills. Separate raw capture from governed consumption and preserve immutable source evidence where required.
Version breaking changes and identify consumers before release. Use contract tests and representative reconciliation. Provide examples and a path to report issues. Treat dashboards as user products: test comprehension, accessibility and decision fit. A metric should have one governed definition where comparability is required, with deliberate variants clearly named.
7. Drive adoption and measure value
Train users on meaning, limitations and appropriate interpretation. Embed trusted products into workflows rather than requiring people to visit another portal. Retire duplicate extracts and reports carefully after confirming consumers. Provide office hours and issue response. Incentivize producers to improve source quality, not merely downstream teams to cleanse repeatedly.
Measure active qualified users, decision cycle time, manual reconciliation, issue resolution, data contract compliance, freshness, trust survey and business outcome. Avoid celebrating catalog entries or pipeline count alone. Review whether the product changes decisions and whether benefits justify operation. Decommission unused products and preserve required records.
8. Operate a continuous data review
Hold a monthly product review covering use, outcome, quality, incidents, access, cost, changes and consumer feedback. Review cross-domain problems quarterly. Fund root-cause correction when local workarounds recur. Keep definitions and lineage synchronized with releases. Exercise recovery and rebuild for critical products.
Maintain a change calendar for source systems, schemas and business policy. Reassess use when purpose, users or sensitivity changes. Archive decisions and limitations so later teams understand context. Maturity is demonstrated by faster, safer delivery and fewer unresolved disputes, not by a one-time certification.
Example: make margin data usable across finance and sales
Finance and sales disagree on margin because discounts, returns and allocation timing differ across reports. Define the decisions first: monthly close, deal approval and product planning. Create governed measures with explicit grain, currency, treatment and effective dates. Preserve variants where decisions truly differ, but name them clearly and trace each to source transactions.
- Assign finance ownership and sales/product consumer representatives.
- Document transaction grain, timing, currency and adjustment policy.
- Reconcile a representative period against the ledger.
- Create automated completeness, duplicate and freshness checks.
- Publish lineage, limitations and approved decision uses.
- Measure reconciliation time, disputes and post-close corrections.
Deliver a certified margin product through the metric layer and approved exports. Pilot one region and compare decision time and correction with the old reports. Review every discrepancy to improve source capture or policy. Retire duplicate spreadsheets only after consumers confirm replacement and access needs.
Review evidence before expanding scope
Before expanding how a company makes data work, the accountable owner should review representative outcomes, exceptions, access, changes, operating cost, user feedback and recovery evidence. Confirm that metrics still reflect the intended business result, that known limitations are visible to users and that suppliers have not changed material behavior without evaluation. Exercise one realistic failure and reconcile the resulting records. Record the decision to scale, narrow, correct or retire the capability, including assumptions and a review date. This review keeps implementation evidence connected to authority and prevents a successful pilot from becoming an unmanaged dependency.
Before scaling to another domain, verify that the first data product can be operated without its original project team. A new steward should be able to find definitions, trace a material value, understand failed checks, grant approved access, run a backfill, restore service and contact consumers. Finance should see recurring platform, people and supplier cost, while business owners should see outcome and unresolved risk. Test a source schema change and one access revocation. Review contracts for data portability, location, subcontractors, incident notice and deletion. This readiness evidence reveals whether the organization has built a reusable capability or only a successful demonstration supported by specialist memory.
Key takeaways
- Begin with a decision or service outcome and name accountable owners.
- Define quality as fitness for a stated use and fix recurring defects at source.
- Combine automated technical metadata with business meaning and testable lineage.
- Deliver data through governed contracts, access and operating objectives.
- Measure changed decisions, trust, correction and value, then retire unused products.
Frequently asked questions
Does every dataset need a data product team?
No. Apply product discipline in proportion to reuse and consequence. Critical shared data needs explicit ownership, service and lifecycle; a temporary local analysis may need lighter controls. Inventory both so temporary assets do not quietly become unsupported enterprise dependencies.
Who should own data quality?
Producers own defects in capture and source processing, data product teams own delivered contracts, and business owners set fitness priorities. Consumers report issues and use data appropriately. A steward coordinates, but should not become the sole person expected to repair every upstream problem.
How long does a first implementation take?
A bounded product with accessible sources can reach a pilot in several weeks. Cross-domain identity, legacy quality and policy disputes take longer. Deliver one end-to-end slice while building reusable ownership, contracts, metadata and access patterns, then expand from measured use.
Conclusion
A company makes data work through a sustained operating model: important questions, accountable ownership, testable meaning, controlled access, reliable delivery and evidence of use. Start with one outcome and make every governance or platform investment earn its place in that path. Reuse what works and remove products that no longer support a decision.