Poll Day
Today, Belgians voted for the Federal parliament. This year, for the first time, I was chosen as part of a 5 person team to man the polling station. So, I spent most of Sunday thinking about and implementing process improvement. This Lean and Theory of Constraints stuff is addictive!
Step 1: What is the Goal?
We want to reduce the waiting time, the time people spend in the queue before being able to cast their vote. The queue length is easy to see, that gives us Visual Control.
Step 2: Where is the bottleneck?
Most polling stations use computers, some use paper ballots. The computer-based voting process has the following steps:
- Voter presents ID card and their invitation to vote
- Team verifies that the voter has come to the correct polling station and that the invitation matches the ID
- Team verifies that the voter is on the register and register their presence
- Voter receives their voting token, a card with a magnetic stripe
- Voter chooses their candidates for the lower House and the Senate (X 5 polling booths)
- Voter inserts their voting token (the magnetic strip contains their choice) into a sealed box. The token is validated and counted during insertion.
- Team verifies that the voter is on the register and register their presence again, by second person
- Voter receives back their ID card and their invitation, now stamped to indicate that they have voted
- Voter leaves.
It was quickly apparent that the voting booths (thick red lines) were the bottleneck: we could fill all the booths with voters, everybody on the team had idle periods, even when there was a queue. We had a ‘bottleneck in waiting‘ in step 3 (thin red line): when a lot of people showed up after a slow period (and the booths were empty), voters had to wait for step 3 to get to the booth.
Step 3: exploit the constraint
So, if the booths are the bottleneck, we will improve throughput by exploiting the booths: try to keep the booths filled at all time. As soon as someone left a booth, the next person in line received a voting token and could enter the booth. During busy periods (of course, voters don’t arrive evenly spaced out over the day), when there was a queue, we achieved very high utlization of the constraint resource.
Step 4: subordinate to the constraint
No problem for the team members behind the bottleneck. They could work at a sustainable pace, as people came out of the booths.
The three people performing steps 2-3-4 worked at the rhythm of the booths. A one-person buffer was created before the bottleneck, so that there was always someone ready to enter a vacated booth. Another one-person buffer was created before step 3, the one task that might starve the bottleneck.
The voting computers are not very dependable. They regularly break down, leading to long queues and in a few cases to delays in voting. Another subordination is to have plenty of people on site or on call who can fix the computers. One of the five computers broke down twice during the day. Whenever that happened, queues lengthened, reinforcing our assessment that the voting booths/computers were the bottleneck. These breakdowns accidentally “lowered the water level to expose the rocks“. Luckily, in both cases, the machines were ‘fixed’ (or just rebooted?) quickly.
Fixing quickly is nice; avoiding problems is better. What are the root causes of these breakdowns and installation errors? In one polling station the computers didn’t work, because “the cables were connected incorrectly”. Is there a way to detect this kind of problems quickly (Jidoka) or to avoid wrong connections (Poka-Yoke)?
One-family flow
There are two one-person buffers, before the two bottlenecks. The rest is flow, following the “flow where you can, pull where you must” adage. We found a way to reduce the load on the minor bottleneck by increasing the first buffer to one family. The electoral register is sorted by address. Therefore, it is very easy to check off multiple people living at the same address. Thus, the person performing step 2 takes on a bit more work (not being the bottleneck, there’s capacity to spare): look ahead in the queue so that people living at the same address are presented together for verification. Thus, the buffer before step 3 is family-sized, the buffer before the booths is still one person. With this improvement of step 3 in place, we could fill the booths up more quickly after a lull, and thus bottleneck utilization went up again.
Step 5: elevate the constraint
Most people use the voting computers without problem. I found them to be a little slow. However, some people have trouble using the computers. This is probably the one time in the year that they use a computer. The display tries to mimic the paper and pen-based voting process, but the UNDO and CONFIRM buttons seemed to confuse people: “Why should we confirm our choice? We’ve already made our choice with the pen“. The mixed metaphor confuses: it’s like paper-based voting (mark your choice with the electronic pen), with which voters are familiar, combined with the undo-ability of an electronic form, with which many voters are not familiar. Of course, we couldn’t do any detailed user interaction studies, what with the confidentiality of the vote 🙂
The voting rules were another cause of confusion and questions. You can vote for a party and primary and subordinate candidates. Which options can you combine, which combinations are illegal? Paper-based voting has the same problem. There were explanations in most media before the vote, but I believe a reminder in the polling station would be useful.
Of course, we could always install more booths. That would be expensive and wouldn’t give us much: most of the time there were no queues or queues with only a few people waiting. Waiting time was never more than 5 minutes between entering the polling station and entering the polling booth. I can’t give you exact numbers (only “most”, “some”, “a few”…), because it’s hard to be participant and observer of a process at the same time.
Step 6: And again!
People arrive randomly at the polling station. Very busy moments alternated with idle time. There was no predictable “takt time”. We made good use of this “feature”. During “slow moments”
- team members took breaks. Because the two sub-groups in the team (before and after the bottleneck) made sure that everybody could perform all the tasks of the subgroups this was never a problem. The other teammembers could still perform all the work, albeit slightly slower.
- we performed lower-priority “book-keeping” and administration chores.
- we looked at the process and discussed improvements. And so we kept on improving.
We have applied the Theory of Constraints and a few Lean techniques. Are we satisfied now? No. Lean people are never satisfied! Next time we’ll see more ways to improve voter throughput.
