In a current engagement, we’re faced with the challenge of being given large goals. They can be learning, or performance support, or even just awareness. One of the things we’re wrestling with is how and when to break things up into smaller chunks. To be clear, this is about whether to put it into a separate entity, rather than how to segment within an entity. This isn’t an area of my expertise, I admit. As a consequence, I’ve done some scouring and pondering, and here’re some thoughts and my request for help with breaking up.
My initial reaction is that this is about curriculum. That is, the level above pedagogy: not how to teach, but what to teach. A term which made sense is ‘curriculum mapping‘. Which works for K12, but the advice I found wasn’t helpful in this instance. It seemed to be about iterating, which is good, but I was looking for some research-based principles. We don’t have external standards.
Asking around, my colleagues suggested it’s more like information architecture. I know a bit about information architecture, but not a lot. In general, I take it as organizing around the way users think about the content. Which is good for information, but not necessarily for learning.
Of course, your learning objectives should provide a guide. There should be a path from the learner’s initial state, through enabling objectives, to the final objective. That should define the scope of an experience. If it gets too big, then make one or more of the enabling objectives their own piece. In this case, we’re taking something already created and trying to make sense of it.
Really, I’m fine with that latter, but I just wonder if there are any evidence based principles to guide this thinking. Something besides seemingly sensible breakups. It all seems based upon perception (and iterative testing). However, I wonder if there are metrics, or a principled basis. Hence, my request. I’m asking for help with breaking up. What am I missing? Any pointers?
Guy W. Wallace says
I would organize performance-based instructional content around the Output and its associated Tasks. Enabling K/S might be separated as they might enable more than one Output-Task-set.
Here are a couple (of many) posts:
Fernando Barcellos Ximenes says
My take on this: goals are expected outcomes, and expected outcomes come from some job (task, process) that must be done.
Goals (when properly stated) are the success criteria we use to determine that the job has been successfuly performed.
However, not all expected outcomes are equally relevant. Therefore, they must be prioritized, and this could be the first step in breaking them up. Whenever some goal is relevant and difficult to achieve, we have a priority. And priorities can be thus ranked.
There are situations where dependencies apply and, if that is the case, they have to be included. But carefully …
Then solutions come into play: what is the most effective way to meet the goals / expectations, block by block, module by module.
Hope it helps.
Many thanks! Very much appreciated.
I did think of your process, Guy, thanks!