Task analysis is generally defined as the process of breaking a task into its subordinate components. By doing this, you can determine exactly what the training objectives for the task ought to be. Results of task analysis usually include conditions, standards, major elements, or steps of the task, and the underlying skill and knowledge components. These are used to derive the training objectives, test questions, and any hands-on task training that may be required. Other information such as references, tools and equipment, system components, and safety issues are often collected as an additional part of the task analysis process.
On the other hand, task analysis is not always the best way to figure out what the substance of training should be. More importantly, it is very easy to spend a great deal of time doing task analysis, only to find later that the information you collected contains much more detail than you need. Task analysis can be a powerful technique to build a truly effective training program, or it can be too time-consuming to justify.
When is a Task Analysis an Effective Technique?
Task analysis is usually considered the most appropriate technique for situations where the tasks are procedural, and the process can be observed. Other techniques may be more appropriate for tasks that are cognitive, and not easy to see or measure.
However, task analysis can fail even for the simple, procedural things if it is not done right. Conversely, it can be surprisingly successful even for the more complex, non-observable areas if the analyst is very skilled at extracting the necessary substance. So, success or failure of a task analysis depends a lot on how well it is done.
Here are some characteristics of a good task analysis:
•The task statements themselves are clear and measurable. Collectively, they represent the important job outcomes at an appropriate level of detail.
•The skill and knowledge statements represent more than just a further breakdown of the task. They represent underlying concepts, principles, rules, and factual information that trainees must possess in order to perform the task with the necessary level of understanding.
•All skill and knowledge statements are clear enough to be transformed by someone other than the task analyst into instructionally sound objectives without further breakdown. Generally, a good task analysis results in a number of objectives that is equal to or less than the number of task analysis components—never the reverse. On the other hand, unnecessary detail is avoided; most (at least 70%) skill or knowledge statements can be transformed directly, one to one, into worthwhile learning objectives.
•The analysis addresses not just the task proper, but its conditions and standards as well. For example, if a condition "using the XYZ meter" applies, a skill statement may be defined to address the condition: "can take voltage readings with the XYZ meter."
•The analysis reflects direct input from expert job incumbents. It is usually a good idea to utilize procedures and direct observations in the analysis process. But an analysis done without direct input from existing job incumbents is more likely to fail, no matter how well it was done.
There are several approaches to task analysis. In some cases, you can use procedures or technical references to derive the analysis data. In others, direct observation is best.
Interviews with job experts, at some point, are very important. Job experts utilized in the training design process are often called subject matter experts, or SMEs. The expert job incumbent assigned to assist with the task analysis should have the respect of the organization’s personnel involved in the training process. The learners and their supervisors know that the quality of their training is dependent on the quality of the technical input it is based upon.
Ideally, a combination of all three sources (procedures, observations, and interviews with job experts), can be applied. This maximizes the use of the SME’s time, and samples a broad range of input before settling on specifics. Below is a suggested task analysis process that combines all resources:
1.Assemble a rough draft of the analysis from reference materials.
2.Interview a qualified SME to refine the analysis results.
3.If possible, observe the tasks actually being carried out; make further refinements to the analysis.
4.Have several qualified SMEs verify the technical accuracy and completeness of the analysis.
5.Finalize the analysis to reflect SME comments.
Recognizing the Need for Sub-Tasks
When a task is broken into sub-tasks, the original (parent) task becomes an organizer of the sub-tasks. A task should be broken into sub-tasks if any of the following conditions apply:
The task can be performed in more than one way, each involving a method or procedure that is significantly different from the other(s). How different does it have to be, in order to break the task into sub-tasks? If one or two steps are different, and the rest are the same, there is probably no need for sub-task. The alternative steps can be pointed out within the list of steps for the task. If quite a few of the steps are different, say close to half, it is usually better to break the task into sub-tasks. You may also want to break it up if:
•Performance of the task under different conditions requires substantially different steps, methods, skill or knowledge.
•The task is so complex that each step, or element of the task is actually a task in itself.
When you break a task into sub-tasks, watch for decision tasks. For example, if there are two methods of performing a task, do you need a task for selecting which method to use?
The illustration below shows a task being broken into sub-tasks. Notice that the original parent task becomes an organizer of the two sub-tasks. When you count the tasks in your list, the example situation would count as two tasks, not three. The original task, though still labeled as a task, serves now merely as an organizer for the true tasks under it.
Examples
Here are some examples of sub-tasks based on different methods or procedures.
Procedural task
Sub-Tasks based on different conditions
Sub-Tasks derived from a large, complex task
Writing a Task Statement
To write a task statement, use these guidelines:
•Always begin with an action verb.
•Include only one verb per task statement.
•The verb should describe something observable.
•You should be able to observe or measure the outcome of the verb. Remember, there are exceptions to this point. Not all tasks can be observed as they are being performed. Some tasks are decisions, involving mental analysis or evaluation. Still, you can observe and measure the results, even if the result is simply a decision or conclusion. "Select the best site for a parking structure" is an example of such a task.
•The statement should stand on its own. In other words, the reader should be able to tell exactly what the statement means, even if it appears on a list without reference to a particular job or function.
Example
Procedures
A procedure is typically a document that lists step-by-step instructions on how to perform some work or operation. In the past, procedures have been thought of as documents that are separate from training. This is because typically procedures are created long before a training program is set in place. However, many agree that it would be advantageous if procedures were more directly related to training.
VISION accomplishes this by extending your job and task analysis. In the job and task analysis, a task would represent the title of a procedure and each element (step) would represent a procedure step. To capture the content for a procedure step, VISION provides a Procedure menu item on the Task, Sub-Task, and Element Properties workscreens.
Generating a Procedure from Within VISION
To generate a procedure from within VISION, you must first complete the job analysis phase down to the task level. Once you have identified the tasks (procedures), you will need to break up a procedure into elements (procedure steps) and enter the content for each element. Furthermore, if your procedures have any special characteristics such as utilizing tools and equipment or special safety considerations, for example, then you will want to capture these as Cross Reference Table items and link them to each procedure (task) as necessary.
Identifying the Major Elements of a Task
Elements are the steps, actions, operations, or other logical components of a task. You may hear the term step used in place of element. Step implies a sequence. Steps are performed one at a time, in a prescribed order. Since some tasks contain activities that are not necessarily performed in a particular sequence, the term element is used instead. This avoids the implication that the task activities are performed in a particular order.
Elements begin with a verb and are listed in sequence, if a sequence is applicable. Some tasks contain steps or operations that are NOT sequential.
•A troubleshooting or problem-solving task may involve an algorithm or flowchart approach, rather than sequential steps.
•A decision task may involve the weighing of variables and factors, in no particular order, rather than a set of sequential operations.
•Some procedure tasks or procedural tasks require the completion of activities without requiring them to be done in any order, such as checking the mechanical condition of a car before a trip: check oil, battery, water, etc.
Elements are usually, but not always, observable. Some tasks require the application of mental skills or cognitive activities that are not directly observable.
An example task: Select the best site for development of a new office building.
This task requires the evaluation of several variables, such as visibility from major highways, access to parking, and so on. Evaluation of these elements is not observable. Rather, it’s a mental process and only the results can be seen or judged.
Elements are measurable. Whether the elements are steps, operations, or other logical components of a task, and regardless of whether or not they are directly observable, they are measurable. That is, you can determine whether or not the element was done, and whether or not it was done correctly. Even for elements that are not directly observable, the result of performing the element can be determined, and judged as being either correctly or incorrectly done.
Example 1
Example 2
Example 3
Example 4
Skill or Knowledge
A skill or knowledge component is an expression of a discrete skill or knowledge that a learner must possess in order to accomplish a task or a specific element of a task.
•A skill component describes what the learner must be able to do in terms of a physical action in order to complete the task or element. Some physical actions (skills) describe components of the task or element. For example, to perform the element "inspect the vehicle’s battery," one physical skill might be: "Use a hydrometer to check the specific gravity of battery water."
•Some skill statements describe psychomotor abilities required to perform the task or element. Psychomotor abilities are defined as the ability to perform a physical action requiring coordination of body movements: writing neatly, aligning parts to close tolerance, lifting heavy objects properly, maneuvering a moving vehicle through a series of turns, etc.
•A knowledge component describes what the learner must know or understand in order to perform the task or element correctly. One type of knowledge statement describes something the learner must know or understand that is very specific to the task or element. For example, for the element "Inspect the vehicle’s battery," a knowledge statement might be "Explain the relationship between specific gravity and battery cell life." On the other hand, knowledge statements can also describe knowledge that is applicable to the task as a whole, rather than one element. For example, for the task "Inspect a motor vehicle in preparation for a long trip," a general knowledge statement might be "Identify the function of each part on the list of parts to be inspected."
How to Express Skill and Knowledge Statements
Analysts differ in their opinions about how to state a skill or knowledge component in the analysis process. The method recommended here is to use action verbs, and write the statement in a form that is as close to an objective as possible, but without spending time on refinements.
Use action verbs that narrow the statement to something that is measurable. If it sounds like you are reading about objectives, you’re right! But that’s what skill and knowledge statements are for: to produce objectives for training. The closer you can get to measurable objectives during task analysis, the less time you’ll need later on when developing objectives.
•Measurable statements using action verbs:
o"Calculate voltage, current, and resistance using the Ohm’s Law formula."
o"Raise a car using a hand jack."
•Be sure your skill or knowledge statement contains only one action.
•Avoid writing "perfect" statements. You can later refine them, when it is time to write objectives.
While this method does take more time than writing more general statements, it assures that the result can be later translated into objectives, and it minimizes the chance of misunderstandings. Some analysts prefer writing very general skills and knowledge statements. They usually favor these rules:
•Precede a skill statement with something like "ability to..."
•knowledge statements are preceded with "knowledge of...," or "understands the theory of…," and so on.
The risk in making general statements is twofold: you may end up with statements that cannot be reliably interpreted by another analyst or by the person who must write a measurable objective from the skill or knowledge. "Knowledge of Ohm’s Law," for example, can mean many different things, depending on one’s point of view.
Another problem is the waste of time writing things that really add very little value to the result. "Ability to..." or "Knowledge of..." are usually considered to be understood. Why bother to write these words over and over again? In a large analysis, there may be thousands of skill and knowledge statements. Think of the time and database space consumed writing "knowledge of..." a thousand times!
The Right Level of Detail
The level of detail you allow in writing skill and knowledge statements is very important. If you make your statements too broad, you really haven’t finished the analysis. Someone, maybe you, will still have to break the general statement down into components discrete enough to be used as objectives.
If you write your skill and knowledge statements at a level that is too detailed, you will either have too many objectives to work with, or you will spend a lot of time consolidating or packaging the statements into objectives. A suggestion is to write each skill and knowledge statement to represent, as closely as you can, something that can be easily translated into an action verb or a behavior statement of an objective.
If you’re not sure how to write the behavior or action statement for an objective, particularly how big or finite the scope of an objective statement should be, this would be a good time to get it straightened out!
Examples
Conditions of Task Performance
Conditions are circumstances, equipment, documents, and other such things that significantly impact task performance. When you look for the task conditions, think real world: Under what circumstances, or with what equipment or resources, will this task be performed in the real world?
Examples of task conditions: Maintenance Task:
Examples of task conditions: Operations Task:
The Importance of Identifying Task Conditions
Ideally, there is no difference between the conditions that exist when performing a task in the real world and those that exist when performing the task for purposes of training. When there is no difference at all, we say that we have 100% fidelity between the real world setting and the training environment. That’s the ideal. It doesn’t happen all of the time. It is important, then, to identify the conditions of the real world task.
Conditions help us identify skills, knowledge (and perhaps attitudes or personality traits) that the trainee must possess in order to perform the task proficiently. In other words, the conditions are an important source of input to the task analysis.
Conditions are often applied to task qualification checklists (and sometimes other types of documents) to ensure that task evaluation is conducted in the proper context. In other words, we want to have 100% fidelity between actual performance conditions and those under which the trainee was qualified.
Performance Standards
Without identifying the standards of performance that you expect of trainees, you have no real way to judge whether or not a trainee is qualified. The unsettling possibility is then left wide open that trainees will not be judged with consistency. Without standards, one evaluator may say a trainee has performed a given task to an acceptable level of proficiency, while another evaluator may not agree.
Task Performance Standards
Standards of task performance are absolutely vital. Task standards define the criteria that will be used to measure whether or not the trainee can perform the task under real world conditions. There are two broad categories of standards:
•Process standards: Those designed to measure the process or methods applied to doing the action.
•Product standards: Those designed to measure the product, or quality of the result.
When you are looking for standards of a task, think about how you would judge whether or not an individual performed the task well enough to be judged qualified. First, consider the task process: What would you look for while the trainee is doing the task to assure yourself that he or she is conducting the steps properly?
Next, consider the result, or product of the task. What characteristics would you expect to be present to assure yourself that the task is completely done, and represents the quality you expect?
Here are example process standards for a task:
Here are example product standards for a task:
As you can see, some of the standards apply to the process of conducting the task. The others apply to a judgment of the product, or results.
Consider the Outcomes (Documents) You Want
With VISION, you can produce various outcomes directly from task analysis data. For example, you can produce procedures and on-the-job evaluation checklists (Task Qualification Checklists) directly from the task analysis.
If your procedures have any special characteristics such as utilizing tools and equipment or special safety considerations, for example, you will want to capture these in Cross Reference Tables and link them to each procedure (task) as necessary.
•In order to prepare the documents, you may need to link Cross Reference Table items to hierarchy components. Once the links have been made, you can generate documents and queries.
•When, during your project, should you make links for Cross Reference Table items? This will depend on your project plan. If you want to generate Task Qualification Checklists early in the analysis phase of your project, you would probably link the cross reference items for the checklist document to the tasks, just as soon as your preliminary task analysis has been completed. That way, you can generate useful Task Qualification Checklists early in the project. For instructions on making cross reference links, see Linking Cross Reference Items.
•It is usually important and worthwhile to get Subject Matter Experts or others to review and verify the task analysis. To assist you in the verification process, you can generate a Task Analysis Verification Form from VISION. This document will provide all of the information needed for verification, in a format that is convenient for Subject Matter Experts (SMEs).
•When the task analysis is finally done, you can generate another form from the same list, the "Approved Task List." This report provides a place to get signatures that verify completion and acceptance of the task analysis.
•If you do not know which procedures, checklists, or other documents will be generated from the task analysis, ask the appropriate project team member or supervisor.
How Standards are Used
Standards are used for several purposes:
•Standards help a task analyst identify skill and knowledge components required to understand and perform a given task.
•For example, let’s say you identify a task standard:
o"The holes are drilled slowly enough to prevent undetectable scorching or cracking of the metal or damaging the temper of the drill bit."
oThe analyst may choose to add a knowledge component such as:
o"Explain the effect that rapid drilling (heat) has on the structure and integrity of metal alloys."
•Standards document the level of proficiency that must be attained in order for a trainee to be qualified. Usually, standards appear on task qualification checklists and other documents so that every evaluator will judge a trainee with consistency.
•Documented standards can be used as a tangible baseline against which an organization can continually improve the bottom line. When task standards reflect business goals, they can have a direct impact on the bottom line.
Clear and measurable standards are one of the most important aspects of your training and evaluation program. If you decide to cut corners, don’t do it here!
