Archive for the ‘Paper Review’ Category
The myth of the lonely project
Introduction
Much of project management theory and practice is based on the premise that projects that are lonely – that is, they are unique undertakings, largely independent of their organizational environment and history. In an important paper published in 2003 entitled, No project is an island: linking projects to history and context, Mats Engwalls argues that such a view is limited and misleading. This post presents a summary and some reflections on the paper.
Background
It is easy to understand why the lonely project perspective dominates much of project management practice and research. A project manager’s focus is on his or her current project; history, environment and context are therefore seen as irrelevancies. Perhaps as a consequence, this view also permeates much of mainstream research in the field. There are exceptions, of course, such as the paper I have reviewed in my post on the relationship between projects and organisations.
As Engwall states:
With few exceptions, research has been dominated by a perspective based on “the lonely project”. The primary interest has been in the structures and dynamics of individual projects, typically discussed from the individual project manager’s (PM’s) perspective. As an outcome, the project has been conceptualized as a lonely phenomenon, independent of history, contemporary context and future. Earlier experience, simultaneous events, and future intentions are seldom included in the analysis. In this dominating ontology, procedures employed in one project are considered to be unique and factors determining project success are considered to be due to the individual project in question
In contrast, organizational theory has long recognised that (permanent) organisations are influenced by their environment and history. As he states:
In organizational theory, the environmental impact on organizations is a classical issue. There are probably few organizational theorists today who would challenge the idea that external factors strongly influence the inner life of an organization.
Engwall’s contention is that projects, like permanent organisations, are best viewed as open systems whose structures and processes are influenced by their environment and the history/culture of the organisations in which they are embedded. He builds his argument through a detailed analysis of two major engineering projects undertaken within one organisation. We’ll take a brief look at the two projects first and then discuss his analysis in some detail .
The case studies and the approach
The two projects were carried out within a major Scandinavian utility company. Both projects were multidisciplinary, involving teams with expertise in construction, process and electrical engineering. The first project – referred to as the Hydropower project– was a major upgrade of a hydroelectric plant and the second – called the Transmission project – involved the design and construction of a high voltage direct current (HVDC) power link across the Baltic Sea.
The two projects had several features in common. These include:
- Both were internal projects – i.e. the deliverables were intended for use by the power company.
- The projects were carried out in roughly the same period (between 1985 and 1992).
- They were the two biggest projects carried out by the company during the period.
- Both projects were organized on a matrix principle. Work carried out in individual departments was coordinated by the project manager.
- The project managers on both projects were of a similar age. Both were seasoned engineers with plenty of experience of working on major projects.
As we’ll see, the two projects took very different trajectories despite these similarities.
Engwall gathered data on the two projects through a variety of sources – from archives, through interviews and even by direct observations in project meetings. He then analysed the data from two perspectives: first, from the view of a near-autonomous project (the “lonely project” view) and then from a viewpoint that takes into account historical and contextual linkages with the parent organisation.
The lonely project view
The hydropower project
This project was implemented by the hydropower division, one of seven engineering and business divisions within the utility. The project was run by a project manager who coordinated the engineering work done by the different divisions. Most of the work was done by internal staff, supplemented by externals where necessary. Most important, though, is the fact that the project was run as a traditional “textbook” project. As Engwall puts it:
The PM was well aware of the message in project management literature and had the explicit intention of employing its concepts and techniques in his project. He put a strong emphasis on structuring, planning, scheduling, and cost control. He produced a project management handbook, defining guidelines and checklists for the project. He formally defined the roles and procedures of the project organization. He initiated start-up meetings, workshops, and seminars for key engineers, and assembled his project team for coordination meetings once a month. He felt responsible for all kinds of issues concerning the design and engineering of the hydropower plant…In many ways, his management approach resembled the role model of the project management textbooks.
The project manager felt that he was ultimately responsible for delivery of the design and engineering work, and his approach reflected this. In short: the project was run pretty much as recommended by project management orthodoxy.
The transmission project
This project was run by the transmission division of the utility. The project was managed by a team leader from one of the engineering departments within the division. The core HVDC system was procured from external vendor, but most of the other engineering work was done by different divisions within the company. The project manager’s main job was to coordinate the work done by the different divisions and the external party. He did not have as much positional or expert authority as his counterpart on the hydropower project. Further, he kept a much lower profile, often deferring to experts to make decisions. Significantly, neither the manager nor his deputy had any formal knowledge of project management principles. As Engwall puts it:
In relation to the Hydropower Project, this PM had a lower formal rank within the company’s hierarchy. In his position as PM, he had no formal authority at all. He held a degree in electrical engineering from a junior college. He was very humble, had a very low personal profile and was often silent during meetings. He, and his deputy, coordinated the project without an explicit management approach. Neither of them had any formalized training in project management and they had limited theoretical knowledge of project management methods and techniques. During the interviews, they often excused themselves for their lack of knowledge in project management theory.
Moreover, the project had no formal organizational structure. Project meetings were optional – it was up to the departments to decide whether or not send a representative. Most of the coordination work was done through direct (but informal) contact between the project manager and the engineers doing the work. The responsibility for scheduling and timely delivery of different modules was delegated to the engineering department doing the work. In short: the project was run without formal project management processes and controls.
Analysis
Surprisingly, the manager of the hydropower project had many more problems than his counterpart who ran the transmission project. As Engwall states:
The PM of the Hydropower Project encountered several difficulties when he tried to coordinate the activities of his project. Many of the participating engineers did not follow his instructions and decisions. The project was constantly delayed because the engineering departments were not paying enough attention to it. Furthermore, many of the engineering departments tried to perform their parts of the project independently of the other departments, and without the involvement of the PM. On many occasions, the PM found it impossible to gain control of the project, which he was formally in charge of. Time schedules and milestones were not taken seriously, costs were recorded without consideration to budget, and different departments were planning and engineering their technical power plant subsystems without sufficient coordination with the other players…
The project manager’s response to the above was pure traditional PM: he attempted to assert control by pushing the formal processes even further on an already mutinous team. Yet, despite his efforts, the project was judged a failure because of delays and budget blowouts.
In contrast, the transmission project ran smoothly, and was deemed a great success. The specifications were met within the stipulated budget. Further, the transmission link was operational several days ahead of schedule.
From the lonely project perspective, the difference between the two projects is paradoxical. As Engwall writes:
The PM with his formal authority, explicit management approach, and who deliberately applied state-of-the-art methods of project management was having significant problems, while the PM who lacked both formal authority and an explicit management approach, and who deviated substantially from the textbooks, was being significantly successful. How come?
As an answer to the question posed above, Engwall suggests that classical project management theory (as described in books and BOKs) is incomplete – i.e. there are factors that the theory does not take into account. To illustrate this point, he takes a broader perspective of the projects, one which includes the organisational environment (context) and history. We’ll look at this organisational view next.
The organisational view – linking projects to environment and history
The hydropower project
On the technical side, one of the key requirements of the hydropower project was that many features and aspects of the existing plant had to be preserved for their historical value. It was also stipulated that the plant had to continue operating uninterrupted whilst the upgrade was in progress. These requirements greatly increased the technical complexity of the project. Finally, the project was truly unique because it was the first time the organisation was carrying out a major upgrade within a single project; all prior upgrades had been carried out as a series of minor, ongoing extensions.
On the management side, the project was used as a testing ground for a new project management approach within the organisation. The new approach conflicted with the existing one in many ways. For one, the project manager took on responsibility for coordinating work between different engineering divisions – something that, in the old approach, was done through direct contact between those responsible for the work. Consequently, many project personnel saw the new approach as a deliberate move by management to micro-manage their work and reduce autonomy.
As Engwall puts it:
For the first time, engineers and department heads, who were used to working almost autonomously, encountered a PM who was deliberately trying to control the project process by actively getting involved in their day-to-day work. The management problems of the project were, in this sense, the result of a collision between two philosophies: … traditional procedures…and [a] “modern” management style…The hidden agenda behind the client’s appointment of this specific PM for this specific project was as follows: to force the Hydropower Division to change its management procedures from within.
In short: there was a clear lack of trust and open communication between the project manager and the team.
The transmission project
The transmission project, because of its strategic importance, was strongly supported by top management. The project was therefore given high priority. Further, the project was considered interesting by engineers because of its technical novelty and complexity. Yet, despite the perceived novelty, the organisation had carried out many similar projects involving HVDC technology. Further, the company already had a longstanding relationship with the external contractor who was responsible for the core HVDC component: the players involved in the project were known to each other and, more importantly, trusted each other. The key team members – many of whom had worked on the earlier HVDC projects – had the same responsibilities as they had on those prior endeavours. The project was therefore not so unique.
Another important point is that the low-key management style of the project manager fit perfectly with the ethos and existing procedures of the organisation. Quoting from the paper:
The PM had been working at the division in over 30 years; he was a well-respected engineer and had an in-depth understanding of the inner life of the division. He manifested trust in his engineering colleagues and had no interest in challenging the traditions of his division. He did not fight for any formal power or official recognition as a PM. Once the HVDC contract was signed, he left most of the responsibility for its execution to the informal team of key engineers….the PM did not challenge the permanent engineering departments by fighting for more formalized procedures or methods in accordance with project management textbooks. On the contrary, his humble and informal way of coordination harmonized the existing norms and structures perfectly.
In short: the PM did his job in a way that was sensitive to the expectations of those who worked with him. He did not violate the (explicit or implicit) rules and norms of the organisation.
Analysis
When viewed through the lens of context and history, the following differences between the projects become apparent:
- The transmission project, because of its strategic importance, had greater visibility and prestige in the organisation. The fact that it was well supported by management and had interesting technical challenges made the project attractive to engineers within the organisation. In contrast, the hydropower project was low key and had little support from top management. Consequently, there was little incentive for engineers to devote time to it.
- The projects differed in degree of uniqueness: the organisation had more experience in HVDC transmission projects than it had in performing upgrades on functioning hydropower plants. The fact that the organisation had successfully carried out projects similar to the former reduced uncertainty associated with that project.
- The projects were managed using very different approaches. The manager of the hydropower project used an approach that did not fit with the existing culture and ethos of the organisation whereas the transmission project was managed in a way that was sensitive to institutional norms and practices. It isn’t surprising, therefore, that the manager of the hydropower project had more difficulty in getting the job done.
The paradox is thus resolved: a full understanding of a project must take into account the context of the project, and the culture/environment of the host organisation(s).
Discussion
The author’s analysis suggests that project success factors are context dependent: a methodology or approach that works in your organisation may not work in mine. An implication of this is that prescriptive project management methodologies are unlikely to work when they are applied without due regard to organisational quirks and circumstances. Several other studies support this conclusion – see my posts on going beyond best practices and project management in post-bureaucratic organisations for examples.
Another important implication of this work is that intrinsic properties of projects (such as size, scope, technology etc.) are perhaps less significant than extrinsic ones (such as organisational culture). As Engwall puts it:
… these [latter] factors have little to do with the technical content of a project per se, but rather with how different stakeholders interpret a project in relation to the procedures and traditions of its surrounding context. The findings suggest, for instance, that important aspects of a project’s inner life are dependent on the level of deviation between the practices applied within the project and the knowledge base and institutional structure of its organizational context.
The research also calls into question the notion of a project as a unique undertaking. Engwall’s contention, supported by the case studies, is that projects typically consist of a mix of unique and repetitive processes. We never begin with a completely blank slate, nor do we ever repeat exactly the same project.
Endnote
The obvious takeaway from the paper is that project managers need to be aware of the history, culture, strategic imperatives and social dynamics of the organisations within which their projects are embedded. They should then tailor their approach based on their knowledge of these factors. As the case studies illustrate, project management best practices may count for little if historical and contextual factors are ignored.
At a more philosophical level, the paper illustrates that project success is contingent on a host of factors that at first sight have nothing to do with projects. Often these factors will become evident only in hindsight, after the project has run its course. Managers can therefore never be absolutely certain that they have considered all the key variables on their projects. Consequently they should view any actions they take as being provisional, subject to change as their knowledge of the project evolves.
Politics and counter-politics in project evaluation
Introduction
Ideally, project evaluation decisions should be made on the basis of objective criteria (cost/benefit, strategic value etc.). In reality, however, there is often a political dimension to the process: personal agendas, power games etc. play a significant role in determining how key stakeholders perceive particular projects. In a paper entitled Seven Ways to get Your Favoured IT Project Accepted – Politics in IT Evaluation, Egon Berghout, Menno Nijland and Kevin Grant discuss seven political ploys that managers use to influence IT project selection. This post presents a discussion of these tactics and some strategies that can be used to counter them.
The seven tactics
Before outlining the tactics it is worth mentioning some of the differences between political and rational justifications for a project. In general, the former are characterised by a lot of rhetoric and platitudes whereas the latter dwell on seemingly objective measures (ROI, cost vs. benefit etc.). Further, political justifications tend to take a “big picture” view as opposed to the detail-oriented focus of the rational ones. Finally, it is worth mentioning that despite their negative connotation, political ploys aren’t always bad – there are situations in which they can lead to greater buy-in and commitment than would be possible with purely rational decision-making methods.
With that for background, let’s look at seven commonly used political tactics used to influence IT project decisions. Although the moves described are somewhat stereotypical and rather obvious, I do believe they are used quite often on real-world projects.
Here they are:
1. Designate the project as being strategic: In this classic ploy, the person advocating the project designates a project as being necessary in order to achieve the organisation’s strategic goals. To do this one may only need to show a tenuous connection between the project objectives and the organisation’s strategy. Once a project is deemed as being strategic, it will attract support from the upper echelons of management – no questions asked.
2. The “lights on” ploy: This strategy is to dub the project as an operational necessity. Here the idea is to indulge in scare-mongering by saying things like – “if we don’t do this, we run an 80% chance of system failure within the next year.” Such arguments are often used to justify expensive upgrades to legacy systems.
3. The “phase” tactic: Here the idea is to slice up a project into several smaller sub-projects and pursue them one at a time. This strategy keeps things under the organisation’s financial radar until the project is already well under way, a technique often used by budget-challenged IT managers.
4. Creative analysis: Most organisations have a standard process by which IT projects are evaluated. Typically such processes involve producing metrics to support the position that the project is worth pursuing. The ideas here is to manipulate the analysis to support the preferred decision. Some classic ways of doing this include ignoring negative aspects (certain risks, say) and/or overstating the benefits of desired option.
5. Find a problem for your solution: This strategy is often used to justify introducing a cool new technology into an organisation. The idea here is to create the perception that the organisation has a problem (where there isn’t necessarily one) and that the favoured technology is the only way out of it. See my post on solutions in search problems for a light-hearted look at warning signs that this strategy is in use.
6. No time for a proposal: Here the idea is to claim that it would take too much time to do a proper evaluation (the implication being that the person charged with doing the evaluation is too busy with other important matters). If successful, one can get away with doing a bare-bones evaluation which leaves out all inconvenient facts and details.
7. Old wine in a new bottle: This strategy is employed with unsuccessful project proposals. The idea here is to resubmit the proposal with cosmetic changes in the hope that it gets past the evaluation committee. Sometimes a change in the title and focus of the project is all that’s needed to sneak it past an unwary bunch of evaluators.
Of course, as mentioned earlier, there’s a degree of exaggeration in the above: those who sanction projects are not so naïve as to be taken in by the rather obvious strategies mentioned above. Nevertheless, I would agree with Berghout et. al. that more subtle variants of these strategies are sometimes used to push projects that would otherwise be given the chop.
Countering politics
The first step in countering political ploys such as the ones listed above is to understand when they are being used. The differences between political and rational behaviour were outlined by Richard Daft in his book on organisational theory and design. These are summarised in the table below (adapted from the paper):
| Organisational Feature relating to decision making | Rational response or behaviour | Political response or behaviour |
| Goals | Similar for all participants – aligned with organisational goals | Diversity of goals, depending on preferences and personal agendas |
| Processes | Rational, orderly. | Haphazard – determined by dominant group |
| Rules/Norms | Optimisation – to make the “best” decision (based on objective criteria) | Free for all – characterised by conflict |
| Information | Unambiguous and freely available to everyone | Ambiguous, can be withheld for strategic reasons |
| Beliefs about cause-effect | Known, even if only incompletely | Disagreement about cause-effect relationships |
| Basis of decisions | Maximisation of utility | Bargaining, interplay of interests |
| Ideology | Organisational efficiency and effectiveness | Individual/ group interest |
Although Daft’s criteria can help identify politically influenced decision-making processes, it is usually pretty obvious when politics takes over. The question then is: what can one do to counter such tactics?
The authors suggest the following:
1. Go on the offensive: This tactic hinges on finding holes in the opponents’ arguments and proposals. Another popular way is to attack the credibility of the individuals involved.
2. Develop a support base-: Here the tactic is to get a significant number of people to buy into your idea. Here it is important to focus efforts on getting support from people who are influential in the organisation.
3. Hire a consultant: This is a frequently used tactic, where one hires an “independent” consultant to research and support one’s favoured viewpoint.
4. Quid pro quo: This is the horse-trading scenario where you support the opposing group’s proposal with the understanding that they’ll back you on other matters in return.
Clearly these tactics are not those one would admit to using, and indeed, the authors’ language is somewhat tongue-in-cheek when they describe these. That said, it is true that such tactics – or subtle variants thereof – are often used when countering politically motivated decisions regarding the fate of projects.
Finally, it is important to realise that those involved in decision making may not even be aware that they are engaging in political behaviour. They may think they are being perfectly rational, but may in reality be subverting the process to suit their own ends.
Conclusion
The paper presents a practical view on how politics can manifest itself in project evaluation. The authors’ focus on specific tactics and counter tactics makes the paper particularly relevant for project professionals. Awareness of these tactics will help project managers recognise the ways in which politics can be used to influence decisions as to whether or not projects should be given the go-ahead .
In closing it is worth noting the role of politics in collective decision-making of any kind. A group of people charged with making a decision will basically argue it out. Individuals (or sub-groups) will favour certain positions regarding the issue at hand and the group must collectively debate the pros and cons of each position. In such a process there is no restriction on the positions taken and the arguments presented for and against them. The ideas and arguments needn’t be logical or rational – it is enough that someone in the group supports them. In view of this it seems irrational to believe that collective decision making – in IT project evaluation or any other domain – can ever be an entirely rational process.
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.

