Election Management Software Problems: The 7 That Become Public Failures

Why does scope drift toward the certified boundary so often?

Because the boundary is invisible from outside the field. A developer looking at an election office sees check in, ballots, counting and reporting as one workflow, and proposes to improve all of it. The office, under pressure, hears an offer to fix everything. Six weeks later somebody asks whether the proposed check in feature is regulated, and the answer changes the project.

Voting systems that mark, cast, count or tabulate ballots fall under the federal Voluntary Voting System Guidelines administered by the Election Assistance Commission and under state certification regimes on top of that. Electronic pollbooks are separately regulated in many states. No jurisdiction should commission a custom vote counting system, and a firm that offers to build one is telling you it does not understand the field.

Set the boundary in writing before anything is designed. The legitimate scope is everything around the certified core: ballot style reconciliation, mail ballot workflow inside your office, poll worker recruitment and assignment, equipment logistics and custody, ballot and supply planning, public status pages, and canvass and audit reporting. That is a large amount of work and it is where your staff time actually goes. If a pollbook capability is being discussed at all, confirm your state's certification requirements first, because that answer determines whether the work is even possible.

What goes wrong with street file, district and voter data?

The street file is the foundation and it is nobody's full time job. A range of odd house numbers is assigned to the wrong side of a line. A new development is coded to the old precinct. An apartment complex straddles a boundary and was resolved by whoever entered it. Each of these is a single quiet record and each produces wrong ballots.

The mistake in software projects is treating the statewide assignment as truth and importing it. If you import the assignment, you inherit the errors and you have built nothing that could ever find them. The second mistake is running the reconciliation once, at go live, and calling the data clean, when annexations, boundary adjustments and new construction change the answer continuously.

Hold districts as geographic layers and resolve every registered address against them independently, then compare that result with what the statewide system says. The output is a working list rather than a report: addresses where the two disagree, addresses falling in no district, styles with zero voters that should not exist, and voters whose style changed since the last election. Run it in July, when it is boring, and after every annexation or boundary change rather than only after redistricting. A jurisdiction that runs this quarterly stops having the fourteen day phone call, and that is the whole return on the ballot style part of the build.

Why do statewide and pollbook integrations break after launch?

Because you do not control the statewide voter registration system and it changes on the state's schedule. Exchange is usually a scheduled file rather than a modern interface, formats change with little notice, and a field that has always been populated stops being populated after a state release. Pollbook products such as KNOWiNK Poll Pad or a Tenex deployment, and components from VR Systems, have their own update cycles and their own export shapes.

These break at the worst time because election activity is concentrated. A format change in March is a nuisance. The same change discovered on the second day of early voting is a public incident.

Build defensively and assume the file will be wrong. Validate every import against expected structure and value ranges, quarantine failing records rather than rejecting the whole file, and produce a reconciliation report showing counts by category and what disagreed with the previous load. Never let a bad import silently overwrite good data, which means loading into a staging area and promoting explicitly. And run a scheduled test import in the quiet season so a state format change is discovered in January rather than in October. Any developer who assumes a clean real time connection to a state system has not worked in this field, and that single answer is a reliable filter.

What happens when custody and offline operation are not covered?

Chain of custody is where a build either earns its cost or fails publicly. Equipment leaves the warehouse with seal numbers, arrives at a location, is opened by two people, is sealed at the end of the night, and returns with ballots, memory devices and paperwork. Every step has a form, and in a contested election those forms are evidence. The question asked will not be whether your process was good. It will be whether your records prove it.

Paper fails predictably: illegible seal numbers, a missing signature, a form filed in the wrong box. A spreadsheet fails differently and worse, because it can be edited afterwards and cannot prove it was not. Offline capability is the related gap. Networks at vote centres fail, and a custody application that requires connectivity produces exactly the paper fallback you were trying to remove.

Record custody events in an append only log, scanned rather than typed wherever possible so seal numbers are not mistyped, capturing device, seal, location, timestamp and both signatures. Nothing is deletable and corrections are new entries with stated reasons. Make the capture work offline with local queueing and later reconciliation, and make the sync state visible to the person holding the device. Then reconciliation before certification becomes a report rather than a weekend, which is the change directors tell us they notice most.

Should you build custom or configure what you already own?

Configure if you are a small jurisdiction running a handful of precincts with a modest mail programme. Your statewide system plus a commercial pollbook plus a ballot tracking service built on postal barcode scans will carry you, and a build cannot be justified from that budget. Ballot tracking services in particular handle transit visibility well and there is no reason to rebuild that.

The gap those tools leave is inside your office rather than in the field. The signature challenge queue, cure notice generation with the correct statutory deadline, second and third contact attempts, reconciliation between ballots issued and returned by precinct, poll worker assignment with party balance and language constraints, and the daily numbers your county administrator and the local paper both want. None of that is a product gap anyone will close for you, because your deadlines come from your state code and your constraints come from your local charter.

Build when two or more apply: enough district complexity that ballot style errors are an annual event, mail volume that has made signature review and cure a spreadsheet operation with legal deadlines attached, more than a few hundred poll workers, paper custody records that a close race would expose, or processes existing only in one long serving director's head. That last one is the reason we see most often and the one jurisdictions consistently underrate.

How do hidden costs get into the quote?

The calendar is the cost nobody prices. A release cannot land in the eight weeks before an election under any circumstance, which means a twelve month plan is really a plan with two usable deployment windows. In a jurisdiction with a fall general election those windows run roughly December to April. A quote that assumes continuous delivery is a quote that has not read your calendar, and compressing work into the wrong months costs more and delivers less.

Language requirements are the second. Multilingual ballots, notices, worker materials and public pages multiply content management rather than adding a translation invoice, and each notice carries a statutory deadline that must be right in every language.

Third is the statewide interface, which is outside your control and therefore variable by definition. Ask for it to be priced with a discovery spike and a stated assumption about file format. Fourth is security work: multifactor access, role based permissions, append only logging, encrypted backups and whatever review your state or a federally aligned programme expects, including a penetration test before go live. Fifth is training and documentation for a workforce that turns over every cycle, which is a real deliverable in elections and not a courtesy.

What separates a build that works from one that fails here?

The builds that work go live on a small contest first. A municipal race or a special election with modest turnout is the correct first live use, and it exposes the things no test plan finds: a printer that behaves differently, a worker who taps a button twice, a location whose network fails. Jurisdictions that debut a system in a presidential general are making a decision they cannot reverse in public.

They also write down the process knowledge as they build. The elections director knows which precincts split three ways, which nursing home needs a mobile board, and that the seal log is reconciled before equipment leaves the warehouse. Encoding that is often the real deliverable, and it is what protects the office when that director retires.

The failures are recognisable at the proposal stage. A firm that cannot immediately explain the difference between a voting system and an administrative system should be removed on that answer alone. So should one that assumes a live connection to the state, or that plans a first deployment inside the eight week window. Then get ownership in writing before kickoff: the jurisdiction holds the repository, the infrastructure accounts and the right to hire another firm. Public confidence in an election does not survive a vendor dependency argument in a contested year.