The Mount Everest Disaster of 1996was one of the greatest expedition failures in the history of climbing. Young, Hailey, and Neame (2010) focused on the leadership failures of the expedition, and found that a situational analysis should have been carried out. However, there were multiple errors in planning and strategy that led to the death of eight people that could have been avoided. Sullivan (2007) approaches the failures from the risk-assessment perspective, stating that judgements were not made based on the basis of risk assessment, and there were no calculations performed before the dangerous expedition started. The below review of the disaster will highlight additional issues: lack of flexibility, performance and quality monitoring, and the inability to focus on the objectives of the project. The author of the current review will argue that using PRINCE2 project management approaches would have improved the feasibility of the project, allowing the team to succeed, eliminate or minimise risks, and remain focused on the desired outcomes.
2. Situational AnalysisAccording to Young et al. (2010: 1), “climbing teams pre-determine turnaround times to signal descent or abandon summit efforts”. However, these turnaround times were estimates, and did not take into consideration weather conditions, the training level of climbers, etc. There were no calculations made regarding to major risks, such as performance reduction due to the lower oxygen level at high altitudes, dehydration, lack of sleep, and – most importantly – reduced decision-making abilities of leaders (Young et al., 2010). Further risks were not assessed, such as the surprise snowstorm that occurred between 4 and 5 in the afternoon.
There were other risk factors that could have been addressed before the trip, such as the problems with radio communication. For example, the leaders assumed that two people were dead, and abandoned them, however, they were alive. By the time they returned to rescue them, they could not be saved.
Leadership errors are also noted by Sullivan (2007), who concludes that the two leading guides were unable to make decisions about turning back without Fisher, with whom they could not communicate with. If they took the clients back to camp on time, noting that the turnaround time has passed, they could have saved their lives.
3. Why and How the Expedition FailedAccording to Sullivan (2007), several people believe that the severe weather conditions caused the death of mountaineers on the Everest in 1996. He, however, notes that “the weather was a risk that should have been considered more carefully by both leaders” (Sullivan 2007: 38). Based on that statement, it is clear that no risk assessment was completed, and no real-time situation monitoring was implemented.
The other reason why the project failed is the lack of clear role definition in the leadership team. There was already a rivalry between Hall and Fischer (Sullivan 2007), and it was not clear who was responsible for supervising the Sherpas, waiting for clients, providing medical emergency services, or even tying the ropes. This confusion about ropes resulted in a lack of action and delay. Delay – in a mountaineering world – means more oxygen used, and less time to turn around. Therefore, the lack of planning and clear roles was also responsible for the disaster. As Sullivan (2007: 42) puts it: “commercial high-altitude mountaineering must be recognized as an activity of risk, not one of risk-taking”.
Analysing the bad decisions made by Hall and Fischer, Roberto (2002) introduces the idea of the “sunk cost effect”. He provides a clear definition for this effect as: “the tendency for people to escalate commitment to a course of action in which they have made substantial prior investments of time, money, or other resources”. This, translated to the world of climbers and commercial mountaineers means that they carry on, despite they know they are failing at the task, in other words: they are overcommitted, and make irrational decisions. This was the reason why they did not turn the climbers around, and let them carry on against the odds. Even though they had a “two o’ clock rule”, as a latest turnaround time, they did not communicate this clearly with the team.
4. How PRINCE2 Could Have Improved Project Management4.1. Process Fundamentals
There were several failures regarding the project fundamentals. In PRINCE2, these are described as starting up a project, directing a project, initiating the project, controlling stage, managing product delivery, managing stage boundaries, and closing a project. Each of these fundamentals can be applied to a project of climbing the Everest. In the starting up phase, the leaders should have clearly identified the objective of the project: completing the climb and getting all climbers back to the base safely. In the directing phase, they should have ensured that all infrastructure and resources were available, in good working condition, and accessible. In the project initiation stage, the leaders should have communicated the rules and objectives clearly with the climber and the Sherpas. They should have created a common understanding of the project (CIPFA 2012). The main failures, however, occurred on the controlling and product delivery stages. Resource commitments were not agreed, and this meant that some climbers had to attempt reaching the camp without enough oxygen. There was simply no project manager who could have controlled the activities and created a stage plan. If there were controlling stages introduced, for example times when teams would communicate and provide updates, it would have been noticed on time that there were serious problems that needed solving. In the controlling stage, tolerances are also agreed (Murray 2010). If PRINCE2 was applied to the project, the different participants could have agreed on the acceptable deviance from the turnaround time, and many of the problems and communication errors could have been prevented. Similarly, if the framework was used in the development of the project, the product (expedition quality and safety) delivery would have been more controlled and better managed in the Managing Product Delivery stage.
Finally, it is important to note that in the Managing Stage Boundaries stage. According to CIPFA (2012), this is the stage where “at each stage end, the continuing viability of the project should be confirmed”. If stage boundaries were created by the leaders, “reality checks” could have been completed, and it would have been clear that there was no chance to get all the participants safely home without oxygen. Based on benchmarking and evaluation, the project could have been abandoned (turning back), or redirected, modified. In the closing stage, the leaders should have identified lessons learned. More importantly, however, they should have learned from experience before starting the project, as they had many expeditions behind them, already. Reflecting on past and potential problems could have improved the overall project’s outcome and design.
4.2. Theme Fundamentals
Based on the theme fundamentals of PRINCE2, it is clear that the weakest aspect of project design was risk. Managing uncertainties, such as weather, the physical condition of participants, communication systems’ reliability could have helped avoid risks that led to the death of climbers. There was no clear understanding and consensus on quality attributes the project wanted to achieve, and the plans were clearly not matched to the needs of participants (Plans Theme Fundamental). It is also necessary to highlight the fact that there was no clearly defined plan on dealing with changes, such as weather conditions, lateness. All the conditions, such as slow pace, not meeting deadlines had a negative impact on the project’s baseline aspects (CIPFA 2012). Continuous assessment of the viability of plans should have been carried out, such as performance monitoring, and the escalation of intervention plans if the project does not go according to plans. This control is in place to help the project manager determine whether or not the project should go on or be abandoned.
4.3. Further Considerations
As the TSO (2009a) guidance states, the key features of PRINCE2 for project managers are the clear definition of roles, authorities, and processes. If this framework was applied to the Everest expedition, all participants would have known what was expected from them in order to help achieve the acceptable quality product (outcome) (TSO 2009b).
Marsh (1996) further explains the benefits of PRINCE2 for complicated projects: according to the summary provided by the authors, this system allows the clear definition of the requirements related to the organization itself, users, project managers, the operation team, and other stakeholders. If Hall and Fischer determined what was the desired outcome of the expedition, and identified processes that were needed to achieve them, assigning each individual with tasks, an advanced business system could have been developed. They could have agreed on set time-scales and project boundaries.
4.4. Application of PRINCE2 Principles
The Oracle (2011) White Paper further explains the main principles of PRINCE2, and they can all be applied to the case examined in this study. The first principle is continued business justification. This relates to regular reviews of the progress of the project, and decisions made whether or not it meets the needs of the organization. If this principle was applied in the Everest expedition of 1996, it would have been found that – because of the lack of oxygen, severe weather, and lack of adherence to timescales – carrying on with the trip was not serving the interest of the stakeholders, and would not result in the outcomes planned by the team. Learning from experience is another principle that would have helped the leaders prevent risks. It is evident from Sullivan’s (2007) account that the two experienced leaders have experienced problems previously. If these problems and potential risks of their recurrence were assessed before the expedition, plans could have been made to address the issues. For example, both Hall and Fischer have taken inexperienced climbers on the same route, and knew that the lack of planning would result in groups breaking up. Hall did know about the lack of reliable radio communication, and decided not to address the issue.
There were no managed roles and responsibilities; another principle of PRINCE2. Sullivan (2007) writes that one of the guides, Anatoli Bourkeev did not act as a guide at all. He was hours ahead of clients. This clearly shows that responsibilities and roles were defined, he would have stayed with the clients and carried supplementary oxygen. Managing by stages was also not applied, as the leaders and guides were too focused on delivering the service clients paid for (Roberto, 2002). Even though another principle of the system is “Focus on Products”, it refers to fulfilling the product descriptions: in this case the product’s description would have been safe delivery of expedition, preserving the health and safety of participants, leaders, and Sherpas. However, several members fell ill, including Hall who had a previously developed chronic condition, and many people had to be rescued. Managing by exceptions was another principle that – followed – would have made the expedition safer and more successful. No alerts were made when problems occurred. As Roberto (2002: 145) writes: “The guides as well felt uncomfortable speaking up. Neil Beidleman, a guide on the Mountain Madness expedition, has indicated that he had serious reservations about people climbing well past midday. However, he did not feel comfortable telling Fischer and other team members that they should turn around”. In PRINCE2, risk registers are created (London South Bank University 2016), and they are accessed and updated by all participants. If this procedure was followed, the identified risk could have been dealt with appropriately: by management, rejection, elimination, or minimisation. Finally, PRINCE2 could have been tailored to the project environment, taking into consideration the challenges, the training level and health of participants, and the resources available.
5. Lessons Learned for Project ManagersSeveral lessons can be learned from the Everest disaster of 1999. The main cause of the failure of leaders to keep participants, leaders, and Sherpas safe was the lack of clear quality measures, roles, and risk assessment. The project was not managed and monitored by stages, and communication was poor. The project owners did not ensure that all the resources needed for delivering a quality product (outcome) were in place (initiating a project). Based on the above assessment, it is clear that applying PRINCE2 principles, themes, and processes would have created better outcomes for the Everest expedition project.
BibliographyCIPFA. 2012. PRINCE2 Quick Reference Guide.
Ferguson, C. 2011. PRINCE2 for Small-scale Projects. Novare Consulting.
London South Bank University. 2016. PRINCE2 Presentations and Lectures.
Marsh, D., 1996. Project management and PRINCE. Health Informatics, 2(1), pp.21-27.
Murray, A. 2010. White-paper: PRINCE2 AND Governance. Outperform. Document Number: 1042-01-01 Version Number: 1v0
Oracle. 2011. PeopleSoft Projects (ESA) Support for PRINCE2. An Oracle White Paper June 2011
Roberto, M.A., 2002. Lessons from Everest: The interaction of cognitive bias, psychological safety, and system complexity. California Management Review, 45(1), pp.136-158.
Sullivan, P., Failure of Risk Management in the 1996 Everest Disaster. Discoveries.
TSO. 2009a. Managing and Directing Successful Projects with PRINCE2. The Stationary Office.
TSO. 2009b. The Executive Guide to Directing Projects: within a PRINCE2™ and MSP® Environment, TSO 2009
Young, S., Healey, K. and Neame, V., The Everest Disaster.
