Adjusting to a Hybrid Workplace: How BRAD Solved Our Parking Validation Problem

A journey from BC to AD (Before COVID to AutoValidator Device)

COVID-19 vastly changed the way that many of us work. Our reality now is that most of us have had to adjust to a hybrid work environment where we commute to the office once or twice a week. While this flexibility is convenient, it has also introduced new challenges.

In the Houston Build Center, we had to get creative with how we dealt with our parking situation. As Builders, we did what we do best. We decided to build a device to solve our problems.

This article serves as a narrative for the project’s scope. Its primary aim is to showcase our innovative approach to tackling the unique challenges that have emerged in the post-COVID era. By embracing this new era and our forward-thinking solutions, we formed a team to bring our idea to life.

Houston H1 Connect

Climbing the Mountain

Upon hiring, new employees receive a parking sticker for their vehicle that automatically grants them access to our parking garage.

This past year, the Houston office was one of the fastest-growing Build centers in North America. As COVID restrictions eased, more and more people sought to connect with their fellow Builders. Over half of our new Builders do not have a permanent parking pass. This meant they must have their tickets validated every time they commute into the office. This led to our current parking problem.

Parking for the Houston Build Center costs Slalom about $70 a month per parking spot, regardless of actual attendance. That comes out to about $3.50 per business day each month. A small price to pay when people were showing up to the office every day. Once we moved to remote work, this cost was no longer a justifiable expense. A person would have to show up more than ten full days to exceed the cost of a monthly reservation, and most people come in once a week! Therefore, our operations team decided that it would be best to validate parking tickets for those individuals who came into the office at a max cost of $7 per day.

Individual parking validation is a pain! Every day employees would have some form of the following conversation:

Builder A: Hey Brad! Can you validate my parking ticket?
Builder B (thinking): Ah, geez. Not again … this is the tenth person today! Will my suffering ever end?!
Builder B: Sure! Hand it over, and I’ll take care of it shortly.
Builder A (waits patiently): Man … this sure does take a while. Why haven’t we automated this?
Builder B: …

Of course, the answer to this question was that no one had really identified the pain. Specifically, the parking validation website was very slow to load and was poorly designed. To compound this issue, Work-From-Work-Wednesdays crowds boomed, and very few people had permissions to validate parking tickets.

Builder B had had enough interruptions. Thus, we set out to automate the process.

Swinging the Bat

Before building and designing anything, the team decided we needed to develop a proof of concept for how our solution would work. Initially, we set out to operate the site via exposed API endpoints. Eventually, we realized that the parking validation website had logic built into the user interface. This was a challenge because we could not hit the endpoint with the expected parking ticket information. Since we did not have access to any documentation, the best we could do was guess — and we were not about to go down that path. This meant the team had to take a different approach. We needed to leverage user-interface automation to avoid having to worry about hitting the exposed API endpoints. UI automation would let us validate tickets the same way a person does, but in this case, our machine would be the one going through the process.

Once we had proven that running a headless browser containing the parking validation website was possible, we could validate a parking ticket! HURRAY!

Then came other complex challenges, including:

• How do we refresh our authorization token?
• How should a user interact with this automation?
• How do we get the information off the ticket from the user?

The initial team began recruiting other team members with experience building hardware solutions to answer all these questions. Little did they know how tall the “mountain” they were climbing really was.

Early Success

The majority of the team formed around the solution quite organically. Four additional members joined, bringing their experience in computer vision, hardware, UX/UI design, and testing solutions. It was impressive that the Builders that owned these aspects of the project often operated outside their usual roles and responsibilities. We had Quality Engineers developing architecture and designing hardware implementation. We had Data Engineers modeling and 3D printing designs. We also had Software Engineers leading and organizing timelines and team deliverables scheduling. Everyone had a chance to shape the final design and flex other muscles that they usually do not get to use in their normal operations.

Our tester discovered that to stay logged into the parking validation website in a headless browser, we would have to refresh our authorization token in 25-minute intervals. The UI/UX designer designed all logos, instructions, and icons to teach users how to use the device. We also decided to extract ticket information using AWS Textract, which the team member with computer vision experience could implement.

Our combined skills took this solution from an idea and a couple of lines of code to a tangible device everyone in the office was excited to see.

Here’s the way it worked:

1. A ticket is placed in the ticket tray.
2. An ultrasound sensor is triggered.
3. An image is captured using Raspberry Pi.
4. This captured image then goes through some preprocessing steps to reduce the size of the image and make the text easier to identify.
5. Once the image is ready, it is sent to AWS Textract as binary data, and a response is returned that can be parsed to get the ticket number, entry date, and entry time.
6. The ticket information then hits an endpoint.
7. We open a headless instance of the parking website to validate tickets in a matter of seconds.

With all that, plus a couple of blinking lights for user feedback, it looked like we were almost done! We had reached an enormous milestone for our team. There were still a couple of bugs and improvements that needed to be made, but we had a semi-functioning, barebones version of what our solution was supposed to look like.

As mentioned earlier, only a few people have access to validate parking tickets. Our most prolific ticket validator was Brad Merell.

After a few conversations, the team decided to name the device BRAD, which stood for the …

Better
Reliable
AutoValidator
Device

Initial designs for BRAD

Navigating Setbacks

We could power the device and actually validate people’s parking tickets. We were happy with our progress but knew things could be better.

Moving forward, the team was able to capitalize on the previous traction once they formed a rhythm of adding small features and improving their solution every week.

We started to promote the project to the rest of the office, and any concerns we hadn’t addressed as a team were quickly brought to our attention. We tested the way users would come and place their tickets on the device. We adjusted the timing of when the camera would capture an image of the ticket and then tested again. On a separate occasion, we improved the computer vision script to handle tickets in multiple orientations. We repeated this process until BRAD began operating more consistently and the user could interact with the device without having a team member give as much guidance.

We promoted it and learned the hard way to determine your stakeholders early. Before deploying BRAD for everyday use, we were informed that we had to confirm that we were abiding by Slalom policies and not breaking any rules the parking vendor might have in place. We also learned that we had to let the operations team know how this device worked and get their approval to maintain control over who was coming in and out of the office to validate their parking tickets. Having non-Slalom employees validate their tickets could raise other issues with our parking vendor.

Our first step was to reach out to InfoSec, who gave us a list of requirements that we had to meet to ensure that what we were doing was allowed and not breaking any policies.

New requirements:

• There cannot be any Slalom IPs physically stored on the device.
• There cannot be any credentials physically stored on the device.
• We must get approval from the parking vendor to do this.
• We must get approval to use the parking validation website with this solution.
• Houston Operations’ team must be on board with using our device as a parking validator, and the device must be only accessible to Slalom employees.
• We must have a deployment and support strategy for our device.

Needless to say, meeting these requirements would require a full re-architecting of our solution. It was a major setback.

As we realized there was a procedure we needed to follow, other parts of the project came into question. We also faced challenges while upgrading the physical components, like our lighting rig on the device, raising even more uncertainty. In our attempts to harden BRAD, we discovered that not all hardware components were easy to integrate with the i/o pins, and perhaps we were maxing out how much power output the Raspberry Pi could handle.

• Would the operations team approve of this device?
• Where would this device be located?
• Would the vendor support what we were trying to do?
• Should we move from using cloud services to locally hosting everything on the device?
• Should we revert back to our old lighting implementation?

For a couple of weeks, the project was on a downward spiral. On three occasions, it looked as if our device would not be approved and our project was dead in the water.

We are happy to say that after weeks of uncertainty about the projects’ future, our team finally secured the necessary approvals to continue working. First, we adjusted the project architecture to remove all sensitive information from the device. Since we were already using AWS resources, we removed all passwords and usernames and stored them in Secrets Manager. Second, we met with our parking vendor and building manager to demo a prototype of BRAD and explained to them the steps we took to ensure our device would be secure. We restricted our AWS account to limit access to the Raspberry Pi’s IP address while connected to Slalom’s IoT Wi-Fi. We also got approval from our operations team to deploy BRAD in a common area behind our badge-accessed doors as an added layer of security. Lastly, we researched and implemented a voltage converter to increase the Pi’s voltage output from 3.5 volts to 5 volts so that we could adequately operate the lights.

With the newly lit “green light,” the team worked hard to:

• Incorporate a blinking light feature that signals to users that their ticket information is being processed and validated.
• Set up the 3D printed casing, which gave us a good idea of what the final device would look like.
• Implement OCR improvements since we knew that the camera would be stationary. This allowed tickets to be scanned in any direction, making up for user errors.
• Reduce the time Textract was taking by one-third via proper image preprocessing.
• Design, print, and add all the necessary stickers to the device, so users would have all the information they need when interacting with our device.

A production-ready device was completed in time for a client open house event in Houston, which allowed local clients to see the device in action.

BRAD at multiple stages

Can I Get off This Wild Ride Now?

Whew. Yes.

Overall, BRAD is a testament to our team’s skills, dedication, perseverance, and commitment to delivering high-quality solutions to clients. The successful development of BRAD demonstrated Slalom Build’s propensity to address complex software, hardware, and integration challenges. A process that usually took over five minutes and a lot of context-switching for our leaders can now be done by each Builder in a matter of seconds. BRAD helps alleviate the end-of-day scramble as people who had forgotten to get their ticket validated searched for the nearest leader or ops team member who could still be found in the office. As to ticket validations, BRAD is successful over 95% of the time. Most failures are a result of two common problems. The most common failure is a result of the user placing the parking ticket incorrectly. When this happens, the instructions on the device prompt the user to try again. The second failure is due to our reliance on our building using an older parking system that has, on rare occasions, been down for servicing. Instructions have also been provided about what to do if users find themselves unable to validate their tickets.

As a team, we learned the importance of testing while developing a product, especially when end users interact with prototype versions of the device. We all had to expand beyond our usual roles and got to have fun creating something that has had a positive impact on our Build center. Thanks to this device, we made ticket validation a faster and smoother process. Each team member brought their unique expertise, but our collaborative effort brought BRAD to life.