Introduction
The Objectives Hierarchy should not be thought of merely as a big bucket in which to store your objectives. Instead, use it as a place in which to begin framing out the curriculum, using hierarchical relationships to identify objectives that have prerequisites.
Why should objectives be arranged in a prerequisite order?
Imagine that you have created an objectives hierarchy in which all the objectives are placed in a flat list, like in the example below:
The order may help you properly sequence the objectives into a compete lesson plan, but beyond that, the order doesn't do you much good. Suppose that another instructional designer later picks up management of this objectives hierarchy. Should the designer want to design a smaller lesson with only a few of these objectives, how will they know if they are teaching everything the learner needs to know?
Or suppose another example, in which your VLS system is configured to deliver just-in-time-training. The flat list doesn't convey to the system any information again about prerequisites; a learner may find themselves confused and frustrated, for example, if they choose to learn about troubleshooting a fault in the wafer handler system, but did not get the prerequisite modules about geometric zero, or being able to list the five steps of a geometric zero calibration.
Putting your objectives into a prerequisite order in the Objectives Hierarchy solves these problems.
How should objectives be arranged in a prerequisite hierarchy?
When an objective is prerequisite to another in the list, place it in as a child, rather than as a sibling below. The parent-child relationship signals to VISION, as well to other instructional designers who understand the purpose of the objectives hierarchy, which objectives must be taught first, and which can be taught on their own.
In the example below, the objective "Troubleshoot a fault in the wafer handler robot system" represents a fairly high-order learning objective. Troubleshooting requires understanding of the systems components, its theory of operation, and also a deeper understanding of how those components interact with each other to produce either good or bad results. In this simple example, the worker needs to understand the five steps of performing a procedure, but also needs to be able to define a concept. It makes sense that these lower-order objectives need to be mastered before the higher-order troubleshooting objective. So the prerequisite objectives are placed in a position in the hierarchy that communicates this relationship in a way that a flat list cannot.
Note that the "fundamentals", or the objectives that apply generally to the task as a whole, will be taught first in any training scenario. Next, the objectives in a prerequisite order are taught from the bottom up; the objectives at the bottom are lower-order, and those above are higher-order. Next, the remainder of the cognitive objectives are taught.
Finally, the performance objectives are taught in OJT or other hands-on settings, with the Terminal Objective taught last.
