Choosing to use “disruption” twice in the same statement, especially regarding the discipline of embedded performance Support [EPS] is not just a tactic to form a snappy title. The reason is bigger than that. Does adopting EPS as a discipline really have to be disruptive? Any good consultant would answer a question like that with two simple words, “It depends!” Why? Because there is more than one disruption going on when choosing to pursue the EPS discipline.
Think about it; when any major decision to make a change in tactics or strategy, disruption to existing paradigms and methodologies stand to be upended. Certainly, we can agree that there is some disruption in the chaos of adoption change and overcoming resistance to new methods. But it’s bigger than that.
Something had to tip the scales in favor of even considering taking on a different tact. What was it? Something or a combination of some things had to happen. Something significant enough to make it worth breaking long-held beliefs; something serious enough in terms of business risk that trigger actions to shift thinking…challenge attitudes…and unsettle embedded values. Something disruptive has either happened…or is happening…to the environment in which our business operates to the extent we have to do something different.
I just read an article in CLO magazine [September issue] entitled “Disruption: the Key to Meet Today’s Customer Needs” by Brian Lambert. The subtitle reads, “Today’s customers know exactly what they want. To meet these demands, organizations will have to shake up development strategies and collaborate across business silos.” I could not agree more, and when you consider what we [Training] have to do “to meet these demands”, disruption to existing paradigms are up for examination.
The opening sentence, “Change and complexity are creating a variety of productivity problems in today’s workforce.” Read that again…productivity problems. Where and when are these “productivity problems” manifesting? It ain’t during training. It’s bigger than that. It is manifesting when and where we need the most effective performance out of our workforce – @ the point of work. Again, that ain’t training.
I suppose that are a number of variables we could point to as catalysts for change that are shaping the business environment. The velocity of business. The continuous nature of change. The competitive marketplace demanding agility and resilience of our workers. The list goes on. To me, these are all symptoms of the drivers and/or restrainers that affect performance. What I feel is at the root of these symptoms is a phenomenon I’ve written about before – convergence.
“Productivity problems”…to me at least…and maybe my view is shaped by the curse of being a performance consultant…stem from deficient performance. But…deficient performance is also a symptom. Of what? Depends. Somewhere in the list of things that limit effective performance are one or more root causes that are impeding productivity.
The manifestation of these root causes typically surface as one or more “moments of need”. Moments of need are triggered by the convergence of a workflow requirement with the need to effectively perform. Simple enough…but what is required in order to effectively perform? After diagnosing countless performance deficiencies over the years, I can say with confidence that it is some “thing” that supports the performance required at that moment of need.
That “thing” is some sort of asset that was intentionally designed and developed to be accessed and applied at the moment of need. That “thing” might be a live collaboration with a SME. It could be a 15-second video clip viewed from a tablet. It could be a downloadable job aid, or something as stupid-simple as a laminated card hanging from a lanyard around the worker’s neck on a clip with their ID badge. Whatever “it” may be, it was intentionally designed to support performance at an anticipated moment of need.
Before we can intentionally design anything, we must have some idea about the environment within which performance is expected to take place along with the attributes that will be present when the performance is supposed to take place. We need to enter the Performance Zone in order to accurately define the attributes that will shape our intent when we begin to make design and development decisions. Step away from the Training Needs Assessment…yeah…told you it was disruptive…and define a few other things first including:
- Who – From a functional role perspective, who is involved in the performance. Not just the “doer” but who supports…who is upstream causing complications…who is downstream cleaning up the mess from mistakes?
- What – From a performance outcome perspective, what is actually being done? What is produced? What does the outcome look like?
- Where – From a proximity perspective where does the work take place? Where within a workflow does the breakdown occur?
- When – From a timing perspective when does the work action take place…not just time of day/night, but how often – frequency? What happens that triggers the need to act…seek causes, not symptoms.
- How – From a work completion perspective how does the work task get accomplished? What systems are involved? Ties in with “where” and points to networking and security implications.
- Why – From a who-gives-a-rip perspective why is this work being done in the first place? What value is generated for the business? What is the business criticality of successfully completing the work…or failing at it?
There are more, but these are a few considerations.
Do you have enough information to build a storyboard? No. Not yet anyway. Sure, you can make some assumptions about learning objectives, but why launch into an 8-to-16 week design and development cycle for an hour of e-learning when the evidence is potentially staring you in the face screaming for a performance support [PS] job aid needed at the point of work? Disruptive? Yup! Agile? You’d better believe it. Pick one…70:20:10, SAM, AGILE. This is where an agile methodology will shine, but like I said earlier…step away from the storyboard…it’s not time yet. Fight the urge. Intentionally prioritize impacting performance ahead of transferring knowledge. Read your discovery findings and seek out that incremental PS object you could pound out in less than a week and implement it directly into the workforce [a pilot user group is best] to field test using the same technology that would ultimately be available to the larger audience. Gather some feedback on things like:
- Is it relevant to the identified moment of need?
- Is it effective at the identified moment of need?
- Is it accessible to the performer at the identified moment of need?
Yes? No? Maybe? If not, find out why and iterate. Refine your PS object(s) until your user population tells you the PS effectively solved their moment(s) of need.
Evaluate the impact derived by your incremental PS implementation and generate some level 3 and 4 evidence of impact. And during all of this…you have not even pumped out a final storyboard to begin development for the traditional course. Who knows…if the problem has been resolved, you may not need the course to be as extensive as you first thought. And another thing…that PS object you just validated in the field is now fair game for replication and insertion into role-specific, task-centric experiential exercises should you purse the development of an entire course.
How can you cause a disruption in a long-held training paradigm without introducing technology? Well…you probably can’t, but here’s the trick; don’t go there…at least not yet. Besides, budget has already been allocated for the year, and who wants to be the unlucky schmuck to go ask for more money? And by the way, IT is booked solid with projects for the next three years and the likelihood of adding a shiny new electronic performance support system [EPSS] into the implementation workflow has lousy odds. So what do you do? Generate proof that EPS is not just real, but that the business impact it will return on the investment just might blow the doors off something that is perceived as a higher priority. Been there…done that…got money where there was none…IT support as well.
Start small. Do not set out to boil the ocean. Take a path where you can impact a tangible business-impacting performance challenge with PS. Technology-wise you likely already have the tools in the kitchen. Use SharePoint or tack a URL onto the intranet or portal if you have one. Enable a “two-click, ten-second” accessibility environment to connect a performer with a moment of need to the PS asset that will resolve it. We’re not talking rocket science here, we talking expediency. Facilitate convergence with what you already have and measure the results. Your results may well prepare you for building a compelling business case that justifies that bright shiny new EPSS.
What do you think? There are too many moving parts here for this to be a simple journey into the Performance Zone. I mean, if it was simple, everybody would be doing it, right? Adopting a new discipline is never simple. What we’re talking about here with EPS is a transformational change initiative. Organizational change must be managed gradually through a multi-stage EPS maturity model. Start small and scale is the approach…the seed…that is planted. Planted where? Somewhere in the business, there is an operational business stakeholder with a performance challenge that PS can address. Your solution approach will be a welcome disruption from a steady diet of training solutions that did not deliver results.
I’ve uncovered more than one simply by using the discovery approach I shared earlier. That discovery was triggered by a “training request” that turned out to not require training as much as it required a performance solution. Never has a stakeholder turned down a solution that positively impacted performance and sustained their workers’ capability.
So…why isn’t everybody jumping on the EPS boat? I’m probably the wrong person to ask because of the biases I own due to having been on board with EPS for ten years now. Despite my own biases, I am seeing across our industry, a greater number of companies exploring EPS as a viable alternative to driving workforce performance. With no hesitation, I predict that we are going to need a bigger boat.
EPS is poised to change the rules of engagement. That CLO article I mentioned up front in this post point to the need for disruptive approaches to driving productivity. We [Training], in turn, will need to embrace disruption within our own sphere of influence and contribution toward driving productivity through supporting sustainable performance in the work environment.
How do you get there? Start by defining your own readiness. Define where you are on the EPS maturity model. Start small and scale. Become part of a new community of learning and performance professionals who have taken the plunge into EPS and who can share insights and learnings of the journey.
I’m one of nine members of the Leadership Council of a new Performance Support Community [PSC] being rolled out as I write this post. Bob Mosher and Conrad Gottfredson are founders of this new community and are unveiling the PSC at the Performance Support Symposium 2014 in Boston today [9/9/14] where six of the Leadership Council are presenting.
I was unable to attend the PSS2014, but am fortunate enough to be speaking at DevLearn 2014 again this year in Las Vegas on October 29th. This post is somewhat of an abstract of my breakout session scheduled for the 29th – Session 212 – “How to Integrate a Disruptive Embedded Performance Support Methodology” at 1:15PM on the Performance Support Track. I do not have details yet, but am confident the PSC will be active at DevLearn and will likely meet as a group and with new and potential members at the event as well.
I welcome any of you who will be at the conference to sit in my session, and I look forward to deeper conversations in the event the opportunity presents itself afterward.