Strategy & Tactics Tree

The latest addition to the TOC-TP application tools, the Strategy and Tactics Tree (S&T Tree) is used to move from the highest-level organizational goals to a comprehensive, multi-tiered, fully-justified set of implementation steps. It is used to implement a wide-ranging improvement throughout a larger organization by making it clear what role every part of the organization plays.

Flying Logic Setup

An S&T Tree is based on Necessary Condition Thinking. Since Flying logic documents are set up for Sufficient Cause thinking by default you will want to set the Operator popup menus as follows:

• Entity Operator: Fuzzy And (AND)

• Default Junctor Operator: Fuzzy Or (OR)

S&T Trees are usually read from top-to-bottom, starting at the highest-level Strategy. However, this means the flow of the edges (arrows) must be towards the highest-level Strategy or bottom-to-top: so you will want to set the Orientation popup menu to Bottom to Top.

S&T Trees are created using the entity classes in the provided domain file Strategy & Tactics Tree.logic-d you can open by selecting File ➡ Open Example... and then Domains/Strategy & Tactics Tree folder. When you open this you will offered the opportunity to either open it as a new, black Flying Logic document or import it into your currently open document.

Structure of the S&T Tree

The S&T Tree is based on the idea that Strategy and Tactics are complementary concepts used to describe a tree-like hierarchy of action, with each Step (node) of the tree justifying its existence with a strategy: a description of why the node exists. The highest-level strategy corresponds to the system’s goal.

Each Strategy is supported by a single Tactic entity that describes how the strategy will be implemented. The bottom of a complete S&T tree will always be a layer of Tactics: the most fundamental actions that support the strategies.

If more than one Tactic is necessary to implement a Strategy, a Tactic may be broken down into two or more sub-Tactics, but each one must first be justified by its own Strategy. Therefore, each Strategy always has exactly one Tactic below it, but tactics may have either zero, or two or more sub-Strategies.

If a Strategy has more than one possible Tactic that can accomplish it, then this can be added as an OR relationship.

For a given Strategy, we need to do more than provide a Tactic for accomplishing it, we also need to justify that Tactic as both necessary and sufficient to accomplish its parent strategy. So we create a Necessary entity and a Sufficient entity and make each one a sibling of each Tactic entity. The title given to each entity should do exactly as the class name suggests: describe why the Tactic must be implemented to accomplish the strategy (Necessary), along with why that Tactic absolutely will work (Sufficient). If there are numerous justifications for why a Tactic is Necessary or Sufficient, then additional Necessary or Sufficient entities can be added, or they can be enumerated in the entity’s textual annotations.

One more entity class, the Parallel (“parallel assumption”) class is used to proactively answer objections that neither directly address the Necessity or Sufficiency of the Tactic, such as:

• The Strategy already exists: no action need be taken to implement it.

• It is not possible to implement the Tactic.

Taken together, all five kinds of entities constitute a Step.

Since S&T Trees can grow quite large, it is useful to use Flying Logic’s grouping feature to manage the diagram. One approach is to group all a Strategy’s supporting entities and use a junctor to combine their edges with an AND junctor so only a single edge emerges from the group.

Groups can, in turn, be used to group entire Steps, including the Strategy entity, the Tactic entity, and the sub-group containing the Necessary, Sufficient, and Parallel (NSP) entities. Using this technique, you can arrange a very large S&T Tree to make it easy to “drill down” to the level of detail you need. Take these ideas as suggestions, and feel free to develop your own techniques for managing large Flying Logic diagrams.