The Concept in Short © Donald V Steward 2007
THE CONCEPT
I have been working on a concept called The Thinking Enterprise. It is based on the idea that in this Information Age the enterprise needs to think as a whole, solving problems utilizing all of the knowledge and thinking capacity that is distributed throughout the enterprise. When the environment changes so fast that your planning horizon is too short, you must be prepared to solve problems to find opportunities as quickly as they arise. Especially when working with new technologies, it is likely that many more assumptions will be required. Success or even survival may depend on how well these assumptions and their risks are managed.
I have developed a largely selfmanagement approach to solving these problems by coordinating everyone’s thinking through what I call the structure of the problem. The structure of the problem shows the information dependencies inherent in the problem itself. This structure is displayed by a spreadsheet showing for each information item needed to solve the problem, what other information items it directly depends on. This structure has no time dependence provided the problem itself does not change.
Problem structures have some interesting characteristics that we have previously not seen. Information dependencies can have circuits. Circuits are broken by using assumptions. Once these circuits are broken, then a time element can be added to make a plan. This plan shows for each assumption where in the plan information becomes available so a review can be made to determine whether the assumption was valid, or whether some work must be repeated using a new assumption.
Assumptions are risks that need to be revealed, tracked, and driven out. A measure of progress shows at each point in time what assumptions have been resolved, what assumptions have not yet been resolved, and what still depends on those unresolved assumptions.
This selfmanaging organization is really the structure of the problem itself.
HOW IT WORKS – A very simple example
First, to see how information items can depend on each other, consider the following example. The price we set for a product depends on its manufacturing costs. But if we can make more of them, we can reduce the manufacturing costs. So the manufacturing costs, in turn, depend on the number sold. But the number that can be sold depends on the price. Here we see not only that information items can depend on other information items, but also that these dependencies can sometimes occur in loops. Later we will see that when we have loops, we will break them by using assumptions. This will help us manage assumptions and their risks.
Second, we need a way of representing these dependencies of information items on other information items. We are probably already familiar with spreadsheets. We can use them for this purpose quite effectively. Each row represents an information item. And for each row, there is a corresponding column. It makes it easier if we keep them in the same order. Obviously, there will be as many columns as rows.
Each cell occurs at an intersection of a row and column. Let’s say that the row of that cell represents an information item to be determined, and its column represents an information item it depends on. Then we put a mark in that cell. We only include the most immediate dependencies. This spreadsheet then represents what we call the structure of the problem.
I agree that most people would be more comfortable if they saw these dependencies as diagrams consisting of bubbles and arrows. Such diagrams are clear, provided we don’t have to deal with many items. But as the number of items grows, these diagrams become quite messy and very hard to read. It is also hard to trace paths in these diagrams. We have found that, once you get use to them, spreadsheets work much better than diagrams. So I ask that you initially put up with the spreadsheet representation. You soon you will feel that are quite natural.
Let’s look at an example.
We have added ‘Price’ and ‘Features’ to our earlier information items. X’s just mark the diagonal. The 0 in row 1, column 4 says that ‘Price’ depends on ‘Manufacturing Costs’. But note that if we pursue determining these items in the order they appear in this spreadsheet, when we determine ‘Price’, we will not yet know what the ‘Manufacturing Costs’ are, or for that matter what ‘Price’ the customer is willing to pay for the ‘Features’.
We would like to reorder the rows and their corresponding columns so that each item depends only on items that come before it in the spreadsheet. Look at row 3 column 1. Note that 1 occurs earlier than 3 in the spreadsheet. A cell showing that an item depends on an item that has already been determined will always appear below the diagonal. Also look at row 1 column 2. A cell showing that an item depends on an item that will not be known until later appears above the diagonal. Thus, the marks above the diagonal represent assumptions we make until later when we have the information to confirm or reject what we assumed. Given a mark above the diagonal, its row shows where the assumption is used, and its column shows where it will later be known. So the mark in row 1 column 4 indicates that this assumption will be used in determining the ‘Price’, but won’t be known until we later determine the ‘Manufacturing Costs’.
If we can reorder the rows and their corresponding columns to get all the marks below the diagonal, then these information items can be determined in the order they appear in the spreadsheet. Some must be determined in sequence. Others that don’t depend on each other can be worked on simultaneously.
We tried to get all the marks below the diagonal. But it couldn’t be done because there is a circuit, as we see below. The circuit is in a block. Everything in a block depends, directly or indirectly, on everything else within the same block. The best we can do is to get these blocks on the diagonal, with all the remaining marks below the diagonal.
‘Price’ is used to determine ‘Number Sold’, and ‘Number Sold’ is used to determine ‘Manufacturing Costs’, which is used to determine ‘Price’. This is a circuit. We have to break the circuit by using an assumption. For this ordering, an estimate for the ‘Manufacturing Costs’ is used to determine the ‘Price’. But perhaps this is not the best estimate to make. We can reorder the items within a block to use different assumptions.
Let us say that the effect of the ‘Number Sold’ on ‘Manufacturing Costs’ is rather small, so we can miss the estimate on ‘Number Sold’ without having too large an effect on ‘Manufacturing Costs’. So we are willing to use an estimate of ‘Number Sold’. We can reorder the items within the block so that an assumption for ‘Number Sold’ comes above the diagonal, indicating it is assumed when determining the ‘Manufacturing Costs’. Later, we may find that when we determine the ‘Number Sold’ that we must go back and change the “Manufacturing Costs’.
In the past we have always considered that the problems we are solving can be ordered so that all their marks are below the diagonal. If we had a hierarchy where each boss can hand down to his or her subordinates all the information the subordinate needs to do his or her job, we could always get all the marks below the diagonal. But in our experience and as illustrated by the example about, this seldom is the case.
Does this mean that passing information down through a hierarchy does not always get the right information to the right people? Yes it does. You may have had this suspicion. Now you can see why your suspicion was correct. And you can probably also see that there needs to be some agreement between the structure of the problem and the structure of the organization.
