Work areas are logical subdivisions within a project. For example, a "maintenance staff" project might be divided into a work area for Electricians, another for Mechanics, etc. Further, there are three sections of every project database: Analysis, Objectives and Programs. Each of these sections can be a single work area, or be separated into multiple work areas.
Test questions are connected to the Objectives Work Area. Test questions do not comprise a separate work area.
Projects Work Areas
In a project you can have more than one work area of the same type. For example, you might have one job analysis work area for a worker, and one for a supervisor. Yet they might very well be in the same project because they are associated with the same basic job: maintenance, operations, or whatever. Alternatively, you could represent the worker and supervisor as separate job position nodes within a single hierarchy. It’s up to you.
A project need not include each type of work area. For example, a project might contain only the curriculum for teaching some academic subject. As such, it might have work areas for objectives and the program, but no analysis work area. Or, your project might have an analysis work area and an objectives work area, but no program work area, just because the project development hasn’t reached that phase yet.
If all of this sounds a bit confusing, remember: you can always go with the usual three work areas for each project: Analysis, Objectives and Program. You can change things around later, if necessary.
The terms "work area" and "hierarchy" are interchangeable in this manual and in VISION. At times, you will be asked to open an Analysis Hierarchy, for example. On doing so you will be presented with a window asking you to select an Analysis Work Area. A work area is named or identified by the highest node (also referred to as the root node) in the hierarchy representing the work area.
Remember that you can make as many Analysis Work Areas as you want and that you can always display several work areas in a Workbench at one time, and go back and forth between them. You can link each Analysis Work Area to its own new Objectives Work Area, or to an existing Objectives Work Area, but this kind of link is largely symbolic, and not functionally important.
Different Approaches to Making Work Areas
The illustration below represents a database separated into four projects. Projects are depicted as a set of three horizontally connected sections: Analysis, Objectives and Program. Each project represents a different approach to the establishment of work areas.
Project 1: Usual Approach
This project is broken into only one work area for each section. There is one Analysis Hierarchy, one hierarchy of Objectives (tied to the Analysis Hierarchy) and one Program Hierarchy. The Program Hierarchy is the organization of courses, topics, lessons, etc. This is the configuration that you will get if you accept the defaults on the Create New Work Areas window during the setup process.
Project 2: Multiple Program Work Areas
This project contains only one work area for Analysis, one for Objectives, and several Program Work Areas. In this model, the Analysis Hierarchy will be linked to an Objectives Hierarchy. But the Program Hierarchy will be divided into several work areas. Perhaps there will be a Program Work Area for each course.
Project 3: Analysis Only
This example shows that it is not necessary to have all sections present for a project. Maybe all that is needed is an Analysis Work Area; no Objectives will be developed for this project.
Project 4: No Analysis
Some projects may only require an Objectives Hierarchy. It may be that a hierarchy of fundamental objectives, not linked to specific performance outcomes, is appropriate. This example shows two Objectives Hierarchies and three Program Hierarchies.
