Decision support systems have come a long way since the Sixties and Seventies. Time was when Nobel Prize laureate Herbert Simon could announce with a straight face: "There is every prospect that we will soon have the technological means, through [heuristic programming] techniques, to automate all management decisions." /1/ From battlefield strategy to commercial product development, machines would increasingly take charge.
While I suspect there is more truth to Simon's prediction than most observers allow -- after all, only a person whose own thinking processes were already largely "automated" could have ventured such a statement -- history has contravened his expectation. Now, some thirty years later, neither the battlefield commander nor the CEO is in foreseeable danger of obsolescence.
We still hear about decision support systems, of course, but they mostly attempt to offer a relatively humble suite of logistical services to the human decision maker. The buzzwords flitting about the research publications tend toward the more modest end of the spectrum: electronic meeting systems, groupware, computer-mediated deliberation, and so on. What these denote can range from simple electronic extensions of the chalkboard and the paper memorandum to ambitious, if relatively crude, gestures in the direction of Simon's original vision.
The typical meeting under this system has three phases. Using Electronic Brainstorming software and typing at their separate terminals, all members of the group record their ideas regarding the questions posted on the meeting's agenda. Although these contributions are anonymous, everyone can see the complete and growing list of ideas. Next, a vaguely described Issue Analyzer helps the group "identify and consolidate key focus items resulting from idea generation." Information from other sources can be imported during this phase. Finally, a Voting tool provides various methods for prioritizing the key items. Again, voting is anonymous, but the results are easily displayed for all to see.
The Arizona researchers report on the experimental use of this system at IBM. In one case a manager, frustrated in her attempt to identify certain problems in shop-floor control through conventional meetings, employed the group support system with apparent success. "At the end of the brainstorming session, the manager reflected that for the first time she was able to get meaningful answers" to her questions. Immediately following this, the group prioritized a list of "focus items," held some face-to-face discussion, and voted. The result? A high degree of satisfaction among the participants, who felt they had successfully addressed the problems.
This system can clearly provide low-level, logistical support. Ideas, once entered into the computers, are part of a meeting record that can be recalled at any time. Complete "minutes" of the session are available immediately upon its conclusion. Votes can be taken and recorded in an instant. Not surprisingly, the Issue Analyzer, designed to help structure the actual problem analysis, came in for criticism as "clumsy." It appears that this was where the face-to- face discussion proved most important.
Overall, the system produced large time savings "strongly correlated with the degree to which the group's task was stated clearly and concisely." One participant cited "the preciseness of the process procedures" as an advantage. The researchers note in a later publication that "process structure helps focus the group on key issues and discourages irrelevant digressions and unproductive behaviors. /3/
Paradoxically, the anonymity of the process won praise for "knocking down barriers" between people One user mentioned the "openness of the process and its lack of intimidation. This was because of the anonymity." A second was impressed by "the way the personalities are taken out of the process so that the process becomes more rational." And a third remarked how "the anonymity of the input allows participants to change positions on an issue without embarrassment."
In a related experiment, a Hughes Aircraft manager offered a similar observation: "I noticed that if someone criticized an idea of mine, I didn't get emotional about it .... No one knows whose idea it is, so why be insulted?"
The University of Arizona developers claim a number of benefits for their electronic meeting system. In their own words, it
On the other hand, they identify no risks or liabilities, although in a general discussion of electronic meeting systems they mention in passing the potential for depersonalization by the electronic medium, together with the necessarily limited "view" offered at any one time by a video display screen. Having listed these as theoretical concerns, they do not go anywhere with them.
Another researcher describing this same work manages to come up with two potential disadvantages: most people cannot type as fast as they speak, so the meeting is slowed down unless there are approximately eight or more participants (in which case the advantages of parallelism more than compensate for slowness of typing); and the system is useless for "one-to-many" forms of communication, such as lectures. /4/
There is something disconcerting about this peculiarly limited range of assessment -- a limitation, incidentally, that seems quite typical of efforts in this field. The adaptation of the group task to a kind of computable algorithm seems just a little too easy, and the world of possibilities outside the algorithm just a little too neglected. This neglect is only more disturbing when set beside the authors' claim that the technology "is fundamentally changing the nature of group work."
It is not that it is wrong to assess one's tools and methods against criteria such as the external flow of information, the precision of procedures (as indicated by faithfulness to a step-by- step, procedural outline of the way things ought to proceed), and time-to-solution. It is just that if these considerations do not take place against a larger and more meaningful backdrop, they easily begin to oppress, a fact generally ignored within the engineering and research worlds giving birth to the new software tools.
This is not to say that supporting software is inherently threatening. Much depends on the awareness of the group using it. That is exactly why the restricted vision of the researchers and their test subjects is disturbing -- the cultivation of a wider awareness is exactly what does not seem to be going on.
The risks are not trivial. For one thing, the work group may begin to conceive and carry out its tasks mechanically, simply following the prescribed format for its own sake. Such prescription can cramp any human relationship -- particularly where creativity is desirable (and where isn't it?). Even to write things down at too early a stage -- so that the things written confront one as a kind of objective, already achieved "reality" -- can in some cases stifle any further, freewheeling, imaginative thinking.
My own experience of meetings suggests that critical insights often crystallize unexpectedly at the end of a long and meandering journey -- and they may even nullify everything that preceded them. And yet, the journey was essential to the insight. Any effort to make the later stages grow too systematically out of the earlier ones may discourage profound revisualization of a problem in favor of a pedestrian "solution."
Group work does require structure as well as freedom. But when the structuring tools contain embedded intelligence, one needs to assess carefully just how intrusive and coercive their influence might be. For such intelligence is aggrandizing: it not only increases the range of capability and the adaptability of the tools, but for these very reasons it also invites users passively to abdicate some of their own responsibility for shaping group processes.
But suppose we answer, "Yes, the corporation is a human activity in the service of human needs." What then? The first thing we realize is that the individual and group activities within the company are more than a means to some external end; they are themselves a primary justification for the company's existence. After all, prominent among human needs is the need to work, to create, to cooperate, to solve problems, to struggle against the solid resistance of the world. In this striving, the individual and the working community grow, and such growth is -- or ought to be -- a good part of the reason for binding these human efforts together in the first place.
In this context, every problem is a gift -- part of the company's inventory of "raw goods" -- and invites the production of new, human "capital." This is far different from seeing a problem merely as something to be gotten rid of by the most efficient means possible.
All of which indicates that meetings we support electronically cannot be assessed solely in terms of productivity, time-to-solution, precision of procedures, and so on. A manager must balance many different concerns, in addition to getting the product out the door. Is each member of the group being stretched so as to gain new skills and exercise a more mature judgment? Does the distribution of tasks reckon appropriately with the different ages and experience levels of group members? Is there a way to call upon this or that contributor's intense personal interests? What do the frictions between Jane and John suggest about their future assignments? In what ways can the group internalize and make practical the larger organization's commitment to meeting human needs?
As Lievegoed points out, some will not make this transition successfully, but instead grow more rigid with age, hewing to petty rule, defending their own turf ever more jealously, and generally proving a headache to the larger organization. In this case, management must ask,
What mistakes have we made so that he has become like this? When he was between 40 and 50 did we not profit from the fact that his department ran on oiled wheels? Did we leave him there because we could not be bothered to make a change? Did we overlook the symptom that no promising young men emerged from his department ready to move on to higher levels?" (p. 153)
When a manager is prepared to ask such questions, and then, with the questions in mind, to facilitate the deeply organic interrelationships within a group -- all in service of the values and purposes governing the larger organization -- will the group support software help her or hinder her? I don't believe there is any direct answer. There is only a complex set of issues we haven't really begun to address yet.
And so the distortions and constraints of an electronic support system, used as a kind of foil, can help to answer the question, "What distinguishes a human-centered organization from a mechanism?" But the prerequisite for this is, unfortunately, just what is missing in the current literature: an ability to step back and look for the distinctly human potential in social institutions. Nor is the failure here surprising. What should the programmer look for, if not what is programmable? And yet, if we were not thinking in mechanical terms, we would train our engineers to think first of everything about a task that cannot be programmed. Only when they had fully lived their way into the specifically human -- and therefore never fully capturable -- dimensions of the task would they consider what supporting role their software might play.
Approached in this spirit, software engineering would prove a discipline of continual revelation by clarifying the boundaries between man and machine.
1. Simon, 1965: 47.
2. Nunamaker, Vogel, Heminger, et al., 1989.
3. Nunamaker, Dennis, Valacich, et al., 1991: 41-61.
4. Aiken, 1993.
5. Lievegoed, 1973: 152.
Steve Talbott :: The Future Does Not Compute, Chapter 10