Will Data Quality Campaigns Stay in the Dark Ages?

Data about students that are high quality yield the best outcomes for students—this is the basis of nearly all education data quality campaigns. As education data systems mature across the nation due to investments from Department of Education Statewide Longitudinal Data System grants, states have not been able to find more innovate ways to ensure that the data feeding into these systems is high quality.

Assuming that high data quality is an important goal for grantee states, why then do they continue to rely upon tired professional development workshops, giant posters, and endless PowerPoint decks devoted to awareness campaigns to identify and solve data quality issues? If we’re going to rely on more modern data systems, we also need to modernize our thinking around diagnosing the root causes of data quality issues.

We think we’ve found a way to do just that.

These new systems generate mountains of rich data—data so fine-grained that we were able to develop a series of indicators to test various aspects of data quality, such as timeliness, uniqueness, and accuracy. But what we found truly exciting was what happened when we combined these indicators with survey data about district technology and capacity. We used these data to reveal stark contrasts between high-data quality and low-data quality districts. For example, we found that districts high on the data quality scale had an average of 4 full-time data staff and spent $20-$30k per year in fixed system costs, while districts on the low end of the data quality scale had an average of 2 full-time data staff and spent $10-$15k per year.

Using this approach, we can now provide districts with a real “pulse” on their data quality while also giving them greater information about the quality control levers at their disposal. If more districts adopted this approach, we would stand a much better chance of improving outcomes for students.

AK

Getting to “The Finals” with Education Technology

As the National Basketball Association (NBA) pre-season sets to open, I am excited about the thought of cheering the new franchise team in my hometown, the Brooklyn Nets. The Brooklyn Nets have energized the borough and locals. I have the Brooklyn Nets tee-shirt, mug and bumper sticker. I am not sure if I want a Deron Williams’ or Joe Johnson’s jersey. They are, of course, the team stars. However, without Coach Avery Johnson, Kris Humphries, Brook Lopez, Gerald Wallace and other bench players, the Brooklyn Nets can forget about making it to the play-offs, never mind the Finals. Teamwork is vital.

My new obsession leads me to wonder about what “the Finals” are for system design and development. To many in the tech field, “the Finals” are a fully developed system that users can actually use to complete necessary functions related to their work. To make it to “the Finals,” a system design and development team needs a core group of professionals that work together. The core team consists of developers (star centers and forwards), project manager (coach), subject matter experts (3-point shooter) and requirements analyst (point guard). There are other essential members of a system project like a project sponsor (general manager) but the core team is the heartbeat of the project.

On a core team, the guy or gal that takes the ball to the basket is the developer. The developer bears the load of bringing the system to life. However, the developer needs well-defined requirements (i.e., good plays and passes) to develop the system. A core team member that helps define the requirements and often gets overlooked is the Subject Matter Expert (SME). The SME on a system project is vital because they understand content and functionality required in a system. A good SME also understands the policy, regulations and user scenarios that drive design. If a system project lacks a dedicated SME in the early phases of design, key functionality and content can be overlooked. The results are missed timelines and blown development budgets. No matter how capable the developers, project manager and requirements analysts are, without a strong SME, the core team will run plays (design and develop a system) that do not result in the big win, “the Finals”.

In the coming weeks, I hope to share my views on other members of the “Core team”.

JPL