Why did I single analysis out but not design in my 5 bucket graphic for PACT?
The first reason is that I wanted it to produce the same analysis outputs, just using different methods and techniques due to the SCOPE of the instructional effort. Determining the performance-based needs at an entire job where the typical project life cycle is 3-5 years – versus – determining and providing content on the new program interface for enterprise-wide reporting of travel and living expenses – is very different in scope only. In the former example there might be one hundred key outputs produced – with the associated task sets and gap analysis. I call those Output-Task Clusters – clusters of data – a data-set. In the latter example there might be three. Or one.
Here is a Performance Model Chart page that captures two Output-Task Clusters.
I wanted that to be the standard output regardless of whether you captured it looking like that in a meeting of a group of Master Performers, or after a dozen interviews with various performers, managers and other stakeholders such as upstream suppliers and downstream customers. Or by observation. Unless the performance cycle is too long and you simply cannot take as long to do your analysis as it takes a project cycle to complete.
And the second reason is that I wanted to show the 3 levels of ISD “design” stacked. I can use that imagery to suggest a cascade effect, a BOM effect, a taxonomy for design – just as a house may have an artistic rendering of the exterior, and blueprints lay out the floor plans, and more detailed blueprints lay out additional details – all so a team of developers, err, carpenters and other trades, can build it in more of a parallel process than in a series process.
And “ISD is iterative” – forgetaboutit – I’ve never had a client that wanted to hear or see that. No home buyer wants to hear that. No instructional effort’s clients wanted to hear that.
Graphic of T&D Path:
Graphic of Lesson Map:
IAD is a subset of MCD in terms of outputs produced and task steps in the IAD effort. In other words, if you can do MCD you can do IAD. If you can develop a typical Event, you can construct tests, exercises or demonstrations and develop those first – if that is what best meets the client’s needs.
In IAD the intent is to produce certain components of the modular CAD design versus more traditional and current to meet the needs of the enterprise, versus just automatically assume that the next step is to develop all of the content of “the design” – when the thinking should be: where is there a significant return to be gained by developing, deploying and maintaining these gaps? Can the client ask for “just the performance tests” – or a series of job aids produced with the initial analysis data serving as the starting point for embellishment as needed? Can they set aside a Learning/Instructional/Social solution until they reengineer the process and the measures and consequences to get what they need?
My business partners and I had a client back in the mid-1980s who wanted to conduct the front end of the CAD project, and then jump to (what we now call) an IAD effort to produce what turned out to be about 2200 Performance Tests for about 20 target audiences, and then to design the CAD Paths for these, and then develop the priority gaps. Because the Performance Tests were part of a PPP – Progressive Pay Program, which tied everyone’s pay increases to proving performance capability in the battery of do-it tests for their job at one of five levels of pay, everyone was motivated to learn what they needed to learn and then prove it when it became their time to do the testing. And so doing the CAD design of Paths and establishing priorities for development of instructional gaps proved unnecessary.
Training avoided. Costs avoided. Performance Competence improved and documented and managed.
Here is a 1988 newsletter article on that project at Prudhoe Bay on Alaska’s North Slope: Getting Paid For What You Can Do
Here is a 15 minute video of me touring the facilities at Prudhoe Bay in 1987.
The analysis data from this project was useful to tie many HR-type things together, anchoring them all to an authentic description of Performance Competence requirements.
# # #