Chapter 2—Basic Steps to Establishing Data Governance

Ideally, a good data governance system will be in place before LDS development begins. However, if your organization has broken LDS ground without establishing an effective governance structure, it is never too late to start. And, even if your agency has implemented a governance structure, data governance is an iterative process that can always be improved.

	Gauge your governance
How governed is your organization? The Data Administration Newsletter offers a data governance test to help you evaluate your agency in eight areas of data governance. The test is available at http://www.tdan.com/view-articles/10149 and is geared towards building the case for data governance to leaders of your organization.

Although no single approach is best for implementing a data governance initiative, some key action steps should always be taken on the road to good data governance. Normally, chief information officers (CIO) initiate the data governance plan. However they, or other leaders, come to realize their organization would benefit from better data governance, they should begin with a careful and honest appraisal of the agency’s approach to data management, weighing the enterprise’s current levels of coordination. For tools to help in this period of reflection, see "Gauge your governance" above.

After this stage of self-assessment come some key steps. Firstly, high-level executive support should be sought, followed by the assignment of key responsibilities to staff members and the formation of several groups central to managing and implementing the initiative. Data governance structures range from basic to elaborate in terms of personnel who serve the various functions (see chapter 3). However, the key action steps in a minimal, core data governance structure are:

1. Seek executive support for the initiative.
2. Create a Data Policy Committee.
3. Assign a data governance coordinator.
4. Identify data stewards.
5. Create a Data Governance Committee.
6. Identify, prioritize, and resolve critical data issues.
7. Form working groups of data stewards as needed.

In this chapter, the terms "data steward" and "data owner" are used to describe staff roles within a data governance structure, and do not imply technical or legal ownership. However, these terms are sometimes used elsewhere with meanings different from those applied here. For instance, by "owner," real ownership of the data is not implied here in the way the Family Educational Rights and Privacy Act (FERPA) outlines. That is, at an organizational level, a state education agency (SEA) may be considered a data steward when managing data on behalf of a district, in this case the data owner. Or, similarly, a district might be referred to as a "data steward" for managing data from its schools, which are the "data owners" at this more granular level.

1. Seek executive support for the initiative

Appeal to agency leadership to gain buy-in for the data governance initiative. The specific leaders who should be on board will vary depending on the state’s size and staff. In small states, support might come from the education chief; while in bigger states the appropriate executive might be on the chief’s staff, perhaps an assistant commissioner or deputy. Communicate the costs of the status quo and the benefits that will result from greater coordination. Executives must understand the value of the agency’s data and the need to ensure effective management of those information assets, and to improve quality and security. To gain support, present qualitative and, ideally, quantitative costs of poor data, redundant efforts, and insufficient security. Stress the tangible benefits of a more strategic, enterprise-wide approach to data management that coordinates policies, processes, and architecture to improve data quality; aligns work across the agency and streamlines operations; more effectively protects the data; and shares information in a more systematic and timely manner (NASCIO 2008). In making your case for data governance, try the following compelling arguments.

2. Create a Data Policy Committee

The CIO should convene a group of executive management staff that includes the education chief (or other high-level agency staff member), the data governance coordinator, and executive leaders from each program area with a data steward. Rather than creating a new group, identifying an existing group that includes these members and asking them to occasionally focus on data governance may be preferable. This group’s main roles will be to establish the data governance policy; and to address issues that require executive support, such as those that affect multiple program areas and/or affect major agency reports or deliverables. (For a more detailed description of this group, see chapter 3.)

3. Assign a data governance coordinator

Assigning responsibility for overseeing the data governance initiative to one individual is absolutely critical. This staff member, the data governance coordinator, should be the "catalyst" for coordinating the data governance initiative, setting a cohesive action plan, and tirelessly pushing the process forward. Significant culture change must occur for data governance to take hold and make a difference in an agency. In fact, many initiatives fail because no single individual is in charge of making sure that the roles, responsibilities, and processes of the initiative are being followed on a daily basis. In the search for a coordinator, leaders may look for the following:

• Tenacity. This individual must give the data governance process momentum,setting goals and constantly following up on progress to keep the work moving forward.
• Strong analytical skills.The coordinator must identify areas of needs and the players needed to address them.
• An ability to see the forest and the trees.This staff member should be able to see the overarching goals of the organization, as well as the details required to meet these goals.
• An understanding of technology.The coordinator should understand technology and be able to bridge the divide between program area staff and IT.
• An education background.This individual must understand why the organization is actually collecting the data and why they matter (it’s about the students, not the data).
• Good mediation and communication skills.This staff member must be able to bring people together to work through difficult and sometimes contentious issues.

(For a more detailed description of this role, see chapter 3.)

4. Identify data stewards

Identify areas of data and assign a data steward to each one. Articulate specific responsibilities, making each and every data element the responsibility of a single steward. For example, each data steward should be responsible for data elements, rather than for databases. Data stewards should “own” specific contents of the system regardless of where the data physically reside (e.g., on a desktop, in a database, or in a central LDS). A clear process should be created for identifying data stewards. For instance, leaders may look for staff who

• have business subject matter expertise and work directly with data (not supervisors);
• are knowledgeable about data and their educational context, i.e., the programs and policies (preferably not techies);
• serve as points of contact for districts’ questions about a program area’s data;
• are frequent users of data and are comfortable with databases and querying;
• prepare data for federal and/or state collections;
• are detail-oriented and understand how to review data for accuracy; and
• appreciate the value of quality data.

Of course, many education agencies will not have personnel with all of these abilities in every program area. But, as a general practice, rather than hiring new staff to serve as data stewards, start with existing personnel and provide support to grow necessary skill sets and knowledge. Try to identify the best “fit” possible to lessen training requirements. The data governance coordinator should be responsible for identifying gaps in knowledge and skills, and for providing necessary professional development and coaching. (For a more detailed description of this role, see chapter 3.)

5. Create a Data Governance Committee

Form a cross-area group of data management staff that includes the data governance coordinator, data stewards, and other key staff members. This group will be the core of the data governance process, and will effect most of the collaboration and decisionmaking. The data governance coordinator should chair the group and oversee the agenda. Early in its formation, the group should collectively agree upon a mission statement, which should include the identification, documentation, prioritization, and resolution of critical data issues; and to core goals and objectives (see appendix D). The committee should then meet frequently, perhaps monthly, to fulfill its stated mission. The coordinator and the data stewards should contribute agenda items for these meetings. Agenda items may include

• federal reporting updates (e.g., from the EDFacts coordinator);
• technology updates, including any IT problems affecting data transmission or reporting;
• LDS project updates; and
• time for any member to raise issues not on the agenda.

(For a more detailed description of this role, see chapter 3.)

6. Identify, prioritize, and resolve critical data issues

	Document everything!
Every data governance detail should be documented. For example, who’s responsible for what? When are deliverables due? What are the critical data issues and what’s the status of their resolutions? What are the standard procedures? Documentation helps keep the work on track, prevents confusion, and allows staff to replicate activities from year to year and in spite of turnover.

At each Data Governance Committee meeting, members should work to identify, prioritize, and resolve critical data issues, maintaining a log to track progress. Critical data issues are the organization’s data problems that must be addressed if the committee is to achieve its core goals. One data steward should be responsible for each critical data issue and, at each monthly meeting, should update the group on progress made towards its resolution. At first, the data governance coordinator will likely identify many of the critical data issues. But as the process matures, data stewards should identify most of the issues. Examples of data issues that might be deemed “critical” are:

• a data collection that creates significant burden for school districts due to timing, collection mechanism, or duplication with other collections;
• reporting linked to funding that has been late, incomplete, or inaccurate; and
• high profile reporting that has been late, incomplete, or inaccurate.

Prioritize these issues based on factors such as

• time sensitivity;
• the number of program areas affected; and
• the data’s importance or how often they are used for federal reporting.
(Chatis Consulting)

Master data management

Master data management (MDM) refers to the ongoing process of identifying the authoritative source of data and ensuring that this source is consistently used to feed other data systems, or to populate the agency’s central data store; as well as for reporting, dissemination, and analysis. In this way, it is the answer to the “collect once, use many times” challenge. When key data elements are collected and used by multiple data systems, MDM is the process that determines which single source is authoritative. When integrating data from multiple sources into a central data warehouse, for example, authoritative (i.e., “master”) sources are identified for each element. And when new elements are collected, an authoritative source is assigned for each. When populating the data store with historical data collected before the MDM process began, the authoritative sources need to be determined for those older data items as well. MDM also keeps track of the data collected and maintained throughout the agency to ensure that common standards (data element names, definitions, codes, formats, etc.) are being used. When all of the agency’s past and present data are addressed, MDM’s will then focus on handling new data elements. MDM relies on both data governance processes and technological solutions. The data governance side of the process can be fulfilled through the Data Governance Committee, as it facilitates the collaborative designation of authoritative data sources and elimination of redundant collections. Technology solutions can then be used to share data among multiple data systems (“horizontal integration”) by updating secondary data in one system with the authoritative data from another. For instance, if the agency uses several operational databases, the student information system (SIS) may hold the authoritative student addresses, while the transportation system holds secondary student address data. The MDM application would feed the SIS data into the central data store and update the transportation system automatically whenever the information was changed in the SIS. Additional resources: The Data Warehousing Institute This organization has produced a number of resources about master data management, including a tool to help agencies determine how much a data management solution would benefit them, as well as to assess how ready they are to implement such a solution. Master Data Management This presentation on MDM was given by several state education agency representatives at the July 2008 Statewide Longitudinal Data Systems Grantee Meeting.

On occasion, data issues will arise that require leadership-level support beyond the Data Management Committee. The data governance coordinator should bring such cases to the Data Policy Committee.

LDS Lore: Integration-inspired indigestion

Adam dug his fingertips into the armrest. He, his supervisor, and other program area staff were in a meeting with the data governance coordinator and the CIO to discuss the agency’s plan to phase its data into the LDS. Yori, the coordinator, was going over the LDS project’s goals and timeline, and had just told Adam and his colleagues that their program area’s data would be part of the first phase of data migration into the LDS. Adam did not like this idea one bit. “That’s my data,” he thought. He felt he was losing control of a data set he’d managed for years and he didn’t want them dumped into some communal data store. As the meeting continued, he worried the data would be at risk in the LDS and he wasn’t swayed by the argument that the move was necessary to give users greater access to the records. “They already get enough access to the data,” he thought. Would it be harder for him and his staff to work with the data? He was accustomed to a good deal of autonomy, and he didn’t want to have to coordinate with other areas of the department. Suddenly, Adam’s stomach tensed. Was this the first step in phasing out, or scaling back, the staff? Would his job be at risk when the integration was complete? Then, twisting his feet around the chair’s legs, Adam realized that integrating “his” data into the LDS would probably expose the records to scrutiny. Errors might be discovered. He and his staff would be held accountable for poor quality data. This was bad… Across the table, Yori noticed the uncomfortable looks on some of the faces around the table. Adam, slightly contorted in his seat, seemed particularly uneasy. Seeking to reduce the growing tension in the room, Yori reviewed the plan again. He said that, while the integration had support from agency leadership and was nonnegotiable, there would be many benefits for the agency’s stakeholders and for the team itself. For example, integration would make it easier to create reports that were previously painstaking or impossible to generate, and conduct analyses across multiple program areas. For instance, they would soon be able to see how their attendance data correlated with discipline incidents and dropouts. Yori said the agency needed the team’s help to increase the system’s benefits, and asked the staff to consider what reports could be made available through the LDS to ease their workload and help districts. He also assured the team that while the physical location of the data would change, staff ownership of the data would not. After the meeting, Yori visited each of the data stewards and let them know they should feel free to ask questions or raise concerns whenever they have them. Knowing that some of the staff lacked data management experience, Yori made it clear that this effort was to ensure quality data, not punish people. The agency would offer a host of professional development sessions to inform staff and improve necessary skill sets. Yori also scheduled regular one-on-one meetings with data stewards to see how things were going and to answer questions. During his meeting with Adam, he explained that, while the data governance process was a major departure from how the agency had managed its data in the past, its objectives were aligned with high-level goals and the initiative had strong executive support. Change is difficult, Yori said, but he made it clear they were all in this together and the benefits would be worth the trouble.

7. Form data steward working groups as needed

As discussed earlier, a key principle of data governance is collaboration across the program areas of the organization. Many data issues affect multiple program areas but, without data governance, these issues are unlikely to be addressed in a comprehensive way. According to Chatis Consulting, when an issue arises, the Data Governance Committee should form a working group of stewards to collaboratively address the problems and craft a solution. Within the group, one data steward should be ultimately responsible for ensuring the working group resolves the issue. Groups should identify the problem and pinpoint its original source; define the goals of solving the issue; set up a clear and detailed strategy for a resolution; report back to the Data Governance Committee on progress; work with IT to implement the business solution; and, finally, communicate the resolution to all relevant stakeholders. (See appendix D for guidelines on how group meetings can be structured.)

	Track data problems to their source
The identification of a data problem’s source is essential if the issue is to be resolved once and for all. If staff only treat the symptoms, the problem will likely surface again in the future.

Top