Archive for the ‘Organizational Culture’ Category
The Abilene paradox in front-end decision-making on projects
The Abilene paradox refers to a situation in which a group of people make a collective decision that is counter to the preferences or interests of everyone in the group. The paradox was first described by Jerry Harvey, via a story that is summarised nicely in the Wikipedia article on the topic. I reproduce the story verbatim below:
On a hot afternoon in Coleman, Texas, the family is comfortably playing dominoes on a porch, until the father-in-law suggests that they take a trip to Abilene [53 miles north] for dinner. The wife says, “Sounds like a great idea.” The husband, despite having reservations because the drive is long and hot, thinks that his preferences must be out-of-step with the group and says, “Sounds good to me. I just hope your mother wants to go.” The mother-in-law then says, “Of course I want to go. I haven’t been to Abilene in a long time.”
The drive is hot, dusty, and long. When they arrive at the cafeteria, the food is as bad as the drive. They arrive back home four hours later, exhausted.
One of them dishonestly says, “It was a great trip, wasn’t it?” The mother-in-law says that, actually, she would rather have stayed home, but went along since the other three were so enthusiastic. The husband says, “I wasn’t delighted to be doing what we were doing. I only went to satisfy the rest of you.” The wife says, “I just went along to keep you happy. I would have had to be crazy to want to go out in the heat like that.” The father-in-law then says that he only suggested it because he thought the others might be bored.
The group sits back, perplexed that they together decided to take a trip which none of them wanted. They each would have preferred to sit comfortably, but did not admit to it when they still had time to enjoy the afternoon.
Harvey contends that variants of this story play out over and over again in corporate environments. As he states in this paper, organizations frequently take actions in contradiction to what they really want to do and therefore defeat the very purposes they are trying to achieve.
—
The Abilene paradox is essentially a consequence of the failure to achieve a shared understanding of a problem before deciding on a solution. A case in point is Nokia’s ill-judged restructuring circa 2003, initiated in response to the rapidly changing mobile phone market.
Prior to the restructure, Nokia was a product-oriented company that focused on developing one or two new phone models per year. Then, as quoted by an employee in an article published in Helsingin Sanomat (A Finnish daily), Nokia management deemed that: “Two new models a year was no longer enough, but there was a perceived need to bring out as many as 40 or 50 models a year… An utterly terrifying number.” Company management knew that it would be impossible to churn out so many models under the old, product-focused structure. So they decided to reorganise the company into different divisions comprising of teams dedicated to creating standard components (such as cameras), the idea being that standard components could be mixed-and-matched into several “new” phone models every year .
The restructuring and its consequences are described in this article as follows:
[The] re-organisation split Nokia’s all-conquering mobile phones division into three units. The architect was Jorma Ollila, Nokia’s most successful ever CEO, and a popular figure – who steered the company from crisis in 1992 to market leadership in mobile phones – and who as chairman oversaw the ousting of Olli-Pekka Kallasvuo this year [i.e 2010].
In Ollila’s reshuffle, Nokia made a transition from an agile, highly reactive product-focused company to one that managed a matrix, or portfolio. The phone division was split into three: Multimedia, Enterprise and Phones, and the divisions were encouraged to compete for staff and resources. The first Nokia made very few products to a very high standard. But after the reshuffle, which took effect on 1 January 2004, the in-fighting became entrenched, and the company being increasingly bureaucratic. The results were pure Dilbert material.
That the Nokia restructure was possibly a “trip to Abilene” is suggested by the following excerpt from an interview with a long-time Nokia employee (see part IV of the Helsingin Salomat article):
…Even CEO Jorma Ollila was less than enthusiastic about the heavy organisational structure, and recognised perfectly well that it was making Nokia stiff and sluggish in its movements. In their time, Ollila’s views made it all the way down to the factory floor.
But was it not Jorma Ollila himself who created the organisation he led?
“Yes”, replies the woman.Ollila’s unwavering line was to allow his subordinates freedom, to trust them without tight controls. In this way the then leaders of the business units like Mobile Phones and Multimedia could recruit whom they wanted. And in so doing the number of managers at all levels mushroomed to enormous proportions and the product development channels became clogged…
Management actions aimed at shoring up and boosting Nokia’s market share ended up achieving just the opposite, and the irony is that the restructure did not even have the whole-hearted support of management.
—
Like the Nokia restructuring effort, most projects are initiated in response to a perceived problem. Often times, those responsible for giving the project the go-ahead do not have an adequate appreciation of the problem or the proposed solution. As I have stated in an earlier post:
Many high profile projects fail because they succeed. This paradoxical statement is true because many projects are ill-conceived efforts directed at achieving goals that have little value or relevance to their host organisations. Project management focuses on ensuring that the project goals are achieved in an efficient manner. The goals themselves are often “handed down from above”, so the relevance or appropriateness of these is “out of scope” for the discipline of project management. Yet, the prevalence of projects of dubious value suggests that more attention needs to be paid to “front-end” decision making in projects – that is, decision making in the early stages, in which the initiative is just an idea.
Front-end decisions are difficult because they have to be made on the basis of ambiguous or incomplete information. This makes it all the more important that such decisions incorporate the honest views and opinions of all stakeholders in the organisation (or their nominated representatives). The first step in such a process is to ensure that all stakeholders have a common understanding of the goals of the project – i.e. what needs to be done. The next is to reach a shared understanding of how those goals will be achieved. Such stakeholder alignment can be facilitated through communication-centric, collaborative techniques such as dialogue mapping. Genuine dialogue is the only way to prevent pointless peregrinations to places that an organisation can ill-afford to go to.
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.
Beyond Best Practices: a paper review and the genesis of a collaboration
Introduction
The fundamental premise behind best practices is that it is possible to reproduce the successes of those who excel by imitating them. At first sight this assumption seems obvious and uncontroversial. However, most people who have lived through an implementation of a best practice know that following such prescriptions does not guarantee success. Actually, anecdotal evidence suggests the contrary: that most attempts at implementing best practices fail. This paradox remains unnoticed by managers and executives who continue to commit their organisations to implementing best practices that are, at best, of dubious value.
Why do best practices fail? There has been a fair bit of research on the shortcomings of best practices, and the one thing it tells us is that there is no simple answer to this question. In this post I’ll discuss this issue, drawing upon an old (but still very relevant) paper by Jonathan Wareham and Han Cerrits entitled, De-Contextualising Competence: Can Best Practice be Bundled and Sold. Note that I will not cover the paper in its entirety; my discussion will focus only on those aspects that relate to the question raised above.
I may as well say it here: I have a secondary aim (or more accurately, a vested interest) in discussing this paper. Over the last few months Paul Culmsee and I have been working on a book that discusses reasons why best practices fail and proposes some practical techniques to address their shortcomings. I’ll end this post with a brief discussion of the background and content of the book (see this post for Paul’s take on the book). But let’s look at the paper first…
Background
On the first page of the paper the authors state:
Although the concept of ‘imitating excellent performers’ may seem quite banal at first glance, the issue, as we will argue, is not altogether that simple after deeper consideration. Accordingly, the purpose of the paper is to explore many of the fundamental, often unquestioned, assumptions which underlie the philosophy and application of Business Best Practice transfer. In illuminating the central empirical and theoretical problems of this emerging discipline, we hope to refine our expectations of what the technique can yield, as well as contribute to theory and the improvement of practice.
One of the most valuable aspects of the paper is that it lists some of the implicit assumptions that are often glossed over by consultants and others who sell and implement best practice methodologies. It turns out that these assumptions are not valid in most practical situations, which renders the practices themselves worthless.
The implicit assumptions
According to Wareham and Cerrits, the unstated premises behind best practices include:
- Homogeneity of organisations: Most textbooks and courses on best practices present the practices as though they have an existence that is independent of organizational context. Put another way: they assume that all organisations are essentially the same. Clearly, this isn’t the case – organisations are defined by their differences.
- Universal yardstick: Best practices assume that there is a universal definition of what’s best, that what’s best for one is best for all others. This assumption is clearly false as organisations have different (dare I say, unique) environments, objectives and strategies. How can a universal definition of “best” fit all?
- Transferability: Another tacit assumption in the best practice business is that practices can be transplanted on to receiving organisations wholesale. Sure, in recent years it has been recognized that such transplants are successful only if a) the recipient organisation undertakes the changes necessary for the transplant to work and b) the practice itself is adapted to the recipient organisation. The point is in most successful cases, the change or adaptation is so great that it no longer resembles that original best practice. This is an important point – to have a hope in hell of working, best practices have to be adapted extensively. It is also worth mentioning that such adaptations will succeed only if they are made in consultation with those who will be affected by the practices. I’ll say more about this later in this post
- Alienability and stickiness: These are concepts that relate to the possibility of extracting relevant knowledge pertaining to a best practice from a source and transferring it without change to a recipient. Alienability refers to the possibility of extracting relevant knowledge from the source. Alienability is difficult because best practice knowledge is often tacit, and is therefore difficult to codify. Stickiness refers to the willingness of the recipient to learn this knowledge, and his or her ability to absorb it. Stickiness highlights the importance of obtaining employee buy-in before implementing best practices. Unfortunately most best practice implementations gloss over the issues of alienability and stickiness.
- Validation: Wareham and Cerrits contend that best practices are rarely validated. More often than not, recipient organisations simply believe that they will work, based on their consultants’ marketing spiel. See this short piece by Paul Strassman for more on the dangers of doing so.
What does “best” mean anyway?
After listing the implicit assumptions, Wareham and Cerrits argue that the conceptual basis for defining a particular practice as being “best” is weak. Their argument hinges on the observation that it is impossible to attribute the superior performance of a firm to specific managerial practices. Why? Well, because one cannot perform a control experiment to see what would happen if those practices weren’t used.
Related to the above is the somewhat subtle point that it is impossible to say, with certainty, whether practices, as they exist within model organisations, are consequences of well-thought out managerial action or whether they are merely adaptations to changing environments. If the latter were true, then there is no best practice, because the practices as they exist in model organisations are essentially random responses to organizational stimuli.
Wareham and Cerrits also present an economic perspective on best practice acquisition and transfer, but I’ll omit this as it isn’t of direct relevance to the question of why best practices fail.
Implications
The authors draw the following conclusions from their analysis:
- The very definition of best practices is fraught with pitfalls.
- Environmental factors have a significant effect on the evolution and transfer(ability) of “best” practices. Consequently, what works in one organisation may not work in another.
So, can anything be salvaged? Wareham and Cerrits think so. They suggest an expanded view of best practices which includes things such as:
- Using best practices as guides for learning new technologies or new ways of working.
- Using best practices to generate creative insight into how business processes work in practice.
- Using best practices as a guide for change – that is, following the high-level steps, but not necessarily the detailed prescriptions.
These are indeed sensible and reasonable statements. However, they are much weaker than the usual hyperbole-laden claims that accompany best practices.
Discussion
Cerrits and Johnson focus on the practices themselves, not the problems they are used to solve. In my opinion, another key reason why best practices fail is that they are applied without a comprehensive understanding of the problem that they are intended to address.
I’ll clarify this using an example: in a quest to improve efficiency an organisation might go through a major restructure. All too often, such organisations will not think through all the consequences of the restructuring (what are the long-term consequences of outsourcing certain functions, for instance). The important point to realize is that a comprehensive understanding of the consequences is possible only if all stakeholders – management and employees – are involved in planning the restructure. Unfortunately, such a bottom-up approach is rarely taken because of the effort involved, and the wrong-headed perception that chaos may ensue from management actually talking to people on the metaphorical shop floor. So most organizations take a top-down approach, dictating what will be done, with little or no employee involvement.
Organisations focus on how to achieve a particular end. The end itself, the reasons for wanting to achieve it and the consequences of doing so remain unexplored; it is assumed that these are obvious to all stakeholders. To put it in aphoristically: organizations focus on the “how” not the on the “what” or why.”
The heart of the matter
The key to understanding why best practices do not work is to realise that many organizational problems are wicked problems: i.e., problems that are hard to define, let alone solve’s (see this paper for a comprehensive discussion of wicked problems). Let’s look at organizational efficiency, for example. What does it really mean to improve organizational efficiency? More to the point, how can one arrive at a generally agreed way to improve organizational efficiency? By generally agreed, I mean a measure that all stakeholders understand and agree on. Note that “efficiency “is just an example here – the same holds for most other matters of strategic importance to organizations: organisational strategy is a wicked problem.
Since wicked problems are hard to pin down (because they mean different things to different people), the first step to solving them is to ensure that all stakeholders have a common (or shared) understanding of what the problem is. The next step is to achieve a shared commitment to solving that problem. Any technique that could help achieve a shared understanding of wicked problems and commitment to solving them would truly deserve to be called the one best practice to rule them all.
The genesis of a collaboration
About a year ago, in a series of landmark posts entitled The One Best Practice to Rule Them All, Paul Culmsee wrote about his search for a practical method to manage wicked problems. In the articles he made a convincing case that dialogue mapping can help a diverse group of stakeholders achieve a shared understanding of such problems. Paul’s writings inspired me to learn dialogue mapping and use it at work. I was impressed – here, finally, was a technique that didn’t claim to be a best practice, but had the potential to address some of the really complex problems that organisations face.
Since then, Paul and I have had several conversations about the failure of best practices in to tackling issues ranging from organizational change to project management. Paul is one of those rare practitioners with an excellent grounding in theory and practice. I learnt a lot from him in those conversations. Among other things, he told me about his experiences in using dialogue mapping to tackle apparently intractable problems (see this case study from Paul’s company, for example).
Late last year, we thought of writing up some of the things we’d been talking about in a series of joint blog posts. Soon we realised that we had much more to say than would fit into a series of posts – we probably had enough for a book. We’re a few months into writing that book, and are quite pleased with the way it’s turning out.
Here’s a very brief summary of the book. The first part analyses why best practices fail. Our analysis touches upon diverse areas like organizational rhetoric, cognitive bias, memetics and scientific management (topics that both Paul and I have written about on our blogs). The second part of the book presents a series of case studies that illustrate some techniques that address complex problems that organizations face. The case studies are based on our experiences in using dialogue mapping and other techniques to tackle wicked problems relating to organizational strategy and project management. The techniques we discuss go beyond the rhetoric of best practices – they work because they use a bottom-up approach that takes into account the context and environment in which the problems live.
Now, Paul writes way better than I do. For one, his writing is laugh-out-loud funny, mine isn’t. Those who have read his work and mine may be wondering how our very different styles will combine. I’m delighted to report that the book is way more conversational and entertaining than my blog posts. However, I should also emphasise that we are trying to be as rigorous as we can by backing up our claims by references to research papers and/or case studies.
We’re learning a lot in the process of writing, and are enthused and excited about the book . Please stay tuned – we’ll post occasional updates on how it is progressing.
Update (16 June 2010):
An excerpt from the book has been published here.
Update (27 Nov 2011):
The book, which has a new title, is currently in the final round of proofs. Hopefully it will be available for pre-order in a month or two.
Update (05 Dec 2011):
It’s out!
Get your copy via Amazon or Book Depository.
The e-book can be obtained from iUniverse (PDF or Epub formats) or Amazon (Kindle).
Eight to Late 