by Donald V. Steward, 4/15/00
Every problem has its own inherent structure. By looking at the information items needed to solve the problem and which items depend on which others, we can obtain the information flow needed to solve that specific problem. Given this structure, an 'approach' can be developed defining which of these dependencies will be satisfied by earlier tasks and which will be satisfied by assumptions to be verified by later tasks. From this we can derive a plan and schedule. This dynamic organization changes whenever the problem or approach changes.
The computer can be used to display to everyone involved in the solution process the visibility to see the whole problem, his or her role in solving that problem, and the changes in the state of the information during the process of solving the problem. This visibility provides greater accountability, allowing greater autonomy, leading then to faster respond times, greater learning, and the tapping of knowledge from throughout the organization.
The most common method for solving complex problems assumes that a problem can be repeatedly broken down into smaller problems that can be solved. Problems that are naturally amenable to this approach are called 'tree problems' because the directed graph, i.e., a diagram showing what information items depend on what others, looks like a tree. But a great many problems are not amenable to this approach because their graphs contain circuits, which cannot be represented as trees. We call these 'web problems'. People often try to force web problems kicking and screaming into a tree approach, which can be very ineffective.
We tackle web problems by finding the blocks of items in the graph that contain the circuits. Then in each block, we assign distinct natural numbers to the nodes representing the items within that block. This divides the graph for that block into two sub-graphs. One contains the arcs from lower numbers to higher numbers that we call the 'task graph', and the other contains the arcs from higher numbers to lower numbers that we call the 'assumption graph'. The task graph shows the dependencies satisfied by tasks done earlier. The assumption graph shows the dependencies satisfied by assumptions to be verified by tasks done later. Each assignment of numbers to the nodes represents what we call an 'approach' to solving the problem.
We can represent the graph as a matrix where the rows and their corresponding columns represent the items, and the non-blank marks within the matrix represent the dependence of one item on another. But to display this as a matrix requires that there must be some order to the rows and their corresponding columns as they are shown in the matrix. This order might generally be arbitrary. But we will use this order to represent the 'approach', i.e., changing the order the items as they appear in the matrix gives a different approach. The diagonal divides the two graphs, the task graph on one side and the assumption graph on the other. This matrix then represents the plan for this approach to the problem. We call this a dependency structure matrix.
During the implementation of the plan, what information items are known and which of these still depend on as yet unverified assumptions constitutes the state of the solution. This information state of the solution is much more informative than just knowing what tasks have and have not been done because the tasks may have to be redone with new assumptions if the earlier assumptions prove to be invalid.
The task graph can be treated as a critical path network provided all the assumptions are valid. The assumption graph is used to modify this critical path network to provide for reviews and possible iterations in the event that the assumptions might not be valid.
We have devised a software program that allows one to play with various 'approaches', providing heuristic advice for each block on where to use assumptions to break the circuits.
This program and its technique for solving problems have the following implications:
Situation visibility then has the following implications: