More Objectives Can Make Life Easier

I’m talking about performance based equipment training objectives. I’ve actually written a ten page white paper on this.

A lot of people find PBET objectives tedious, so the last thing they want to hear is any suggestion that they create even more objectives. So why am I even writing about it?

Because it can help solve a lot of learning sequencing problems. For example-

resolving discussions about “what is a guru?”
deciding in what level a task belongs.
accounting for variations of tasks that are customer-specific.
differentiating aspects of one task that are for the service organization- not the customer.
creating a CSE (customer service engineer) certification plan for which all of the above bullets are relevant

One Task: Operator Level? Maintenance Level? Guru Level?

I remember having an objective for a basic maintenance course that read (in part): “Operate the ion implanter.”

But later on, it was suggested that getting “signed off” in training didn’t mean they were really-truly competent. Sound familiar?

The reality is that there are many dopant gases used while operating an implanter, each requiring slightly different knowledge; there is also an auto mode and a manual mode for operating the machine. This alone suggests differing levels of competence (expertise, skill, ability, experience…) and thus the advisability of separate objectives to account for these variations in conditions or standards.

And just when I have sorted that out, it is suggested that competence in the three or four more detailed objectives that I have newly extracted and written is still insufficient to account for the way a really, really, really experienced, seasoned, guru operates the machine, compared to the way that a novice does.

So I explore this. What is the “pro” doing differently, exactly? She doesn’t need to actually look up anything, it is instinctive, I’m told. Her performance is “on automatic” and flawless. And she is fast. No matter what dopant is required, she always has the machine pumping out product before anyone else. She is, in training lingo, giving a “fluent performance.”

“There is no way to account for that in one of your objectives!”

Yes there is. And this spotlights another reason to further subdivide the original objective. Here are some ideas:

Change the condition of the task so that it is performed without any references (memorized).
Change the standard of the task so that it is performed within a specified time frame based on the analysis of the most expert performer.

These two changes will lead to the task being performed fluently. Fluency is not required in most cases. It is not cost-efficient for everyone to be fluent on all the tasks. Competence is enough in most cases.

But when you want to have a way to distinguish two levels of performing roughly the same task, the solution is to have two objectives for that same task.

In summary, subdividing an objective into two or more other objectives and placing each at differing points on the learning hierarchy can solve many training headaches.

Enough. If you think this could help you, help yourself: download my white paper called, “Using Performance Objectives to Differentiate Levels of Skill Difficulty.”

Share and Enjoy: