Trolling through my networking groups on LinkedIn yesterday, a post caught my eye where an individual was lamenting how the disjointedness of running disparate systems compromised effective and efficient operations. The suggested solution was a desire for the creation of a unified enterprise platform to eliminate the disparity. I agree that unification is the answer…but not among disparate systems.
Taking systems out of the equation for a minute, I believe what we are really seeking is sustainable operation by end-users across whatever mix of business applications are deployed in the enterprise. Where we have the greatest opportunity to unify anything is in the creation of readiness to perform in the end-user population. And no, this is not an exercise in training; rather, this is facilitating the convergence of learning and support into the actual workflow of these systems.
Disparate systems in the enterprise are disparate for a reason; each has its own core competency and function in the operation of the business. To unify them all under a single platform, we stand to lose the power of specialization that defines the “sweet spot” each brings to the table. If it is consistency and simplification we seek, then let’s go after what is common to all systems – end-user capability…or lack thereof.
Convergence Drives a New Paradigm
Rather than converge all systems into a single platform, let’s consider how we can converge operational support to a consistent look and feel regardless of the diversity of each systems’ workflow and operation. To accomplish this we should consider consistency on how we support users at their moments of need regardless of the system with which they are interfacing when the moment surfaces.
Focusing on Conrad Gottfredson’s Five Moments of need, we find the first two moments of NEW or first time learning and MORE learning to enhance of deepen knowledge align with our existing training paradigm and are delivered in any number of learning blends from classroom to online in its many varieties. When we get to moment three – the moment of APPLY – we find ourselves outside of the scope and charter of what Training was designed to support. Add moments four [CHANGE] and five [SOLVE] and we remain outside of the training paradigm.
In reality APPLY – CHANGE – SOLVE are most relevant when actual work is underway. What we see converging are work with learning and support. This new paradigm changes the rules of engagement when we must build effective solutions that integrate both learning assets with performance assets. The criticality of design and development decisions change priorities from leading with learning content to leading with performance support assets. This does not preclude training from happening; it simply reorders the application with the work context coming ahead of the learning context.
To stay close to the enterprise systems example I started with, what we are converging is learning and support with a diverse mix of systems and workflow, and as we all know there are plenty of both within any organization. Consistency is well within our reach if we take an intentional approach to designing both learning and support assets.
Agile design and development methodology is getting a lot of press lately, and rightly so. My position on “agile” methods is that they are a tactical approach that plays a crucial role in supporting a strategic discipline like Embedded Performance Support [EPS]. From what I’m gleaning from a number of conference breakout sessions I’ve attended recently and numerous dialogues within networking groups, I get the impression that we [Training] are leaving a great deal of what “agile” can do for us on the table. A leading motivation for adopting “agile” is to accomplish rapid development. Nothing wrong with that if Training is/was the only solution required to sustain performance capability.
EPS, when combined with a framework like Charles Jennings’ 70:20:10 model gives us a whole new set of “agile” aspirations. Add in the advantages of incremental “agile” design and we have opened the door to step beyond our limited training paradigm and use Intentional Design decisions to embrace a more holistic performance paradigm. [See Figure #1]
Converging learning with work is not a training function. I say this simply because of where convergence happens – at the point of work – and – at the end-user’s discreet moment(s) of need. Obviously, these moments of need are going to vary across the end-user population making a one-size-fits-all solution virtually impossible. For this reason alone we cannot rely on training to drive sustained capability.
Embedded Performance Support [EPS] represents a solution that resides within the workflow and is accessible on a contextual basis – meaning at a specific moment of need from anywhere within the workflow. This implies that Performance Support [PS] assets are intentionally designed to align diverse workflows with diverse role responsibilities.
Intentional design leverages an “agile” methodology to fist align PS assets on task level work with the various end-user roles that are expected to execute effectively and efficiently. Agile, in and of itself does not look at task-level work processes, nor audience roles or business criticality. That takes an intentional look prioritizing efforts based upon greatest opportunity to relieve pain and/or protect or improve business value. Agile is the paint brush; whereas Intentional Design is how we paint the room using that brush.
Role-specific, task-centric work associated with an enterprise business system transaction, or any workflow defined by a process, requires alignment with the actual work to be accomplished. Mapping the workflow may be required in some cases, but in all cases, task-level definition of the necessary steps to accomplish the task(s) is/are essential. Our driving objective is to improve time to business impact – not rapid development to speed training content delivery. Intentional Design places PS assets into the work context incrementally via the technology at hand and test it among users before training is ever completed. If we can close a performance gap with a PS asset in a week or two, why wait for 12-16 weeks for an e-Learning course to be completed?
Using the iterative nature of “agile” I can refine the PS assets that have been tested and then deploy them to a larger audience for immediate consumption while the course is being built. Those same PS assets are reused by embedded links from the course that take me to the same technology in the context of my training course. Those very same PS assets can then be replicated or reused to support post-training reinforcement by Help Desk, managers, mentors and coaches. I wind up with single source content assets that address all five moments of need. Each asset represents a single point of update for the multiple uses in play.
What makes EPS solutions different from training is the accessibility of incremental, task-centric objects on demand. That means the design decisions on how “granular” these incremental objects need to be are intentionally designed to match both the workflow and the moments of need where recall memory fails or where we confirm it fails during the validation phase of incremental implementation.
Given PS assets may include virtually any media or collaborative interactions we must ensure they address three tests in their application that are:
- Accessible – Readily accessible by the user at their moment of need
- Relevant – Relevant to the business task at hand
- Effective – Produce consistent results when applied at the moment of need
Intentional design enables defining the most effective media, mode, and venue of assets appropriate for the moment(s) of need being addressed. Given we often have a highly mobile user population and hundreds of work processes, PS assets range from short video segments; to brokered reference content; to simple downloads that illustrate steps of a process; and this mix [or blend] of assets falls nicely into a framework I call the EPS Performance Stack. [See Figure #2]
The EPS Performance Stack
I use the EPS Performance Stack [a variation on Bob Mosher’s original pyramid graphic] expanded it into a framework to illustrate the points of interface with PS assets regardless of media, mode or venue with technology and social resources. More on the technology later…
The EPS Performance Stack, to me anyway, is the secret sauce behind the EPS discipline. Intentional design is easily accomplished by satisfying specific moments of need through a potentially diverse mix of informal and formal learning and PS assets. The Jennings 70:20:10 Model is also a perfect backdrop for integrating the EPS Performance Stack. Let’s look at the pyramid stack first and then the technology implications.
- Context – Sometimes a moment of need only requires a little contextual orientation similar to a mall locator map that says “You Are Here”. This could be a visual string of icons that define steps and/or roles with little-to-no detail intended to orient the user at anything other than a high level. These icons typically link directly to more detail if/when required.
- Steps – Provide more detail regarding step-level information specific to the task when high-level context does not provide sufficient support. Additional links are embedded and accessible leading to a deeper level of detail if/when required.
- Details – This layer drills down to greater detailed information. This layer often includes screen shots and deeper description of the actions required within a targeted segment of the larger transaction.
- Brokered References – Refers to content/media that already resides in existing repositories. This enables direct URL accessibility to supporting information like policy documents, streamed-media clips, methods & procedures archives, etc. “Brokering” enables access to single-source assets eliminating the need to replicate content in multiple locations. Single-source content eliminates redundancy and facilitates easy and rapid content updates via a single effort.
- Structured Learning – At times, task-level support is not sufficient and the need for more formal learning is necessary. The beauty of the EPS Performance Stack shines through by giving the user the option to link to the LMS for a deeper learning experience. Notice that Structured Learning is not at the top of the Stack. In the 70:20:10 model, this is the link to the “10”; whereas the preceding four layers are often associated with the “70”.
- Social Learning & Collaboration – This layer represents the “20” in 70:20:10 and may include live collaboration among support groups like the Help Desk or mentors, coaches, managers, etc. At times, the link to more passive resource databases that contain knowledge objects, FAQs, best practices, etc., are appropriate to satisfy the moment of need.
Regardless of where or when the application of learning and/or support takes place, the power to choose the best asset is in the hands of the individual user…and is directly triggered by their individual moment of need. While the Stack shows a top-down framework, the user has non-linear options based upon where we embed the links within the Stack for directly accessing the right learning and/or support assets at THEIR moment of need.
Intentional design should consider all six layers of the EPS Performance Stack with an eye on re-use of content/media assets at all layers. A “create-once-use-many-times” mindset is good to follow. This means that a PS asset created for a specific moment of need could have multiple applications including:
- Primary use in DETAIL level as a specific job aids linked to directly from the application
- Accessible via an embedded link as a BROKERED REFERENCE asset
- An e-Learning course accessible via an embedded LMS link in the STRUCTURED LEARNING layer
- Used in the SOCIAL & COLLABORATIVE layer as reinforcement assets pushed by the Help Desk; as PS tools used by mentors, coaches and managers; or as part of a larger knowledge database.
Adopting the EPS discipline is not anything like implementing a new LMS or buying a new piece of authoring software. To be more specific, adopting EPS as a discipline is as much of an Organizational Change Management [OCM] initiative as it is anything else. The best way to look at this adoption effort is to consider it a journey with several key moving parts, not the least of which involves technology. Consider these change drivers:
- A cultural shift from a training paradigm to a performance paradigm
- Different conversations between training professionals and stakeholders having a perceived “training need”
- Expanding discovery to a more holistic context that embraces the Performance Zone
- Adoption of intentional design to leverage agile and the 70:2010 model
- Routinely measuring business impact at levels 3 and 4
- Adopting new technology as EPS adoption grows across the enterprise
That last bullet is the focus in this section because ultimately, EPS may require formal Embedded Performance Support System [EPSS] software in order to reach enterprise-level adoption. Again, EPS adoption is a journey of sorts that will mature as small successes scale to broader integration. [See Figure #3]
The EPS Maturity Model illustrates a journey that starts small and then scales. Starting small is critical mainly because of the implications that come with shifting a paradigm. The first push-back to anticipate is related to adding “another technology” into the mix. This is never easy to do, especially when IT is already locked down on a list of initiatives and budgets have already been allocated. “You want money for WHAT?”
This is where “start small and scale” is critical because you can start with technology you likely already own. I used SharePoint. On a small scale, SharePoint gives you most of what you need to accomplish a viable proof of concept. Generating tangible performance results at levels 3 & 4 are easily tied to hard dollars, and when visible proof of a return on investment is on the table, it is amazing how budget suddenly appears.
The battle with IT resources has dramatically been relieved because the newer EPSS technology no longer requires IT to build API hooks into an enterprise application…something they will always dig in their heels every time…and I don’t blame them. The last thing they want to do is put the integrity of an enterprise application at risk by adding a new component. The newer EPSS software only needs a browser to interface with to provide the contextual access to PS assets.
I won’t go deeper specific to technology in this post, but suffice it to say, don’t let the technology boogey man scare off an opportunity to adopt a performance paradigm and an EPS discipline. Stages 1 & 2 of the EPS Maturity Model may well be served with existing technology. Eventually SharePoint will run out of gas to serve your needs, but by then, you’ll have the ammunition to build a compelling business case.
As a performance consultant, I’ve survived numerous system deployments only to then have my teams fight their way toward sustainable implementation. Even reaching implementation, as it turns out, is not the final destination; merely another battle along the way. Deployment and implementation are but two of three essential phases of successfully integrating any system or process into the workforce. The final phase is where we need to wind up, and that is full adoption.
Again, let’s take enterprise systems out of the conversation for a second. If adoption is the ultimate win; what is the game? I would argue a point that has cross-industry relevance – we’re after sustained capability in our workforce.
Going to DevLearn 2014?
Stop by Session #212 on October 29th at 1:15PM for my breakout session on “How to Integrate a Disruptive Performance Support Methodology”.
Performance & Learning Solutions Strategist