Archive for the ‘Communication’ Category
Groupthink in project environments
Introduction
Groupthink refers to the tendency of members of a group to think alike because of peer pressure and insulation from external opinions. The term was coined by the psychologist Irving Janis in 1972. In a recent paper entitled, Groupthink in Temporary Organizations, Markus Hallgren looks at how groupthink manifests itself in temporary organisations and what can be done to minimize it. This post, which is based on Hallgren’s paper and some of the references therein, discusses the following aspects of groupthink:
- Characteristics of groups prone to groupthink.
- Symptoms of groupthink.
- Ways to address it.
As we’ll see, Hallgren’s discussion of groupthink is particularly relevant for those who work in project environments.
Background
Hallgren uses a fascinating case study to illustrate how groupthink contributes to poor decision-making in temporary organisations: he analyses events that occurred in the ill-fated 1996 Everest Expedition. The expedition has been extensively analysed by a number of authors and, as Hallgren puts it:
Together, the survivors’ descriptions and the academic analysis have provided a unique setting for studying a temporary organization. Examining expeditions is useful to our understanding of temporary organizations because it represents the outer boundary of what is possible. Among the features claimed to be a part of the 1996 tragedy’s explanation are the group dynamics and organizational structure of the expeditions. These have been examined across various parameters including leadership, goal setting, and learning. They all seem to point back to the group processes and the fact that no one interfered with the soon-to-be fatal process which can result from groupthink.
Mountaineering expeditions are temporary organisations: they are time-bound activities which are directed towards achieving a well-defined objective using pre-specified resources. As such, they are planned as projects are, and although the tools used in “executing” the work of climbing are different from those used in most projects, essential similarities remain. For example, both require effective teamwork and communication for successful execution. One aspect of this is the need for team members to be able to speak up about potential problems or take unpopular positions without fear of being ostracized by the group.
Some characteristics of groups that are prone to groupthink are:
- A tightly knit group.
- Insulation from external input.
- Leaders who promote their own preferred solutions (what’s sometimes called promotional leadership)
- Lack of clear decision-making process
- Homogenous composition of group.
Additional, external factors that can contribute to groupthink are:
- Presence of an external threat.
- Members (and particularly, influential members) have low self-esteem because of previous failures in similar situations.
Next we’ll take a brief look at how groups involved in the expedition displayed the above characteristics and how these are also relevant to project teams.
Groupthink in the 1996 Everest Expedition and its relevance to project teams
Much has been written about the ill-fated expedition, the most well-known account being Jon Krakauer’s best-selling book, Into Thin Air. As Hallgren points out, the downside of having a popular exposition is that analyses tend to focus on the account presented in it, to the exclusion of others. Most of these accounts, however, focus on the events themselves rather than the context and organizational structure in which they occur. In contrast, Hallgren’s interest is in the latter – the context, hierarchy and the role played by these in supporting groupthink. Below I outline the connections he makes between organizational features and groupthink characteristics as they manifested themselves on the expedition. Following Hallgren, I also point out how these are relevant to project environments.
Highly cohesive group
The members of the expedition were keen on getting to the summit because of the time and money they had individually invested in it. This shared goal lead to a fair degree of cohesion within the group, and possibly caused warnings signs to be ignored and assumptions rationalized. Similarly, project team members have a fair degree of cohesion because of their shared (project) goals.
Insulation from external input
The climbing teams were isolated from each other. As a result there was little communication between them. This was exacerbated by the fact that only team leaders were equipped with communication devices. A similar situation occurs on projects where there is little input from people external to the project, other teams working on similar projects or even “lessons learned” documents from prior projects. Often the project manager takes on the responsibility for communication, further insulating team members from external input.
Promotional leadership
Group leaders on the expedition had a commercial interest in getting as many clients as possible to the summit. This may have caused them to downplay risks and push clients harder than they should have. This is similar to situations in projects which are seen as the “making of project managers.” The pressure to succeed can cause project managers to display promotional leadership.
Lack of clear decision making process
All decisions on the expedition were made by group leaders. Although this may have been necessary because group members lacked mountaineering expertise, decisions were not communicated in a timely manner (this is related to the point about insulation of groups) and there was no clear advice to groups about when they should turn back. This situation is similar to projects in which decisions are made on an ad-hoc basis, without adequate consultation or discussion with those who have the relevant expertise. Ideally, decision-making should be a collaborative process, involving all those who have a stake in its outcome.
Homogeneous composition of group
Expedition members came from similar backgrounds – folks who had the wherewithal to pay for an opportunity to get to the summit. Consequently, they were all highly motivated to succeed (related to the point about cohesion). Similarly, project teams are often composed of highly motivated individuals (albeit, drawn from different disciplines). The shared motivation to succeed can lead to difficulties being glossed over and risks ignored.
External threat
The expedition was one of many commercial expeditions on the mountain at that time. This caused an “us versus them” mentality, which lead to risky decisions being made. In much the similar way, pressure from competitors (or even project sponsors) can cloud a project manager’s judgement, leading to poor decisions regarding project scope and timing.
Low self esteem
Expedition leaders were keen to prove themselves because of previous failures in getting clients to the summit. This may have lead to a single-minded pursuit of succeeding this time. A similar situation can occur in projects where managers use the project as a means to build their credibility and self-esteem.
Symptoms and solutions
The above illustrates how project teams can exhibit characteristics of groups prone to groupthink. Hallgren’s case study highlights that temporary organisations – be they mountaineering expeditions or projects – can unwittingly encourage groupthink because of their time-bound, goal-focused nature.
Given this, it is useful for those involved in projects to be aware of some of the warning signs to watch for. Janis identified the following symptoms of groupthink:
- Group members feel that they are invulnerable
- Warnings that challenge the groups assumptions are rationalized or ignored.
- Unquestioned belief in the group’s mission..
- Negative stereotyping of those outside the group.
- Pressure on group members to conform.
- Group members self-censor thoughts that contradict the group’s core beliefs.
- There is an illusion of unanimity because no dissenting opinions are articulated.
- Group leaders take on the role of “mind-guards” – i.e. they “shield” the group from dissenting ideas and opinions.
Regardless of the different contexts in which groupthink can occur, there are some stock-standard ways of avoiding it. These are:
- Brainstorm all alternatives.
- Play the devil’s advocate – consider scenarios contrary to those popular within the group.
- Avoid prejudicing team members’ opinions. For example, do not let managers express their opinions first.
- Bring in external experts.
- Discuss ideas independently with people outside the group.
Though this advice (also due to Janis) has been around for a while, and is well-known, groupthink remains alive and well in project environments; see my post on the role of cognitive biases in project failure for examples of high-profile projects that fell victim to it.
Conclusion
Hallgren’s case study is an excellent account of the genesis and consequences of groupthink in a temporary organisation. Although his example is extreme, the generalizations he makes from it hold lessons for all project managers and leaders. Like the Everest expedition, projects are invariably run under tight time and budgetary constraints. This can give rise to conditions that breed groupthink. The best way to avoid groupthink is to keep an open mind and encourage dissenting opinions – easier said than done, but the consequences of not doing so can be extreme.
Beware the false analogy
Reasoning by analogy refers to the process of drawing inferences based on similarities between different objects or concepts. For example, the electronic-hydraulic analogy is based on similarities between the flow of water in pipes and the flow of electricity in circuits. Closer home, project teams often use analogies when they estimate tasks based on similar work that they did in the past. Analogical reasoning is powerful because it enables us to leverage existing knowledge in one area to solve problems in other, possibly unfamiliar, areas. However, such reasoning can also mislead. This post looks at the problem of false analogies in project estimation.
I’ll begin with a story…
—
Some years ago, I was in a discussion with a client, talking about costs and timelines for an application that the client needed. The application was a sales bonus calculator for front-line sales staff. The client needed an app that would calculate bonuses for each salesperson (based on some reasonably involved calculations) and display them via a web front-end. Nothing fancy really, just a run-of-the-mill corporate web-database application. The discussion was proceeding quite nicely until a manager from the client’s side felt obliged to make a remark based on a false analogy. I can’t recall the conversation word-for-word, but it went something like this:
“It can’t be that hard, he said. ” You guys have built a similar application before, your promotional literature says so”. He knew from our brochure that we had built a bonus calculator before; problem was he didn’t know the details.
There was a brief silence until my boss said, “Umm…yes we have done a superficially similar project before, but the details were very different from this one.”
“How different can it be?” retorted the manager, “bonuses are based on sales data. You process the data based on rules and display it. Yes, the rules are different, but the concept’s the same. You should be able to do it in half the time you’ve quoted.”
My boss countered the argument politely, but the manager would not let it go. They went back and forth a number of times until the sponsor stepped in and asked my boss to ensure that the manager’s concerns were addressed. The issue was resolved later, after my boss stepped the manager through the application, showing him just how different it was from the one they had requested.
—
The technical manager based his estimate on a superficial similarity between the app we were building for him and one that we had done earlier. Analogies almost always break down when examined in detail. For example, the electronic-hydraulic analogy mentioned in the first paragraph has several limitations. The same is true when comparing two projects or tasks.
An insidious (and dare I say, more common) occurence of such reasoning is when team members themselves draw false analogies. This happens when they make seemingly harmless (and often tacit) assumptions regarding similarities between tasks that are actually dissimilar in ways that are important. See my post on the reference class problem for a discussion of an estimation technique that is prone to incorrect analogical reasoning.
Estimates based on false analogies are a reflection of poorly understood requirements. This begs the question: why are requirements misunderstood when most projects involve countless meetings to discuss scope and requirements? In my opinion this happens because talking about requirements doesn’t mean that everyone understands them in the same way. In fact, in most cases different stakeholders walk away from such meetings with their own version of what needs to be done and how to do it. The first step towards curing the problem of false analogies is to ensure that all stakeholders have a shared understanding of the requirements. This applies particularly to those who will create the product and those who will use it. Dialogue mapping, which I’ve discussed at length in several posts on this blog, offers one way to achieve this shared understanding.
Of course, a deep understanding of the requirements does not by itself cure the problem of false analogies. However, it does make estimators aware of what makes a particular project different from all the other ones they’ve done before. This makes it unlikely that they’ll use a false analogy when making their estimates.
On the relationship between systems and the organisations that build them
Introduction
System design is a creative activity, but one that is subject to a variety of constraints. Many of these constraints are obvious: for example, when tasked with designing a new software product, a team might be asked to work within a budget or use a particular technology. These constraints place boundaries on the design activity; they force designers to work within parameters specified by the constraints. But there are other less obvious constraints too. In a paper entitled, How Do Committees Invent, published in 1968, Melvin Conway described a notion that is now called Conway’s Law: An organisation which designs a system will inevitably produce a design that mirrors the organisation’s communication structure. This post is a summary of the key points of the paper.
Conway begins the paper with the observation that the system design is an activity that involves specifying how a system will be built using a number of diverse parts. Many elements of the act of design are similar, regardless of the nature of the system –be it software or a shopping mall. The objective of a design team or organisation is to produce a specification or blueprint based on which the system can be built.
Much of design work is about making choices. Conway points out that these choices may be more than design decisions:
Most design activity requires continually making choices. Many of these choices may be more than design decisions; they may also be personal decisions the designer makes about his own future. As we shall see later, the incentives which exist in a conventional management environment can motivate choices which subvert the intent of the sponsor.
The paper is essentially an elaboration and justification of this claim.
Pre-design work
The preliminary stages of design work are more about organizing than design itself. First, the boundaries have to be understood so that the solution space can be defined. Second, the high-level structure of the system has to be explored so that work can be subdivided in a sensible way within the organisation that’s doing the design. This latter point is the crux of Conway’s argument:
…the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise. Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist. Therefore, there is no such thing as a design group which is both organized and unbiased.
There are a couple of important points here:
- The act of delegating design tasks narrows the scope of design options that can be pursued.
- Once tasks are delegated to groups, coordination (via communication) between these groups is the only way that the work can be integrated.
Further, once established, it is very hard to change design idea (or a project team, for that matter).
The system mirrors the organisation
Most systems of any significance are composed of several subsystems that communicate with each other via interfaces. According to Conway, these elements (italicized in the previous sentence) have a correspondence with the organisation that designs the system. How so? Well, every subsystem is designed by a group within the organisation (call it a design group). If two subsystems are to communicate interact with each other, the two groups responsible for their design must communicate with each other (to negotiate the interface design). If subsystems don’t interact, no communication is necessary. What we see from this argument is that the communication between subsystems roughly mirrors the communication paths within the organisation.
As any system designer knows: given a set of requirements, there are a number of designs that can satisfy them. If the argument of the previous paragraph is true then the structure of the design organisation (or project team) influences the choice that is made.
Managing systems design
Conway points out that large system design efforts spin out of control more often than those for small systems. He surmises that this happens when the design becomes too complex for one person (or a small, tightly-knit group of people). A standard management reaction to such a situation is to delegate the design of component to sub-teams. Why? Well here’s what Conway says:
A manager knows that he will be vulnerable to the charge of mismanagement if he misses his schedule without having applied all his resources. This knowledge creates a strong pressure on the initial designer who might prefer to wrestle with the design rather than fragment it by delegation, but he is made to feel that the cost of risk is too high to take the chance. Therefore, he is forced to delegate in order to bring more resources to bear.
A major fallacy in this line of thinking is that more resources means that work gets done faster. It is well known that this isn’t so – at least as far as software systems development is concerned. Conway points out that politics also contributes to this effect. In most organisations, managerial status is tied to team size and project budgets. This provides an incentive to managers to expand their organisations (i.e. project teams), making design delegation almost inevitable.
Large teams have a large number of communication paths between their members. Specifically, in a team consisting of N people, there are N(N-1)/2 possible communication paths – each person can communicate with N-1 people making N(N-1), but this has to be halved because paths between every two individuals are counted twice. Organisations deal with this by restricting communication paths to hierarchical management structures. Because communication paths mirror organizational structures, it is almost inevitable that system designs will mirror them.
Conclusion
The main implication of Conway’s thesis is that a project team (or any organisation) charged with designing a system should be structured in a way that suits the communication needs of the system. For example, sub-teams involved in designing related subsystems should have many more communication channels than those that design independent components. Further, system design is inherently complex, and the first design is almost never the final one. A consequence that flows from this is that design organisations should be flexible because they’ll almost always need to be reorganized.
In the end it is less about the number of people on a team than the communication between them. As Conway mentions in the last two lines of his paper:
There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity. The development of such a philosophy promises to unearth basic questions about value of resources and techniques of communication which will need to be answered before our system-building technology can proceed with confidence.
This is as true now as it was forty-odd years ago.
Eight to Late 