Archive for the ‘mismanagement’ 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.
The four destructive enthusiasms of IT
Introduction
Several surveys have indicated that IT projects – especially large ones – fail at an alarming rate. In a paper entitled, Pessimism, Computer Failure, and Information Systems Development in the Public Sector, Shaun Goldfinch mentions that 20-30% of projects costing more than $ 10 million are abandoned altogether. Further, over half are over time and/or budget, and do not deliver to expectations. Although Goldfinch’s paper focuses on IT investments in the public sector, the situation in the private sector isn’t much better.
Goldfinch makes the observation that,
Enthusiasm for large and complex investments in IS continues unabated despite decades of failure. Indeed, the largest-ever public sector project was initiated in 2002 by the United Kingdom’s National Health Service at an estimated cost of US$11 billion…
He proposes a model of four pathological enthusiasms which cause key stakeholders to talk-up benefits and downplay difficulties when advocating such projects. In this post, I take a brief look at the model and its utility evaluating project proposals.
The four enthusiasms model
Many projects begin as ideas which originate from a small number of enthusiastic advocates. Often a single enthusiast with sufficient influence can push an ill-conceived project through the approval stages to the point where it is given the go-ahead. According to Goldfinch, such misplaced enthusiasm generally falls into one of the following categories:
- Idolisation (Technological Infatuation): This is a situation where a key business stakeholder believes that business problems can always be solved by technology. Projects driven by such people place technology at the heart of the solution. Such efforts often fail because not enough attention is paid to other factors (people, processes etc.).
- Technophilia: This refers to the IT profession’s belief that all problems have technical solutions. As Goldfinch puts it, “it is the myth of the technological fix, in which “the entire IS profession perpetuates the myth that better technology, and more of it, are the remedies for practical problems.” Efforts driven by technophilia fail because those who are involved get too caught up in learning and mastering the technology rather than solving the problem.
- Lomanism: This term, derived from the protagonist in the play Death of a Salesman, refers to the (real or feigned) over-enthusiasm that IT sales and marketing professionals have for their companies’ products. Unfortunately such folks often have the ear of IT decision-makers who are susceptible to sales pitches that promise untold (but unrealistic) benefits. On the other hand it should also be mentioned that Lomanism is often a response to unrealistic customer expectations coupled with the pressure to meet sales targets. The only clear beneficiaries from Lomanism-driven efforts are technology vendors.
- Managerial faddism: This refers to the tendency of managers and senior executives to fall under the spell of the latest management fads. Many of these fads recommend a wholesale overhaul of organizational structures and processes, and are often accompanied by technical tools. IT service management methodologies are good examples of such fads.
Goldfinch states that:
Together, these four enthusiasms feed on and mutually reinforce one another in a vicious cycle, creating a strongly held belief that newer and larger IS projects are a good idea. Doubters and skeptics may be portrayed as “negative,” “not team players,” “not helpful”… Together, these pathologies make up the four enthusiasms of IT failure. When a project does encounter difficulties, these four enthusiasms can undermine attempts to curtail or abandon the project — a project can always be fixed with better management, a redesigned monitoring system or contract, more technology or hardware, better programming, or just a reassuring “it’ll be right on the night.”
Conclusion
Goldfinch suggests that large IT projects are often driven by one of four types of enthusiasm. These can lead to projects being driven by nothing more than wishful thinking and undue optimism. To counter this, he recommends that decision-makers take a pessimistic view when evaluating proposals for IT projects. Among other things this means questioning assumptions, particularly those relating to the technology that will be employed. Independent opinions are a good way to do this, but truly unbiased ones can be hard to come by (vested interests aren’t always obvious). In the end the solution may be as simple as relying on one’s own common sense and judgement. That’s where the model can help: viewing a business case or project proposal through the lens of the model can show up over-optimistic claims and projections.
The role of cognitive biases in project failure
Introduction
There are two distinct views of project management practice: the rational view which focuses on management tools and techniques such as those espoused by frameworks and methodologies, and the social/behavioural view which looks at the social aspect of projects – i.e. how people behave and interact in the context of a project and the wider organisation. The difference between the two is significant: one looks at how projects should be managed, it prescribes tools, techniques and practices; the other at what actually happens on projects, how people interact and how managers make decisions. The gap between the two can sometimes spell the difference between project success and failure. In many failed projects, the failure can be traced back to poor decisions, and the decisions themselves to cognitive biases: i.e. errors in judgement based on perceptions. A paper entitled, Systematic Biases and Culture in Project Failure, by Barry Shore looks at the role played by selected cognitive biases in the failure of some high profile projects. The paper also draws some general conclusions on the relationship between organisational culture and cognitive bias. This post presents a summary and review of the paper.
The paper begins with a brief discussion of the difference in the rational and social/behavioural view of project management. The rational view is prescriptive – it describes management procedures and techniques which claim to increase the chances of success if followed. Further, it emphasises causal effects (if you follow X procedure then Y happens). The social/behavioural view is less well developed because it looks at human behaviour which is hard to study in controlled conditions, let alone in projects. Yet, developments in behavioural economics – mostly based on the pioneering work of Kahnemann and Tversky – can be directly applied to project management (see my post on biases in project estimation, for instance). In the paper, Shore looks at eight case studies of failed projects and attempts to attribute their failure to selected cognitive biases. He also looks into the relationship between (project and organisational) culture and the prevalence of the selected biases. Following Hofstede, he defines organisational culture as shared perceptions of organisational work practices and, analogously, project culture as shared perceptions of project work practices. Since projects take place within organisations, project culture is obviously influenced by the organisational culture.
Scope and Methodology
In this section I present a brief discussion of the biases that the paper focuses on and the study methodology.
There are a large number of cognitive biases in the literature. The author selects the following for his study:
Available data: Restricting oneself to using data that is readily or conveniently available. Note that “Available data” is a non-standard term: it is normally referred to as a sampling bias, which in turn is a type of selection bias.
Conservatism (Semmelweis reflex): Failing to consider new information or negative feedback.
Escalation of commitment: Allocating additional resources to a project that is unlikely to succeed.
Groupthink: Members of a project group under pressure to think alike, ignoring evidence that may threaten their views.
Illusion of control: Management believing they have more control over a situation than an objective evaluation would suggest.
Overconfidence: Having a level of confidence that is unsupported by evidence or performance.
Recency (serial position effect): Undue emphasis being placed on most recent data (ignoring older data)
Selective perception: Viewing a situation subjectively; perceiving only certain (convenient) aspects of a situation.
Sunk cost: Not accepting that costs already incurred cannot be recovered and should not be considered as criteria for future decisions. This bias is closely related to loss aversion.
The author acknowledges that there is a significant overlap between some of these effects: for example, illusion of control has much in common with overconfidence. This implies a certain degree of subjectivity in assigning these as causes for project failures.
The failed projects studied in the paper are high profile efforts that failed in one or more ways. The author obtained data for the projects from public and government sources. He then presented the data and case studies to five independent groups of business professionals (constituted from a class he was teaching) and asked them to reach a consensus on which biases could have played a role in causing the failures. The groups presented their results to the entire class, then through discussions, reached agreement on which of the biases may have lead to the failures.
The case studies
This section describes the failed project studied and the biases that the group identified as being relevant.
Airbus 380: Airbus was founded as a consortium of independent aerospace companies. The A380 project which was started in 2000 – was aimed at creating the A380 superjumbo jet with a capacity of 800 passengers. The project involved coordination between many sites. Six years into the project, when the aircraft was being assembled in Toulouse, it was found that a wiring harness produced in Hamburg failed to fit the airframe.
The group identified the following biases as being relevant to the failure of the Airbus project:
Selective perception: Managers acted to guard their own interests and constituencies.
Groupthink: Each participating organisation worked in isolation from the others, creating an environment in which groupthink would thrive.
Illusion of control: Corporate management assumed they had control over participating organisations.
Availability bias: Management in each of the facilities did not have access to data in other facilities, and thus made decisions based on limited data.
Coast Guard Maritime Domain Awareness Project: This project, initated in 2001, was aimed at creating the maritime equivalent of an air traffic control system. It was to use a range of technologies, and involved coordination between many US government agencies. The goal of the first phase of the project was to create a surveillance system that would be able to track boats as small as jet skis. The surveillance data was to be run through a software system that would flag potential threats. In 2006 – during the testing phase – the surveillance system failed to meet quality criteria. Further, the analysis software was not ready for testing.
The group identified the following biases as being relevant to the failure of the Maritime Awareness project:
Illusion of control: Coordinating several federal agencies is a complex task. This suggests that project managers may have thought they had more control than they actually did.
Selective perception: Separate agencies worked only on their portions of the project, failing to see the larger picture. This suggests that project groups may have unwittingly been victims of selective perception.
Columbia Shuttle: The Columbia Shuttle disaster was caused by a piece of foam insulation breaking off the propellant tank and damaging the wing. The problem with the foam sections was known, but management had assumed that it posed no risk.
In their analysis, the group found the following biases to be relevant to the failure of this project:
Conservatism: Management failed to take into account negative data.
Overconfidence: Management was confident there were no safety issues.
Recency: Although foam insulation had broken off on previous flights, it had not caused any problems.
Denver Airport Baggage Handling System: The Denver airport project, which was scheduled for completion in 1993, was to feature a completely automated baggage handling system. The technical challenges were enormous because the proposed system was an order of magnitude more complex than those that existed at the time. The system was completed in 1995, but was riddled with problems. After almost a decade of struggling to fix the problems, not to mention being billions over-budget, the project was abandoned in 2005.
The group identified the following biases as playing a role in the failure of this project:
Overconfidence: Although the project was technically very ambitious, the contractor (BAE systems) assumed that all technical obstacles could be overcome within the project timeframes.
Sunk cost: The customers (United Airlines) did not pull out of the project even when other customers pulled out, suggesting that they were reluctant to write off already incurred costs.
Illusion of control: Despite evidence to the contrary, management assumed that problems could be solved and that the project remained under control.
Mars Climate Orbiter and Mars Polar Lander: Telemetry signals from the Mars climate orbiter ceased when the spacecraft approached its destination. The root cause of the problem was found to be a failure to convert between metric and British units: apparently the contractor, Lockheed, had used British units in the engine design but NASA scientists who were responsible for operations and flight assumed the data was in metric units. A few months after the climate orbiter disaster, another spacecraft, the Mars polar lander fell silent just short of landing on the surface of Mars. The failure was attributed to a software problem that caused the engines to shutdown prematurely, thereby causing the spacecraft to crash.
The group attributed the above project failures to the following biases:
Conservatism: Project engineers failed to take action when they noticed that the spacecraft was off-trajectory early in the flight.
Sunk cost: Managers were under pressure to launch the spacecraft on time – waiting until the next launch window would have entailed a wait of many months thus “wasting” the effort up to that point. (Note: In my opinion this is an incorrect interpretation of sunk cost)
Selective perception: The spacecraft modules were constructed by several different teams. It is very likely that teams worked with a very limited view of the project (one which was relevant to their module).
Merck Vioxx: Vioxx was a very successful anti-inflammatory medication developed and marketed by Merck. An article published in 2000 suggested that Merck misrepresented clinical trial data, and another paper published in 2001 suggested that those who took Vioxx were subject to a significantly increased risk of assorted cardiac events. Under pressure, Merck put a warning label on the product in 2002. Finally, the drug was withdrawn from the market in 2004 after over 80 million people had taken it.
The group found the following biases to be relevant to the failure of this project:
Conservatism: The company ignored early warning signs about the toxicity of the drug.
Sunk cost: By the time concerns were raised, the company had already spent a large amount of money in developing the drug. It is therefore likely that there was a reluctance to write off the costs incurred to that point.
Microsoft Xbox 360: The Microsoft Xbox console was released to market in 2005, a year before comparable offerings from its competitors. The product was plagued with problems from the start; some of them include: internet connectivity issues, damage caused to game disks, faulty power cords and assorted operational issues. The volume of problems and complaints prompted Microsoft to extend the product warranty from one to three years at an expected cost of $1 billion.
The group thought that the following biases were significant in this case:
Conservatism: Despite the early negative feedback (complaints and product returns), the development group seemed to acknowledge that there were problems with the product.
Groupthink: It is possible that the project team ignored data that threatened their views on the product. The group reached this conclusion because Microsoft seemed reluctant to comment publicly on the causes of problems.
Sunk cost: By the time problems were identified, Microsoft had invested a considerable sum of money on product development. This suggests that the sunk cost trap may have played a role in this project failure.
NYC Police Communications System: (Note: I couldn’t find any pertinent links to this project). In brief: the project was aimed at developing a communications system that would enable officers working in the subway system to communicate with those on the streets. The project was initiated in 1999 and scheduled for completion in 2004 with a budgeted cost of $115 million. A potential interference problem was identified in 2001 but the contractors ignored it. The project was completed in 2007, but during trials it became apparent that interference was indeed a problem. Fixing the issue was expected to increase the cost by $95 million.
The group thought that the following biases may have contributed to the failure of this project:
Conservatism: Project managers failed to take early data on intereference account.
Illusion of control: The project team believed – until very late in the project – that the interference issue could be fixed.
Overconfidence: Project managers believed that the design was sound, despite evidence to the contrary.
Analysis and discussion
The following four biases appeared more often than others: Conservatism, illusion of control, selective perception and sunk cost.
The following biases appeared less often: groupthink and overconfidence.
Recency and availability were mentioned only once.
Based on the small data sample and the somewhat informal means of analysis, the author concludes that the first four biases may be dominant in project management. In my opinion this conclusion is shaky because the study has a few shortcomings, which I list below:
- The sample size is small
- The sample covers a range of domains.
- No checks were done to verify the group members’ understanding of all the biases.
- The data on which the conclusions are based is incomplete – based only on publicly available data. (perhaps is this an example of the available data bias at work?)
- A limited set of biases is used – there could be other biases at work.
- The conclusions themselves are subject to group-level biases such as groupthink. This is a particular concern because the group was specifically instructed to look at the case studies through the lens of the selected cognitive biases.
- The analysis is far from exhaustive or objective; it was done as a part of classroom exercise.
For the above reasons, the analysis is at best suggestive: it indicates that biases may play a role in the decisions that lead to project failures.
The author also draws a link between organisational culture and environments in which biases might thrive. To do this, he maps the biases on to the competing values framework of organisational culture, which views organisations along two dimensions:
- The focus of the organisation – internal or external.
- The level of management control in the organisation – controlling (stable) or discretionary (flexible).
According to the author, all nine biases are more likely in a stability (or control) focused environment than a flexible one, and all barring sunk cost are more likely to thrive in a internal focused organisation than an externally focused one. This conclusion makes sense: project teams are more likely to avoid biases when empowered to make decisions, free from management and organisational pressures. Furthermore, biases are also less likely to play a role when external input – such as customer feedback – is taken seriously.
That said, the negative effects of internally focused, high control organisations can be countered. The author quotes two examples:
- When designing the 777 aircraft, Boeing introduced a new approach to project management wherein teams were required to include representatives from all groups of stakeholders. The team was encouraged to air differences in opinion and to deal with these in an open manner. This approach has been partly credit for the success of the 777 project.
- Since the Vioxx debacle, Merck rewards research scientists who terminate projects that do not look promising.
Conclusions
Despite my misgivings about the research sample and methodology, the study does suggest that standard project management practices could benefit by incorporating insights from behavioural studies. Further, the analysis indicates that cognitive biases may have indeed played a role in the failure of some high profile projects. My biggest concern here, as stated earlier, is that the groups were required to associate the decisions with specific biases – i.e. there was an assumption that one or more of the biases from the (arbitrarily chosen) list was responsible for the failure. In reality, however, there may have been other more important factors at work.
The connections with organisational culture are interesting too, but hardly surprising: people are more likely to do the right thing when management empowers them with responsibility and authority.
In closing: I found the paper interesting because it deals with an area that isn’t very well represented in the project management literature. Further, I believe these biases play a significant role in project decision making, especially in internally focussed / controlled organisations (project managers are human, and hence not immune…). However, although the paper supports this view, it doesn’t make a wholly convincing case for it.
Further Reading
For more on cognitive biases in organisations, see Chapter 2 of my book, The Heretic’s Guide to Best Practices.

