Business Systems Deployment: Driving Implementation & Adoption with EPS
READER NOTE: This is a re-post that has been updated based upon new learning and experiences as well as a couple new links.
This could easily turn into another rant, but I will press ahead anyway and attempt to make a point or two that addresses the question, “How can we not see this?” The “this” in my question represents the desired outcome we anticipate but rarely achieve, even with our best training efforts to equip our workforce to deliver – sustained capability. To support my point, I will address this sought after state of performance by defining sustained capability as consistently flawless execution at the point of work.
For further definition, the point of work is where role-specific, task-centric performance takes place and generates a tangible business result. In this post I am referencing enterprise system deployment, but in reality you could substitute any non-system process flow in its place. Whatever the performance example you choose to envision, I’m seeing a very bright light shining on an increasingly troublesome phenomenon I call convergence. What’s converging? Quite simply…
The need to LEARN is converging with the need to PERFORM
I suppose I could say that this convergence has ALREADY happened and we’re just trying to figure out how to best address it. Part of our challenge is WHERE this convergence is happening. Once again…at the point of work.
With the velocity of business increasing such as it is, we have little choice but to enabling access to the right assets to the right Performers at their moments of need. The closer to the point of work we can make that happen, the closer we are to sustaining capability. To me, convergence is a key driver behind the momentum to integrate a critical new discipline by all L&D teams – Embedded Performer Support [EPS].
That blissful state of sustained capability we desire for our workforce population is put at risk every time there is a change in the work environment; add a new system where workflows and/or processes are disrupted. The most visible disruptions include:
- New business systems brought on-line
- New users brought into a system or process that is “new” to them
- Systems are upgraded to new versions or patched that change user interactions
I doubt there are many [any?] who hope for less-than-flawless-execution when users access critical business applications that have the potential to create chaos when mistakes are made. And yet, we continue to perpetuate a false sense of user readiness by relying upon Training to ensure they are capable of executing flawlessly in the post-training environment – the point of work. “How can we not see that Training alone falls short?”
Enterprise Resource Programs [ERPs], Client Relationship Management systems [CRMs], Electronic Medical Record systems [EMRs], and Sales Force Automation systems [SFAs]; to name a few of the chaos creators, do not represent a complete list. Basically, any “system” that involves workflow(s) that have role-specific and task-centric performance requirements are targets. That means that even a process like On-Boarding or any other human system could/should be included.
I’ve written a couple of blog posts previously that go deeper than I will go here, so you might want to check them out if you have time:
You can probably guess which one is a bit tongue in cheek but the message is clear: There are differences between deploying a system and implementing one, and we cannot expect Training [no matter how excellent it may be] to be completely effective during Deployment and then expect successful post-training Implementation to build user competency to the ultimate point of full Adoption.
I see a successful integration of any enterprise-wide business application as three major deliverable phases – Deployment – Implementation – Adoption.
Deployment represents a major milestone for both IT and the Training team. Often there are one or more big gala GoLive parties with clowns, 3-bite shrimp, and face-painting. I’ve been a participant in many of these in my career, and have even been to a couple that had an open bar after the system had been turned on and delivered to the business. Deployment is a chance for many involved to breathe out at a job well-done. Deployment is not the end, it marks the beginning.
Whether there is a party with all the amenities or not, a milestone has been reached worthy of a celebration. No argument there; however, neither of these business functions can turn away at GoLive and call it “Complete” because it merely marks the beginning of the next phase of activity – Implementation. In reality, this role may be more important for Training than IT.
I’ve been guilty of washing my hands of responsibility at GoLive because everybody was trained. Job well done…and it was…but it was two additional phases short of full adoption and sustained capability. In other words, our scope was two phases short.
Turning away after deployment took place because that was what we did…and many of us do today…because that’s what our paradigm…what our Training discipline…calls for us to do. Get everyone trained and we satisfied both our scope and our charter as a Training organization. Doing our job exceedingly well within our scope and charter does not make it right.
My argument is that this is not a Training deficiency; rather; it is a discipline shortfall. By adopting and integrating an EPS discipline that deficiency will never show up again.
This critical activity is where we often find reactionary damage-control and mad scramble by support staff, help desk, and subject matter experts. We also find a hostile gang looking back at Training with disgust written on their faces inferring we did a lousy job of creating a state of readiness in the workforce. Excessive finger pointing prevails and every effort is taken to place the blame on somebody…anybody…and why not Training?
Sadly, implementation duties often default to the Help Desk staff who do not have enough resources [both bodies and support assets] to satisfy the demand. It truly is not exclusively theirs to own, that’s just where it lands after the GoLive gala event.
I’ve seen large conference rooms set up as internal “call centers” with 100+ people and phones and special wireless routers installed to field calls from users needing help from the middle of a workflow. I’ve seen SMEs wearing red vests and roaming the work space watching for a user in distress. How expensive and unsustainable are those solutions?
Implementation activity is where countless individualized 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 [see Figure 1] begin to surface when knowledge retention blatantly fails. Training was never designed, nor was it ever intended to be applied in this downstream, post-training work environment.
Full system adoption is ultimately what we seek. Actually, I would say adoption has been reached if we have succeeded in creating sustained capability. Adoption is an outcome – a final state – where work tasks are routinized and users willingly execute their assign tasks. Adoption means things are “business as usual” despite being in a new state.
What is important to note is that the process…or the journey…of reaching Adoption has implications of Change Management all over it. Change Management requires that Performers have been an included and an informed part of the CHANGE from the beginning. Looking back on a Medical Records challenge I survived; even the most resistant, elitist, skeptic, senior physicians were led through the change effort targeting them specifically.
PSOs are satisfied by versatile, role-specific, task-centric assets that span formats from downloadable job aids – to assets that are system embedded – to social interactions – at the point of consumption by users.
When you consider what these PSOs may include, we find a number of asset formats that do meet fit into traditional training ISD models or methods. There are too many moments of need that are specific to the individual Performer to maximize the use of traditional ISD approaches. If you recall, we need our assets to be role-specific and task-centric. I feel those attributes point us toward being more agile.
Agile Design & Development
Agile methodologies targeting instructional design are popping up like mushrooms after a summer shower. My caution is to investigate the flavor you choose to adopt, because I’ve seen and researched several and quickly find some better equipped to integrate the EPS discipline than others. Some are aimed at rapid training development as a primary outcome and represent only lipstick on the training pig.
More specifically, we must look beyond WHAT assets are created and identify instead “WHY & WHERE did these assets come from?” The rules of engagement regarding instructional design have changed when you are targeting the post-training point of work. Surprisingly, the point of work is where your agile design efforts should BEGIN.
That answer falls outside of our current Training discipline. Forget ADDIE. Forget SAM. Forget whatever tradition ISD model you prefer to use; because nothing about this post-training work environment is linear, structured, or controlled. This ain’t training!
This is about individual performers’ Moments of Need, and their PSOs require the integration of an evolved EPS discipline that drives:
- Intentional design that begins at Moment #3 – APPLY
- Incremental rapid development to impact work performance as soon as possible
- Iterative deployment via technology for review/feedback… and/or immediate integration of Performer Support [PS] assets outside of…and possibly in lieu of…formal training courses we typically rely upon.
The EPS discipline calls for an evolution in design methodology to something that is more holistic and agile than simply satisfying Moments 1 & 2 to safely arrive at the Deployment GoLive party. Implementation requires PS assets that support flawless execution at the point of work – at the Moment of Need.
Those same PS assets can certainly be used to support training, but the secret of their design is what I am calling INTENTIONAL – intentional in that they were designed FIRST for consumption at the Moment of Need and often from within the workflow at Moments 3 thru 5. Again, that ain’t training!
At the end of the day, your agile design and development methodology should be intentional enough to address all five Moments of Need to ensure that:
- LEARNERS experience PS assets during simulated work contexts during their formal Training in the run up to Deployment, as well as what may be implemented incrementally as pre-training PS.
- Training ONLY happens if training is required. If intentionally designed PS is developed as a result of agile methodology, why pursue the time and distraction of developing a course/module?
- Actual PS assets are inserted with role-based scenarios in the event training actually IS advisable.
- Those PS assets are accessed from whatever Embedded Performance Support System [EPSS] technology users will be expected to use post-training.
- HELP DESK staff is trained on the same PS that they will “push” to Performers who call for post-training assistance.
- MANAGERS are equipped with the same PS to reinforce training [if there was any training] after the fact during meetings to refresh or as onboarding aids to new hires.
- Training from PS mean that PERFORMERS only have to remember where/how to get the PS versus remembering every step of a process they might use infrequently.
- PERFORMERS become ADVOCATES and pull the SKEPTICS toward Adoption with positive experiences using the application.
- PERFORMERS willingly provide feedback on 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.
In the fourth bullet above, I referenced a piece of technology called an Embedded Performance Support System [EPSS]. The EPSS options in the market are also popping up like mushrooms. Caution! Some are glorified content management systems while others have on-board authoring features that can create workflow documentation simply by walking through an application. Actually, EPSS is a piece of software that runs on your own servers or may be cloud-based depending on the vendor you choose to use.
EPSS is not SharePoint, though SharePoint can be a perfect content repository behind the EPSS…as well as the content Management System [CMS] or document system, or policy management systems, or methods and procedures stash, or streaming media content, or whatever else may be directly addressable via a URL.
The point to note here is that the EPSS does not have to own any of the content. In many respects, the EPSS acts as a “broker” and serves as a single point of access to PS assets that reside elsewhere. In many larger applications, like ERPs, EMRs, and Call Center software, the EPSS is “embedded” within the application itself. This means PS are available from within the workflow – the user never leaves the application to get help – and PS is screen sensitive – and only the PS a specific role needs to see will be shown.
The more advance EPSS platforms are beginning to sport SMART capabilities that can proactively intervene when a user is about to make a mistake in a workflow entry. Some even have “push” capabilities that inform users of new processes or new data entry requirements when they reach the screen where that update is relevant. The SMARTest EPSS platforms even anticipate errors based upon entry data and then push a warning real-time. That takes just-in-time learning to a whole different level. And just for the record, training on updates was just eliminated.
All technology chatter aside, there are a couple of things I think are critical before you go dropping a dime on a sparkly new EPSS:
- You cannot make an informed EPSS solution decision until you know the scope of the learning and performance support environment [ecosystem] that you plan to maintain.
- You should not integrate EPSS if you are wrapped around the axle of ADDIE as your instructional design methodology – You need to embrace an agile approach to prevent redundant and often unnecessary design, development, and delivery efforts.
- Find an internal sponsor who has a tangible pain point that is costing the company money and hard dollar benefits can be derived from an EPS solution that targets those key performance indicators.
- Cutting over a new EPSS is not like cutting over a new LMS. Start small and scale.
- If EPSS is new to you, find a resource who has traveled the road before.
- If you are not agile-proficient, you need to get there…and upon arrival you will clearly see why an EPSS is very likely to be in your future.
Okay, so this post may not earn rant status, but who am I to judge my own work? I cannot apologize for the passion because I am beyond convinced that we all need to become more agile with the creation of PS assets and how they could…if needed…be re-used as part of a formal training effort. By saying that, I’m affirming that training is not going away. But make no mistake; the role of training is rapidly being challenged by the need for more agile content that is directly tied to PERFORMANCE OUTCOMES versus the effective TRANSFER OF KNOWLEDGE. The importance of training is being eclipsed by EPS discipline where organizations have experienced the positive impacts by integrating that new discipline.
The point is we need both Training and PS…and both are part of the EPS discipline. BUT…if I can use an agile methodology to identify, prioritize, and create PS assets in a couple of days, I may not need training in the first place. My question to you is this; “Is your focus on Training or Performance?” Maybe another question should be addressed as well; “Are your business owners/stakeholders focused on Training as the only solution to address performance issues?”
Chances are good that your stakeholders are locked down on a Training Paradigm because that’s what we’ve been selling them for years. I’ve done it. We’ve all done it. And they bought it! Now we’re in a box of self-inflicted perception that we’ve created with our own promises that training is going to drive performance. We need to get ourselves and our business stakeholders out of that box…re-position thinking and expectation for performance impact to downstream and into the post-training work context where Performance and the Performer truly matter.
That sounds simple, but it contradicts what we’ve been selling forever; hence, why I suggest finding a sponsor with an identified performance pain point that is tied to real dollars. I guarantee that one small EPS success will create an advocate for you and your future EPS and potential EPSS ambitions. Knock one EPS implementation out of the park by showing tangible level 3 & 4 impacts, and you will find yourself facing the need to scale your capabilities and grow your EPS integration to the point of adoption.
Gary G. Wise
Learning & Performance Solutions Strategist