Here comes another one…
Permit me to set the tone of this post with a question: “Why would we invest eight to sixteen weeks developing an hour of e-learning when tangible, incremental performance impact could be realized in a week with targeted performance support assets?”
Did you hear that sound? It’s hard to describe, but it sounds a lot like folks entrenched in a Training paradigm just clutched their storyboards to their chests tighter than ever. Relax. Nobody is taking your storyboards away; however, what you do with them might be a little different. Yeah, I know, “different“ can be a scary word too, but hey, the rules of engaging our workforce with performance-enhancing “stuff” have changed.
More emphasis is needed in the downstream, post-training work context where Performers confront moments of need that do not conform to what we build storyboards to address. Transferring knowledge through linear learning is great for raising awareness, but sustained capability in the form of consistent performance results happens downstream at the point of work. That’s where the rules of engagement have changed.
Having the good fortune to attend multiple conferences in 2013 as a speaker, I get the chance to sit in many other breakout sessions too. At every conference there were several sessions that focused on “agile” methodologies. I sat in every one of them and saw a couple of things that were disturbing. Not disturbing because of being wrong, but by what was being overlooked.
My first indoctrination to agile methodology came from a software implementation in a previous life where our IT design team took an out-of-the-box business application and began to modify it to meet the company’s workflow requirements. A series of short bursts of concentrated work on incremental components of the larger application called Sprints were then tested, validated and evaluated. The results were reviewed in Scrum sessions, and the Sprint/Scrum cycle was repeated – highly iterative.
The incremental implementation and iterative design concepts are key to the methodology shift for adopting “agile” as an instructional design and development methodology as well. Makes perfect sense, but that’s not what I found disturbing.
The rub for me was one of the primary motivations behind adopting agile methods specific to training seem to zero in on achieving rapid training development. One might ask, so what’s so disturbing about that? Maybe it is my bias toward driving performance as a priority over transferring knowledge…that few can retain long enough to apply. I’m disturbed that we are looking at agile only through the lens of a Training paradigm. Certainly, agile methods work for creating training quickly but there is a more impactful application overlooked. The emphasis on agile should be focused on reduced time-to-business-impact; not just reduced time to training.
Now…for those white-knuckling those storyboards, did I say anything that implied Training was no longer valid or necessary? No. So relax that grip and consider this. Go back to my original question in the opening sentence. It truly is not a question of should we train or not; it is a question of why wait on the final Training product to launch learning if there may be some incremental business impact gained through implementing increments [Performance Support- PS] assets in a week or so versus waiting through the full training development cycle. That approach does not preclude an hour’s worth of e-learning from being developed in any way.
What it DOES accomplish is validating smaller PS “objects” over four criteria:
- Agility – Are the assets in the right amount and right format to satisfy “just-enough-just-in-time-just-for-me” for the roles intended to apply the PS asset to drive the performance required?
- Relevance – Does the asset align with the performance requirements of the TASK in the workflow?
- Effectiveness – Do the reviewers [SMEs and/or pilot user groups] find the asset works at the point of work?
- Accessibility – Are the PS assets easily accessible through the destination technology [SharePoint or EPSS, etc.]…and…compatible with the end-user technology used to receive the “push” or initiate the “pull” transaction to access the asset?
That addresses the use of the asset for performance support. Now what? Those very same assets [now validated and tested as viable] should be included in the e-learning course or whatever blend is being developed. The same exact assets should be used as an experiential activity that is Intentionally Designed to train users on the following:
- Recall that there are PS assets available to help in moments of need
- When to use the PS asset
- How to get to the PS asset
- How to use the PS asset in the context of a role-specific, task-centric workflow
- How to get help beyond the asset if necessary
- How to provide feedback to the asset owner
You just might find that there is less time spent in Training because the instruction becomes more of a facilitation than a delivery. Plus, this approach is consistent with Charles Jenning’s 70:20:10 model, where the 70% piece is indeed experiential. But…here is another thing that gets me all raked up in a pile. There are some, whose names shall remain unspoken, who are taking the 70% of the Jennings model and attempting to build the experiential component into the Training product. That’s okay to strive for that, but why stop there? Put the experiential component – the PS assets – they practiced using in training in both the performance and the learning opportunities.
Maybe it’s a word order thing. Maybe if we switched things around and said we were going to build Performance & Learning Solutions we would have emphasis in the right order. I really believe bundling the 70:20:10 model with an agile [intentional] design and development is an attractive approach. This methodology places emphasis on incremental improvements to Performance while we build the formal Learning piece and, by the way, we are driving tangible business result sooner than later. Using that same bundled approach to only reduce time-to-training is like putting a flipper on a one-legged duck – still swimming in circles – but swimming them faster.