Stop Doing Limited Task Analysis
Back in the late 1970s and early 1980s I saw way too many results of Task Analysis that were seemingly random lists of disjoined Tasks. They could have been organized alphabetically and been no worse, nor better.
And then the Training that resulted most often became a series of Topics – that never quite made it back to Tasks and Outputs.
Start Doing Output/Task Analysis
When you “begin with the end in mind” – for Tasks – you should understand what the Output is from a set of Tasks – and – what the key Measures are for both the Output and the Tasks.
“How can you tell a good Output from a bad one?” I almost always ask.
Are they accurate, complete and appropriate? Timely compared to some due date? Done within the allotted Cycle Time? With Cost or Budget parameters? With zero, to some minimum standard, for Waste or ReWork? Etc.
Meeting those Measures make them Worthy Outputs, or not. Same with the Tasks. But the Tasks are the means to the ends of Outputs. So first things first.
An Output is an Input Downstream
That’s who, the downstream user, among others, are key to establishing the measures for the Output. Is it robust to their uses and perhaps to some level of mis-uses?
Is the Output as Input Robust to those uses and mis-uses? If not – then figure out what Task and resources need to be addressed to make the Output as Input more Robust.
It may have nothing to do with T&D/L&D/ISD.
Focus on the Performance Requirements – and Enable Them.
# # #