Learning Objectives
By the end of this lesson you will be able to:
- Define the four main types of Key Data Stakeholder (KDSH)
- Explain the difference between a Data Owner and a Data Steward
- Describe how KDSHs are found and engaged throughout the project
What Is KDSM?
Key Data Stakeholder Management (KDSM) is the PDM process for finding, documenting, and maintaining the people the project needs to engage with across the business and technical landscape.
This is not stakeholder management in the generic project management sense. It is specifically about the people who have authority over data - the authority to sign off a decommissioning certificate, to make a data quality decision, to override a mapping rule.
The Key Data Stakeholder Types
Data Owners
Definition: Those people within the enterprise or outside of it who have a legitimate right to prevent the migration going ahead.
Equivalently: the people who will sign the system decommissioning certificate.
Data Owners are the most important stakeholders in the project. They may not be the most senior people in the organisation - often they are operational managers whose day-to-day work depends on the system being migrated.
Finding the real Data Owner (as opposed to the nominal IT system owner) requires asking the question: “Who has to say yes before this system can be switched off?”
Business Domain Experts (BDEs)
Selected by Data Owners to represent their interests in day-to-day project work. BDEs are frontline staff with direct, hands-on contact with the legacy data stores. They attend DQR meetings, validate mappings, answer questions about business rules, and make decisions within the scope delegated by their Data Owner.
BDEs are the interface between the project team and the business. They are not the same as Data Owners - they operate under delegated authority.
Technical System Experts
People with technical expertise in specific systems - the legacy databases, the target application, the network infrastructure. This category includes target system specialists (on the supplier side, in an embedded PDM engagement) as well as legacy system administrators.
Migration Analyst
The PDM-certified migration lead. The Migration Analyst is the person responsible for running the PDM process on the client side - facilitating DQR meetings, maintaining the KDSH map, and acting as the bridge between the business engagement and technical workstreams.
Other Data Stakeholders
In addition to the four primary types, KDSHs may include:
- Regulatory stakeholders - industry regulators with requirements for the migrated data
- Architectural stakeholders - enterprise architects who must approve structural decisions
- Local stakeholders - people with project-specific authority (e.g. a finance director who must sign off financial data quality)
KDSHs Are Not Data Stewards
A point of clarification: KDSHs are not Data Stewards in the enterprise governance sense.
Data Stewards are typically responsible for ongoing data quality management after a system is in production. KDSHs in PDM are specifically responsible for the data during the migration. The roles may overlap, but they are not the same - PDM requires a more precise definition to create effective Business Engagement.
Finding KDSHs
The initial KDSH list is provided in the Migration Strategy Document. Additional KDSHs are discovered through:
- System Retirement Plans - the interview process for BTR always identifies the Data Owner and often reveals additional BDEs
- Landscape Analysis - discovery of new LDS reveals their owners
- DQR process - data quality issues that cannot be resolved without a specific business expert reveal new KDSHs
- GAM - mapping decisions that require business context point to the right business expert
Each KDSH record captures:
- Name and title
- The LDS (or sub-part of an LDS) they relate to
- Their KDSH role
- Contact details
- Degree of engagement (SRP involvement, DQR board attendance)
Key Takeaways
- The four primary KDSH types are: Data Owner, Business Domain Expert, Technical System Expert, and Migration Analyst
- Data Owners are defined by their authority to prevent the migration - not by their job title or position in the hierarchy
- KDSHs are not Data Stewards - PDM uses a more precise definition to drive effective Business Engagement
- New KDSHs emerge throughout the project; the KDSH map is a living document
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 08 - Key Data Stakeholder Management