Roles and responsibilities are the backbone of a successful information or data governance program. To operate an efficient and effective program and hold people formally accountable for doing the “right” thing at the “right” time, it requires the definition and deployment of roles that are appropriate for the culture of the organization. To communicate effectively with people at all levels of the organization requires roles that address the existing structure of your organization. To formalize accountability for how people define, produce, and use data requires a solid role-based foundation. As I said, roles are the backbone to a successful program.
With this article, I am providing an updated list of roles and responsibilities (last updated two years ago) that should be considered at each level of the organization. The model I share is often referred to as the “pyramid diagram”, the “operating model”, the “steward diagram”, or my basic model of roles and responsibilities. The model is shared below.
Reading the Operating Model
The model is made up of the levels of authority that typically exist within an organization. These levels include the Executive level, the Strategic level, the Tactical and Operational levels, as well as the Support level.
Working our way from the bottom to the top of the triangular, the Operational level represents the needs of the specific business unit or function and does not take into consideration cross-business unit decision making. At the next level up, the Tactical level is where data is now viewed as a cross-business unit resource. The Strategic level represents the decision making level of the enterprise while the Executive level is there to guide and steer the organization. The names of the roles associated with level must be adjusted depending on organizational culture and the appropriate context of data governance. [For example the term “Owner” may not be accepted because it means something different to the organization.]
The space inside each level of the triangle represents the rough percentage of instances that organizations expect decisions to be made about the data at this level; decisions should be made at the operational level if the decisions only affect that level of the organization. This means that the majority of the decisions will eventually be made within the Business Units that make up the operation level of the pyramid. Therefore, the amount of space within the operational level of the pyramid is greater than the tactical or strategic levels of the pyramid.
When decisions cross over Business Units, these decisions are made at the tactical or strategic levels of the pyramid, or part of an organization, where individuals and departments have the authority to make decisions for the enterprise regarding a certain subject area or domain of data. An example of a domain could be claims, provider, group, employee and finance, or sub-sets of these domains or subject areas.
Many organizations find the identification of the cross-functional roles to be the most difficult hurdle when developing the roles of their data governance program. At the cross-Business Unit level, the silos of data are broken down and the data is shared and extracted across Business Units. Finding the appropriate people to fill the roles associated with decision making for a specific subject matter of data is not easy. Sometimes this role is predefined through policy. At other times, this role and person is dictated from the highest level of the organization. When the strategic level does not dictate who the tactical steward is, then the role is often filled by someone who volunteers to play the role of facilitator across Business Units and who has no decision-making authority.
When this “volunteer” scenario becomes the case, data issues tend to escalate to the strategic level with more regularity. Note the arrows along the right side of the pyramid. One arrow represents a decision-making escalation path from the operational (business function) to strategic (enterprise) authority. The outer arrow represents the need for effective communications at, and between, all levels and roles of the operating model.
The escalation path does not extend into the executive level because data issues are not typically escalated to the senior-most management of an organization. For this reason, the executive level has no space within the pyramid. Organizations prefer that only five to ten percent of all decision-making is raised to the strategic level. Higher percentages often reflect a short-coming in tactical facilitation toward acceptable solutions. The space within the strategic level of the pyramid reflects the fact that five to ten percent of decisions are made at the strategic level.
Along the left side of the pyramid are the roles associated with managing and supporting the program and often include three primary components:
- The people or person that have responsibility for managing and administering the program.
- The existing functions that operate with a governance level focus like IT, Security, Risk Management, Project Management, Audit, and Legal. Some organizations have included business support functions like Marketing/Communications and Human Resources as members of the Partner or Support function of Data Governance.
- The working teams that are convened in a timely and directed fashion to complete a specific action or implementation. Examples of working teams include a business unit by business unit approach to classifying and handling sensitive data, the focus on specific sets of Critical Data Elements (CDEs) to improve understanding, quality and value, or rationalizing reports to limit the availability and access to critical data and information.
The arrows to the right of the triangle represent:
- The bi-directional data governance communications across all levels of the program.
- A data governance issue escalation path from the operational level (issues pertains to a single business unit) to the tactical level (where data is viewed as a cross business unit resource) to strategic level (where the strategic decision is made).
The bullets below define the make-up of each data governance role and provide the responsibilities associated with each role during the planning and on-going program deployment.
The responsibilities of the Senior Leadership Team (or other named Steering Committee) include:
- Identifying people in their part of the organization for Data Governance Council.
- No specific day-to-day or monthly data governance activities … except to be reported to – Data Governance Program Status.
- Support, Sponsorship, and Understanding of Data Governance.
- Data Governance / Council becomes an agenda item at meetings.
Small images provided for reference.
The responsibilities of the Data Governance Council are to:
- Become educated in what Data Governance means, how it can and will work for the organization, and what it means to embrace Data Governance and activate your Enterprise Data Stewards (Data Domain Stewards).
- Approve things that need to be approved – i.e., Data Policy, Data Role Framework, methods, priorities, tools, etc.
- Push Data Governance into their areas by actively promoting improved data governance practices.
- Make decisions at a strategic level in a timely manner given the appropriate knowledge to make that decision.
- Meet regularly (or send alternate), read minutes to stay informed of Data Governance Program activities.
- Identify and approve of pivotal data governance roles including cross-enterprise domain stewards and coordinators.
- Advise the Data Governance Council Owner in applying data governance to Risk Management, Compliance, Business Unit-specific governance interests.
- Influence change.
The responsibilities of the Data Domain Stewards (one per data domain or subject area of data) are:
- Responsible for ‘enterprise’ management of a domain of data.
- Identified by position (or person) as part of a single business unit or functional area.
- When acting in role of data domain steward, affiliation to business unit becomes secondary.
- Involved/facilitator in cross business unit resolution of data definition, production and usage issues.
- May or not be the authority (decision maker). Depends on position in the organization.
- Responsible for escalating well-documented issues to the strategic level with or without recommendation.
- Responsible for documenting data classification rules, compliance rules, business rules for data in their domain (may delegate this).
- Responsible for making certain the rules are communicated to all stakeholders of data in that domain (may delegate).
- Responsible for participating in tactical groups (with other domain stewards, steward coordinators, and operational stewards) for finite periods of time to address specific issues and projects related to their domain and business unit.
The responsibilities of the Data Steward Coordinators (one per unit, division or functional area) are:
- Act as the point communications person for distributing rules and regulations per domain of data to the operational stewards in their business unit (and making certain that the operational data stewards understand the rules & risks).
- Act as the point communications person for their business unit to document and communicate issues pertaining to specific domains of data to the proper data domain steward.
- Act as the point person in the Common Data Matrix (or data steward repository) regular change control process.
- Identify the operational stewards of data per domain for their business unit. This typically requires research and inventory time for the Data Steward Coordinator.
- Work alongside the Data Domain Stewards and operational data stewards on specific Tactical Data Steward teams that are set up for the duration of issue resolution or project focused task.
- The Data Steward Coordinator typically has no decision making authority but plays a pivotal role in data governance and data stewardship success.
- In the Common Data Matrix (CDM), they should fill in the operational data stewards per domain for the domains in which their business unit are stakeholders. This may require the coordinator to research exactly how and what data is being defined, produced and used in their business unit.
The responsibilities of the Operational Data Stewards include:
- Defining the data that will be used by the organization, how that data will be used, and how that data will be managed. – Data Definers
- Producing, creating, updating, deleting, retiring, archiving the data that will be managed. – Data Producers
- Using data to perform their job and processes.
- Integrity of data usage. – Data Users
- Participate in creating/reviewing/approving data definitions.
- Participate in the integrity and quality of data definition.
- Producing, creating, updating, deleting, retiring, archiving data.
- Integrity and quality of the data created or updated in their department or process.
- Following the rules associated with identifying and classifying data access levels.
- Identifying and documenting regulatory and legal/risk issues.
- Supporting / sharing knowledge with other stewards.
- Communicating new / changed business requirements to individuals who may be impacted and can influence change.
- Communicating concerns, issues, and problems with data to the individuals that can influence change.
The responsibilities of the Data Governance Administrator, Data Governance Office or Data Governance Planning/Program Team are:
- Planning Team evolves into the Program Team.
- Participate in Data Governance Program Development.
- Architect Solution & Framework.
- Assist in Administering the Program.
- Facilitate the Data Governance Council meetings.
- Participate in the Delivery of Education, Awareness & Mentoring Materials.
- Report Results to Data Governance Council.
- Participate in the Development & Delivery of Data Governance Policies, Standards, Guidelines, and Procedures.
- Assist in Defining Data Quality Metrics for Periodic Release.
- Support Data Quality Issue Analysis & Remediation for “Strategic” Data.
- Conduct Audits to Ensure Components are in Place for Improving the Program.
The responsibilities of Information Technology (Data/System SMEs) as an example of Data Governance Partners are:
- Focus on Consistent Protection/Classification of Data by Data Classification.
- Responsible for Technical Data Handling to Meet Data Classification.
- Secure Infrastructure On Behalf of the Business Units.
- Managing Projects to assure appropriate Data Governance.
- Responsible for championing the integration of data governance within the standard project methodology.
- Ensure that policies, procedures and metrics are in place for maintaining & improving data quality and the creation, capture and maintenance of metadata.
- Ensure that all “strategic” data is modeled, named, and defined consistently.
- Ensure that projects source and utilize data from the designated system of record.
- Provide technical support for ensuring data quality.
- Provide technical support for data governance and data cleansing .
- Ensure that metadata critical to Data Governance is included and accessible.
The responsibilities of Data Governance Working Team are:
- Convened by the Data Governance Council with assistance from and facilitated by the Data Governance Administrator to address data issues or participate in data projects.
- Working Groups should be formed and engaged to:
- Improve Data Definitions / Standards for Critical Data Elements (CDE)
- Improve Data Production and Collection
- Improve Data Classification and Protection
- Improve Data Usage and Understanding of Business Data Rules
This article contains a brief description of a set of Data Governance Roles and Responsibilities, how to structure the roles into a coherent model, a description of how to read the model, and sets of roles and responsibilities associated with each level of the model. These roles and responsibilities have been used as a starting point for many Non-Invasive Data Governance™ implementations. This list of roles and responsibilities should be used as a starter list that should be adjusted to how you expect Data Governance to operate for your organization.
All images and content in this article – Copyright © 2019 – Robert S. Seiner / KIK Consulting & Educational Services