Kurt A. Richardson, Institute for the Study of Coherence and Emergence, USA Andrew Tait, Strategic Leadership Sciences (Europe), UK Michael R. Lissack, Institute for the Study of Coherence and Emergence, USA
Abstract: As the connectivity of the business environment increases, as a result of rapid technological development, project teams are becoming more geographically dispersed. Given that team members may be positioned on different parts of the globe, multi-cultural issues may become more prominent, providing further complications for the project manager. Project planning and decision-making, therefore, becomes yet more complex and intricate. A diverse range of factors, both tangible and intangible, including global IT limitations and differing local working practices (or cultures), needs to be considered. Many of these factors will be interdependent, creating a complicated intertwined net of causes and effects. Managing the complexity inherent within this high-dimensional ‘project space’ provides considerable challenges for the project manager and team members alike in ensuring timely and quality production of project deliverables. Group decision support tools (GDS) provide a structured and, generally, transparent way of managing the complexity associated with the modern business environment. This paper argues that group decision support tools represent a valuable addition to the project manager’s toolbox in that they facilitate the management of project complexity and encourage coherence in the project team. In addition, the role that virtual community applications may play in facilitating the operation of dispersed project teams (in encouraging creativity as well as providing an extensive audit trail, for example) will be discussed. It will be argued that such communities are likely to be the form in which most temporary organizations, or teams, will embody themselves during the next few decades.
Project management is becoming more difficult. An obvious statement perhaps to the day-to-day project manager, but the changing operating environment is uncovering some genuinely novel challenges for the project manager. The modern organization can no longer be viewed as a group of loosely related departments with specific formal links, but as a series of highly interconnected business processes. The increased use of information technology, and the resulting interconnectivity, from local area networks, through intra-nets, the Internet, and now extra-nets of business-associated organizations, has increased the capability for individuals and groups to exchange information rapidly. This increased connectedness has meant that the identification of causal links, and where identified, the affect of such links on organizational behavior, is also increasingly difficult, making it more problematic to take informed decisions. This is the complex organization, and, rather than being an exception, it is becoming more common with the current trends in globalization and associated business fragmentation. In association with this higher level of organizational complexity we are also witnessing, not surprisingly, a corresponding rise in project complexity. But what exactly do we mean by the term ‘complexity’?
Recently a review of project complexity by Baccarini1 proposed a definition of project complexity to be “consisting of many varied interrelated parts”, which he operationalized in terms of differentiation—the number of varied elements—and interdependency—the degree of interrelatedness between these elements (or connectivity). These measures are to be applied in respect to the various project dimensions, and he discusses two of them:
(i) In terms of organizational complexity, ‘differentiation’ would mean the number of hierarchical levels, number of formal organizational units, division of tasks, number of specializations, etc.; ‘interdependency’ would be the degree of operational interdependencies between organizational elements.
(ii) In terms of technological complexity, ‘differentiation’ would mean the number and diversity of inputs, outputs, tasks or specialties; ‘interdependency’ would be the interdependencies between tasks, teams, technologies or inputs.
This clearly defines an important element of project complexity, perhaps the element that we think of most often when we consider a ‘complex’ project. There are, however, a variety of other meanings associated with the term that may prove useful in appreciating what is meant when a project is said to be complex (of course all projects are complex, some just more so than others). Table 1 summarizes these different modes:
Table 1 Different modes of complexity (adapted from Rescher 2)
|Epistemic inodes—formulaic complexify|
|Length of an account that must be given to provide an adequate description of the project of interest.
Length of the set of instructions that must be given to provide a recipe for producing the project of interest.
Amount of tune and effort involved in resolving a problem
|Ontological modes—compositional complexity (or differentiation)|
|Number of constituent elements or components. (Compare, for example, computers, people, and communication lines.)
Variety of constituent elements: number of different kinds of components in their physical configurations. (Compare, for example, different cultures and different commumcalion channels.)
|Ontological modes—structural complexity (or interdependency)|
|Variety of different possible ways of arranging components in different modes of interrelationship. (Compare a bureaucratic organisation with an ‘organic' organisation.
Elaborateness of subordination relationships in the modes of inclusion and subsumptions. Organisational disaggregation into subsystems. (For example: individuals, teams, departments, sectors, companies, etc.) Here the lngher-order units are, for this very reason, always more complex than the lower-order ones.
|Variety of modes of operation or types of functioning. (Teams have a more complex lifestyle than individuals. The processual structure of chess is vastly more elaborate than checkers.
Elaborateness and intricacy of the laws governing phenomena at issue. (Matrix management structures are more complex in this manner than vertical management structures.
It is clear that these different views of complexity are interrelated (as you might expect)—it might be that greater organizational complexity goes hand in hand with hierarchical or operational complexity for example. In general, however, we can distinguish between the ‘complicated’—more items, events or parts—and the more ‘complex’—more interactions and emergent products of those interactions amongst the items, events, and parts. Thus, the initial research question: does the increasing complexity often associated with modern projects signify a need for change in project management style?
In the not too distant past, it was an adequate approximation to assume that each department, sector, etc. could actually operate almost unawares of the other departments. This of course is an over-simplification, but given the diminished complexity of the business environment, it seemed a reasonable and effective assumption to make. This is the (quasi-)complicated world. In this world, time seems to run more slowly (the business tempo was more sedate than the hectic pace in many industries today). Thus when errors in judgement occurred, there was more time to recognize the effects of the error; more time to understand how the error arose; and more time to take corrective action. All this was possible simply because the business environment was less complex—it was essentially ‘complicated’. In the complex environment, however, life is less user friendly, particularly if one merely pays lip service to the complexity. In this economy-in-overdrive, there is less time to recognize errors, but, because of the sometimes apparent disassociation between cause and effect, it can be very difficult to even recognize an error by its effects. Furthermore, if the error is caught there is little time for corrective action. This is more than mere speculation. Williams, et al.3 describes a case study in which a large engineering company was held hostage to just such an exceptionally complex environment.
Sometimes the error might not be life threatening (in an organizational sense), other times it might be—it is difficult to tell which beforehand, as complexity also significantly hinders our ability to predict. This shift in organizational form from (quasi-) complicated to complex is fundamental, and it is not controversial to suggest that a paradigm shift within the management sciences is necessary to continue managing effectively in this new (newly labelled at least) environment4. For a more in-depth treatment of the implications of complexity for decision-making refer to Richardson, et al.5
Despite the difficulties that confront project teams in this (post-) modern environment, there exists a wealth of evidence demonstrating the benefits of working in teams. Benefits that are frequently attributed to teamwork include: higher productivity, improved quality, enhanced employee quality or work life, lower costs, reduced turnover and absenteeism, reduced conflict, increased innovation, and better organizational adaptability and flexibility6. Not all evidence however, especially in more rigorous academic research, is completely supportive of these claims. If project managers are to give themselves and their teams the best opportunity of realizing these benefits and, in so doing, meeting customer requirements they must update their techniques and attitudes, which are broadly guided by the principles of the command and control perspective.
Analysis in the past has, at best, tended to reduce project management to formal communications, pre-defined informational pathways and reporting structures to create the first order system dynamics. The insight generated, in comparison to the complex enterprise modelled, is small. Projects are far more than the doctrine, strategy or formally defined structures, it is the people within, and their behaviors that create, define, run the endeavor. People do not work mechanically in their business nature, they work by experience, instinct and analysis. Therefore, the study of projects should be less about predictive certainty, and more about the insight and broad understanding that exploration using the complexity metaphor can bring. The uncertainty inherent to project management must be understood and managed rather than linearized and ignored—which is essentially the command and control doctrine.
In the authors’ second paper at this conference7 a possible framework is proposed that claims to support this paradigmatic shift. This framework recognizes that in this new environment the perspective that the project team adopts, through which a representation is made, and on which decisions are based, is critical in the development of a ‘coherent’ strategy. By coherent we simply mean that the strategy is aligned with requirements defined from within and without the project team, i.e., it is ‘situated’. In order to achieve such a strategy the interactions between the different team members and the team environment must be rich. Interaction and exploration are key features of this (post-positivist) framework. In essence, what is proposed is a control strategy (without the ‘command’). Such control is not prescriptive (that would comprise of commands) but instead is of the ‘specify, observe, test, and respond’ variety such as adjusting the temperature of your shower. The framework is based upon the following ten basic building blocks:
Each of which is explained in detail at reference 7. These ten building blocks are unified through taking five simple steps: (i) identify yourself and your goals, (ii) use the right language, (iii) create the right context, (iv) turn people loose and then get out of the way, and (v) use communication that works. For further details see reference 8. For further details of control strategies, which we would prefer to refer to as ‘guidance’ strategies, see the literature on Perceptual Control Theory as expounded in reference 9.
The premise of this paper is simple. Interaction and exploration are vital in modern management endeavors, group decision support (GDS) tools are based upon these same two concepts, and so GDS tools, by definition, should be an effective tool in the struggle to create coherent strategies.
After a brief introduction to what participative decision support tools are and their mode of application, their potential contribution to each of the ten building blocks will be discussed in an attempt to support the paper’s premise. A secondary aim of the paper is to add to the body of literature concerning the GDS techniques and technologies. More than a dozen years of research in the lab and in the field have shown that GDS can substantially improve group productivity. There are now several thousand GDS installations worldwide, and that number is growing, but GDS has not yet achieved a mass market10. This may simply be through a lack of awareness concerning the existence of such methods. It might be a reluctance to accept the paradigm-shift as real and necessary, in which case many might find it hard to class such techniques as ‘scientific’ and therefore be unprepared to take the plunge. Whatever the reasons, it is hoped that this paper will add to the growing literature supporting the use of such approaches.
To get the most out of this paper it is recommended that the reader first look at the our other conference paper “Towards Coherent Project Management.”7
Group decision support systems (GDSS) facilitate the sharing of information and expertise to improve the quality of group decision making. The full benefits of such approaches accrue in decision-making contexts where the problem situation is ‘messy’. One of the most pervasive characteristics of messy problems is that people hold entirely different views on (a) whether there is a problem, and if they agree there is, (b) what the problem is. In that sense messy problems are quite intangible and as a result various authors (see for example reference 11) have suggested that there are no ‘objective’ problems, only situations defined as problems by people. Given the increasing complexity of the project teams and their operating environment more and more decisions of this type arise. These varying perceptions of whether a problem might or might not exist and what might constitute the problem derive from the different mental models each project member is endowed with. Indeed, the starting point of any group decision analysis will be based on the different perceptions of the participants. We have already stated that the use of GDSS facilitates the sharing of information and expertise. Another way of stating this is that GDSS systematically elicits and shares mental models within teams—with the aim of developing a ‘negotiated reality’ as a basis for decision-making. The underlying assumption being that this interactive process will inevitably lead to better decision-making, as the problem space would be better explored and the participants would buy into the decision resulting in greater success for decision implementation.
Exhibit 1. GDSS features (Adapted from J. Nunamaker, Jnr., et al. 12)
Working in team environments is not always easy, and is not always effective. For instance, the team members may simply follow the lead of the senior member (conformance), or the team members may be more concerned with reaching agreement than with the quality of the final decision (a process known as groupthink13). GDS researchers claim that GDSS overcome these limiting factors14, and in so doing contributing significantly to the value of group decision exercises. Exhibit 1 summarizes both the potential losses and gains to the group decision process that result from the use of GDSS. The numbers in Exhibit 1 identify the GDSS features that prior research suggests contribute to increasing (numbers enclosed in parentheses) or decreasing (numbers enclosed in brackets) the specific processing gains and losses.
Exhibit 2 illustrates a ‘typical’ GDS intervention. A group of decision-makers (e.g., members of a project team needing to adopt a key supplier) are gathered together, either physically or, via technology, virtually. They are supplied with a facilitator who manages that decision making process for the group, but (generally) does not contribute to the content of the decision. At various stages of the intervention, the decision-makers are asked to contribute to an evolving group database that, over time, begins to define the problems and their solutions. For example, as an initial task, the group might use a networked computer system to brainstorm the key issues currently confronting their organization. This information would be collected by the facilitator (in real time) and given a rudimentary structure (e.g., encoded as an interrelated map of ideas), potentially using a specialized decision support system linked to the database. The facilitator’s initial attempts at structuring the information would then be relayed to the group, via interactive visualization technologies and restructured to reflect the group's own understanding of the situation. The group would then use this understanding in the next stage of the process (e.g., evaluation of priorities).
Exhibit 2. GDSS process
The crux of the GDS approach lies not in the, often impressive, technology, but in the way the decision process is managed. GDSS allows a group to document and manage the complexity of its situation. This complexity can often paralyze a group into inaction, or lead it to continually revisit the same issues in a frustrating re-enactment of “Groundhog Day.” Successful systems encourage groups to interact with the information they are creating, altering it and questioning assumptions as they move towards an enhanced understanding of the situation. Rather than leaving key parts of the puzzle in the heads of individuals GDSS elicits that information, structures it and presents in a manner that allows groups to work with the full complexity of the problem—as opposed to oversimplifying it into unreal, but manageable, chunks.
GDSS provides a suite of powerful tools to assist groups making decisions in a complex environment—all designed to aid understanding and exploration, rather than produce formulaic ‘answers’. Some of these tools include: electronic brainstorming; idea mapping; electronic voting; interactive simulation models; cluster mapping; interactive questionnaires and; conflict identification and resolution systems. With all these tools at their disposal, facilitators can approach a problem from multiple angles—often widening the perspectives of the decision-makers in the process.
One of the most exciting developments in the area of global team working is the rise of the virtual community concept. Virtual communities have grown out of the explosive growth in the use of the Internet. Like so many Internet-based initiatives, society has stolen a march on ‘big business’. Many have advocated this global communications framework as the vehicle upon which to build a new organizational model. However, while companies have harnessed its power as an information delivery and communications mechanism, they have singularly failed to harness its infinitely more potent potential as a knowledge creation tool. Meanwhile, community organizations like The Motley Fool have become big businesses by being able to nurture on-line communities.
A virtual community is an on-line meeting and collaboration space, where individuals can identify common interests, share ideas and collectively solve problems. Newsgroups are a simple, but extremely effective, example of a virtual community in action. More sophisticated systems have been developed for specialized areas. For example, The Motley Fool focuses on financial information and includes articles on personal investment, assessments of investment opportunities and private areas where groups can set up their own global ‘investment clubs’.
Virtual communities may provide the mechanism for the new organizational model that Internet advocates have been predicating for the past few years. A virtual community can be used to create organizations based on the complexity principles advocated by modern organizational theorists (see for example references 15 and 16). Rather than applying isolated complexity concepts to outmoded organizations (as tends to happen), and watching as the “innovative new idea” inevitably crumbles, virtual communities allow a complete, parallel, complexity-based organization to be overlaid on the existing organizational structures.
The virtual community concept presents a particular opportunity for the operation of project teams. Due to its independence from traditional organizational structures and geographical boundaries, it allows teams to be formed based solely on the profiles of individuals. Project managers no longer have to make do with local resources, truly global resources pools can be tapped for the smallest projects. Management thinkers, such as Handy17, have forecast an increase in the use of project teams comprised of independent, self-employed specialists—such as the model used in the film industry. Simultaneous forecasts for the rise in knowledge working suggest that tomorrow's successful organizations will be temporary affairs that can support efficient collaboration between the best expertise, wherever it is located. Virtual community technologies excel at such tasks.
Over the past few years, the GDS community has begun to see the potential of virtual communities as collaborative decision making environments. As a result, some of the most innovative GDSS now combine the formation of community with powerful analysis and visualization tools developed from years of organizational decision-making research. Such hybrid systems can tap vast reservoirs of global knowledge, over extended periods of time, and efficiently turn this vast knowledge base into enhanced organization understanding and timely, up-to-date, decisions.
In the remainder of this paper, GDSS will be taken to refer to the wider class of group support facilities that includes virtual communities and associated technologies (such as on-line ‘chat-rooms’).
The remainder of this paper will consider how the different attributes of the GDS process contribute to the ten building blocks that are seen as necessary components in the development of coherent project management strategies. The essence of each building block will be expressed, with further details being found at references 7 and 8.
Project management is complex enough without making it more so. The guiding principles that work are those that are aligned with basic values. Using guiding principles is much better in helping people work efficiently than having a 20-page prescription. The fundamental guiding principles in GDSS are exploration and interaction, and the authors have asserted elsewhere7 that these key ingredients are essential in the process to development coherent project management strategy. The group decision process could be utilized to explore further and assist in the identification of simple guiding principles. However, the guiding principles intrinsic to GDSS are very powerful in themselves. Rather than specifying the determined guiding principles, team members can experience the manifestations of adopting these principles through everyday use of GDSS. Given the previously reported successes of those who have taken advantage of GDSS for complex decision-making, the team would experience for themselves the benefits of working in such an interactive mode and buy into the underlying principles (consciously or sub-consciously). Through their continued use the simple guiding principles of exploration and interaction would become internalized as part of the individuals’ mental models encouraging each of them to carry these principles into other areas of their work where a GDSS might not be obviously employed. Experience has shown us that the individual may be unaware of this transition, but a change in behavior is instigated.
Each of us possesses a mental model that we employ to interpret our surroundings. These models are not static, but are amended and refined daily as we live our lives. Given that our personal history plays a central role in the details of this model it is not surprising that our personal models are unique. This means that when two people look from the same point in the same direction they will ‘see’ different things, sometimes entirely different. Generally, a mental model can be considered to be anything that helps an individual to answer questions, and a model can be seen to be good to the extent that one finds it useful for answering questions. We have already suggested that GDSS can affect the aspects of individuals’ mental models that guide how they go about investigating a problem, but can it help to enable individuals to develop appreciations of their colleagues’ mental models? Given that GDSS, an example being electronic brainstorming, encourages interaction and facilitates the visualization of the problem space, one would expect it to be invaluable in helping each member develop such an appreciation.
A major selling point, though, of GDSS is that contributions to the analysis are anonymous. Anonymity mitigates the effects of free riding, conformance pressure and domination, but at the same time it prevents the source of the contributions from being known. This can hinder the direct sharing of opinions that would yield insight into the contributors’ perspective. This in turn would affect ‘group memory’ or the group’s mental model. However, without the anonymity feature a very relaxed and open atmosphere would already have to exist within a team so that free riding, conformance pressure, and domination were not important issues. There exists the potential for trade-off. Is awareness of individuals’ mental models more important than overcoming negative group processes that limit problem exploration? The answer to this is not black and white, like most answers to many questions concerning complex problems. In some teams continued practice of the simple guiding principles encourages an atmosphere in which anonymity is no longer necessary. Of course, debating the value of different concepts and how they might relate to each other will draw out the opinions of individual contributors so all is not lost, even in quite dysfunctional teams.
The increasingly complex environment in which project teams operate, makes deciding what action to take, and when, problematic. What is needed is the means to recognize patterns in our complex environment to facilitate the decision-making process. The ‘means’ comes in the form of an interface that can be used to take advantage of our considerable pattern recognition skills. The metaphor of landscapes can provide this interface in the very same way that Windows provides the interface between the 0s and 1s of computers and ourselves. GDSS can provide an integral part of this interface. For example, the development of a qualitative system dynamics model (or influence diagram, or causal map) within a group setting, which is an effective way of synthesizing the project members’ different perspectives, will facilitate the visualization of the problem space, which will enable coherent maneuvering within the project ‘landscape’. Furthermore, quantitative system dynamics modelling will provide further input into the development of the operating landscape by allowing real-time investigations into how the landscape might evolve in response to the implementation of different project strategies.
It is important to be aware of how the different elements of a GDSS bind the exploration of the landscape, and not to become too dependent upon one approach.
There has been much written in the management literature suggesting that operation within a complex environment requires holistic thinking, as opposed to reductionist thinking. This perspective is valuable (and synthesizing the different perspectives of the project team will result in a more ‘complete’ picture), but it is not the be all and end all. Sometimes, in simply reorganizing the elements that make up the current perspective, new, and potentially valuable, interpretations of the ‘landscape’ are uncovered. Most of the GDSS available provide a facility to visualize the problem space, also providing a variety of powerful tools to manipulate the representation to allow viewing from different positions. The ability to identify leverage points, potent concepts, and hiersets, etc. are central features of the Group Decision Explorer tool, for example. GDSS is very much attuned to assisting in the identification of what makes up the ‘whole’ and how those parts interact with each other by encouraging both bottom-up and top-down perspectives in the development of the ‘landscape’.
In the modern organization the identity of each individual is written out explicitly in the company’s operating procedures, along with the roles and responsibilities that the identity should be associated with. For instance, in a project team there might be the Project Manager, Quality Manager, Technical Manager, Project Secretary, Technical Support, Subject Matter Expert, and so on. The problem with such distinct, and unchanging identities, is that context is pre-defined, i.e., the rules of engagement are determined beforehand not taking into account local conditions. As with most teams the roles and responsibilities, though initially based on the company ‘operating plan’, evolve as the team evolves so the recognition of multiple roles will inevitably occur. To allow this evolution to occur team members must feel comfortable about stepping over the boundaries described by their formal job description. This can help lever creativity that would be otherwise suppressed through the detailed definition of roles and responsibilities. Although GDSS does not explicitly address such issues, (though the generation of the project ‘landscape’ may shed light on the importance of members’ role(s)), the spirit of exploration and interaction endorsed will encourage an atmosphere in which members will feel comfortable in exploring the boundaries of their own roles.
The need for a level of team member freedom in order to endow the team, not only with the flexibility necessary to adapt to changing requirements, but also with the inquisitiveness to explore their surroundings, is essential when operating as part of a complex project. This inquisitiveness contributes to the successful development of a coherent strategy, and also enables the team to pre-empt changes to the strategy as necessary. It is difficult, if not impossible, to build such features into the fabric of the project team through the application of extensive procedures. The whole underlying philosophy of GDSS has developed to support such requirements. Not only are previously untapped sources of creativity levered by addressing and reversing many of the negative performance features of project teams, but they also provide a structured way of exploring the complex problem space. GDSS very much supports the creation of canyons by not placing rigid boundaries around the team. Naturally, the team’s endeavors are bounded by the GDS paradigm but this is a very large ‘space’ to traverse. If the GDSS being employed is used appropriately then any limitations defined by the tool will be uncovered, and the team can, informed by their already developed understanding of the situation, look elsewhere for the necessary support.
Telling stories is about allowing others the benefit of shared experiences. Stories allow others to relate to fact, context, emotion, and to bring their own interpretation to what they hear or read. This richer mode of interaction also enables others to develop insight into how an individual sees the world, and in what contexts they use certain words. In some ways the computer-based GDSS limits the telling of stories by reducing ‘socializing’ within the team, which is seen as a negative attribute, and by channeling much communication (at least during the early stages of process of decision-making) through the computer equipment. Telling stories plays an important part in the creation of a cohesive (or synergic) team. The stories not only convey important information regarding the problem space, but also allow others to sympathize with the storyteller’s perspective and appreciate how the storyteller uses language (which will mitigate the chances of misunderstanding and conflict when members interact). During the debating stage of group decision-making, stories concerning relevant experiences can be important in legitimizing certain concepts and relations that might have been proposed during the brainstorming session. GDSS by no means wholly prevents story telling, and the process can certainly benefit from the telling of stories. It is up to the facilitator to judge whether the story is ‘valuable’, or whether it is simply causing the team to defocus.
In order to remain coherent the team must have a clear understanding of what is going on in its environment, and how different events might affect the team’s operations. It is arrogant to believe that the team knows everything there is to know about the subject matter it is working on, customer politics, etc. By sending out scouting parties to probe the environment, vital stories might be found that would be of great value to the team in achieving its goals. One of the great benefits of GDS is that it quickly highlights areas where a group's knowledge is too weak to make an accurate decision. By structuring the issues faced by an organization, and the strategies required to tackle these issues, visualization tools can be used to accurately pinpoint missing information. This provides an agenda for a team's scouts. Ideally, scouting parties would be given a completely open agenda, ensuring that they do not focus on certain issues prematurely. However, the temporal and financial constraints of business life often make this an unrealistic ideal. By focusing the scouting activity, GDS maximizes the benefit of this investment.
GDSS documents the on-going decision process within a group and sets up a dialogue between the project group and this documented understanding. When scouts report back to the group, their insights can be fed directly into the group's evolving ‘organizational memory’, allowing them to be assimilated by the other group members. In addition, the information obtained by the scouts is unlikely to be neatly packaged. They will have ill-defined experiences and perceptions, just as the decision-makers have of their own organization. The GDS framework will assist in extracting this tacit knowledge and determining what is of value to current requirements.
Finally, virtual communities can be used to provide vast numbers of scouts who report on a regular basis. As virtual communities make it easy for many individuals to participate in a project (by allowing multiple simultaneous communications channels and removing geographical barrier) an extended project team can be recruited, comprised of anyone who may have useful information to contribute. One example of this approach is the formation of an industry discussion group associated with a given project—where people from different organizations meet to swap ideas. Such groups are time consuming to operate in practice—not least because they require regular meetings to be organized. Virtual discussion groups operate continuously, with minimum maintenance, and support collaboration between hundreds of individuals. Each member of this group effectively becomes part of the project team, surveying the environment for pertinent information.
No project team will maintain coherence if the varied contributions of its members and of the team itself are not recognized with sufficient attendant notice such that the members involved can develop pride with regard to their activities. Such acts of recognition and notice function as ‘road signs’ within a community or housing development. Not only do such signs allow for recognition, but they also allow for meaningful directions to be communicated to others who are not part of the team.
One of the concerns often voiced about GDSS is their anonymity. This allows individual members of a team to express their true feelings without fear of reprisals. However, this strength can become a weakness when people want to be recognized for their contribution. Criticisms of this kind, however, tend to be based on a misunderstanding of the practice of GDS. Those who contribute key ideas tend to explicitly note the fact that it is their idea—either verbally or though the use of the technology used to support the team.
In fact, GDSS tends to reinforce the contribution of individuals by clarifying the role of the project and the individuals’ activities within it. By helping to nurture a team memory, or negotiated reality, each person's role is unambiguously recognized across the team, and the significance of his/her assigned tasks is explicitly mapped back to the success of the entire project. This reduces the potential for others to downplay the activities of an individual. If they do not agree with the task, which was explicitly documented by the GDS exercise, why did they not bring it up at the time?
Many GDS approaches begin by placing the project in context—i.e., determining how it supports the wider organizational goals. This context is essential in providing a full understanding of the project. As a by-product of this process, individuals can trace the benefits of their activities through to the goals of the wider organization. This allows these individuals to demonstrate their worth to the organization and, as a result, senior management.
In a number of the elements described thus far, mention has been made of the importance of language and the development of a project language. Despite the many supporters of a definitive English language, words do not have absolute meaning—which would require the omission of context. The meaning of words depends strongly on the context, i.e., the meaning of words depends upon usage. Given our different mental models, our personal context, the same word will mean something slightly different. In effect, the words we each use determine what we ‘see’. If, then, we all use words differently, how can we convey our thoughts to others without a common comprehension of what the words mean? We can’t. However, through word usage, through story telling for example, an appreciation of how individual team members use words and associate meaning with them can be developed (which in turn provides insight into their mental models). We call this a project language. This language acts as a shorthand for the team, relieving the members of the need to provide complicated explanations to each other, and helping to develop a unique team culture. Anyone who has ever worked in a military environment will recognize the role of acronyms in developing an efficient, if exclusive, organizational language.
As with posting road signs, the focus of GDSS on the development of a common team mental model provides the basis for a shared vocabulary. In fact, the technical terminology of a given GDS process can help to form part of that vocabulary. An obvious example is in scenario planning, where a team is asked to define a set of 3–4 scenarios which represent possible future environments in which the team may have to operate. Each of these scenarios is purposely given a snappy, memorable title so that the group can integrate the scenarios into their everyday language. The titles are given their meaning by the group, from the shared process of constructing the associated scenarios. In another example, taken from a GDSS used by one of the authors, ideas generated by the group have associated numbers that allow them to be quickly referenced by the software. These ideas have no meaning beyond this housekeeping activity. However, groups quickly adopt the numbers as a team vocabulary and months after a GDS session can be heard asking, “How are we doing on 67?”.
This paper has attempted to open up a debate about the role of GDSS (and virtual communities) in project management. It has argued that modern projects are complex environments and introduced ten building blocks that are important facets in the successful management of complex project. It was then argued that GDSS could assist in the application of each of these building blocks.
Perceptual Control Theory suggests that projects can be viewed as ‘control’ hierarchies. “In a control system hierarchy … the higher systems, rather than telling the lower ones how to act, tell the lower systems what to perceive. It is up to the lower systems to produce whatever actions are required to make the real perception match the reference perception. This means that the higher systems don’t have to plan what to do in the case of disturbances; the lower systems will do so without being told if they can, and will notify the higher systems if they cannot.”9 The higher systems function to alter the reference perceptions. Management consists of guiding what team members perceive rather than instructing them on how to act. The ten building blocks, supported by GDSS, function as a critical means of providing such guidance and of providing the monitoring system for when actions at lower levels are not aligned with reference perceptions. While there is little proof, to date, that control hierarchies function better than command and control hierarchies, the many documented failures of the latter suggest that in the face of complexity something different is needed.
Projects will continue to become more complex. The march of technology, and its influence on global financial and business activities will ensure that this is the case. Society is also evolving, leading to significant changes in the way we work. If managers continue to use traditional project management processes, these societal changes will compound the complexity they face. Only by adopting new participative and exploratory project management practices will it be possible to effectively manage the projects of the future.
The challenge falls on two sides. GDS researchers and practitioners must turn their attention to providing on- going support to project teams. For too long have they focused on, arguably more glamorous, ‘one-off’ strategic decisions. Project teams need processes and systems that are easy to set up and maintain over extend periods of time. Conversely, project teams need to adopt group decision technologies in managing their projects. The tools already exist to allow them to manage more effectively. Teams need to become less focused on predictive, command and control approaches and adopt the flexible, exploratory (and sometimes scary) approaches necessitated by the complex environment they now face.
5. Richardson, K A and Cilliers, P. 1999 The role of operational analysis for strategy development in a postmodern world. Presented at OR41, Edinburgh, September 1999. Detailed notes and overheads available from Richardson (firstname.lastname@example.org).
10. Briggs, R O, Mittleman, D D, Weinstein, N, Nunamaker, J F and Adkins, M E. 1998 Collaborative technology for the sea-based warfighter: a field study of GSS adoption and diffusion. Proceedings of the 31st Annual Hawaii International Conference on System Sciences, Hawaii.
12. Nunamaker, J, Dennis, A, Valacich, J, Vogel, D and George, J. 1993 Group support systems research: experience from the lab and field. In Group Support Systems: New Perspectives, edited by Jessup, L M and Valacich, J S. Macmillan, ISBN 0023606258.