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.