Having been a road warrior sales trainer for enough years to be “platinum-everything” in virtually every frequent traveler program, I have a natural affection for live, stand-up training. The rewards came back to me through good level one evaluations and getting to see the occasional graduate of my new hire product training classes at the year-end President’s Club gala events. It felt good to have a hot shot sales rep come up to me and thank me for the knowledge gained from new-hire training. I did not see it at the time, but having the “occasional graduate” thank me was more of a failure than a success.
It was not so much a failure on my contribution as it was the fact that over the course of a year or so, there were only a couple or three hot shots that survived. Funny how employee “churn” rhymed with “burn” and that ratio of “successfully trained sales reps” to “successful sales reps” sucked. But hey, my level ones were stellar and the butts-in-seats numbers were through the roof, and those were my success metrics. Neither of those metrics, misaligned as they were, could point to sustainable sales performance where it counted most – @ the point of work.
Reps were failing from within the work context of their post-training workflows. Our training blinders were strapped on tight and cemented by the traditional paradigm of train them, issue the new hire training tattoo, and turn them loose to thrive and prosper in the role of field sales rep. Training was good. Tattoos were crisp, and those consistent results marked the limits and the potential for driving business impact by our training. Something had to change, so we did the next best thing, which was also the tradition of the day.
We began to blend training with some on-line content. It was good stuff. It was sexy. It was Flash-based; top drawer content, and we wound up perpetuating performance impact shortfalls with much greater efficiency. We were deploying learning. We were not implementing learning, and there is a significant difference between the two. We decided that the problem was based upon not being able to get to the “next level” of training. We were not addressing the root cause, choosing instead to flog the symptom with the desire for more and better training. Imagine that…
Constant new hire classes pumped new recruits full of product information and prevented us from getting beyond that cycle to pursue more robust and business-relevant application training. At the time, that seemed like a logical reason for the high churn rate. There was not enough time, nor was there enough resource bandwidth to do anything more than what we were already doing. Does any of this sound familiar in your training world? Ever build a plane while flying it? Been there too, huh?
After a promotion to regional training manager, I started to ride with sales reps and was impressed that many points of failure were prompted by their lack of accurate recall of the knowledge we so expertly pumped into heads and hearts only months earlier in new hire training. Simple solution; they needed job aids – performance support. So we started building performance support tools in our not-so-spare time, and we succeeded in slapping a Band-Aid on a symptom and failed to affect a cure at the root of our problem.
Okay, so performance support did not work as a post-training solution. Now what? I never got to prove a wild theory that popped into my head because the company went Chapter 11 before I could give it a try. Bummer.
So…Let’s Try This Again
They say we can learn from our mistakes. Not sure who “they” are, but my next corporate gig proved that axiom to be true, and it turned out to be fertile ground for testing this radical new theory despite the business application having nothing to do with sales training. This new environment involved parachuting into a mid-stream SAP deployment that was well into its second phase. Four modules had already rolled out with great difficulty, and four more were just released as I landed behind the lines; Manager Self-Service (MSS) and Employee Self-Service (ESS), both core components of a couple new HR-related modules.
In the first phase, excellent classroom training fell short. Lesson learned, and the training team had already added what I would call exceptionally well done e-learning blends. As I began to assess the training results, they did not match the performance results anticipated even after the e-learning additions. Performance by managers and employees began to show signs of falling short @ the point of work, and the Help Desk was getting swamped with calls.
Again, I had the team build in performance support objects (PSOs) supporting the transactions that appeared to be the source of the biggest problems. Granted, these PSOs were after-the-fact solutions to training that fell short before my arrival, but the next wave of deployment did not promise to be any better than the first two despite the training content being all that you could ever want it to be.
Being familiar with Einstein’s theory of insanity – continuing to do the same thing and expecting different results – I figured it was time to test the new theory. The PDR Learning Continuum was born as a self-defense strategy.
For the third wave of deployment, my team built PSOs in advance of the roll-out. We changed the approach to training using the Continuum framework:
- The “P” stood for PREPARE and that consisted of brief e-learning chunks that introduced SAP concepts, definition, and visuals of workflows that were role-specific. We even introduced the HELP system which was an early version of EPSS (Electronic Performance Support System). In the Help system was a library of workflow support for individual tasks by role. Each task could either be viewed or downloaded to print.
- The “D” stood for DEPLOY and that was greatly shortened classroom training sessions [by about 50%]because we focused on transactions by role and only the relevant transactions that role would be responsible to use. In fact, the training was comprised of role-specific scenarios that required the use of PSOs relevant to that particular task. The learners logged into the system in a playground environment, and they read scenario that forced them to use the HELP system to find and extract the PSOs designed to support that transaction. In a sense, we did not train on SAP as much as we trained on WHERE TO GET THE PSO WHEN IT WAS NEEDED.
- The “R” stood for REINFORCE and served as the post-training resource for learners who were @ the point of work and faced with a moment of need. In those moments, they knew where to go to gain access to the very same PSOs we used in the training simulations. Our REINFORCE deliverable was simple – just-enough-just-in-time performer support @ the point of work.
The genesis of the PDR Learning Continuum framework was more successful than anything I had ever been associated with in all my years of training. The most humbling part of the whole deal was how stupid simple it really was when I stepped back and looked at it. Without a doubt, Performance Support was not just a post-training effort. Performance Support is best leveraged when it shows up in all three phases of the Learning Continuum. Here are a few things that we learned and experienced by way of results:
- Calls to the Help Desk went down by nearly 80%
- Time spent in classroom training went down by nearly 50%
- Errors that required IT intervention went down and so did the amount of beer we had to buy them – no other IT metrics were tracked at the time, but beer and pizza costs plummeted
- PSOs were reused in classroom, on-line training, as well as being directly accessed without ever thrashing about in the LMS looking for them.
- Updating PSOs at a single point also served the function of updating training automatically because the same PSO served both the “P”, the “D” and the “R” with the same content.
- Data captured on which PSOs were being downloaded flagged for us [Training] those opportunities to investigate why they were being downloaded in the first place. In some cases, we used those findings to update training content to do a better job in the “P” and the “D” phases of the PDR framework.
The birth of PDR was around 2003 or so. What made implementation a challenge was the limited EPSS capabilities at the time. Web 2.0 was still a pipe dream in Geekdom so directly accessing PSOs was a function of the SAP on-line Help systems which was virtually worthless. We over-layed another package on top that helped, but it was still limited. Nevertheless, our results were startling and broke a lot of traditional rules regarding the use of design protocols like ADDIE. Actually, what it did was make us consider ADDIE three times…on the “P”…the “D”…and the “R”. We also had to put on the performance consultant hat and dig into the work context to ferret out performance issues users were having using the application. Not that SAP is not…koff…intuitive and user-friendly.
Today’s Web 2.0 technology and the latest EPSS technology blow the doors off what we had in 2003. The methodology and approach using the Continuum are still spot on however. Pricing has come down, and by comparison an high-end EPSS a fraction of the cost of a LMS. Depending on the degree of functionality you need, a free WordPress site could potentially handle some of the requirements including the social aspects most LMS systems cannot offer. Many of the newer LMSs can, but after drinking the PSO Kool-Aid a few years back, I’d be hard-pressed to prioritize dropping big bucks on a LMS when I can implement a system of PSO support @ the point of work for less than the sales tax on a big LMS. Who knows, you might just avoid implementing a system that everyone is going to hate anyway…but that’s another story for another day.
If you are getting closer to the edge and may be feeling the urge to jump into Performance Support, feel free to reach out as I have several of those t-shirts in my stash already. It may be an easier transition to evolve your training to support performers @ the point of work than you might think.
Learning & Performance Solutions Strategist