Okay…so my trigger got tripped this morning on a white paper put out by HR.Com…which was very well done, by the way. What tripped my trigger was not what was included in the article, “An Overview of HCM Technology Deployment and Factors Influencing the Strategy”, but what was left out. For me, it was a gaping hole that I had fallen into earlier in my corporate training life – reaching deployment [GoLive] – is not the end of the effort; instead, it marks the beginning of implementation.
In past lives, I have survived installations of numerous SAP modules, a couple of very large LMS systems, a significant Oracle/PeopleSoft HRIS upgrade, a massive Epic electronic medical records system (EMR) and several smaller Oracle/PeopleSoft module installations. A very ugly SAP installation was the first exposure to anything significant for me, and I quickly learned that deployment did not equal implementation.
- Deployment = Big gala GoLive party with clowns, 3-bite shrimp, face-painting, and an open bar in a couple of the deployments after the system had been turned on and delivered to the business.
- Implementation = Reactionary damage-control and mad scramble by support staff, help desk, subject matter experts. Includes those who look back at Training with that look of disgust on their faces inferring we did a lousy job of creating a state of readiness in the workforce. Excessive finger pointing to place the blame on somebody…anybody else.
Yes, this is a bit tongue-in-cheek, but after having been beaten about the head and shoulders [figuratively…but with no less malice of intent] over a post-deployment SAP fiasco. I learned that getting to deployment was the easier role for Training to accommodate. This next part may be confusing, but hang with me. Training’s role in deployment should have been more difficult…not in the sense of building and/or delivering blended training…not in the content design effort…not in the development process…but in the pre-design discovery process. What SHOULD have added complexity to the routine of the ADDIE workflow was the absence of the missing “D” – the DISCOVERY – that did NOT happen before the training needs analysis was accomplished. Some might argue that discovery does indeed happen in the training needs assessment…and I would agree…it does…to an extent. My argument is based on the limited focus that typically limited on what a learner needs to KNOW. Nothing wrong with that, it transfers knowledge, but it’s not enough to sustain performance outcomes. Sustaining performance outcomes and solidifying competency is a post-training PROCESS called implementation. Training deployment is an EVENT…a transaction.
The missing Discovery that did not happen should have been based upon what end-users were going to DO within their respective roles and responsibilities in the use of SAP at their respective points of work. The missing Discovery that should have happened would have mapped workflows and noted transaction points that defined TASKS using the software specific to PERFORMERS and their ROLES. Those transaction points would have been indicators for Performer Support (PS)…or job aids…or quick references…or cheat sheets…or whatever you wish to call them. Point is this…those PS assets should have been integrated into the Training blend. Experiential activities and/or simulations should have been developed that were based upon those very same PS objects, role-specific and targeting critical tasks within SAP that required hands-on execution/practice/simulation exercises, etc. during Training.
Why? Goes back to the difference between recall knowledge versus reference knowledge. The latter plays the larger role these days because there is waaay too much for a humanoid type person to recall. Training should focus on participants being proficient in “recalling” where the “reference” content resides…when to use it…how to access it at the moment of need…and how to use it in the context of their respective workflow…not recalling how to do every transaction in the software.
Being hired into the company in mid-deployment gave me an advantage because I had not been sucked so deeply into the deployment training efforts. My lens was colored by the stakeholders whining about how bad the previous SAP training sucked. When I reviewed the training content I found some top-drawer design had been used, awesome development techniques had been used, sizzling Flash, etc. etc. The gap was not based on quality or quantity, it was based on timing and the limits of knowledge retention. The time between training and the ribbon cutting party at GoLive…a.k.a.DEPLOYMENT. Nearly six and sometimes as many as eight weeks had elapsed. We all know what happens to non-reinforced knowledge retention in less than 30-days with upwards of 90% of it evaporating.
We succeeded in deploying excellent training, but we failed in the post-training implementation efforts. For this camper, that is when my paradigm changed. My entire epiphany was based upon the desire for self-preservation. I really hated people telling me the training sucked. It did not. It did exactly what it was designed to do – contribute readiness to the workforce through knowledge transfer. It is only after the fact…after GoLive…that we confirm it just was not enough. It was never designed to support implementation. Training did not have the reach…did not have a compatible format…did not provide knowledge that was “sticky” enough to get to the post-training work context “edge” of the learning ecosystem where we would support Learning @ the Point of Work.
Of course, at the time, no one…especially me…was thinking in terms of learning ecosystems, or continuous learning, or just-in-time, or PS assets, or learning @ the point of work, or any of that. The training paradigm of the day did exactly what it was supposed to do, but the scope was limited by nature of the paradigm itself. That is where the idea for the Learning Continuum came from – a selfish move on my part to build a self-defense solution. Whatever gets you there, right?
Seriously, issues creating havoc for the Help Desk could not be solved by our Flash-based e-learning content, nor the binders full of of beautifully formatted information used by instructors in the classroom segments of the training blend. All the pain came from transaction-level roadblocks – role-specific and task-centric moments of need – especially #3 trying to remember or apply. [See Figure #1] If you have been a reader of my blog for a while, this is not new, so excuse the repetition. In this model, we handled…as our paradigm allowed…the first two moments of need. The Help Desk was left to fend for themselves on the other three moments. The Learning Continuum changed that line of thinking.
The resulting shift in my learning paradigm came from a very ugly trip into implementation after enjoying a celebratory deployment. I walked away with a couple of promises to myself that I would never allow that to happen again. Those promises included:
• No training would be designed or developed until clear indications of performance expectations and tangible evidence of performance outcomes had been identified and mapped at the task level…and by role.
• No training would be designed without integration of PS assets that would be re-usable to the extent that simulations by the LEARNER would use the EXACT PS they would be expected to use in the post-training work context as a PERFORMER.
• No training would be delivered that the Help Desk would be excluded from the use of…and the access to…all PS assets that the end-users would use. They would be enabled to “push” PS on demand to any user in distress anywhere within the workflow.
• No deployment would ever be allowed to reach GoLive until the necessary PS assets were in place…in whatever repository was available…and today that new Web 2.0 technology is the Embedded Performer Support System [EPSS] and every end-user knew how and when to access them…from whatever device in their possession…from wherever they might be…and when the moment of need surfaced.
When you look at these “promises” I made to myself you will find some of them fall outside the scope, and in some cases, the capability of Training. If you find that to be true, you may be living in a broken, out-dated paradigm too. No offense intended, but the shortcomings of Training will never be addressed effectively until we get downstream and have the ability to implement learning and support in the work context. This implies a new discipline called Embedded Performer support [EPS]
Deploying training is not enough, no matter how good your Flash or HTMLx developers may be.
Oh yeah, I suppose I should share with you what actually tripped my trigger this morning. There was a graphic in the white paper titled Five Things to Consider When Structuring the Deployment of HCM Technology. They included:
1. Org Structure Priorities
2. Provider Structure & Functionality
3. Technology Type(s)
4. Service Delivery Team
5. End-User & Other Populations
Each was defined thoroughly following the graphic, but nowhere in any of these five consideration was there a mention of training or support. References to “support” were limited to software support by the vendor and maintenance related efforts. The trigger was officially tripped at that point – flashbacks to ugly SAP deployment and accusations of suckie training. WHY would “five things to consider…” for a strategic deployment of something as mission critical as HCM technology NOT include even a slight mention of training and support? And I would bet even money that if training had been included, it sure as heck would not have been focused on the PS requirements in the post-training work context where implementation takes place.
Okay, let me catch my breath. Please, please do not allow yourself to go into the deployment of ANYTHING that does not include integration of the appropriate PS assets designed intentionally to address learning moments of need during downstream, post-training implementation of whatever technology, or process, or workflow, or whatever that requires sustained human performance rendering tangible, business-impacting outcomes.
The time has come for us [Training] to evolve our Training paradigm. That requires changing the conversation we have with our clients and more importantly with ourselves. I actually find more resistance to the shift in thinking from within the ranks for the L&D teams than with the business stakeholders who own the job of driving business results.
LEARNERS do not produce results – PERFORMERS produce results.
Competent performers produce sustainable results and that is a PROCESS of maturity within their assigned roles. Maturity does require additional learning that is part of doing the job. Doing it flawlessly requires overcoming moments of need three thru five. That ain’t training, folks! It’s a prime example of where the EPS discpline is required.
Making matters even more challenging is the proliferation of mobile technology in the hands of our workforce. Phones, pads, tablets, or wrist radio/TV gizmos in the hands of the workforce have blown past the limits of our Training paradigm. Technology is so far ahead of us that our design philosophies have some major catching up to do. The strategic application of PS assets @ the point of work require an evolved design paradigm, and if we embrace it a funny thing will happen – training time will decrease. Give me a device from which I can search on a keyword/phrase relevant to what I am trying to DO. Give me choices as the return on that choice that include training if I want it…or a video clip if visual support is the best venue…access to collaboration with a SME…linkage to a knowledge base. What else might I need? Go back the “missing Discovery” to slip into the work context and see where potential moments of need do…or might…manifest within the actual workflow. That ain’t training deployment – it’s holistic discovery of an ecosystem that can only be supported through effective implementation.
If you’re not sure how to integrate the EPS performance paradigm concept; ask! It’s not a matter of “IF” you go there; it’s “WHEN”!
Performance & Learning Solutions Strategist