Katy Owens Hubler discusses the history of the creation of voter registration databases, complexities surrounding developing requirements for new systems, and how The Turnout's process modeling workshops might be able to help.

Think back to when your state's voter registration database, or VRDB, was created. Were you involved in elections yet at that point? Many of us have been in this business a long time—though over the last few years we've unfortunately been losing many of the luminaries of election administration to retirement—but there are fewer and fewer that were involved in the early stages of their state's VRDB system. We're losing some of the lore—and the horror stories-of how that came about in states and in some cases, why things are the way they are.

After the Help America Vote Act, or HAVA, required it, states scrambled to create statewide VRDBs. Sometimes they turned to an established election vendor to help with this process, but often it was a local effort. Someone from the state IT office or the secretary of state's office was called upon to start the project. Or maybe a local software vendor was brought in. As time went on, many of those involved in the development the VRDB moved on or retired and the system continued to grow organically as laws changed, reporting requirements were added, and county election officials demanded that the system become more user friendly. As a result, you may now have a VRDB that, when diagrammed out, looks more like an octopus than a linear process flow. It may also be written in programming language that most software developers are no longer fluent in.

Now that many of the systems are 20+ years old—several lifetimes in IT years—many states are looking to replace or significantly update their VRDBs to meet the security requirements and user expectations of the more modern technological world. But where to start? Over the last couple of years, The Turnout has been involved in a number of state-based efforts to model the voter registration process.

We start with bringing in the key stakeholders for a series of process modeling meetings. This usually involves members of the state election office who use the system—and in some states may "own" the database in a more top-down way—and local election officials and their staff that enter voter registration information daily. Here it's important to get a variety of election officials involved from different kinds and sizes of jurisdictions, since a small election office may handle things very differently than a large office, even while working in the same database. And increasingly it probably involves the state IT office or another entity that can address the security of the database and the information it holds.

We then work with this group to model the process. This starts with the basic model for voter registration that was started by Kenneth Bennett from Los Angeles County and further developed by John Dziurłaj and the NIST Interoperability Working Group. These diagrams were developed with input from election officials and vendors all over the country with an aim to describe election processes at the 10,000-foot level, with the understanding that each state has its own variations. By using this as a base, we can then explore the different state variations and requirements. For more on the election models see this document on America's Election Model.

It can be surprising the number of functions that a statewide VRDB is expected to do in a state. These systems might track absentee ballot applications and ballots, or they may contain a module for tracking poll workers. In some states, they may contain information on voters who have signed petitions or be required to track preregistered voters who have yet to turn 18. And then they have to produce a series of reports for local election officials tracking their resources, to easily disseminate election results, to provide to the state election office or the legislature, and of course for the EAC's biennial Election Administration and Voting Survey, or EAVS.

Since the systems have largely grown organically, these process modeling exercises can bring up a number of questions. Do the systems really need to do all the things they're doing? Are they doing too much? Or not enough? Does it make sense to start from scratch? What does the system really need to do to provides the functions necessary for election officials?

The process modeling exercise can provide many benefits:

1. Building consensus on the necessary functions of a statewide VRDB throughout the state.
2. Completing a gap analysis of what a current system does vs. what an ideal system would do.
3. Tracing legal requirements to procedures and controls in the VRDB.
4. Streamlining the process to the necessary functions and getting out some of the "extra" stuff.
5. Identifying specific functional requirements that can be used in a procurement process for a new or updated system.

We know that many states are looking at their VRDBs and working to determine what needs to be done-do they need to be replaced? Updated? Trimmed down? Expanded? The Turnout's Process Modeling services can be a good start. So get in touch and see if we can help: info@turnout.rocks.