Using the phrase “EPS Technology” is probably a mistake when you consider Embedded Performance Support [EPS] is not a technology; rather, it is a discipline…that has technology implications. What I’ve experienced over the years is our tendency toward embracing the technology too early and then wind up trying to make our business requirements fit into whatever was purchased…or whatever we got talked into by a vendor.
The actual technology component is known as Electronic Performance Support Systems [EPSS], and in reality, outside of the servers used to deploy it, is a software application. EPSS is not new technology/software; in fact, it has been around since the early 1990’s. Back then, EPSS was “tied to” another business application, meaning there were actual connections to the code of the primary application and the EPSS. Basic intent behind today’s EPSS is similar in it provides contextual support to the user while using the primary application…like SAP, Oracle, SafesForce, etc. That’s where the similarities end.
Contextual Support in the Performance Zone
The concept of “just-in-time-just-enough-just-for-me”, a phrase I first heard used by Aaron Silvers at Training 2013 in Chicago, epitomizes the concept of contextual support. We design Learning for a multi-user audience for consumption during a Training event. Performance Support [PS], on the other hand, is designed intentionally around role-specific, task-centric workflows. To be even more specific, workflows within which a single user may have a moment of need.
This intentional design discipline represents a core driver behind EPS. What makes it contextual is enabling user access to the exact support content/ resource at the moment of need…AND…from within the actual workflow…AND…at a point within the workflow discrete to the user experiencing the moment of need. That “point” may well be different for each user as they work through the process flow; hence, the “just-for-me” becomes an individualized moment.
Regardless of who the user may be, or where in a 17-step workflow they may experience a “moment of need”, they are in a work context Gloria Geary wrote about in her book “Electronic Performance Support Systems” called The Performance Zone. See Figure #1. In short, the Performance Zone is the downstream, post-training, work context I refer to as “the point of work”. This is where role-specific, task-centric work takes place with the intent to support business drivers necessary to meet specific business goals, and ultimately, strategic goals.
The objective of contextual support is to enable access to the performance support assets necessary to execute at the task-level effectively and efficiently. “Effectively” means as error-free as humanly possible. “Efficiently” implies accessing the asset(s) quickly…and that often means “at the point of work” and from within the actual workflow. The EPS design target should enable access within “2-clicks & 10-seconds”…not that 3-clicks and 20-seconds would be a problem. The point is…the less time to access exactly what’s needed [just enough], when it’s needed [just in time], for the task at hand for a user [just for me], the better chances for solid performance outcomes.
Figure #1 is a variation on a pyramid concept I saw first used by a colleague, Bob Mosher, that I call the EPS Stack. To me, the “stack” represents the structure of the EPS discipline, while the extreme right side of the illustration shows the technology pieces and parts. I will address the “stack” first.
The EPS Discipline
The top three layers of the stack are to me the primary domain of the “2-click, 10-second” target for accessing PS assets. The moment of need is addressed from within the workflow which may or may not be an actual business enterprise system. In effect this is a drill-down opportunity driven by the nature of the “just-for-me” moment of need. The “stack” is accessed by clicking a “help” icon from within whatever workflow the moment of need is encountered…meaning the user does NOT have to leave the application or the workflow to access “help”. Some vendors enable this through a link within the app itself, while others operate outside the app and have the link in the task tray at the bottom of the browser screen.
- Context – I often use the example of a map kiosk you look at to find where a specific store is located in a large shopping mall. This could be a “site map” for a business application or a role-specific workflow with clickable icons for each step. If this is not enough support, other components in the stack are directly accessible from this top layer.
- Steps – This layer offers high-level, step-by-step instructions specific to the role of the user accessing the guidance. Again, if additional information is needed, the next layer is easily accessed.
- Detail – This layer offers up greater instructional details and supporting information. Often this level may contain screen shots and even access to simulations.
- Brokered References – The beauty of the EPS discipline, and the potential inclusion of EPSS technology is the concept of “brokering” assets. This means the content used for support already exists someplace else and does not need to be duplicated for inclusion as Performance Support. A great example comes from my clinical days in healthcare where there was a Clinical Policy Management System used by the nursing staff where small procedural documents were stored. The EPSS does not replicate any of this content, it merely links to it. The EPSS is a “broker” not a content repository in and of itself. Another common example is where SharePoint is the adjunct repository and the EPSS links directly to the content via URL. I’ll talk more about SharePoint in the next section.
- Structured Learning – This is a perfect example that illustrates how an EPSS can be “in front of” the LMS. Yes, ‘tis true, the LMS does not have to be the oracle of all learning content. The point of having structured learning in the EPS stack is to facilitate the single point of access to learning and performance support from a single point of access. No, I’m not trying to start a turf battle with the kind souls who manage the LMS; instead, I’m building an environment where I…me…as the user…and the one with a moment of need…is free to make the decision of how far down the stack I need to go…and never have to leave the application I’m in. Call it efficiency if you like. That said, if I’m launching into the LMS, I probably need to leave the application anyway, but why not give the option? Seamless access to the learning and support needed is our driving objective here.
- Social/Collaboration – Believe it or not, Performance Support is not all downloadable job aids and cheat sheets. Access to a SME or a content owner may be the best point to satisfy my moment of need. Maybe it is a targeted Yammer group for a specific project team. Maybe it is more passive than that and access to best practice communities or blogs are most relevant to meet the moment of need.
Regardless of where within the “stack” a user may go, somewhere along the line some very intentional design and development decisions had to be addressed regarding the work and the roles that are expected to execute upon it. That is NOT something ADDIE was ever intended to support. That said, what supporting the Performance Zone implies from a design perspective is something that will render:
- User agility in the execution of task-level work
- User resiliency to change within workflows and work conditions
- Content agility in the context of rapid development of performance support ahead of learning content
- Content relevance to the extent just-enough-just-in-time-just-for-me is a common product
- Content accessibility to ensure users can access what they need…when they need it… from wherever they may be… and from whatever device(s) they have at their disposal.
Those five attributes should frame whatever “agile” methodology your organization adopts. If that statement sound assumptive about adopting an “agile” methodology…it is…and you should. I go deeper into this in an earlier post on “intentional design“.
Shiny New EPSS Technology
The EPSS technology that was around when Gloria Geary wrote the book I mentioned earlier [in 1991] was tied to business applications and had to be directly connected to the host application. Directly connecting to a primary application from another application is something IT folks wake up at night hearing the echoes of their own screams. At times they may throw things at you in the event you make a request for them to plug in an API to an enterprise business application. Chances are they are too busy and too many other priorities to even consider doing you a favor. That used to be a really big problem that made adopting EPSS a difficult effort.
With Web 2.0 technology and a precious few of the EPSS platforms able to key on the user’s browser, there is no longer a need to poke the IT bear to plug anything into anything else. That’s way cool, not to mention the cost of EPSS is way low compared to something like cranking up a new LMS. In fact, there is no comparison to any other system because EPSS does not lend itself to a flash cutovers like other enterprise systems. I’ve written many times about “start small and scale”, and those are words that true EPSS gurus all agree are sound advice.
Going back to Figure #1 you can see right away that there are options to protect your existing investment in content repositories like Documentum, technical spec libraries, SOP repositories, SharePoint…just to name a few. Frankly, any content system where content, media, steamed content, etc. can be accessed directly via a URL are fair game for EPSS to broker the user to it.
SharePoint is a perfect place to start small and scale. SharePoint may soon lose its appeal as your core EPSS technology when the number of content objects becomes too unwieldy to manage. I’m not saying SharePoint runs out of gas when it grows too big to manage, I’m suggesting SharePoint cannot give you the visibility to data usage points and essential tracking and feedback you will need when your EPSS grows up to maturity. SharePoint may still serve you well as a “back-end” content repository forever and ever amen, but the additional functionality you will require is missing.
As another technology example that SharePoint cannot fulfill, some EPSS platforms have a “predictive” component that can intervene from within a workflow to prevent mistakes that are “in progress” by virtue of a bogus user entry. This is cool and moves us even closer to eliminating training altogether as it is a fail-safe workflow the provides guidance that eliminates mistakes in a workflow.
There should also be a feedback loop available between the end-user and the content owner to facilitate usability and relevance feedback; not just rating and ranking. And there are other features…BUT…I would be the first to take an existing SharePoint platform and use it to build a small proof of concept from which I could extract real business impact data regarding the viability of adopting the EPS discipline and even so far as integrating EPSS technology. And that impact data can be used to build the business case for fact-based ROI on an EPSS purchase once you have a successful proof of concept in the tank.
Another point to note, not all EPSS vendors are endowed with the same capabilities. Some have sweet spots in specific industry niches. Some have a service offering that is modular and you do not have to buy the full-monty up front…or ever need to integrate the contextual link to an application. If the business need is around rapid workflow documentation, there are vendors who specialize in that with a component of their platform that does not require the EPSS component. It truly boils down to what your business requirements look like at inception and then again as you scale. If it were me going down this path, I would seek out a vendor who could scale along with my EPS maturity as oposed to making me buy something with larger capabilities and then grow into them. Advice? Nail down your business performance and learning requirements up front.
A perfect example is using the authoring capability of one such vendor to whack up to 70+% off your workflow documentation efforts on the front end…and use that same documentation as source content for training development…and output that same content as simulation output…or to mobile technology…and have single-source documentation for rapid update of workflow AND training docs in one swipe…and do all this with only a freaking plug-in to MS Word. We’re not even talking about EPSS yet…and may never need to go there. Truly, I’m on the verge of a RANT here, but everything you choose to do…everything…must be directly tied to your business requirements and your business objective specific to a performance and learning environment.
This ain’t about technology. Send out a dozen RFPs, and you’ll get 8 of them back. All of them will have “YES” checked off as something they can do. And then where are you? Right, ya got zip! Pick the top three with whatever good luck charms you have, and good luck, brother! Unless you have clearly defined your business use cases…and have adopted an agile methodology…and have the capability to accomplish the intentional discover that goes hand-in-glove with intentional design…it’s coming down to a coin-toss. And the result will be an under-performing piece of software because you bought into a technology over adopting a discipline first.
EPS as a discipline is THE most exciting evolution I’ve experienced in my career in corporate learning and development. EPSS technology may be a next step after adopting EPS as a discipline, but not always. Every vendor has a solution that will look good. It will be bright and shiny. Some are shinier than others, but don’t let the shine of the technology drive the decision, let the shine of the demonstration of that technology doing what you need it to do be the driver.
Sorry, this might have become rant-like, but hey…it’s how I roll.
As always, I welcome your thoughts and experiences…good, bad and ugly if you’re so moved.
Performance & Learning Solutions Strategist