Addresses analytical techniques used to determine educational or training program solutions. Participants examine human behavior and the role that instruction can have in changing behavior on the job and in society.
In the for-profit environments I’ve been employed in, the front-end analysis was a crucial part of the service my organizations provided to prospective clients. It was often reserved for very senior consultants with extensive experience in our field. The path they charted with the results of a thorough front-end analysis set the direction and progress of an entire training implementation, along with the duties we instructional designers would perform and when. My work life was in their hands.
In such an environment, however, the goal of the front-end analysis is not always to inform the client of what they need. You would think it is. But ultimately, what was expected of that role was to inform the client of what we could create in the way of end-user training that would address their requests. In other words, what the client requests is not always what they need. What we offered was what would make money for us and give the client what they asked for. To be sure, sometimes these goals do converge. But the whole point of our organizations was to make money, and we can’t make money saying to a prospective client, look, you don’t need a training program. You need [a systems reconfiguration, a different software, etc.]. So we often found ourselves creating solutions with an eye to our bottom line.
I tell you this anecdote not to disparage my previous employers, but to set the context for what was the most difficult part of this course for me to wrap my thoughts around: as the first step in the ADDIE paradigm, if one does the front-end analysis correctly, sometimes the result is nothing. Or, more accurately, an honest front-end analysis sometimes reveals that instruction is not the solution to the client’s problem.
In this course, we pursued several tech and non-tech scenarios to practice our data-gathering and critical questioning skills. The information we gather serves as a basis for making decisions about whether and how to offer instructional solutions. Formal tools are available to help organize our approach to what questions to ask and what the answers to those questions can tell us about a putative performance or learning gap. I especially liked the Behavioral Engineering Model (BEM), first propounded by the late psychologist Thomas Gilbert in 1978, along with the 13 “smart questions” posed by the late Joe Harless in his analysis of front-end analysis in 1973.
Gilbert conceived of his model as a diagnostic tool to investigate causes and potential solutions for closing a performance gap. He suggests addressing the steps to engineer human competence in this order:
Data → Instruments → Incentives → Knowledge → Capacity → Motives
Harless also gave me a useful list I intend to implement in my future front-end analysis duties. Regarding my previous observation that sometimes the result is a non-instructional intervention, the first of Harless’ smart questions is disarming in its simplicity: Do we have a problem? So often in my world, that question is not asked. More often what happens is we skip to a subsequent smart question. Harless’ questions are broken into three groups. The first group is the performance analysis group:
- Do we have a problem?
- Do we have a performance problem?
- How will we know when the problem is solved?
- What is the performance problem?
- Should we allocate resources to solve it?
From there, if you can answer all five of those positively, the next group is the cause analysis group. In other words, once you have determined you have a performance problem, you can go on to look for possible causes.
- What are the possible causes of the problem?
- What evidence bears on each possibility?
- What is the probable cause? (emphasis mine)
Only when we know the cause can we even begin to conceive of an intervention or remedy.
Harless’ final group of smart questions deals with intervention selection, design, and development:
- What general solution type is indicated?
- What are the alternative subclasses of solutions?
- What are the costs, effects, and development times of each solution?
- What are the constraints?
- What are the overall goals?
In determining a front-end analysis tool to use in our final project, I was particularly attracted to the Task Knowledge Structures (TKS) model, an outgrowth of the cognitive GOMS model first propounded by Card, Moran and Newell (1983). GOMS (Goals, Operators, Methods, Selection) was at the time a great tool for describing and modeling the skills and knowledge a learner must have to perform a given task. It grew out of attempts to model goal-directed tasks in computer environments. Problem is, in a performance-based environment, what one knows is secondarily important to what one can do. So, Johnson & Johnson (1991) put together a basic structure and model for applying the Knowledge Analysis of Tasks to complex performances. This later became TKS.
The environments I will be applying these tools to in future consulting, particularly in ERP settings, will likely not care as much about what one has in their mind (what one knows) as about what one can do (performance, the results of which are leveraged by other users in the same work environment to conduct a well-formed business process). I look forward to the opportunity to apply TKS to a front-end analysis for a future client.
Work Samples
I’m happy to bring you two outputs of my learning in this course. First up is a simple infographic of my conception of how TKS would work in an SAP setting.
I’m also excited to bring you a presentation I collaborated with Pooja Gupta and Raenalyn Loomis on, preparing a proposal for front-end analysis for a company based in Texas. This project was based on an actual front-end analysis I did in 2015 for this company, referred to by a pseudonym in the presentation. Thinking about how TKS and also the Critical Incident Method, another activity-based method, could apply to the outcome of my needs analysis for that company was a great way for me to assess how, in retrospect, the analysis could have been improved to the client’s satisfaction.
Final Grade: A
Card, S. K., Moran, T., & Newell, A. (1983). The psychology of human computer interaction. Hillsdale, NJ: Lawrence Erlbaum Associates. In Jonasson, D., Tessmer, M., & Hannum, W.H. (1999). Task analysis methods for instructional design. Routledge.
Harless, J. (1973). An analysis of front-end analysis. Improving Human Performance: A Research Quarterly, 4, 229–244. In Chyung, S. Y. (2008). Foundations of instructional and performance analysis. HRD Press.
Johnson, H. & Johnson, P. (1991). Task knowledge structures: Psychological basis and integration into system design. Acta Psychologica – ACTA PSYCHOL. 78. 3-26. https://doi.org/10.1016/0001-6918(91)90003-I.
Beth's Journey Through the Instructional Design Universe 