Backward Chaining Development
Develop the Test first to meet the Learning Objectives, then the Practice, then the Demos if needed, and then, finally, the Content? Or do most, in your experience, just jump in on the Content first?
Backward Chaining in Design
If you met with a client to conduct a Design effort – without doing any analysis first – you could use this approach in Design and then in development. You’d use my Lesson Map format…
Start with their Learning Objective – and just write down what they say – as you can always come back and amend it after roughing out the design further.
Then have them describe the Test and/or Practice Exercises (APPOs or Application Exercises) – which is how whatever content is eventually developed/deployed will be used back on the job. BTW – the Test is simply the last Practice Exercise/Application Exercise. And … if the exercise isn’t an authentic application (real world) compared to the job tasks – then work that until it is.
Then determine if a DEMO would be helpful to those who will participate in the APPOs. It’s not always necessary. But other times several DEMOs might be needed: full speed & slow-motion speed and then full speed again.
Then determine what INFOs – Content Topics or sub-Tasks – are needed prior to the DEMOs and APPOs.
The go back and wordsmith everything – if that’s really needed. It’s not always needed.
Backward Chaining in Analysis
If the client can’t help you with filling out the Lesson Map – you can begin to discuss the need for some quick Analysis to get on target.
Working with 1 SME or Master Performer is to be avoided as they can miss up to 70% of what a novice needs – according to the research. You’ll need to conduct many reviews with others to help fill the gaps. It’s quicker to facilitate a group of Master Performers as they’ll likely be happy to correct each other. :)
Start with Outputs and the Stakeholder Requirements – which will typically take you downstream as well as in the Process (Tasks) to determine who the Stakeholders are and what they Require (needs … and wants perhap). Then after settling on Outputs and their Measures reflecting those requirements move to Tasks.
Tasks also have Measures – and Standards – which reflect those Stakeholders who care about Process.
One you have that – determine what Knowledge/Skills are needed.
I use 17 Categories of K/S to tease those out.
Backward Chaining is a Useful Approach
I’m surprised that it’s not mentioned much any more in ISD/Training/Learning articles and Blog Posts.
Back in the early 1980s it was mentioned a lot. It was all the rage – so to speak.
# # #