Attendance Automation

The Setup

I worked at a company that had a great L&D team setup.  They developed a lot of internal training on their Learning Management System (LMS), which was augmented by a large number of instructor led training (ILT). There was a wide range of training, from regulation mandated compliance, to new hire onboarding, to skills development.  Luckily we were well supported by an engaged group of trainers with backgrounds ranging from training consultants to formally trained teachers.

Tracking was mainly done through the LMS, and was easy enough since that system was setup to track things like log ins, who watched what, and what quiz scores we got.  A number of built in reports provided basic output we could share with the business.  The ILT, whoever, proved to be more of a challenge.  While we could get an idea of knowledge retention by sending out quizzes or follow ups, keeping track of who actually showed up was more of a challenge.  

Generally paper attendance was taken, which works…. To an extent.  This was compounded as we had multiple locations that had to report back, forcing us to rely on folks outside the team to scan and email us attendance sheets.  Cheating was also a concern, as you could write down anyone else’s name and then claim they were there.  Given the highly regulated area we were in, this could result in significant consequences if we were caught.

---

The Eureka Moment

While thinking over this problem I had a “no-duh” moment that led to an eventual solution - every employee has a security badge, why can’t we just use those to log into class?  I knew our security system could record badges when someone opened a door, including who it was, when it happened and which door.  I didn’t see any reason we couldn’t do this for in-person trainings, now I just had to figure out how it could be done.

I knew other companies had dedicated training rooms (lucky), which would have made this easy.  All we would have do was get folks to badge into that training room and they knew who was there.  While we did have a number of rooms large enough to hold dozens of people (frequently needed for mandatory training), we were not lucky enough to have dedicated training spaces.  This was further compounded by having multiple locations.

My general idea was to have some kind of website setup that folks could swipe their badge into and record their attendance.  This would remove the need for paper (messy and easy to make a mistake), as well as the risk someone would write in someone else’s name (one individual did try to badge in their entire team at once, which we quickly shut down).  The only challenge was I didn’t have was the hardware to scan the badge or the software to process the information.

---

The Challenges

There were three challenges to overcome, two technical and one cultural.  On the technical front I had to figure out how to allow someone to badge into a class, and then how handle and process their scan-in.  The first required a hardware approach (some kind of badge reader), and the second a software approach (some system to take that persons scan-in and put it somewhere).  On the cultural front we had to get buy-in from leaders to socialize this amazing new product, and from individuals to properly use it (e.g. not send one person to scan in their entire team).

The Hardware

The Security team owned our badging system, so I started my quest there.  Their first recommendation was to have the Learning team pay to put a badge reader on EVERY conference room.  Now this would solve our challenge, since it would collect badging information when someone badged in… and it would also cost a LOT of money that we didn’t have (our budget was basically $0).  This approach would also only tell us that someone badged in at a certain time, not information about WHY.  For example, without additional work we wouldn’t know what class they were attending, or who was teaching it, both data points we were interested in.

Their next suggestion was to use a USB badge reader.  This sounded like a great idea, but unfortunately they didn’t know exactly which one we should get.  After a few failed Amazon purchases we reached out to the contractor who setup our system originally.  Without nerding out TOO much, the badges were made by a company called HID and go by the “Prox Card” brand name.  These cards can be programmed with any one of 137 billion unique codes, which is great if you have 137 billion employees, and slightly more of a challenge if you’re looking to read them.  We eventually figured out there are multiple ways to encode the card, for example, you can include a building number, as well as a unique ID for an employee, in the code.  The card readers have to be setup to read the number properly, if not, they’ll grab the information incorrectly (something I ran into during my initial testing).

In this sample card number the first three digits (110) could mean building #110, while the last 5 (72956) could be the unique ID for that individual.  

11072956

Unfortunately the USB card readers don’t know this out of the box… resulting in them reading the entire number as the employee’s ID.  The cards do have the number printed on the outside, so I was able to verify the number the reader was picking up was the correct one.  This, however, did not help me figure out what the numbers actually meant.

Fortunately our contractor was able to help us untangle this and gave us a configuration file that we could write to the card readers.  This ensured they properly read our badges, and meant we could quickly update new card readers ourselves.  We ordered a few readers for each location, and made sure the local L&D folks knew where they were (they aren’t cheap!). This took care of how to get an employees badge ID off their badge.

The Softer Side

Oddly writing the software for this turned out be easier than wrangling the badge readers.  I discovered that Google Suite (gMail, Slides, Sheets, etc.) has a scripting language called Google Apps Script (GAS), which is based off of JavaScript.  Not only was there more documentation available online, but there are massive communities online to reach out to for help (unlike our badge readers, which required a consultant to come in and help out).

GAS allows you to perform virtually anything a human can do via a script.  Need a Form to update a spreadsheet, perform some calculations, then email someone and wait for a response?  GAS can do that.  Need a button you can push to reformat an entire Slides presentation?  GAS has you covered.  Need a Sheet to open a webpage and collect badging information?  GAS serves up HTML and CSS.

Unfortunately while I had some basic coding classes back in the day, I knew nothing of coding (well, I knew it was a thing, in the same way I know quantum mechanics is a thing).  Fortunately I had two advantages - a manager who wholly supported this project and the firm belief that I wasn’t trying to do anything groundbreaking.  Having my manager’s support was essential as it legitimized any time or energy I put towards this project.  Since this was a prioritized project, this also allowed me to push back against other demands on my time and gave my some great backup in the form of my manager getting folks off my back.

Understanding that this project didn’t present truly novel problems to humanity helped me keep my focus and feel from being overwhelmed.  At the end of the day all I was doing was taking a number, looking up a name and displaying something on a website.  Sure, the number came from an ID card, but everything about this was what I called a “solved problem”; everything I was trying to do had already been solved by someone, somewhere.  This understanding gave me a great “out” any time I got stuck - just look it up online.

The challenge with looking things up is knowing what to actually type into Google/your library/whatever to find what you want.  Since my background isn’t computer programming my biggest challenge was not having the correct words to describe problems.  This resulted in a lot of wasted time at the beginning, but helped expose me to a wide range of ideas as I tripped over things and generally beat me head against the keyboard until something worked.

Culture Wars

Getting buy in to use the tool was the easiest part. No one likes doing paper attendance (citation needed), and this is doubly true at tech companies. After all, if we’re surrounded by really smart people who can code new apps and discover new solutions, why are we stuck using technology invented in the first century?

The cultural challenge we ran into was enforcing some simple rules, like “You can only badge in yourself”. This came around after several teams sent one person “ahead of everyone else” to badge in the entire team. We avoided most of these challenges by getting managers and directors buy-in to help enforce behavior. We also told our front-line trainers to push back on anyone trying to break the rules, and, more importantly, they we had their backs if anyone complained.

---

Deployment

Eventually I got to a place where I had a working prototype which I felt comfortable showing my team.  Getting feedback was an important part of this tools life, mainly because I wouldn’t be the one using it on a daily basis, but also because my background wasn’t in running corporate training.  I got several great suggestions, such as having the tool accept an email address in case folks didn’t have a badge, or also recording the instructor and name of the course that someone badged into.  These reviews did take time, but at the end of the day they made a much stronger tool.

We had a large (400+ employee) compliance training coming up and saw it as a great opportunity to field test the tool.  We decided not to say anything to the trainees or their managers, and instead just setup a table with a computer, badge reader and someone to check folks in.  Everyone up until now had been conditioned to sign in on paper, something they really didn’t like since it was one, slow, and two, annoying.  We weren’t sure what the response to the tool would be, but figured it couldn’t be worse than signing in on paper.

We were amazed at the response.

Several folks who badged in wanted to get their hands on the tool for other events their team ran.  Several Directors immediately wanted to know how they could blend this information with other learning systems to see how their teams are performing (e.g. if Sally shows up to training, do her sales numbers improve?).  Many of them asked where we had bought the tool from, and were quite surprised when they learned it was home grown.

Overall, the tool was a hit.  We got some great feedback on how to improve it, and after a few modifications and testing, we deployed it to all our locations to track attendance.  Not only did we entirely remove the annoyance and inaccuracy of paper based records, we drastically improved our reporting capabilities and built great relationships with internal teams.

---

Lessons Learned

• Find pain points - Everyone has something that bugs them about how they do their job.  A screen loads slowly.  They have to get 15 approvals to go to lunch.  Bob in accounting refuses to sign off on something with a $.01 difference.  When folks are first exposed to these pain points, they tend to either complain a little bit and then stop, or just assume that’s part of reality and accept it.  Over time, we learn to deal with them and they don’t seem so bad… but they are.  Take the time to talk to your coworkers about what could go better, and then go do it.

• Get buy in - Once you’ve IDed some pain points, talk with your team/manager and get their feedback and buy in to tackle one or two.  Notice it’s one or two, not ALL of them… you really want to sell the lowest hanging fruit, something you can knock out of the park with a bit of work.  Getting buy in makes it much easier to get help from others, and makes your goal much more legitimate to others.

• Jump in - Once you’ve got buy in, jump in!  The solution may not be a straight line… but those are boring anyways.  Going into it I wouldn’t have been able to tell you I’d end up learning how to write JavaScript, but also learned how our ID badges work.  Take the time to understand the challenge, and give yourself space to explore the options.

Setting Up Ad-Hoc Teams

Implementing a new system takes a ton of effort, planning and energy.  What happens AFTER implementation is equally important, although it frequently doesn’t receive nearly enough attention.  In this case I’ll take a look at how I provided post-implementation support and training for a group of admin assistants, taking them from brand-new users to local Subject Matter Experts (SME).

---

The Setup

After a large Enterprise Resource Planning (ERP) installation we moved into the support phase of the project.  This was a massive change in pace since the pressure to implement on a schedule entirely vanished. We no longer had executives breathing down our necks, and the gaggle of consultants who had been prodding us into action had (finally) left.

Instead we had the crushing grind of daily challenges presented by 3,000+ users of a new system - “I can’t log in”, “how do I add a purchase requisition?”, “Why can’t I find project X?”.  Since there was no way I could (or would ever want to!) handle all these requests, I started looking for better alternatives. Specifically, I began looking for a group of folks I could train up to be strong enough to handle the daily questions, thereby freeing up my time and also improving our support for our users.

---

Likely Suspects

The company I worked for had multiple locations spread throughout the Pacific Northwest.  These facilities ranged in size from 1,500+ employees, all the way down to 10-15 folks. What each location had in common, however, was they all had a dedicated Administrative Assistant.  This individual was responsible for handling general office tasks, including being the local expert with the ERP. “General tasks” might include data entry, helping other employees at that site with problems and being involved in testing or other updates.  Basically, these folks were the swiss-army knife of their office - they knew everyone at their site, knew how the business operated, and were very good at what they did.

Until the ERP system was updated, and they were a bit lost.

This is the challenge with any system update - things change, and users don’t like change.  They don’t like it when buttons change or move, and they REALLY don’t like it when they can’t do their job because they don’t know what to do.  These admins, however, were very well plugged into their local user base (they knew most folks by name if not personally), and, even better, the local users were used to going to them with questions.  This made the admins prime candidates.

---

Beginnings

Luckily I had already been introduced to all of the Administrative Assistant’s over the course of the original implementation.  This gave me a great leg-up since they already knew who I was and had some idea of what I did. This made getting the group together significantly easier as I did not have to sell the idea to both their managers AND the Assistants.  I still needed to connect with their managers (and mine) to align them on the idea, however, having previous contact made this process substantially easier than it can otherwise be.

Getting in touch with the managers was the first step.  After all, they’re in charge of these folks workload, and once sold on the idea they are a great resource to improve the process.  Managers can also shut everything down really quickly if you don’t include them (either for perfectly legit reasons like workload, or just because they don’t like you!).  This makes their involvement, and more importantly, buy in, critical to our success.

Once I had all the managers aligned on the purpose and need for this group, my next step was to connect all the admin assistants together.  Since I already knew them this was as simple as sending them all an email and jumping on a video-conference together. Most were already aware of the idea, so getting their buy-in was relatively easy.  This particular group was also motivated by the need to make their jobs easier, and interest in getting more training on the system.

---

Sidenotes 

What if you don’t know everyone? - Don’t worry, this part’s easy!  Just sit down, identify everyone in the group you’d like to include, and go say hello.  Ideally you can do this in person, but any method works. The main goal of first contact is just to put a face to name, don’t worry about getting them to sign on to anything yet.  You’ll also want to introduce yourself to their managers and begin acclimating them to your idea.

What if a manager pushes back? - This can be rather common… some managers are protective of their space (either due to legit reasons like workloads, or more political ones).  Do your best to back up your reasoning for needing their direct’s time (e.g. this will save X hours over Y days), and tie it into that individual and managers job (e.g. getting Suzie involved will reduce the accounting errors you’ll have to deal with).  If you’re still getting push back speak with your manager and see if they can help influence. Sometimes it just takes another voice to get someone over the line.

What if you have unenthusiastic targets (e.g. my Admins)? - Sometimes the folks you want to include in the group aren’t the best options.  They might be uninterested (“not my job” syndrome), unable due to workload (it’s possible you can change this through their manager), or they may not trust their skills (easier to fix via training and exposure).  Your challenge is to identify WHY they’re unenthusiastic and attack the root cause. Are they shying away because they don’t know the system? Train them. Are they afraid other work will suffer? Talk to their manager.  Do they think someone else would be better? They might be right… talk to that person. If all else fails, see if you can find someone else who would be a good fit.

---

Admins, Assemble!

Once I had my group identified and had manager buy in, the fun part started.  I first went about documenting as much of what we’d be looking at as possible (this ended up being over 300 pages of custom build pages, but more on this in another post).  Fortunately their jobs were fairly well defined, so I could make a laundry list of items they would be responsible for. Having clear documentation allowed me to easily spin up lesson plans to help round out their skills, and, more importantly, gave them a resource that wasn’t me to go to for help (a very critical step towards maintaining my own sanity).

I then setup a recurring video chat with the entire group on a weekly basis.  Originally this began as a 1 hour connection, but as they became more confident in the system we reduced it to half an hour.  The recurring meetings were mostly used to address challenges they ran into with the whole group. I would also hold ad hoc meetings as needed (e.g. in the case of a system failure, critical update, targeted coaching, etc.).  

While the meetings began more as a group lesson, they became more slanted towards team building as time went on.  Instead of helping them with the answer I would challenge the group to try and figure it out. I would also have admins teach each other when they ran into problems (generally after I helped them through it in a one on one).  This helped build their confidence in the system (e.g. don’t bug Rob, you can figure it out), but also their confidence in each other (I can’t figure it out… but I know Gina is good at this too so I’ll ask her first).

Everyone also had write access to the documentation, which they would update as they ran into differences or found errors.  We also went over those changes in our weekly meetings to ensure everyone was up to date, and would update documentation together when it came up.

---

The Endgame

Eventually the Admins became fluent both in the system and in how to address challenges.  They were comfortable both in their own skills, but also in relying on their team (and not just me!) when they needed help.  I did notice, however, that they would still come to me with questions they should know the answer to (or have documented). This was likely just inertia - they were trained to go to me for help so they kept doing it - but it wasn’t serving them any longer (and it was annoying me).  

To solve this, I setup a simple game.  Any time they came to me with a question we’d first check our documentation.  If the answer was in there, I’d get a point, and if it wasn’t in there, they’d get the point and we’d add the answer.  Points weren’t redeemable for prizes, but were intended to serve as a reminder that they had the power and knew what to do.  I also didn’t want them to be afraid of coming to me for help (especially on BIG problems), so I made it clear I’d always help them if they asked.

They almost immediately stopped coming to me with questions.

---

Lessons Learned - Setting up a Team

• Get Buy in - Ensure managers are on board.  Ensuring that your potential team’s actual managers are on board with your plan is critical.  Be sure you’ve got a well thought out idea, and can demonstrate how getting some of their time and energy will benefit both the team and the manager.

• Build Resources - Build documentation, get access setup etc.  At the end of the day what you’re really going for is a self-sustaining group to knock out some work.  To be successful the team will need documentation, references and training so they can build their confidence.  Taking the time to do this early will both help make the best product, but also set yourself up for success later.

• Constantly Connect - Regular meetings and interactions are key.  Not only do these touch points give you an opportunity to improve your relationship with the team, they also help build a sense of camaraderie.  This time helps the team learn to trust each other, and allows them to form connections that don’t require you to be involved.

• Encourage Collaboration -  The main goal is to replicate yourself (to an extent, anyways).  To really be successful at this you cannot be the only place someone can go for help.  Encourage your team to ask each other for help, or have them each take the lead during a meeting and train everyone on something.  Over time they’ll learn they can go to each other instead of bugging you.

Case Study - Learning a New System

One of my first jobs had me in the role of a project management module expert for a new system we were installing.  This was a big step for me since it got me out of being an IT Helpdesk Tech and into business systems analysis (something I find a lot more interesting).  This project would impact how 2,000+ people did their jobs across 6 locations, but the challenge I had was that I didn’t know much about project management, or this new system….

---

The Setup

This turned out to be a great opportunity to learn both by experience and by training.  Since we were already using a version of this system we had environments available for me to play in, and, even better, we had other folks on my team who were familiar with the system and underlying concepts.  Having both of these isn’t always the case, so I got lucky (sometimes system implementations involve a team entirely new to the system, which makes for one rather steep learning curve) . It was still a lot of work to make time in the system and to get to know everyone, but it really helped improve my learning curve.

---

First Things First

The first thing I did was get access to a sandbox version of the new system so I could play around.  This helped me build up the basics, e.g. where buttons were, what they did, what our current setup looked like.  The other thing I did was get my hands on the manual (a digital copy anyways). This helped inform my wanderings by giving me some underlying context into what those buttons were intended for, as well as background on the architecture and setup of the system.

Manuals can be a great resource, but many systems are incredibly complex, resulting in incredibly large manuals.  My recommendation here would be to focus on specific areas to investigate (e.g. whatever area you’re responsible for) to build up familiarity with them.  Sometimes it is fun to randomly explore, but I find this can lead to areas that you may never use, or end up being more confusing than useful.

In short, hands on gave me the “how do I do X”, while the manual gave me the “what this does and how to do it”.  The last piece, the “why are we doing this?” came later.

---

Baby Steps

Going from zero experience in the system to something more than zero was a bit painful.  Not only did I not know what it COULD do, I didn’t even have the basics. So I put in time (to use a gaming term, I did a lot of grinding).  I tried adding simple things over and over. I read the same page of the manual multiple times and then tried doing those things to see if it really did that (a great way to check your own documentation!).  Eventually I got to a point where I felt like I could open the system without hurting myself, which was good. At this stage, however, I was almost effectively useless to the team. Sure, I knew there were some buttons, and what some screens looked like, but I couldn’t translate that into helping the business solve anything.

This was by far the most challenging aspect of it all.  Why did finance care how the GL is setup? Was it important that we used a specific numerical sequence for project numbers?  Which data field was used to identify the project owner? The questions were endless, and each time I found one answer, more questions popped up.

Not only was I very new with the system, I was almost entirely new with the business and with project management as well.  I needed help.

---

Help!

Luckily for me, my project team contained a representative from most areas of the business (Accounting, Accounts Receivable, Project Management, Purchasing, etc).  This made it fairly easy to find someone to help me understand the basics, and even better, they were on the same project, which made it incredibly easy to connect and get some of their time.  In addition to getting formal background on what everyone did (I have zero background with Finance, for example), I also got to see how they were planning on using the system. This helped me better understand how my area would interact with theirs (e.g. if a purchase order is placed on a project how does that impact inventory?  What about the general ledger? Hours worked?). These learnings helped me further round out my understanding of the system, and more importantly, the “why” behind how it operates.

I also got help from other employees who happened to use the system.  This was another bit of luck as not every implementation I work on has this setup (although you can generally get help from the system vendor).  These folks were able to provide me more background on historic use, which is honestly a bit of a double edged sword. Implementing (or re-implementing) a system is intended to improve operations, not simply continue with the status quo.  Understanding how something works is critical to improving it, however, you must be careful to not simply copy/paste that into the next iteration.

Connecting with other technical folks helped as well. For example, I originally believed reporting was a built-in module of our system.  After a lot of (poor) guess work, I found out it was mainly handled using MS SQL. Data was loaded into our data warehouse by (what I eventually learned) were CRON jobs, after which it could be used by our data analysts.  Being able to sit down and talk with our data engineer and analysts made this process both much shorter and more enjoyable.

---

Leveling Up

Having hands-on access to the system, formalized training (in the form of the manual) and access to experts on the underlying process was immensely helpful.  While each area was incredibly informative on their own, when combined they played off each other giving me more depth of insight than otherwise possible. For example, understanding that the project number for any given project was added to the general ledger code string shed a lot of light on why Finance was involved in the structure of project numbers (don’t worry if that doesn’t really make sense out of context!).

On the more technical side this combination of knowledge helped explain why our project managers were so adamant about knowing when data was available in their reports.  If, for example, we loaded data from the system to our data warehouse at 1am that morning, their reports that day would be a day old. Once I explained this to them they got much less concerned when the number in their report didn’t match the live number in the system.

---

Learning a New System - Lessons Learned

Despite the specifics being unique to the situation, there are a number of lessons that can be pulled out of this experience and generalized to others.  Indeed, I’ve repeated this general pattern many times so far (hands on, make friends, do your homework) since then.

• Get hands on - learn by doing.  Any time you have the opportunity to get hands-on with the thing you’re expected to learn, take it.  It doesn’t matter if it’s a new programming language, new vehicle or new system, the more time you have poking around and seeing what is where the better.

• Make friends - know your end users.  Get time (face to face if possible) with folks who already use the system, or who understand the underlying concepts that will impact it.  These folks will, at the very least, give you pointers on what to look into next. At best, they’ll be able to walk you through specific scenarios and help answer your questions.

• Do your homework - understand the business applications.  Underlying concepts or ideas are incredibly important to how systems, programs, processes etc. operate.  Take time to read up on your field to get a better grasp of these. While they may be very abstract or seem unimportant they almost always will have an impact on what you do.

YOU are the expert now

One of the first big IT projects I ever worked on was updating and replacing an ERP system called IFS. At the start of the project I was just an IT help desk tech (the guy who replaces your monitor or installs a printer). I was asked if I wanted to become the IFS Project Management Module expert, to which I readily said “sure, that sounds fun” (not to mention more interesting than installing printers).

Problem was I didn’t know anything about IFS…. or about Project Management….

---

I’m the expert?…

I have a two-pronged approach to solving challenges like this. The first is to have faith in others. In this case my job would involve traveling to multiple sites and standing in front of a room of professional Project Managers as the IFS Project Management expert, despite knowing basically nothing about either. The enormity of this (and the rather large knowledge gaps!) required me to have faith in my manager (who clearly thought I could handle things), my team (who supported me immensely) and myself (who learned to step up)… and this helped me not panic.

The second prong I use is to have faith in my myself. We’re all aware of our own capabilities, as well as our own limitations (be honest with yourself on these!). Once I really understand the challenge, I can map out possible gaps and determine solutions to those… generally this requires learning more about various topics (in this case IFS fundamentals and project management concepts) and boils down to doing my homework.

---

Don’t Panic - aka Have Faith in Others

Trusting those around you is hard. It requires giving up some amount of control and allowing others to dictate some aspects of your life. In most situations, I have enough faith and trust in the people I work with to make the best possible decisions for me in situations like these. This is doubly so once I have a working relationship with them and understand more about how they work.

When asked to take on incredible challenging , generally unknown, requests, I always remind myself that I wouldn’t be asked to do it if someone didn’t think I was capable. In most cases the person asking has more experience in the area than I do, further giving me confidence that I can do the thing (otherwise why would they ask?).

---

Do Your Homework - aka Have Faith in Yourself

Having faith in others is great, but it’s not enough. In order to succeed at this big asks, you also have to have faith in yourself. This includes faith in your abilities, but also in your potential. Over the years I’ve come to enjoy trusting in that potential since it has allowed me to flex and grow in ways I would not have without that opportunity.

For me, this frequently takes the form of (literal) homework. I’ve found myself enrolled in community college courses, teaching data analytics courses (teaching is a great way to help reinforce and learn new skills), reading stacks of books, and getting lost in the guts of a new system (one of the best ways to learn them, but always be sure you have a sandbox!). Since I also had a job, all of that had to be done on my “free” time.

---

I am the expert

It takes time, but eventually you’ll begin to accept these opportunities as pathways to growth instead of something to fear. For me the cycle of insane ask, not freaking out, working the problem and growing has become somewhat of an addiction. Not only have I built technical skills, I’ve had the pleasure of working with some very smart people (and made some great friends).

If we’re not being pushed by ourselves or others, we’re not growing, so grab every opportunity you can and enjoy the ride.