This title may seem a bit odd, but both can end badly; especially if a deployment effort for an enterprise-wide system like ERP, or CRM, or [insert the application of your choice here] relies upon effective training to ensure full adoption. Trust me, I’ve been down this road a couple times now and have an impressive string of failures. No…I was not foolish enough to soap up a monkey that was at least ten times stronger than me, but I have witnessed multiple system deployments that ended poorly.
Certainly there were GoLive parties and celebrations by IT for getting the application launched, and Training had their post-training party after all end-users had been trained. All that marked arrival at a place called Deployment. What about Implementation you say? Sadly, that was left up to the Help Desk.
End-users? Yeah, good luck, buck-o! Call the help desk. Ask a colleague. Make an educated guess. Or if you’re really motivated, wade back into the training content and find that screen shot that tells you what a particular screen is about. Never you mind that there is nothing even close to a workflow that describes step-by-step…and by role…what task anyone is to actually complete on that screen.
Been there – done that…and have done that as a part of Training [hence my reference to failures] and as an end-user who would rather bathe an angry orangutan.
What was missing? How about ADOPTION?
Adoption of a new system is very similar to the process of building competency; in fact, the same methodology accomplishes both – Embedded Performer Support [EPS]. Competency in the use of a business application implies end-users [Performers] are equipped to execute tasks flawlessly; whereas, Adoption implies end-users exercise their competency willingly and consistently. Implementation of an EPS solution enables competency at the point of work. Without it, you may as well bathe the ape and deal with the absence of adoption. I would add; however, that EPS alone is not enough. There is a change leadership component that promotes the creation of critical mass necessary to foster acceptance.
Poor change leadership [some might call this change management] does not create the momentum required, nor does it communicate a compelling WIIFM to engage Performers across the board. This happens regularly in the healthcare market with the growing deployment of Electronic Medical Records Systems [EMR]. Ever confront a senior physician who is clutching his or her manual charts to their chest as they eye the computer with disdain? Think orangutan…
I see a successful integration of any enterprise-wide business application as a series of three phases of effort:
- Deployment does indeed represent the completion of a lot of hard work by both IT and Training. Neither business function can turn away at GoLive and call it “Complete” because it merely marks the beginning of the next phase – Implementation
- Implementation is where Performer Support Opportunities [PSOs] exist in spades because Performers are in their respective workflows and hands-on with the system. This is where moments of need begin to surface when knowledge retention blatantly fails. This is where many attempt to wash the monkey with little to no success…but plenty of frustration…and as many errors…and negative ideas about ever “liking” the system…ever. So forget the final phase and plan on living with a hacked off monkey.
- Adoption is ultimately what we seek. Performers have been an included and informed part of the CHANGE from the beginning; even the senior physicians were led through the change effort targeting them specifically. Performers were equipped from the very beginning with relevant PSOs specific to their roles and task expectations. Adoption is a product of intentional design that enables:
- LEARNERS to experience PSO content for the first time during simulated work contexts during their formal Training in the run up to Deployment. Actual PSOs are inserted with role-based scenarios. They are accessed from the Embedded Performance Support System [EPSS] they will be expected to use post-training.
- HELP DESK staff is trained on the same PSOs they will push to Performers who call for post-training assistance.
- MANAGERS are equipped with the same PSOs to reinforce training after the fact during meetings or as onboarding aids to new hires.
- Training from PSOs mean that PERFORMERS only have to remember where/how to get the PSOs versus remembering every step of a process they might use infrequently.
- PERFORMERS become ADVOCATES and pull the SKEPTICS off the monkey with positive experiences using the application.
- PERFORMERS willingly feedback issues and challenges that serve to better prepare the next batch of LEARNERS…not to mention aid the HELP DESK…who by the way are taking 40% fewer calls.
EPS is a discipline that drives intentional design that does NOT follow the ADDIE or most other ISD methodologies. The authoring role changes from a content orientation to one more aligned with business context. That alignment of content [PSOs] to a business context within a business application is the job of EPSS software and consistently serves up some very sweet benefits. The design methodology must be as AGILE as the content to be used by Performers. I must quickly add that not all EPSS platforms provide every benefit equally, but I am convinced the results will be positive. The effort to identify your specific business requirements for aligning to the right EPSS is an essential first step. Consider a couple of routine benefits you can expect depending on the platform you choose:
- Reduce documentation time 80-90% – Workflow documentation virtually writes itself as simulations are built and can be edited with annotations and embedded links to resources or data points
- Reduce scenario training up to 50% – Given training is reduced to role-based scenario activities, training time is dramatically reduced versus training on every aspect of the application. Some organizations have experienced up to 70% reductions in training time.
- Reduce Help Desk volume by 40% – With Performers equipped with PSOs from within their respective workflows, they make fewer calls to the Help Desk…plus when the Help Desk does receive a call, they coach how fish from the EPSS versus giving up a fish every time
- Reduce creation of material waste – If we can prevent errors at the point of decision in a manufacturing setting, less material waste is produced
- Reduce business liability from errors – If we do not make mistakes that incur business liability there are major litigation expenses avoided
- Reduce loss from flawed execution – Any error that is going to cause rework, or redundant efforts, or delays that can be avoided and directly impact the bottom line
- Reduce search time by Performers – At the Performance Support Symposium September 9th & 10th, Ontuitive shared some research on search time stating that on the average, employees spend 9 hours per week searching for information – 25% of what they find is the wrong information – and typical search costs per employee annually averages $14K. EPSS, when properly configured and a solid taxonomy is in place, should optimize search in two clicks or so, and require only 10-seconds of time invested.
- Reduced time to competency – Fewer mistakes in the workflow by being equipped to execute flawlessly enable competent performance sooner.
With all this good news around EPS and EPSS, why do we insist on wrestling an aggravated ape? If I knew the answer to that I would not be spending time writing blogs or working for a living. But such is life when a paradigm like Training has been baked into a reality we’ve lived with forever. Even our stakeholders bought into the promise that training would drive performance. We [Training] sold that to them. Heck, even our own people in the Training organization bought it. I did…hook, line and sinker.
When I dug deeper and evaluated the root causes behind what was becoming a longer list of failures…despite designing, developing, and delivering some really sexy, sizzling hot, blended training content. Training was only ever targeted, scoped and chartered to transfer knowledge – not equip a workforce to execute flawlessly at the point of work. This was not limited to “system” roll-outs, it proved to be a valid root cause with the results of sales and product training too. Failure was not the result of poor training; it was poor expectations of what training would deliver.
Transferred knowledge, no matter how good it was, did not translate to sustained capability at the point of work. The light finally went on for this camper.
Quite frankly, I’m done with trying to wash the monkey and getting my rump kicked every time. The more sustainable endeavor, from my hard-earned perspective, is integrating EPS in ANY enterprise system activity I come across including:
- A brand new system;
- An upgrade to an existing system;
- A new user population coming in as part of a business acquisition; or
- Coming in behind someone who has already lost to the monkey.
It is time to try a different approach, and EPS is truly the shortest distance between Deployment and Adoption.
Learning & Performance Solution Strategist