Nodes on the same level should all have the same level name
Changing Level Names of Shared Nodes
Changing Level Names of Analysis Nodes
Changing Level Names of Program Nodes
Steps to Change the Level Name of a Node
Eventually, you will want to move, share or copy hierarchy components from one part of the hierarchy to another. When this happens, there is a pretty good chance you will end up moving a component to a different level than its original level.
When a component is moved, shared or copied to a different level than its original level, VISION does not automatically check for a level mismatch and make the correction. VISION allows you to mix level names for components at the same level; it's up to you to maintain consistency (if desired).
You will see any mismatch right away. The different icon will stand out like a sore thumb! Then you will likely want to change the name of the level for the component you just moved, so that it matches the other components on the level.
You cannot change the level name of nodes with a Status of Approved. Change the node's status and then make your adjustments.
Try to make every level in the hierarchy consist of the same type of components. Avoid situations in which there are, say, tasks on the same level as functions (aka "duty areas"). If this becomes too frequent an occurrence, it can lead to confusion, and a hierarchy that is simply too detailed or convoluted to be worthwhile.
Sometimes it's hard to avoid mixing component types within a level. For example, some analysts choose to turn up "embedded tasks". Let's say you list the steps (elements) of a task, and one of the steps is actually an entire task, which appears elsewhere in your hierarchy. The task is "embedded" within the list of elements. It happens; but if it happens with many of the tasks, there may be something wrong with the superstructure of the hierarchy.
One exception to this rule is objectives, where cognitive and performance objectives may be siblings. But even in that case, those siblings would likely all be enablers, or all terminals.
When you change the level of a node and that node is shared, the new level name is applied to all locations of the shared node. Remember that a shared node is really the same data object appearing in multiple locations.
The Analysis hierarchy has strict rules on the ways that Analysis nodes can interact. Here are the rules that dictate how Analysis nodes can be related to each other:
•Organization, Job Position, Responsibility Area, Function, Phase: These nodes are considered "Organizer" nodes, and can have any other organizer node as a child as well as Tasks or Skill/Knowledges. Additionally, their level names can be interchanged without restriction.
•Task: These can only have Sub-Tasks, Elements, and Skill/Knowledges as children. If a Task is the child of a Task, it cannot have another Task as a child. If it has Sub-Tasks as children it can only have Sub-Tasks as children.
•Sub-Task: These can have Tasks, Elements or Skill/Knowledges as children.
•Element: These can only have Skill/Knowledges as children.
•Skill/Knowledge: These can only have Skill/Knowledges as children.
Nodes in the Program hierarchy have Level name on the General pages of their Properties window.
a.You can select multiple nodes for this operation. You can highlight multiple components by using the <Shift> key at the beginning and end of a continuous list of components, or by using <Control> and clicking on each component you want to highlight.
2.From the Main Menu (or right-click menu), click Node Change Level Name.
3.In the window that appears, choose a level name. VISION will change the level name of every component you highlighted.