Justicew Web Collaboratory

A2J Logo
Chicago-Kent College of Law
|Search|Contact
Planning > Structured Planning >Introduction

Structuring the Information I

If there are few Functions to consider, a project can be managed without much trouble. It does not take very many Functions to change that situation, however. Over 20 to 30 Functions to manage almost always means that some kind of organization must be attempted to bring order to the process. Assuming that any project of interest will have hundreds of Functions, the nature of the organizational scheme becomes a matter of importance.

How should Functions be organized? The conventional way to organize almost anything is to look for similarities among the items to be classified and to put like items together. Sometimes the categories are preselected and the likenesses measured are those between items and ideal members of the categories; sometimes (as in numerical taxonomy) the categories are defined in the process by the natural grouping of like objects on a number of preselected characteristics or attributes. A number of theoretical models have been developed for the clustering of items in this way, and computer programs exist to do most of the work. The question is: is similarity, however it is employed, the best relationship to use for organizing Functions? Christopher Alexander suggested another way of thinking that leads to a much more sophisticated concept for organization.

The controlling factor for whether two Functions are related from the planning standpoint is not
whether they are alike, but whether they share potential solutions – or, put more correctly, whether a significant number of their potential solutions are of concern to both Functions (Figure 7). This includes, in a sense, whether they are unalike because of their potential solutions. The concept, once examined, is very appealing. In the first case, if planners consider those Functions together that have a number of potential solutions in common – that is, a solution for one Function also, in some way, is a solution for a second Function – there is an excellent chance that they will be able to fine-tune one or a few solutions so that they will meet the requirements of the Functions under consideration very well. In the second case, if they can see Functions together that have potential conflict problems because of some of their potential solutions (a solution for one Function, if accepted for the overall system concept, aggravates or prevents meeting the needs of a second Function), they have the opportunity early-on to select or devise solutions that will avoid the difficulties.

The RELATN program uses this concept to establish links between Functions based on the Solution Elements given for a project. How it does this can be illustrated with two diagrams. In the first diagram (Figure 8), the “bull’s-eye” represents a two-part abstract space that contains all of the Solution Elements for a project that in some way are of concern to a Function (Function 1, for example). The diagram has a bull and a ring because some of the Solution Elements help to fulfill Function 1 (+), and some – if they are used to fulfill other Functions in the project – will make it difficult to fulfill Function 1 (-). Both kinds of Solution Elements are obviously of concern. There are, of course, other Solution Elements in the collection for the whole project; they are represented in this diagram as being outside the bull’s-eye space (0), because they have no bearing on Function 1 – they neither support nor obstruct its fulfillment. On the left in Figure 8, the spaces are shown; on the right, the Solution Elements of Figure 7 have been inserted for Function 1.

In the diagram of Figure 9, a similar bull’s-eye for Function 2 is combined with that for Function 1.

The intersection of the two creates regions with all the possible combinations of the characteristics from the two original bull’s-eye diagrams. The pairings of positive, negative and zero values indicate the support or obstruction the Solution Elements in each region exhibit for the Functions: left position for Function 1, right for Function 2. The five regions of importance are those which contain the positive Solution Elements, in other words, all the solutions that might be selected to fulfill either of the two Functions. Using these five regions, the amount of interaction between the two Functions (the degree to which the two Functions are related) can be established.

In the (+,+) region are the Solution Elements that fulfill both Functions. These are, in a way, the elegant solutions because each fulfills both Functions at once. The (+,0) and (0,+) regions also contain Solution Elements that might be used with confidence. Two Solution Elements, one from each of these regions, would create a total solution for the two-Function system. While not as elegant, this set of choices at least does not introduce difficulties and, in fact, the independence thus identified may be important in some planning considerations. The two remaining regions, (+,-) and (-,+), are troublesome. A Solution Element chosen from either will create a situation in which it will be difficult to successfully fulfill the Function for which the (-) value was given. Based on the effect they have on the two Functions, the five regions are labeled: reinforcement (+,+); independence (+,0) and (0,+); and conflict (+,-) and (-,+).

The concept of interaction can be drawn intuitively from the diagram. Assuming that the reason two Functions should interact (or be linked) is that they have potential solutions of concern in common, the amount of interaction should be proportional to the number of Solution Elements in the common regions of reinforcement and conflict relative to those in all five regions including those and the two independence regions (Figure 10). None of the other regions is relevant because no Solution Element would be chosen from them to fulfill either Function. Thus, in its simplest form, a measure for interaction is the ratio of the number of reinforcing and conflicting Solution Elements to those plus the number of independent Solution Elements.

In the RELATN program, the interaction concept is extended with three additions. First, instead of simply counting the presence of Solution Elements in a region, the program accepts scaled evaluations for how much a Solution Element supports or obstructs fulfillment of a Function. Scales may be of any resolution, but usually have five values: strongly supports (+2), supports (+1), no bearing (0), obstructs (-1) and strongly obstructs (-2).

Second, weights are accepted for the Solution Elements. With weighting, the impact of any Solution Element can be increased or decreased in its effect on the amount of interaction. Weights typically are used to reflect the likelihood that a Solution Element will be used in the final system solution – some ideas are more practical than others, for example; or some may be favored or even required by constraints placed on the project.

Finally, a balancing factor is incorporated to take care of the problem that some Functions have more Solution Elements of concern than others. The problem arises when a Function with only one or two positive Solution Elements is considered with one that has many (fifty would not be uncommon). If they have one common Solution Element in the reinforcement or conflict regions, what should the amount of interaction be? Intuitively, it is different depending on which Function’s viewpoint is chosen. The balancing factor finds a middle ground.

To prepare for using the RELATN program, the planning team assesses the collective set of Solution Elements against the set of Functions (Figure 11). Data for each Solution Element includes its name, weight and the scale used to assess it (different scales can be used for each Solution Element – although, in practice, a common scale is usually used for all). Data for each Function includes the Function’s name and value assessments for how all the Solution Elements support or obstruct it. Experience has shown that the considerable job of assessment can be made manageable by splitting up the task among the team members. The Functions are divided up among two-member subteams. Each subteam assesses all Solution Elements for its subset of the Functions. Both subteam members independently do the entire assessment for their subteam’s Functions and then compare results. Consultation (the greatest time demand) is, therefore, only required for disagreements. The loss of accuracy (agreement of the results with what would have been derived from a full-team consensus on each assessment) has been acceptably small in test comparisons.

The result of operations with the RELATN program is a nondirected graph, or network, in which Functions are the vertices (or nodes). Links between Functions indicate which Functions have enough interaction to warrant being considered together in any conceptual development activity (Figure 12). For many purposes, this level of organization is sufficient; but for most planning projects, further structuring is valuable.

 

The research project entitled "Meeting the Needs of Self-Represented Litigants" (Access to Justice)
was developed jointly by Chicago-Kent College of Law, the Institute of Design and the National Center for State Courts.

© 1999-2003, The Justice Web Collaboratory, Chicago-Kent College of Law, Illinois Institute of Technology -- All Rights Reserved