Can I safely say we agree that task-level execution and business results do not happen during training? That seems a reasonable statement to me. We can certainly simulate task execution during training, but the simulated environment is structured and controlled and no harm is done when a learner screws up. Even when done well enough to pass the training, no business results are generated. However, when the learner graduates from training and simulations and becomes a performer there is no safety net, and flawless execution within the workflow has real business risks hanging in the balance.

This downstream, post-training work context is where our design philosophy may be exposed. More importantly, if our training design methodologies truly are exposed, it’s for what they lack in including the post-training work context into the final solution. Maybe my background in performance consulting is skewing my thinking, but I think we could be missing key drivers in making fully informed design decisions by ignoring post-training business performance expectations. As a point of clarification, providing the necessary knowledge to execute a task is not the same as enabling flawless task execution at the point of work. Knowing what to do…and being equipped [supported] to effectively do what needs done… are the equivalent of comparing great training to the effective application of learning. We train the former…and we support the performer on the latter. This distinction becomes a liability when we treat performer support as an add-on to training or as an after-the-fact development cycle rather than including it as part of our core design discipline.

If all we are doing is developing checkbox training, this is less of an issue. On the other hand, if the training is tied to business performance outcomes that are very task-centric and have a variable degree of role specificity, then we have the additional duty to extend our design. This is particularly important with business systems implementations. Having survived SAP, PeopleSoft/Oracle, and medical records systems implementations, there are no lingering doubts that we should seek to extend the blend beyond the training event to support our performers who are expected to flawlessly execute their tasks in their respective workflows. This is a design game changer.

Putting Last Things First

Integrating Performer Support (PS) discipline into an existing design methodology requires close examination of task-level work requirements in the work context. Work context being defined as where the workflow is executed. Part of our needs assessment discovery should include the work context. We need visibility to actual workflows and the associated tasks that produce results…not just final results, but interim results within a workflow that may be the root cause(s) for final results coming up short. These “interim points of failure” may represent Performer Support Opportunities (PSOs).

And the only way to uncover these points of failure is to examine the workflows with a SME. Once the PSOs have been identified we have to move them up in priority in the design process. These PSOs should not be kept exclusively for post-training PS…a.k.a. saved for last; they should be factored into the initial design early on so PSOs become part of the learning experience. Avoid task-centric training that does not have an associated PSO integrated with the simulation or other experiential activity. It is during these learning experiences that there should be some reflection of “where” the work is ultimately executed and that reflection has direct implications on design and development decisions.

The work dynamic of a performer being mobile and up a pole messing with a gazillion volts of electricity may carry more risk and urgency for flawless performance than a performer sitting at a desk pounding through a pivot table in Excel. My point is that we have to consider the attributes of the work environment…PLUS…what performance must be executed there.  As I’ve said before “hair on fire is not the time to log into the LMS for a Fire Safety course.”

Personally, and in spite of my bias, I cannot see a way to avoid mapping workflows by role. Take a SAP implementation as an example. I only need to learn about how to execute the requirements of my job, not everything there is to know about SAP. Even after ten years I still awaken in a cold sweat dreaming about procurement protocols when all I really needed to know was how to transfer an employee to another department. And to be quite honest, no one is going to remember enough from the training to execute anything in the software anyway…so why train them in the first place?

Whoa, now there’s a question to consider, eh?

Should we even bother with training? Whaddayanuts? Sure we should, but look through the performance lens in addition to the traditional knowledge transfer lens when designing and developing the training experience. I’ll stipulate there needs to be effective knowledge transfer during training, but here are my thoughts on what needs to transfer and what needs to happen during training:

• Transfer – Know WHAT PSO(s) are available to support the workflow
• Transfer – Know WHEN to access the right PSO from within the workflow
• Transfer – Know WHERE to go to get this life saving PSO
• Apply – Demonstrate the ability to search and access the appropriate PSO
• Apply – Demonstrate effective application of the PSO in a role-based scenario
• Apply – Rinse & repeat…for each PSO for that role and transaction

So what parts of this are really new? Believe it or not, none of this is new. What is new is what I’m suggesting we do with PS during our design decision-making. PS is a discipline; more specifically, it is NOT a post-training discipline, and that’s where PS normally finds its default role. And all too often the evidence that PS is needed is the real presence of tangible business loss…because somebody screwed up in their post-training work context. If we move PS from last resort to early insertion into intentional design, who knows how much damage we could avoid?

So…is this a business application system only kind of strategy? Not exclusively. PS has a natural fit in the business systems training realm, but when you get right down to it, virtually everything we do is a process. PS would have a role-specific benefit to something as human-based as on-boarding. There are roles ranging from corporate leadership level activities to departmental to work group specific, to individual orientation. How many hands touch the new hire? How many points of failure surface as frustration in that new hire within the first sixty days? Hmmmm…might be a good time to interview a pod…or is a gaggle…or a herd…of new hires and see where things broke down for them. Once you have those points of failure dive into a bass ackwards design effort and get the right PS into the right training and into the right hands at the moment of need.

Gary G. Wise
Workforce Performance Advocate, Coach, Speaker
gdogwise@gmail.com 
(317) 437-2555
Web: Living In Learning
LinkedIn