ORGANIZATIONAL PROBLEM SOLVING TOOLS

Introduction

By now, it must be very clear that organizational problem solving is a lot more interesting and challenging than applying formulae to organizational problems. There is always some process that needs to be found, understood, and solved before it can be deployed in an organization. Many times problems exist because of the unintended mess created by an earlier solution. In fact, a surprising number of problems only need to be solved because the organization has allowed itself to engage in questionable practices. Many times removing such impediments is the very best tool for solving organizational problems. When one is dealing with a major task, a method such as business process reengineering can remove and prevent a lot of organizational problems. When, on the other hand, one is dealing with an entire organization, organizational design is needed. Organizational design is the "mother" of all processes to improve organizations.

Most organizations are a mess. They are not well-designed, functioning more or less as poorly designed contraptions patched up by a long series of slip-shod repairs. They are riddled with reporting structures that mismatch the logic of the work. They have too many task forces, standing committees, committees, study groups, and dysfunctional teams. There are truly goofy processes at work which drive people nuts and are the despair of those forced to live in and with them. What may not be understood is that many such problems are issues of poorly designed structures and processes. Often, by cleaning up the Organizational Logic and Organizational Architecture to make them congruent with the strategic direction, many problems simply go away and others are prevented from occurring. Thus, it is often more effective to redesign an organization and remove the underlying cause of the visible problems than it is to direct talent and energy to solve them as they appear.

A practitioner can easily verify this observation by conducting a simple survey. He or she should ask a sample of, say, 10 managers to do two things: (1) list their three top priorities in their job, and then (2) keep an hourly diary for at least five working days on how they actually spent their time. The chances are that there will not be a close correspondence between what the manager knows what needs and should be done and how the manager actually spends his or her time. This is a real eye-opening exercise to sensitize one to the structural nature of the cause of the problems. Thus recognized, the organizational problem solving tool called organizational design becomes both practical and logical.

Virtual Positions and Virtual Processes

There is a very good reason why such organizational design problems occur. It is called authority-task gaps. It turns out that one can view an organization as having three systems. There is the official-role system (the Organizational Architecture) which describes who is supposed to be doing what with whom. There is the actual-role system which describes who is actually doing what with whom. Finally, there is the authority-role system describing who actually has the legal authority to do what with whom.

The authority-role system used to be closer to the official-role system until government agencies such as OSHA, EEOC, EPA, and new legislation such as ADA began mandating regulations covering organizational behaviors.

For example, many times a manager lacks the legal authority to hire, promote, and reward someone without entering into an elaborate process to ensure compliance with these regulations. We have managers charged with responsibilities who lack the legal authority to carry them out.

These three role systems are all changing but they are not all changing at the same rate. Thus, over time, inconsistencies between what one is supposed to do, how it gets done, and the actual authority to do something grows into authority-task gaps. Organizations abound in authority-task gaps. We learn to live with them but some burst into real overt conflicts and become authority-task problems. Unfortunately, authority-task problems get resolved via committees, task forces, standing committees, "passing the buck" upwards, and hiring consultants. Sometimes they can be ignored or solved by a manager.

Authority-task problems appear as structural phenomena called virtual positions. In a virtual position, members of an organization gather to solve an authority-task problem. When a virtual position is regulated it does so in the form of a committee, a standing committee, a task force, or some cross-functional team. When it is unregulated, it is more informal. Participation in a virtual position is an opportunity to grab hold of more authority and responsibility, to be in a position to bargain for responsibility with others, or to avoid responsibility. Virtual positions become the arenas for power struggles in organizations.

In some organizations there are various staff groups involved in decisions such as personnel, investments, scheduling production, developing and deploying technology, etc. A manager desiring to make a decision, such as hiring someone, may have to spend hours and days working around the organization to effect a decision he or she should have been able to make in the first place. These work arounds are called virtual processes.

Virtual positions are anomalies of processes in the world of structure as represented by an organizational chart. Figure 7.1 illustrates a virtual position. Virtual processes are anomalies of structure in the world of processes. The concept of a virtual process is depicted in Figure 7.2. Both virtual positions and virtual processes force Associates to engage in political and negotiating behaviors outside their main job just to keep themselves and the organization afloat. Excessive numbers of virtual processes and virtual positions, create hyperorganizations which become highly dysfunctional. A good organizational design eliminates most of the virtual positions and virtual processes and thus prevents unnecessary organizational problem solving.

As an example, many organizations are trying to install teams and process improvement groups to solve organizational problems. Typically these teams gather people and resources across the organization. But, if the organization were properly designed, would not most of these cross-departmental teams become unnecessary? After all, a manager and his or her direct reports are a natural team in a well designed organization. So, why is it necessary to create so many cross-departmental teams if the department were designed properly in the first place? Basically, teams are not a panacea and many exist because management does not have the guts, time, energy, will and knowledge to make the necessary organizational changes so that the naturally occurring interdependencies are organized together.

Another major source of organizational problems which are preventable are those caused by unethical behavior. Ethical behavior is functional. It prevents problems from occurring and thus saves the time and expense of damage control, often involving high legal and other costs. Ethical behavior simplifies problem solving by making it more understood, acceptable, and implementable. Ethical behavior is motivating because people like to feel good about their organization and themselves. Unethical behavior is wasteful and drains away time and energy. People who believe that they have been treated unfairly will find reasons and ways to get even. Unethical behavior is mostly preventable and removing it is a powerful, highly leveraged organizational problem solving method.

Distributing Organizational Problem Solving

Another powerful method of organizational problem solving to become better organized is thinking through the proper distribution of where it is done. There is a natural hierarchy of organizational problems ranging from the very general issues of determining the principles and philosophy of the organization down to the daily administration of company rules, regulations, and standard operating procedures. By deciding three questions, many organizational problems can be stabilized and simplified. These questions are: (1) What is the scope of application of the decision? (2) Where should the decision be made (called "the locus of rights reserved")? and (3) How flexible is implementation of the decision?

Figure 7.3 shows a schematic for the distribution of the organizational problem solving process according to these three questions. This figure illustrates the best way to distribute organizational problem solving. The strategic apex of the organization (the CEO and senior officers) is the "locus of rights reserved" for very high-level organizational problem solving processes involving setting the principles, philosophies, and strategic direction of the organization (cf. Figure 3.2), because the scope of these decisions are organization-wide. These high level problem solving processes, once set, are inflexible and not subject to sudden change. But, as the scope of application becomes limited and localized organizationally, there should be more flexibility in application, provided that there is no violation of the higher-level solutions, and changes should be made closer to where the problems are occurring.

Thus, the diagram in Figure 7.3 can be understood by the metaphor of a willow tree. A willow tree has roots that are sunk deeply into the ground, supporting a sturdy trunk out of which grows branches and fronds of small leaves. When strong winds blow, the fronds flexibly adapt to the wind but the trunk and roots remain in place. A willow tree is simultaneously flexible and rigid.

By stabilizing the principles, philosophy, and strategic direction, there is order and logic to the underlying structure of organizational problem solving. Given the higher level constraints to decisions and given a shared understanding of what the organization stands for and is trying to accomplish, decisions become easier to anticipate and understand down through the organization. This schematic illustrates the problem of how best to distribute organizational problem solving. Organizations become unwieldy and slow when CEO's are scheduling the loading dock or if the loaders are changing the strategic plans of the organization. Or, as they say in the military, "When a general commands platoons, heaven help the general and the platoons."

Organizational Design

Organizational design is much more than arranging the various organizational positions in some prescribed order. It is foolish to arrange organizational boxes without also aligning the work in order to achieve a fit between structures and processes. The work, called the Organizational Logic, and the form, called the Organizational Architecture, must also be closely linked to the technological support systems and organizational rewards systems. But these are parts of the Implementing Organizational Technology (see Figure 3.3 for a description of Box B representing the Implementing Organizational Technology) which exists as the means to convert strategic direction into organizational results. The strategic direction must make sense in terms of the environments in which the organization operates. Finally there is the need to effect bonding of individuals to the organization and to their jobs. Clearly, organizational design is tied to much more than designing structures. It is tied to achieving what is called dynamic congruency in Chapter 3.

Organizational design is defined as the continuing effort to achieve dynamic congruency in the face of changing environments while the organization continues to operate. Organizational design is dynamic, not static. It is like repairing a truck as it speeds along the interstate highway. The organization cannot stand still while it is being designed and, during the organizational design process, there will be changes as it unfolds due to consequences of shifting environmental and operating challenges and opportunities. The definition specifies that the purpose is to achieve dynamic congruency, and that organizational design is a continuing effort (not a one-shot exercise) which must be done amidst change during operations. Organizational design is a complex process of adaptation and change which sets the stage for yet other changes. It can be used not only to solve organizational problems, but also to prevent them.

One proven technology for organizational design is the Organizational Audit and Analysis Technology (OA&A). The OA&A Technology mirrors the organizational problem solving process of Figure 1.1. The problem finding stage is called the strategic assessment. The problem finding and problem formulation stages are also part of the organizational audit. The decision making stage is the organizational design stage in the OA&A process. There is an implementation planning stage just like the implementation stage in organizational problem solving. The last two major stages of the OA&A process are monitoring the implementation and organizational maintenance. These two OA&A stages are represented by the audit and review stage of organizational problem solving. Thus, the OA&A Technology is a general type of organizational problem solving which is applied to the whole organization and not just one of its problems.

The book, Organizational Design: The Organizational Audit and Analysis Technology (Ablex Publishing, 1986) was written before the development of the theory of the Organizational Hologram. However, the two form a pair of complementary lines of attack. Every stage in the OA&A Technology, as shown in Figure 7.4, involves the theory of the Organizational Hologram and often the Organizational Diagnosis as described in Table 7.1.

This complementarity is illustrated in Table 7.1 which describes the stages in the Organizational Audit and Analysis Technology.

Organizational design provides methods to create the conditions that put in place an organization capable of implementing all of the 12 Holonomic Processes. It tackles directly the issue of strategic direction (HP1), the Organizational Logic (HP2), and ensuring position clarity (HP4). The practitioner can use organizational design to create conditions that allow an organization to rebuild its organizational rewards systems, which affect the Holonomic Processes of operating equitable and effective rewards systems (HP10) and ensuring compatibility of interests (HP11). It also helps define tough and realistic performance standards (HP9) when one knows who is supposed to be doing what with whom.

The organizational diagnostic methods described in Chapter 6 provides more detailed and systematic information about the degrees of dynamic congruency and the deployment of the 12 Holonomic Processes. The HALO process becomes a useful way to verify the need to even engage in an organizational design project. Information provided by HALO reports help to build consensus to undertake an organizational design. The HALO instruments are useful in performing an audit and review of an organizational design project. Comparing results before and after an intervention, for example, provides detailed information of what did and did not work.

An organizational design project involves competently managing vast amounts of information as it changes. For example, consider an organization with 1,000 positions. There are 1,000 x 999 possible linkages between all pairs of positions for one type of interaction on a task. Now suppose this same organization has 5,000 task processes. These 5,000 task processes are also structured by their Organizational Logic. Thus, there is a potential of 5,000 x 4,999 possible pairwise relationships among the 5,000 tasks. Combining this with the 1,000 x 999 pairwise relationships between the positions, there is a potential of (1,000 x 999) x (5,000 x 4,999) pairwise relationships between positions and tasks. But this is only considering each, one at a time. The actual potential number is astronomically larger.

Because of limited short term memories, information processing capabilities, shifting attention, managers simply cannot handle too much interdependence. They must reduce dynamic complexity to something that is at least manageable. The challenge is to be sensible about this by recognizing that all organizations are inherently four-dimensional.

If Xn represents the list of positions, then the Organizational Architecture is a linkage of position to position or Xn x Xn. Xn x Xn represents the Organizational Architecture or its structure. A structure of positions is two-dimensional. If Tm represents the list of task processes, then the Organizational Logic is a linkage of task processes or Tm x Tm. Tm x Tm represents the Organizational Logic or the structure of its functions. Thus, the fundamental reality of an organization is that it is a four-dimensional entity because form should follow function. The need to convert the tasks and the structures creates a four-dimensional organizational reality represented by:

(Xn x Xn) Organizational Logic

x

(Tm x Tm) Organizational Architecture

The dynamic complexity of the inherent interdependencies can be cut down to size by organizing the task processes into an Organizational Logic and the positions into an Organizational Architecture and making sure that the two are congruent. The complexity can be reduced because most of the 1,000 x 999 combinations of positions are never realized and that most of the 5,000 x 4,999 combinations of task processes are irrelevant. By combining both, the actual numbers become manageable because most people are not involved in most tasks.

The temptation is very strong to crunch the inherently four-dimensional nature of an organization into a plane of two dimensions. For example, an organizational chart shows the relationships among positions but leaves out the task processes that are performed by those occupying a position. A process diagram such as an Organizational Logic shows the relationships among the task processes but omits the positions to which they are linked. Any representation of an organization on a sheet of paper will necessarily compress the four-dimensional reality down to a two-dimensional representation. Always, such compressions come at the cost of detail and meaning.

Organizational Responsibility Group Chart (ORG Chart)

So, a practical problem is how to effect such a compression with the minimum loss of information. Algebras have been developed to do this and are summarized in the 1986 Organizational Design text cited earlier. The basic idea is to first structure the positions and then structure the task processes and arrange both in a table called the Organizational Responsibility Grouping Chart (ORG chart). The rows of the ORG chart are the positions and the columns are the task processes. The entries in the ORG chart represent the type of involvement of the position represented by a row and the task processes represented by the column. The ORG chart is the primary method of representing the complexity of linkages among positions, among task processes, and among the positions and task processes. The range of entries in an ORG chart is listed in Table 7.2. A representative ORG chart is presented in Figure 7.5.

Each column in the ORG chart is a "chain of accountability" for the task process represented by the columns. By looking at a column in the ORG chart one can see which position(s) is performing the task, which position(s) is directly supervising the task process, which position is supervising the supervision, etc. Each row of the ORG chart describes, for one position, exactly which tasks are performed and the type of involvement. A row of the ORG chart can be read to define the position description.

Structural and process changes can be accomplished by changing the rows, changing the columns or changing the entries into the ORG chart. Centralizing a task means shifting upwards the type of involvement. For example, if position x2 in Figure 7.5 is currently performing task process t2 and being immediately supervised by position x1, then centralizing this task would mean deleting the "P" entry in x2's row and replacing the "S1" entry by a "P" entry in the row for x1. Conversely, decentralizing means pushing the "P" entry down to a subordinate position and making the necessary changes in the "Sk" entries. The S4 becomes S3, the S3 becomes S2, and the S2 becomes S1.

However, even with the simplifying convention used to construct the ORG chart, there is still a massive problem of data handling involved in any organizational design project. For example, people change their names as when a woman gets married and takes her husband's surname. Position titles change, too. So do the assigned incumbents to a position. Tasks change as does the Organizational Logic. The entries in the ORG chart change, too. Thus, as the organizational design project goes through the stages, there are a lot of data and data changes to manage. Database software can be used to process structural and task information. One such system is the Organizational Design Support System software.