The Data Lake That Nobody Trusts

All three framings are incomplete, and the history explains why: two prior programs 'delivered a dashboard and stalled' because they were infrastructure-first with no committed consumer. The lakehouse migration is the same shape and will likely meet the same fate.

Assess each:

• Lakehouse migration is a platform decision that should be consequent to a workload, not prior to it. Migrating 400 tables without knowing which 40 matter is how two-year programs happen.
• 'Clean data' is unbounded. Cleaning everything is not a project; it is an operating model. The COO is expressing a symptom (nobody trusts the numbers) rather than a scope.
• Proving the model's value is the right instinct but the CFO has set a trap: a forecast model built on this estate will produce unreliable numbers, which will 'prove' the data is bad and restart the cycle.

Recommended sequencing - anchor on the contract, not the platform:

1. Start with the 24-hour delivery-reporting obligation. It is a committed, dated, financially material use case with a known consumer (the customer) and a measurable outcome (three days → under 24 hours). It forces exactly the data ownership, freshness, and lineage work the lake lacks - but scoped to the tables that matter.
2. Use that work to establish the operating model: table ownership, freshness SLAs, and a single definition for delivery events, applied first to the ~30-50 tables in scope. This is the 'clean data' the COO wants, made tractable.
3. Then extend to forecasting and routing, reusing the now-governed tables, and only then decide whether the lakehouse migration is justified by the workload.

This gives the CFO a value case with a compliance deadline attached, which is the strongest funding argument available.

The spreadsheets are shadow infrastructure: they exist because analysts need numbers they can trust and the lake does not provide them. They encode business logic, definitions, and corrections that the official estate lacks. Three implications:

1. They are the de facto definition of 'correct.' Any program that declares the lake authoritative without reconciling against the spreadsheets will be judged wrong by the people who use them.
2. They are a risk and an asset. They are ungoverned, person-dependent, and a single-analyst failure away from breaking reporting - but they also contain the rules the lake is missing.
3. They signal that trust, not technology, is the constraint. Two prior programs likely failed here: they built a source of truth nobody adopted.

Retirement approach:

• Inventory and classify the spreadsheets: which support the contract obligation, which feed decisions, which are duplicates. Expect a long tail of low-value ones.
• Extract the logic. For each material spreadsheet, document the transformation and the reason it exists. Many will reveal a definitional conflict (e.g., three definitions of 'on-time delivery') that must be resolved by a business owner, not by data engineering.
• Migrate in value order, with the spreadsheet's owner as the acceptance tester. A spreadsheet is retired when its owner stops opening it, not when a replacement is built.
• Freeze, don't delete. Lock changes to migrated spreadsheets and route new requests to the governed source, so the shadow estate stops growing.

Measure success as the count of actively used spreadsheets, not the count built.

The survey result - 60% of tables unowned, 35% without freshness guarantees - is a governance gap that cannot be closed by the data team alone, because ownership is a business accountability.

Model:

• Domain ownership. Assign each in-scope data domain to a business executive (e.g., delivery events to Operations, cost to Finance) who is accountable for definition, quality, and fitness for use. The data team provides platform and tooling; it does not own business meaning.
• Tiered criticality. Not all 400 tables deserve the same rigor. Tier 1 (contract, financial, regulatory) gets named owners, documented SLAs, and monitored freshness. Tier 2 gets ownership and best-effort. Tier 3 is catalogued and left alone. This makes the ask finite.
• Freshness as a published SLA, with the consumer's need defining the target, and automated alerting when breached. 'No guarantee' becomes 'guaranteed within X, alerted at breach.'
• A data contract between producing and consuming domains for Tier 1 sources, specifying schema, freshness, and change notification.

Getting acceptance:

• Attach ownership to a consequence the leader already cares about. Operations owns delivery data because the contract penalty is theirs; that is a much easier conversation than 'please own your data.'
• Start with the leaders who have a burning use case, and make them reference customers. Peer proof moves executives faster than a mandate.
• Make the cost of non-ownership visible - the three-day reporting process, the reconciliation hours, the audit findings.
• Have the CEO or COO sponsor the model explicitly, because a VP of Data cannot assign accountability to a peer.

Avoid launching a 400-table ownership campaign. It will stall like the prior programs. Scope to Tier 1 and expand on evidence.