In my most recent Point-of-Work knowledge share with the Western Michigan ATD Chapter in Grand Rapids, Michigan, I confirmed successful implantation of a few seeds of new thinking and more than a few seeds of reflection that said, “Holy new paradigms, Batman!” I saw evidence of more questions than could be addressed in our short time together. One unasked question showed up on faces when I mentioned the significance of determining ‘interdependencies’ in a learning performance ecosystem when pursuing a Point-of-Work Assessment (PWA). “Why is that important?” was the unasked question. The answer to that question yields a couple questions of my own, “How many times have we (L&D) built awesome training solutions to solve symptoms…and miss the root cause(s) behind productivity restrainers in our process?” and ”How many times have we ignored the Ripple Effects influencing or being influenced by our solution decisions?”

I confess to being guilty of these practices myself and encouraging it in teams I led in days gone by when we were outstanding L&D order-takers. A combination of adopting the Five Moments of Need agile design methodology; a healthy dose of Six Sigma discipline as a Green Belt; and my own PWA methodology changed both perspective and approach leading up to learning performance solution development.

The Six Sigma discipline contains a Supplier – Input – Process – Output – Customer (SIPOC) model that tracks nicely with Ecosystem Productivity Flows. (See Figure 1) This graphic is a snippet pulled from my PWA Workshop, and it shows the relationship of a primary Point-of-Work target…could be an individual job role or a functional workgroup. Typically, the Process component is the source for realizing a productivity/performance deficiency. Since it is focused on a suspect PROCESS, there are likely multiple tasks included; hence, the potential for multiple Points-of-Work…yielding multiple points of failure or compromised performance…multiple roles involved…multiple reasons for restrained productivity…and plenty of proof for an operational stakeholder to order training specific to the perceived under-performing workforce tasked with the suspect PROCESS in question. Taking that order puts L&D on the path to expertly attempt to solvesymptoms with a training solution. Been there – Done that!

Figure 1

Every process has someone or some group (SUPPLIER) who deals with some type of stimulus (INPUT) in order to execute a series of tasks (PROCESS) to create some type of OUTPUT for delivery to an entity (CUSTOMER) who may be the ultimate end-user or another group tasked to perform a continuation of PROCESS of their own.

The mistake that can easily happen comes from focusing only on the suspect PROCESS and ignoring two critical considerations:

• The Upstream PROCESS providing their OUTPUT that serves as INPUT to the suspect Process
• The impact from solving the suspect Process whose OUTPUT serves as Downstream INPUT

Could it be the suspect PROCESS is reflecting a symptom (a RIPPLE EFFECT) of an upstream deficiency? Also, what RIPPLES will your solution create for the downstream PROCESS? Trust me when I say a 50% productivity improvement can become a new and bigger problem when the downstream INPUT/PROCESS only has 15% capacity to handle the increase from your OUTPUT. Been there – Done that too!

In my last PWA Workshop, the participant used the PWA methodology to address a training request to upskill the field technical support function with more training due to a number of deficiencies that restrained productivity and caused delays leading to sub-par customer responsiveness. (The ORDER)

Through using the PWA methodology, it was determined that the tech support problems were not a lack of technical support knowledge or skills. Actually, the source of problems turned out to be upstream delays ranging from organizational design challenges, compromised workflows, product problem ownership, and lack of urgency to respond with technical team follow-up. The PWA revealed training was NOT the solution.

Without assessing root cause(s) within the suspect PROCESS, investigating upstream never would have happened and more precious time and resources would have been invested in building training solutions that would not deliver the desired improvements in productivity and performance outcomes from the suspect PROCESS group. Been there – Done that as well!

Now…you may be asking, “So whose job is it to fix that? It’s not in my job skill set or job description.” And you would be correct. The point is…it should belong in somebody’s functional role either in-house or out-sourced because taking and filling ORDERS for training is not sustainable. This is a problem L&D must own sooner than later.

The six categories of performance restrainer attributes used in the PWA also track nicely with the Ecosystem Productivity Flow as well as the SIPOC model. (See Figure 2).

Figure 2

As you can see, there are overlaps with Ecosystem Productivity Flow and PWA methodology attributes and the critical importance of accurately assessing the Ecosystem holistically. That said, I think it important to note that the PWA methodology is not an agile design methodology; PWA is a front-end diagnostic analysis or, if you prefer, a pre-design discovery exercise that builds a solution road map intended to inform whatever agile design methodology you choose to follow. My personal agile design recommendation is the Five Moments of Need where the PWA road map informs where additional work and priority needs to focus on things like Critical Task Analysis and assigning business priority to content solution build decisions.

So…does adopting the PWA methodology mean you need to rush out and buy new performance support technology? No, but as you experience business value creation and the viral nature of content asset volumes being built, you likely will need to consider a technology support system. Managing and maintaining content volumes will force you in that direction. You can develop a proof of concept by using hot-links on the task bar in your browser and SharePoint. The only downside is the inability to scale when things go viral…and they will. But…the good news is that the value creation you will be able to report should serve as justification to make the investment to keep up with the demand. The question that will soon rise up is “What system should we use?” Beware the shiny object syndrome…

The standard consultant’s answer is, “It depends!” And yes, there is a Readiness Assessment that should road map technology requirements to build Use Case scenarios that mirror your Ecosystem’s requirements. The alternative is slow death by RFI/RFQ. Use Case rules! Technology CANNOT be allowed to dictate your methodology; tech decisions must flow from current state AND future state learning performance requirements and your org readiness to deal effectively within the new capability you are about to unleash. With the rush to Digital Transformation, alignment with the “rest of your cloud” becomes a really big deal in how to optimize your Ecosystem.

Thanks for reading. As always, I welcome questions and comments as you may be so moved to share!

Take good care!

G.

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