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. And let’s not overlook the ultimate goal and most critical phase of fully sustained adoption.
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), Electronic Performance Support Systems (EPSS), 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 and was still a long way to adoption.
- 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.
- Adoption = Users are unconsciously competent and use the systems as a matter of routine without threats or bribes of blue jean Fridays.
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 knowledge transfer is not enough to sustain performance outcomes. I makes this statement at conferences where I speak as a matter of routine…
Training does NOT drive performance – Training drives only potential!
Sustaining performance outcomes and solidifying competency is a post-training PROCESS called implementation. Training deployment is an EVENT…a transaction – standard practice if we follow a Training Paradigm. However, if we want to sustain performance at the Point-of-Work in the post-training implementation efforts we need to shift to a Performance Paradigm.
That means 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.
This is where the concept of Embedded Performance Support – EPS represents the core of a Performance Paradigm. EPS brings the Point of Work into the classroom through task-centric, role-specific experiential activities and/or simulations. The “training” experience needs to be embedded with the Point of Work…AND…the exercises should require use of the EPS technology as a matter of practice. The same PS objects developed for post-training contextual support should be those very same PS objects that require 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 workflows…versus the burden to remember/recall how to do every transaction in the software.
Being hired into that company in mid-deployment gave me an advantage because I had not been sucked so deeply into the earlier 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 to a performance orientation. 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. As I stated earlier…we created potential…not sustainable performance results!
It is only after the fact…after GoLive…that we confirm it just was not enough. Training 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. Implementation was left up the the Help Desk…and man did they ever get smoked with call volumes.
Of course, at the time, no one…especially me…was thinking in terms of learning ecosystems, or continuous learning, or just-in-time, or performance support assets, or EPS technology, 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 Learner-to-Performer Continuum came from – where performance is driven at the Point of Work through the use of an Extended Blend design technique – 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 – at the Point of Work – especially at moment #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 – ONLY! The Help Desk was left to fend for themselves on the other three moments. Integrating the Continuum changed that line of thinking.
The resulting shift in my 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 through Extended Blend 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 and via the same technology whether in class or at the point of work.
• No training would be delivered the Learners that the Help Desk would be excluded from the use of…and the access to…all PS assets that the end-users would use. The Help Desk 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 with technology in place supporting EPS, and every end-user knows how and when to access them…from whatever device in their possession…from wherever they might be…and when the moment of need surfaces.
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 to the point of full adoption. 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 considerations 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, and adoption would likely have been an assumption.
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 to a Performance 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 , and that is part of doing the job. Doing the job flawlessly requires overcoming moments of need three thru five. That ain’t training, folks! It’s a prime example of where the EPS discipline is required.
Making matters even more challenging is the proliferation of mobile technology in the hands of our workforce. Phones, pads, tablets, and wearables 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 within the business application and receive contextual performance support in three clicks or less. Give me choices…maybe it is a short form learning object…or a video clip if visual support is the best venue…or access to collaboration with a SME…or 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 only 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”! Stop by Workforce Capability, my new website and consider partnering with a Human Performance Outfitters on the road to full adoption!
Workforce Capability Architect