"The ramifications of modern industry are too widespread, its organization too complex, its problems too intricate for it to be possible for industry to be managed by commands from the top alone." Mary Parker Follett (1925)
For thousands or years, the principal method of organization has been the hierarchy. The hierarchy is based on the concept of solving problems by successive divide and conquers. We have developed an entirely new problem solving method that shows the unique structure of each problem. This structure is usually not a hierarchy.
In this complex modern age of business, other premises of the hierarchy are also breaking down. Managers today often must rely more heavily on the knowledge of their subordinates than the subordinates need rely on the knowledge of their managers. Businesses also have to deal with complex problems that cannot be broken down as easily into the hierarchies corresponding to their organizational structures. Organizations need to be more dynamic. We have to completely rethink old ideas about such matters as who has what authority and access to what information.
Business activity might be considered as having two aspects, routine processes and problem solving. Any time you hear the words 'project', 'team', 'study', or even 'committee' you are likely to be talking about collaborative problem solving. We will consider here the problem solving aspect of business. Processes are routine exercises of the solution of a problem that has already been solved.
A new paradigm is needed that better uses the knowledge distributed throughout the organization and is better able to deal with problems whose solutions require communication patterns that look more like webs than trees. Solving web problems requires the use of assumptions, generating the consequences of those assumptions, reviewing those consequences, and possibly repeating this process with new assumptions. By dealing directly with the web nature of these problems, the assumptions are made more explicit. This allows one to make plans that make better use of assumptions to save time and money and entail less risk.
Management today faces constant misfortunes due to not being able to see and manage all the assumptions and their resulting risks that are hidden in their plans. The consequences of these assumptions frequently strike at the most inopportune times, leading to cost and time overruns and unmet requirements.
When plans are made using the conventional work breakdown structures and critical path networks, we accept many assumptions that we are often unaware of. But once into the project, if some of these assumptions prove to be false, the project can become seriously disrupted, often leading to a situation approaching chaos. The solution is to recognize these assumptions up front so their risks can be managed. But to recognize them, we must look into a dimension that is ordinarily hidden from us, the information dependencies.
The key to understanding the roles of these assumptions, as we will see, is to look into this hidden dimension to find the information involved in the solutions of problems and what information depends on what other information.
Management gurus have been telling us in thousands of books, seminars and articles that to survive and thrive in this new age, we need greater empowerment, more accountability, cross-functional problem solving, knowledge based rather than rank based authority, greater learning, and flatter organizations. Agreed. But trying to achieve all these goals has been less than universally successful.
These considerations are not new to the information age. Mary Parker Follett anticipated them in the 1920's. In addition she showed that they are not just a collection of many diverse concepts each requiring a different management focus. She proposed that they can all be achieved as a natural consequence of just one focus, everyone constantly being able to see, understand and react to the situation with minimal need for management intermediation.
The principal new innovation we have seen that uniquely relies on the new capabilities of information technology is the World Wide Web. Interestingly, the new method of management we propose also concerns webs.
We will show that we are now able to provide the situation visibility Mary called for by using techniques not available to Mary in her time, namely the information dependency paradigm that is the subject of this paper. When we investigate the information dependency paradigm, we also will find solutions to many other vital management concerns, particularly the tyranny of hidden assumptions and the risks they incur, which was referred to above.
THE NEW INFORMATION DEPENDENCY PARADIGM
In business projects it is common to see cycles of Assume, develop their Consequences, then Verify whether the consequences are satisfactory (ACV). If the consequences are not satisfactory, a new assumption is made and the cycle repeated. This is what we see in the task-domain. The ACV cycle is an indication that in the information domain there is a circuit, e.g., A depends on B that depends on C that depends on A. It also indicates that we are not dealing with a tree structure, but with a web structure. A circuit means we must make an assumption to temporarily satisfy a dependence somewhere in the circuit to break it. Where we break the various circuits affects both what assumptions we use and what tasks are done in what order. By starting our planning with the task-dependencies, these choices are made without full visibility of the alternatives and their consequences on the plan. By starting with the information-dependencies we see the alternative approaches and can make wise decisions.
The conventional viewpoint in planning focuses on the dependencies between tasks, i.e., which tasks must be done before which other tasks. But the assumptions only appear when we take a different viewpoint, the viewpoint of solving a problem. This new viewpoint allows us to look at the information dependencies, i.e., which items of information are needed to solve the problem and which items depend on which other items. If we are to expose these assumptions so we can manage their risks, we must start our planning with the information dependencies rather than jump immediately to the task dependencies.
The term 'item' is initially interpreted to be the information item itself. Once we choose an approach, an item is reinterpreted as the task required to determine that information item. An approach is a choice of one out of may ways we can order the tasks so that certain information items are supplied by earlier tasks and others are supplied by assumptions that can only be verified after completing later tasks.
The information dependencies are unique to the problem and thus don't change as long as the problem doesn't change. The approach can be changed quit easily at any time provided those people affected are properly notified.
Figure 1 shows the relationship between the task dependency domain and the information dependency domain. The bottom plane shows the conventional task dependency domain, i.e., what tasks depend on what other tasks. The top plane shows the information domain. In the conventional method we see the dependencies between tasks in the task domain and pieces of information about each of those tasks in the information domain. But we don't see how those information items depend on each other. In this new approach we start with the dependencies between information items. Then the tasks with their dependencies and the assumptions follow.
Fig 1: The bottom plane represents the task domain; the top plane represents the information domain. IN THE CONVENTIONAL PROCEDURE, the dependencies between tasks and information about each of the tasks are considered, but THE ASSUMPTIONS ARE NOT SEEN. IN THE PROPOSED PROCEDURE, starting with the information domain, i.e., what information items depend on what other information items, THE ASSUMPTIONS ARE SEEN.
Note that in the information domain in the Proposed Procedure, we have a circuit b->c->d->b. In this case we choose to make an assumption to satisfy b's dependence on d. This breaks the circuit. The arrows that are not assumed project into the task domain to get the dependencies between the tasks. But in the task domain, when we get to d we will have to verify whether the assumption we made was valid, and if not make a new assumption and iterate. We could have chosen any of the arrows in the circuit for our assumption. Different assumptions produce different plans in the task domain. In general, there will be many circuits and many assumptions.
IMPLEMENTING THE PLAN
While implementing the plan, these information dependencies can be seen on the desktop computer of each person involved, providing Mary's situation visibility. People can see how their work fits into the whole, whose work they depend on, and whose work depends on them. They can see when the information they depend on will be available, and if it is held up they can trace the cause. When people confront difficulties, others can see and offer to help. As people see what others are doing, they can aspire and train to have the capabilities to do that kind of work. As unanticipated events or new thoughts occur, everyone is instantly notified of changes made to the approach or problem. Instead of having organizations created to solve a class of problems, the organization becomes completely dynamic, always providing the Information Dependency that fits the problem and the current approach to solving it. In short, information-orientation provides a completely new and more efficient method of management. Software tools have been developed to facilitate this new management method. (See Figures 8-12)
Figure 12 shows what those involved in solving the problem will see on their screens once the tasks marked in blue have been done. The tasks that now have the inputs they need and are ready to go are marked in green. Note that there are 3 tasks ready to go, and they can all be done in at the same time.
HOW IT WORKS
Consider a diagram with the nodes representing the information items needed to solve the problem and arrows showing which information items depend on which others. (See Figure 2) We call this the 'Information Dependency' diagram. It shows the structure of the problem. Since all the information dependencies exist simultaneously rather than being extended over a period of time, this diagram can and usually does contain circuits, e.g. C to E to F back to C in Figure 2. A circuit implies that somewhere an assumption must be used that can only be verified after other tasks that depend on it have been completed. There are various approaches to how to solve the problem depending on where the circuits are broken by the use of assumptions. It is this 'information dependency diagram' that represents the unique structure of each problem.
Fig 2: This diagram shows information items as nodes A through F and arrows showing which items depend on which others. This represents the structure of the problem, which does not change as we look at different approaches to solving it.
There are a number of ways we can assign the sequence 1, 2, ... to the nodes in this diagram. Each such assignment is an 'approach'. (See Figure 3) Each approach divides the diagram into two diagrams. One consists of all the arrows that go from a lower numbered node to a higher numbered node. This diagram shows the order in which we do the tasks to determine the information items. Note that some tasks need to be done in sequence while others can be done in parallel. The other diagram consists of all those arrows going from a higher numbered node to a lower numbered node. This diagram shows the use of assumptions. While the original Information Dependency diagram may contain circuits, the task diagram will not contain circuits. It may seem counter-intuitive, but by assigning a set of sequential numbers to the nodes in the diagram, we get a task diagram where items can occur either in sequence or in parallel. Thus the tasks can occur in time and be scheduled using classical critical path methods.
Fig 3: Here the distinct natural numbers 1 through 6 have been assigned to the nodes. This corresponds to one approach. Arrows from a lower numbered node to a higher numbered node are colored blue. They show the order in which the tasks to determine the information items are done. The arrows from a higher numbered node to a lower numbered node are colored green. They show where assumptions are used awaiting the completion of a later task that will provide this information. Each way the nodes are numbered is considered to be an approach. Note that with this approach, A and D can be done in parallel. Once A is done, B and C can be done in parallel.
The Information Dependency can also be represented with a square matrix where the rows and their corresponding columns represent the items, and a mark (any non-blank symbol or color) in a cell of the matrix implies the dependence of one item on another. (We prefer that the mark or color in any row and column implies that the item of the row depends on the item of the column.) (See Figure 4)
Fig 4: This is the matrix that corresponds to the diagram above. The rows and their corresponding columns match the nodes in the diagram. The red squares just mark the diagonal. The other colored cells correspond to arrows in the diagram. Blue squares correspond to blue arrows, green cells correspond to the green arrows. There are four marks shown in green above the diagonal that represent where assumptions will initially be used.
When the diagram is represented as a matrix, there needs to be a sequence in which the rows and their corresponding columns appear. Ordinarily this sequence would be arbitrary. But we can make this be the sequence we assigned to the nodes to represent an approach. Then the marks below the diagonal correspond to the task diagram showing where a task gets the information it depends on from a task done earlier. The marks above the diagonal correspond to where a task must use an assumption because the task that produces the information it depends on cannot be done until later.
The marks below the diagonal would form a critical path network for solving the problem if all the assumptions proved to be correct. However, this network needs to be modified by adding reviews of the assumptions and iterations should some assumptions not be correct.
Thus, each sequence of the rows and their corresponding columns in the matrix corresponds to an approach. For any particular problem, the information dependencies, i.e., the structure of the problem, will remain the same while the approach can easily be changed. This gives the planner the opportunity to play with various approaches with their different tasks and assumptions to find opportunities to save project time through such means as increased concurrency and reviews specifically tailored to that problem.
IMPLEMENTING THE IDM SYSTEM
It is a premise of this concept that it should not be imposed by management just because it works for management, but should be used by the people because it works for them. It needs to give greater control to the people who are closest to the work and can recognize how the system helps them. So the concept and its tools might be introduced as follows: First, install the client-server system on the server and desktop computers. In the meanwhile, have project management develop the matrix plan for a demonstration project that can be understood by everyone and displayed on his or her desktop. Then, start running classes for a set of people who will soon be jointly involved in a new project and others as they would like, using the demonstration so everyone can see and play with the project at their desktops. Try to be as responsive as possible to people's suggestions to improve the system and allow them to feel part of it. When enough people feel that the system works for them and are willing to use and support it, then start real projects using the system. Voila
THE MANY ROLES OF ASSUMPTIONS
Many operations in business can be thought of as making a match between a means and a need. Initially the match is very vague, involving many assumptions. For example, a product concept can be looked at as the initial vague matching of a need for a product with a means to produce that product. The need is refined by resolving assumptions in a process called analysis; the means is refined in a similar process called design. Marketing can also be looked at as matching a need and means, namely matching a product that is a means of solving a problem with a customer who has a need for solving such problems.
It all starts when an idea is created, the vague concept that there may exist a match. Then we proceed to pin down those assumptions until we have a well-defined match, e.g., the design or sale of a product. Creativity comes out of an environment in which people are presented with many means and many needs from which they are likely to form conceivable matches. Situation visibility opens the awareness that can facilitate making such matches.
An expectation can be considered as an assumption that a match between a need and a means will occur in the future. Because the match is to occur in the future, an expectation must depend on trust. A manager expects an employee to do a piece of work; the employee expects the manager to reward that effort. The manager expects an investor to supply the wherewithal to produce that award; the investor expects the return of that investment plus interest, and so forth. A business can be considered as a system of expectations that links people who control various resources and capabilities so they may jointly achieve some outcome of greater value than can be achieved by those resources applied in any other available way. The role of management is to develop and maintain a linkage of expectations to achieve that outcome.
The structure of the problem remains stable unless the problem truly changes. Given a problem, various approaches can be taken to the strategy for its solution. The same problem structure and approach might be applied to different objects, as in a production line. This would be a process. If the problem structure is new, this would be a project. In either case they must rely on assumptions, and difficulties can arise when those assumptions may prove to be wrong.
Businesses frequently involve conflicts that arise because the parties to the conflict have different concepts of the problem and their different assumptions are not revealed in their communication. Much of this conflict and its grief could be resolved if the parties were to join in laying out the information dependencies that define the structure of the problem and then together analyzing the assumptions that would support the various views. They can jointly consider the likelihood that the assumptions would be valid.
The importance and ubiquity of dealing with assumptions and their resolutions makes it important to work in the information-dependency paradigm where those assumptions are made explicit and can be properly managed.
Fig 5: This matrix corresponds to a different node numbering than in the matrix above, thus representing a different approach. Because this problem contains circuits, the best we can ever do is to confine the circuits to within one or more square blocks on the diagonal. This is an extremely common situation. This shows that this is a web problem, not a tree problem. There are now two marks above the diagonal representing the use of assumptions.
Fig 6: Now the rows and their corresponding columns within the block(s) on the diagonal have been reordered so there is only one assumption needed. This approach may be better because it requires fewer assumptions. However, the user must choose using his or her knowledge of the meaning of the problem whether it is better to make this one assumption, or perhaps use the approach above because those two assumptions are easier to make.
Fig 7: This diagram corresponds to the approach to the problem shown in the matrix immediately above.
Fig 8: This is part of a larger engineering problem, the design an anti-lock brake system. (Based on a problem developed by Tom Black while a student at MIT.) Engineering problems are parts of larger business problems. See Figures 10 and 11. This matrix represents the structure of the problem. The 0's show the information dependencies.
Fig 9: This is the result of applying an approach to the structure of the problem in Fig. 8. The 5 mark shows the use of an assumption for the 'Lining Material Front'. This separates the green block into the two inner red blocks so two groups of engineers can proceed in parallel, one group working with the simple mechanical features, the other working with the thermodynamics. When each group finishes, they review their work to see if it is consistent with the assumption. If not, some sub-set of the work is repeated with revised assumptions. The approach is chosen heuristically by a user with the guidance of a computer program.
Fig 10: This shows the application of the technique to a simple business problem involving the introduction of a new product. Here the engineering as well as such business considerations as marketing and finance become part of the larger business problem.
Fig 11: This is the result of applying an approach to the problem in Fig. 10. The program, using this matrix, can guide people through the process, informing them when the information they need to do their work becomes available. If it does not appear that it will be available when needed, these dependencies can be used to trace where it is being held up. As people can see work that needs to be done, they can offer their help. The marks with 5's are assumptions used to break up the green block. The 4's are used to break up the inner red blocks.
Fig 12: This shows what those involved in solving the problem will see on their screens once the tasks marked in blue have been done. The tasks that now have the inputs they need and are ready to go are marked in green. Note that there are 3 tasks ready to go, and they can all be done at the same time.
Permission needed from Garth Brooks
Fig 13: And lastly we should point out that all this will feel quite comfortable once we have made a transition from thinking only in terms of Trees and the task domain, and start thinking in terms of Webs and the information domain as well.
© 1995-2015 Problematics
Contact us via email at: email@example.com