Data ownership is one of those terms that gets used constantly in data migration projects and understood barely at all. Let me be direct about what it actually means - and more importantly, what it doesn’t.
Data ownership is a metaphor, not a statement of legal exactitude. The front-line staff and managers we talk about as “data owners” do not own organisational data in any legal sense. The organisation owns its data. What these individuals hold is custodianship - the obligation to protect data from willful or negligent damage, and the authority to create, transform, and destroy individual data items within established frameworks.
They do not control data definitions. That falls under technical metadata governance. Understanding this distinction matters, because conflating custodianship with ownership creates false expectations on both sides.
Where projects go wrong
The typical pattern on data-centric projects is this: the technical team gathers data samples, builds a metadata model, and largely dismisses the locally-developed solutions they encounter along the way - the Access databases, the spreadsheets, the manual workarounds that actually run the business day-to-day.
The consequences are predictable. Users feel excluded from decisions that directly affect their work. When solutions are eventually presented, they diverge from what users expected, because the technical team was solving a different problem. Users don’t understand the compromises that were made, because no one explained them. The technical team has effectively claimed de facto ownership of data they don’t understand the business meaning of.
Then, when the project needs to assign formal data owners, it’s too late. The relationship is already damaged. New owners are assigned without adequate explanation or preparation, and without the context they need to do the job.
Two levels of engagement
In PDM, we address this at two distinct levels, and both need to start from day one.
At the operational level, the answer is the Data Quality Review process. Rather than presenting business stakeholders with a model and asking them to validate it - which is asking them to find errors in something they didn’t build - the DQR process makes them co-builders. The board brings business and technical stakeholders together regularly. Decisions are broken into manageable increments rather than presented as a finished whole. By the end of the project, you have not just resolved the data quality issues - you have built a functioning mechanism for the ongoing business-technical relationship. That infrastructure survives the migration.
At the senior level, the framing needs to shift entirely. Do not talk about data. Talk about decommissioning. A senior manager will not engage with a conversation about metadata governance or ETL mappings. But they will engage very quickly with a conversation about which systems are going to be switched off, when, and who has to sign the authorisation. That is a conversation about their budget, their risk, and their name on a decision.
By identifying early who has the authority to sign off on system retirement and engaging them from project inception, you develop self-certified data owners who understand the constraints - not because you explained the technical detail, but because they participated in the business decisions. They understand the “why” in terms that are relevant to them.
Treating colleagues as team members
The core principle behind both approaches is the same: business colleagues are not stakeholders to be managed. They are team members to be engaged. The difference sounds subtle but it changes everything about how you run the project.
When you treat someone as a stakeholder, you communicate at them. You present. You seek sign-off. You manage expectations. When you treat them as a team member, you work with them. They are in the room when decisions are being made. Their knowledge shapes the model, rather than being used to validate a model built without them.
This is not just good project management. It is the only way to build genuine data ownership - the kind that persists after the project ends and the external team has gone home.
Start both levels of engagement on day one. Not after the technical discovery is complete. Not after the model is drafted. Day one.