Reading Neil Mosley’s post on LinkedIn the other day about Mirjam Neelen’s ATD article on “Improving Learning Transfer: From a Fragmented to a Whole Task Design Approach” brought to mind a couple of things.

One of which was an online exchange I had with Will Thalheimer (that I cannot seem to find) about “leaving the learner hanging” with Micro-Learning. That was my take anyway. He suggested that leaving them hanging was sometimes a good thing.

As always, I suspected that this was a semantics issue – probably due to me not explaining myself very well. It happens I’ve learned.

The other thought I had, related to the first, was that I always cluster “Tasks and Outputs” together.

Or rather, an “Output with it’s associated Tasks”. And then I cluster or link – the Enabling Knowledge/Skills back to one or more Clusters. Not the there could be more than one Cluster of “Output-Tasks” in what I call an AoP – Area of Performance. A chunk of Performance, if you will.

I always want to know “what Output” any “Task” is associated with. I always start the so-called Task Analysis with the Output. I long ago decided I had little use for Task Analysis outputs that didn’t organize Task around Outputs. They were useless lists IMO. But then, I was spoiled, having learned much better waaaaaaaaaaay back in 1979.

Chunking – and – Clustering – two sides of the same coin, or something like that.

The genesis for my thinking harkens back to Tom Gilbert’s warning – that I first read about in 1979 – about The Cult of Behavior – which is basically about addressing behaviors (tasks) in Instruction with no regard to the specific Outputs to be produced. Behaviors for the sake of behaviors – which I have expanded to all sort of narrow approach in the world of ISD – Instructional Systems Design.

So over the years (decades actually) I’ve talked/written about clustering in Analysis and in Design and in Development.

From page 143 of my 1999 book, lean-ISD, I address Output-Task Clusters in Design…

In my newsletter in an article describing my PACT Processes for performance-based ISD from 1993…

And from another newsletter about Design, from back in 2002…

Here is a Past Post from back in 2007 about this: https://eppic.biz/2007/04/04/the-pact-processes-and-workflow/

And one from 2008: https://eppic.biz/2008/05/30/the-performance-model-charts/

IMO you do no one any good INSTRUCTIONALLY if you don’t cover all of the Tasks – including both the overt, Behavioral Tasks of the WorkFlow and the covert Cognitive Tasks of the parallel ThoughtFlow – and the Output itself (which is an Input to somebody else downstream) – and all of the Stakeholder Requirements for both Output and Tasks.

Cluster that. Cluster them.

Whole Task may be more appropriately labeled as “Whole Output-Task-Requirements” – but then, that might just be a little too clunky, although much more descriptive and useful IMO.

###