Table of Content

Prologue . 2

Backgrounds Why Mars? ....................................................................................... 3 First Mars Missions ...... 4 Faster Better Cheaper (FBC) Philosophy .. 4 Mars Missions Under FBC ..... 6 Mars Climate Orbiter Mission .. 8

Project Management Analysis Human Resource Management ... 10 Project Communication Management ... 14 Quality Management .. 18 Risk Management .. 21

Summary . 26

References .. 27

Prologue
The search for extraterrestrial life has been one of the greatest curiosities of mankind. Throughout history, several attempts have been performed to gain more insight about surrounding celestial bodies. In particular, exploration of Mars has been of great interest because of its proximity to Earth and the fact that it is the second most habitable planet in our solar system. NASA is an organization that has been actively exploring Mars since 1960s, but it was in the decade of the 90s that NASA significantly increased the number of missions to Mars. One of this missions was the Mars Climate Orbiter, which received a lot of public attention after its failure and the root causes were made public. In this report we will study the failure of this mission from a project management perspective. For starters, we will give some background about mankinds initial interest on Mars. Also, we will discuss the Faster, Better, Cheaper (FBC) philosophy adopted by NASA in the 90s, a strategy used to cut costs and increase the number of missions. In addition, we will put in plain words the events that led to the Mars Climate Orbiter (MCO) failure. For our analysis of this mission from a project management point of view, we will focus on the knowledge areas and processes that we believe had the greatest impact on the development, operation and failure the mission. As such, we are going to discuss these knowledge areas: Human Resource Management Communication Management Quality Management Risk Management

For each individual knowledge area, we will present a brief overview of its key concepts; then, we will assess the application of these knowledge areas and processes to the management of the mission, as defined by the Project Management Institute; and, we will resume the lessons to be learned of the application of these knowledge areas in this mission. Finally, we will summarize the main causes of the failure of the mission and extract general recommendations that should be take into account in any project.

Why Mars?
In the development of this project management case analysis our first question was Why Mars? Throughout a research process emerged the following answers: 1- The interest and observation of Mars took place in the 1600s, with the invention and development of the telescope. In 1877 the Italian astronomer Giovanni Schiaparelli stated that he saw life on the red planet. Increasingly detailed views of the planet inspired speculation about its environment and intelligent civilizations. 2- Years later of the Schiaparellis finding, the American astronomer Percival Lowell jointly with other astronomers suggested that the presumed forms of life discovered were an irrigation system created by intelligent beings. 3- The Mars space exploration in the context of the space race began as result of the ideological confrontation, called the Cold War, between U.S. and the Soviet Union from 1945 (end of WWII) until 1991 (end of the USSR). 4- On December 27 of 1984 a Martian meteorite (ALH 84001) was found in Allan Hills, Antarctica. Then in 1996 was announced that in this meteorite had been found microscopic fossils of Martian bacteria based on carbonate globules.

1-

2-

3-

4-

Figure 1. Causes of Mars explorations

First Mars Missions

As is shown in the Figure 2, in earlier attempts during the 60s and 70s, the NASA explorations of Mars in comparison with the Soviet Space Program, experienced a high success rate but a low launch rate (USA) with an extremely high cost per project.

Figure 2. Comparison of the first missions

Faster, Better, Cheaper (FBC) Philosophy

Daniel Saul Goldin returned to NASA as administrator on April 1, 1992 and implemented the "faster, better, cheaper" philosophy that proposed Missions should be smaller, launched more often and cost less money. This new approach emerged in response to shrinking budgets and fears that the agency was placing too much emphasis on too few missions. Other important factors that contributed to the appearance of this FBC approach were the internal pressures which came from the multibillion dollar NASA missions that took decades to move from concept to operation and return of data and external pressures derived from the Government-wide initiative to do more with less. Goldin initially promoted a low-cost manned lunar project, but due to the 1996 finding about the Martian meteorite (ALH 84001)), the focus was shifted to unmanned Mars probes.

The Mars Program Independent Assessment Team's report, dated March 14, 2000, defined or traduced FBC as: (1) Utilizing new and innovative technology. (2) Creating smaller spacecraft and therefore reducing costs would result in more frequent missions. (3) Accepting prudent risk where warranted by return. (4) Reducing cycle time by eliminating inefficient and redundant processes. (5) Utilizing proven engineering and management practices to maximize success.

Figure 3. Faster, better, cheaper approach.

Mars Missions under FBC

After 10 years without any Mars exploration missions, NASA is ready to return to the red planet with a new philosophy (FBC). There were a total of six missions related to Mars that were developed and launch during the period starting in 1994 and ending in 2000. The missions that were launched during this period are: Mars Global Surveyor (1996) Pathfinder (1996) Deep Space 1 (1998) Mars Climate Orbiter (1998) Mars Polar Lander (1998) Deep Space 2 (early 1999)

The main objectives and budget of these missions are presented below: The Mars Global Surveyor was the first mission under FBC, and was fabricated by Lockheed Martin Astronautics under the supervision of the NASAs Jet Propulsion Laboratory (JPL). The cost of development and construction was of US$ 154 million, and US$ 65 million to launch. The spacecraft objectives was to orbit Mars and take pictures to map Mars surface and serve as a relay station for future missions. The Surveyor was operatives until 2007, when NASA lost contact with it. The Pathfinder landed on Mars on July 4, 1997. This mission was directed by the JPL with a budget under US$ 280 million. The mission deployed the Mars rover Sojouner that was able to analyze rocks from Marss surface and sent pictures of Mars topography and sky. This mission was programmed to last around one month, but ended up lasting almost three months, failing because its batteries worn out. The Deep Space 1 was also under the responsibility of the JPL with a cost of US$ 95 million. The goals of this mission was to test new technology, like ion propulsion and onboard autonomous operations. In addition, flyby an asteroid was part of the mission with a partial success. But most of the new technology were space proven and this experience was now available for future missions.

The Mars Climate Orbiter, was develop by Lockheed Martin Astronautics and the project was under the responsibility of the JPL. This robotic spacecraft was supposed to arrive to Mars atmosphere after 9 months of its launch, in December 1998, to study Mars climate, atmosphere, surface and act like a communication relay for the Mars Polar Lander mission. The total budget of the mission was of US$ 125 million. But, this mission didnt accomplish it objective and the spacecraft was destroyed during it orbital insertion, which will be discussed in more detail in this report. The Mars Polar Lander and Deep Space 2 missions were part of the same spacecraft. The Polar Landers main purpose was to study the soil of Mars south pole, investigate the possibility of finding ice and study the climate. The Deep Space 2 mission was comprised of two identical impact probes, the size of a basketball, which would be launched by the Polar Lander during its Mars landing. The probes would penetrate one meter of Mars soil to study subsurface composition. Again, the development of the spacecraft and probes was under the accountability of Lockheed Martin Astronautics and the project management was responsibility of the JPL. The budge for this missions was around US$ 222.6 million, including development and launch. This mission failed after the Polar Lander apparently was destroy during landing, and also failed to fire the two Deep Space 2 probes.

Mars Climate Orbiter Mission

The overall scientific objectives of the Mars Climate Orbiter (MCO) were to monitor daily weather and atmospheric conditions, record changes on the surface and look for evidence of past climate changes on the red planet. In addition, it would also serve as a relay between the Mars Polar Lander and the ground systems on our planet. The MCO was expected to operate for 5 years after a complete orbital insertion on Mars. The MCO spacecraft was launched by NASA in Cape Canaveral, Florida on December 11th of 1998 by a Delta II Lite Launch vehicle and lasted 42 minutes in total. The launch sequence went through various stages using different fuel propellants at different altitudes to ensure an optimal escape from the Earths atmosphere. The orbits of Earth and Mars around the Sun allow for a launch window every 26 months or 2 years and 2 months when the energy required for traveling is at a minimum. Only during these launch windows expeditions to Mars are considered. After the spacecraft left the Earths atmosphere, it started what is called a Hoffman transfer to leave Earths orbit and join Mars orbit. The spacecraft trajectory was approximately 416 million miles long and lasted 9 months and 12 days after which communication with the spacecraft was lost. During the first 4 months after the launch, because of problems in the ground navigation software, the navigation team could not communicate with the spacecraft and therefore could not model its trajectory. During that time, the navigation team had to rely on emails from Lockheed Martin Aeronautics to model the spacecraft trajectory. After the communication issue was resolved, the navigation team noted that the ground navigation software was generating anomalous data, specifically, the thruster performance data. The navigation team failed to use Incident/Surprise/Anomaly reports to handle the issue. NASA had provisioned this type of report in order to identify, solve and document issues that happened during the operational phase of a mission. It was understood that the lack of understanding of ISA by the navigation team caused the issue not to be formally tracked causing it to be ignored. Because of the spacecrafts odd design, the solar wind slightly pushed the spacecrafts solar panels making it rotate around the pitch axis. A reaction wheel fitted inside the spacecraft canceled those small disturbances. But reaction wheels have a limited speed making them lose their effectiveness after momentum builds up.
9

This momentum build up is brought back down to controllable levels using hydrazine thrusters. It is important to know that this process is part of the control loop of the spacecraft and is expected. Trajectory Correction Maneuvers (TCMs) were planned ahead and executed to aim the spacecraft for the Mars Orbital Insertion (MOI). However, due to thruster performance data being logged in Imperial units instead of metric units by the ground navigation software, the effects of the trajectory correction events were underestimated by a factor of 4.45 (1 lbf-s ~= 4.45 N-s). This meant that for each correction issued, the thrusters were fired 4.45 times longer than necessary. The need to correct the spacecraft trajectory became more and more frequent. About 10 to 14 trajectory corrections had to be issued to the spacecraft, whereas in other missions the average was about 2. The errors explained before were small, but they added up in a gradual way. The navigation team was not sure how unsure they were about their calculations of the trajectory due to the erroneous nature of data they were working with. As the spacecraft approached Mars, the navigation team executed TCM-4 to prepare the spacecraft for orbital insertion a week later. The underlying error was not the unit mix up, but NASAs failure to detect it and solve it. Using more information to model the spacecraft trajectory, calculations performed by the navigation team indicated that the spacecraft was just barely 18 miles over the survivable altitude. TCM-5, a planned emergency trajectory correction maneuver to steer the spacecraft away from Mars was discussed but not implemented because the risk was not fully understood by the navigation team and could also put the Mars Polar Lander mission at risk. Just before the Mars Orbital Insertion took place, the navigation team lost contact with the spacecraft as expected as it passed behind Mars. The navigation team could not communicate with the spacecraft after it was supposed to reappear from the occlusion. Posterior and correct trajectory simulations placed the spacecraft at 35 miles over the surface of Mars, way under the 50 mile critical altitude. It was understood then that the spacecraft deteriorated and ultimately disintegrated while entering Mars atmosphere.

10

Human Resource Management

Project Human Resource Management is the knowledge area responsible for the choice, training, evaluation and rewarding of the employees. It includes the processes that organize, manage, and lead the project team. The project team is comprised of the people with assigned roles and responsibilities for completing the different phases of the project. The type and numbers may also be referred to as the projects staff. An overview of the four processes involved in Human Resource Management is shown in the next graphic.

Comparing some basic concepts of this knowledge area with how the MCO project was managed; negligence was identified in several situations. Some important points of the first processes seen before, the first two specifically, from left to right, will be discussed as follows. Develop Human Resource Plan The PM is responsible of making sure the team members have the appropriate training according to the task they will be performing. The PM must clearly identify the roles and responsibilities of the team. Acquire project team The PM must evaluate the risk of resources becoming unavailable.

11

MCOs Human Resource Management

Next, some examples we be provided about how Human Resource Management responsibilities like Training, Staffing and Roles definition were not taken into account accurately. These, including other issues analyzed later by other knowledge areas, compose the basic reasons of the MCO failure.

Training The personnels training is a critical consideration that every project manager should not underestimate. A team without proper training can be compare to a time bomb. Everything goes fine until the time is over and all the project objectives collapse. Something similar happened with the MCOs mission, the operations navigation team had not adequate training on the MCO spacecraft design and its operations. A summary of the main issues noticed, in which the lack of training was critical for the project, is detailed as follows: The team did not recognize the purpose and the use of the Incident-Surprise- Anomaly (ISA) procedure. The ISA is a formal problem resolution process used to address formally any incident, surprise or anomaly during the project. Because of the lack of training in the use of this document, when problems came, the team had to use informal ways to communicate. This ended affecting the communication effectiveness severely. The small forces software development team needed additional training in the ground software development process. The understanding of this software was critical, since it was the responsible of determining the spacecrafts trajectory. Because of the lack of training of the team, an end to end test of the software was not performed. This would have prevented the MCOs trajectory failure. Inadequate training about following the Mission Operations Software Interface Specification (SIS). The team did not have a deep knowledge about the attitude operations of the spacecraft. Because of this, unfortunately, the MCO attitude control system and related subsystem parameters were not fully understood even when so many errors were being generated for such systems.
12

The Trajectory Correction Maneuver (TCM) was a contingency plan to execute a trajectory correction in case of needed. It could have been applied to raise the MCO to a safe altitude, but the team had never received a practical training about it. Investigation, experiment, or procedures to commit to a TCM in the event of a safety issue were not completed, nor attempted. Therefore, when such application was urgent, the team was not ready for such a maneuver.

Staffing The FBC approach reduced the personnel such in a way that affected significantly the project. For example, the staffing of the operations navigation team was not enough to deal with all the issues generated effectively. Due to the lack of staff, the Mars Surveyor Operations Project (MSOP) was running 3 missions simultaneously. When the small problems began to appear in the MCO, they could not be very focused on it. The MSOP had no systems engineering and no mission assurance personnel. This was critical for the mission. The presence of a mission assurance manager for example would have helped to improve the project communication. It would have helped also to make sure that specifications or standards such as the AMD file requirements, or the ISA resolutions, were been followed correctly. In other ways, success of space missions in general requires full involvement of the mission science personnel in the management process. Science personnel with relevant expertise are a so important tool generally used through all the progress of the project. These special personnel should be included in all decisions where expert knowledge is required. Such experts were not present in the decisions prior to MCOs Mars orbit insertion. Roles and responsibilities Roles and responsibilities of part of the team were unclear. A recurring argument was Whos in charge? Another such recurring argument was Whos the mission manager? Hesitancy and wavering was perceived on the people attempting to answer these questions. The clearest example can be found on the Flight Operations Manager (FOM). Due to the missing mission assurance manager, the FOM became the improvised mission manager. This was not part of his designated responsibility.

13

Finally, another problem observed on the MCO mission was that the system engineers did not have very clear its function. This caused lack of understanding on the part of the navigation team of essential spacecraft design characteristics. Systems engineering support would have improved the operations navigation teams skills to reach critical decisions and would have provided supervision in navigation mission assurance. The role of these engineers was that critical, that it was the responsibility of the systems engineering organization to identify the units problem leading to mission loss of the MCO. Lessons Learned The team should be provided with proper training and detailed information regarding systems which may have a high impact on the well behavioral of the project. The project manager should identify or provide backup personnel that could be available to serve in some of the critical positions when needed. The human resource department should make sure that the staff has clear and well defined roles and responsibilities.

14

Project Communications Management

The key words of this knowledge area are handling information. According to the PMBOK this area includes the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition of project information. The processes involved in this knowledge area are: -Identify Stakeholders -Plan Communications -Distribute Information -Manage Stakeholder Expectations -Report Performance Throughout the analysis of the MCO project management information we could identify two of these processes that were not used correctly

Report Performance This process is focused on collecting the performance information, examining it, comparing it with the baselines and sending it to the defined stakeholders. Also it is focused on the reliability and accuracy of the information reported in order to prognosticate which preventive actions would be needed in the future of the project.

Distribute Information This process is focused on distributing information to each stakeholder which requires a different type of information, in a specific format and in a specific moment of the project. This process also ensures that there is an efficient and effective communication among all parties involved in the project.

15

MCOs Communication Management

The absence of use of these processes was present throughout the development of the MCO project specifically in the following situations:

FBC Implementation Based on different NASA reports, we identified that the failure of this project began with the FBC philosophy implementation because NASA Headquarters didnt enact a formal definition of FBC, resulting this in different interpretations by project managers of what prudent risk was. Due to this lack of formalization into written policies or guidance, the communication of the FBC approach to the project managers and contractors was ineffective.

Interfaces and Relationships Among the interfaces and relationships reviewed, two significant areas of concern were identified and therefore the communication problems between them: The interface between NASA Headquarters and JPL and The interface between JPL and Lockheed Martin.

NASA- JPL Relationship This interface was highly ineffective from the communications point of view for two reasons: First, the interpretation of the initial information on both parties, the Figure 5 shows the intended versus perceived communications.

16

Figure 5. Communication NASA-JPL

For the MCO project the NASA defined and supplied the program objectives, requirements and constraints to JPL. The JPL management interpreted these terms as mandates and deduced that no cost increase was allowed even when was necessary for mitigating some risks. JPL's response was a supportive attitude to the program in order to present a positive image as a substitute for a rigorous risk assessment with appropriate concerns. Finally NASA understood that JPL was in accordance with the objectives, requirements, and constraints for the MCO project. Second, the lack of a single MCO project interface at NASA responsible for all requirements, including those from other NASA organizations resulted in multiple inputs to JPL MCO project that were in some instances conflicting and in general increase the problem of communication. Jet Propulsion Laboratory Lockheed Martin Relationship The relationship between JPL and LMA was effective over the MCO project development but it became ineffective at the time of communicating the senior management of NASA about the risk which had not been formally identified.

Figure 6. Communication JPL-LMA

17

Communication Barriers Between Project Elements Communication barriers between project team were the main cause of MCO mission failure due to each team worked independently and with little cross-communication. In the MCO project, there are proofs of poor communications among the project management, operation navigation and spacecraft team, for example: The operations navigation team discussed the trajectory concerns among themselves, but they did not communicate it effectively to the spacecraft operations team or project management. When conflicts in the data were discovered, the team relied on e-mail to track and solve the problem, instead of formal problem resolution processes such as the Incident, Surprise, and Anomaly (ISA) reporting procedure.

Figure 7. Communication barriers between project teams

Lessons Learned Senior management must be receptive to communications of problems and risks. A dedicated single interface at NASA Headquarters for the Mars Program is essential. Contractor responsibilities must include formal notification to the customer of project risk and deviations.
18

Increase the amount of formal and informal face-to-face communications with all team elements and especially for those elements that have critical interfaces.

Quality Management
A quality management plan should contain relevant existing quality practices, standards and requirements not only for project deliverables but for the management of the project as well. Processes and procedures should be defined on how to conduct and improve quality. Quality should be measurable, which means that the quality management plan should clearly identify what, when and how to measure. Quality should be controllable, therefore, metrics should be compared against defined thresholds (control limits) and corrections performed as needed. Under FBCs philosophy, a great emphasis was put on reducing cost and schedule with an already steep scope. This philosophy, albeit partially implemented, inadvertently neglected quality and its importance in risk mitigation. As such, several missions under this philosophy failed when pushing the boundaries of the FBC. (Samovinski & Judd & Richards & Bauer & Cipolla & Purcarey, 2001). The MCOs project management team failed to adequately perform all quality management processes as defined by the PMI in the PMBOK: plan quality, perform quality assurance and perform quality control. However, on this report, we will only concentrate on perform quality assurance and control. Perform Quality Assurance The Verification, Validation & Accreditation (VV&A) processes should have determined early on that the navigation software was not to be used because the implemented model and associated data (thruster performance) did not conform to specifications, therefore it did not represent the real world. The VV&A processes were not thoroughly performed against the navigation software of the MCO spacecraft and ground system. In consequence, they failed to catch a discrepancy that caused them to incorrectly model the spacecraft trajectory. Even though the navigation software was developed by Lockheed Martin Aeronautics (LMA) and the software bug was introduced by them, NASA should have caught the mistake through its internal VV&A. Although there was a document containing the specifications of interoperability between systems, namely the Mars Surveyor Operations Project Software Interface Specification (SIS), it
19

was not followed by the software programmers nor used by the software testing team. (Lilley, 2009). Within LMA, the faulty code came from a reused software package that was not mission-critical in the past and not bound to the SIS. At some point, this software package was promoted to be part of the navigation software of the MCO (which made it critical) and a formal code review process was once again not performed. This faulty code later became the root cause of the mission failure: use of Imperial units in the ground navigation software. The SIS clearly defined the use of metric units and format. NASA used (and continues to use) the International System of Units (SI) throughout the whole agency due to the Metric Conversion Act (MCA) of 1975. However, LMA has long used the Imperial system for aircrafts since the MCA only affects U.S. Government programs. Early on when the spacecraft was already en route to Mars, the navigation team noticed anomalous data in the files generated by the ground navigation software. They knew something was wrong but they didnt know what exactly. Increasingly frequent anomalous events used to correct the spacecraft rotation were noted by the navigation team. However, they only discussed these events informally. Due to the odd shape of the spacecraft, the navigation team incorrectly believed that these events were to be expected. Perform Quality Control The anomalous events that occurred were not tracked using the multi-mission, institutional defect database for mission operations that was in use during the lifetime of the MCO mission. An Incident/Surprise/Anomaly (ISA) report documenting the operational issue should have been submitted to the global issue-tracking database. If it had been done, significant efforts should have taken place to solve the problem. This resulted in the issue falling through the cracks. NASA had a separate database for defects during the development phase of a mission. Rigorous and extensive validation of the software interfaces was not found to have taken place as specified by the VV&A processes. Had it been done, the navigation team should have had a chance in determining to what degree the model and its associated data failed to represent the real world. To make matters worse, engineers of the navigation team did not fully understand the navigation system of the MCO and were unqualified to do so. The physical implications of thrusters firing over four times longer than required meant that the spacecraft was drifting off course.

20

Control limits for how often trajectory correction events can occur in a given timeframe were not defined during planning which lead to the team not knowing that there was a serious problem going on. Also, control limits for thruster performance data were not defined either, so they could not know that the data was incorrect by a factor of 4.45. Lessons Learned Following the Verification, Validation & Assurance processes is crucial for mission success. These quality audit processes should be conducted thoroughly by qualified independent reviewers that are expert on the matter during the missions lifetime. A comprehensive test verification matrix for the whole mission should be defined early on. This matrix should contain all mission requirements down to the subsystem level. The project management team should put effort to ensure the use of the matrix by everybody in the team. Continuous review of all the missions integrated systems should be conducted by the project team and review attendance tracked. An unified global issue-tracking database that incorporates all phases (development, operations, etc.) of a mission should be implemented. Analysis of frequent or common issues of previous missions should be conducted in an effort to improve quality. The process of metrification (the use of the International System of Units) of all dependencies of the NASA as well as all procured deliverables with contractors should take place.

21

Risk Management
In this analysis of the extent to which Risk Management (RM) was implemented in the MCO mission, well start giving a summary of the most important RM concepts and tools; as a result, the impact of the RM process, or the lack of it, in the MCO mission, will be more evident and clearly appreciated. RM deals with the uncertainties a project will face through its life cycle, positive or negative ones. This means, RM should start with the initiation process and finish when the project is closed. In the project charter high level risks are first assessed, but its during the planning process group where most of the work related with RM is done, but this doesnt mean that when planning is done so is the risk efforts, this is an iterative process that has an monitoring and control aspect that its carry out after planning through closing of the project. This systematic approach to risk assessment has the purpose of identifying events that could impact, positively or negatively, the project schedule, cost, quality, costumers satisfaction, stakeholders interests, scope, etc. When RM is fully integrated in a project, then the project can be executed without huge fires to put out every day, they should have been eliminated with a risk response plan; risks are brought up in every meeting to be address before they happen; and, if risks events does occur, there is a plan in place to deal with it, meaning no more chaotic meeting to develop a response. To better understand RM, we need to know the processes that comprise it. These processes have a logical sequence, but the RM process is very iterative. The RM process is comprise of: Plan Risk Management Identify Risks Perform Qualitative Risk Analysis Perform Quantitative Risk Analysis Plan Risk Responses Monitor and Control Risks

Plan Risk Management (PRM), answer the question of how to approach risk management depending on the complexity of the project. Therefore, the project manager, sponsor, team, customer, experts and other stakeholders could be involved in this phase. Specifically, PRM will detail the methodology, roles and responsibilities, budget, timing, risk categories, definitions of probability and impact, stakeholders tolerance, reporting format and tracking.

22

Now that we know how we are going to do RM the next step is to Identify Risks (IR). This step can done mainly during project initiation and planning, but it should continue until project closing. There are many tools and techniques associated with this step, like: reviewing of past documentation, brainstorming, interviewing, root cause analysis, assumption analysis, strengthweakness-opportunities and threats. The result of this step is a document call the Risk Register that includes: the list of risks, potential responses, root causes of risks and updated risk categories. With the risks identify we Perform Qualitative Risk Analysis (PQLRA), here we try to filter the risks according with their probability of occurrence and potential impact. One of its tools is the probability and impact matrix that helps classify the risks between the ones that require more analysis and the ones that could go to a watch-list. After this step the Risk Register is updated with a risk ranking, probabilities and impact, list of risks for additional analysis, a risk watch-list and trends. Using the list of risks that require more analysis we start the Perform Quantitative Risk Analysis (PQTRA), but its important that the project manager considers costs versus benefits of doing his analysis. Plan Risk Response (PRR) deals with the question of what to do with the top risks previously identified and quantified. Its goal is to eliminate or reduce threats, and find ways to promote opportunities. The threat that cant be eliminated will be taken care with a contingency plan or a fallback plan, if the contingency fails. Here the work to deal with risks is assign to owners who are responsible of implementing the contingency and fallback responses. There are several strategies to mitigate threats and exploit opportunities. The result of this step is the update of the project management plan, project documents and risk register. The updates to the risk register include: a list of residual risks, contingency plans, risks response owners, risks triggers, fallback plans, reserves, etc. But MR doesnt end with PRR, we need to Monitor and Control Risks (MCR), here the project manager makes sure that all that has been planned to eliminate or reduce uncertainty is being implemented and take into account new risks that could have been identified. Therefore, the project manager has to continuously perform risks reassessment, be prepared for a risk audit, check the level of reserve of the project, organize status meetings and close risks that no longer apply. The result of this step is the update of the risk register, change requests, project management plan updates, project documents updates and organizational process assets updates.

23

MCOs Risk Management

To understand the level of RM implemented in the MCO mission we referred to the: Mars Climate Orbiter Mishap Investigation Board Phase I Report (Nov 10, 1999), Report on Project Management in NASA by the Mars Climate Orbiter Mishap Investigation Board (Mar 13, 2000) and Mars Program Independent Assessment Team Summary Report (Mar 14, 2000). From this reports we couldnt find any evidence that a proper RM was implemented or that there were a formal risk management plan for the mission. We can conclude this because the three documents mention the need to implement a risk assessment and management process in future missions. In such a complex endeavors like the space explorations, risks is a natural factor that should be always considered. The identification and management of risks is one the main tasks of the project manager and its oversight frequently determined the result of a project. As we discussed earlier FBC promoted making more with less, and taking risks that were justified; but the failure of NASA administration to adequately define FBC and the policies and procedures that would guide its application in all projects, especially in respect of what is prudent risk; resulted in different interpretation of what FBC means when dealing with the constrains of schedule, cost, scope and risk. The reports found that the project managers of the MCO mission put more emphasis in cost and schedule without paying attention to project risks. The next graph shows the balance that the reports propose when dealing with FBC and projects constrains.

24

The scope shouldnt be increased or cost and schedule be reduced beyond the point risk grows rapidly. An evidence that the project managers of the MCO put more emphasis in cost control over risks, while keeping a very ambitious scope, is obvious when we compare the cost and scope of the MCO ($125 millions) versus the Mars Global Surveyor ($250 millions). Then, we could say that MCO was underfunded, resulting in testing and analysis shortages that caused a significant increase in the risks and reduced the probability of success. Another example of the lack of a proper RM plan for MCO and the big impact that this lack caused in the failure of the mission, its found in hesitation to implement the Trajectory Correction Maneuver 5 (TCM-5), even though the navigation operation team knew that the spacecraft was out of course and had the opportunity apply TCM-5 as a contingency action, but there was not a procedure and the team was not prepared to implement TCM-5 in case of an emergency. In addition, the reports found that the systems engineering team, which performs critical studies to improve the mission in terms of scope, cost, schedule, and helping the project manager to identify and mitigate risks; didnt showed an adequate execution of its responsibilities when: (i) failed to identified what is an acceptable risk level for the mission; (ii) the nonexistence of any analysis that could have help to identify risks in MCO mission, like fault tree analysis; (iii) poor documentation of the critical elements of the mission; and, (iv) the lack of a contingency plan for TCM-5 and other possible critical situations. All this lead us to understand that the deficiency or absence of a good RM plan prevented that the mission had a change to be successful in the event of any significant threat, and that the mistake in the calculation of the trajectory was a threat that could have been overcame with a good contingency plan. Lessons Learned The reports make a lot stress in the importance of implementing sound RM plans in all NASA missions. Part of the RM lessons drawn from MCO failure, include: Risks associated with the deviation from recognized project management principles should be accepted.

25

Risks most be assessed and accepted by all accountable parties, including senior management, program and project managers. Risk most be assessed and control throughout the life cycle of the project, and should be considered as important as cost, schedule and scope; therefore, should be considered a fourth dimension of project management. The progress in the implementation of the risks mitigation plan should be reported periodically to the project and program managers. A clear and detail definition of what constitute acceptable risk should communicated to all team members. Qualitative and/or quantitative risks analysis tools should be used in all missions to determine probability and impact of all identified risks. All risks that couldnt be eliminated with a mitigation plan should have a risk owner, who is responsible to manage that risk. At all meetings and projects review, the status of risks mitigation plan are reported and reassessed. The concepts of earn value management should be applied to RM, allow the project manager know the progress of the plan at any moment during the life of the project.

26

Summary
Throughout our analysis of the MCOs mission failure, we identified a series of technical and project management related errors and deviations from established procedures; but, we conclude that this catastrophe had one root technical cause and one root management cause. The technical cause is found in the difference in units system used between two software in charge of calculating the trajectory and trajectory correction forces instructed to the spacecraft. On the other hand, the root management cause is clearly found in the precarious implementation of the FBC philosophy, that give rise to more missions, more ambitious scopes, reduced costs, reduced time, and more risks. In principle, FBC should have resulted in more successful missions, but ended up putting more missions in the hands of capable, though inexperienced, project managers that understood in different ways the FBCs values. The general recommendations we can draw from MCO failure and that have to be considered in any project, are the following: Senior management should make sure that new strategies are well understood in all levels of the organization and incorporated in detail in all the relevant documents and procedures. Personnel availability and training in any project is critical to the success of the venture. Any scope, costs and schedule change should degenerate in the project manager setting aside sound project management principles.

Effective communication improves the integration among team members, stakeholder and senior management; but, its absence can have a negative impact in the project.

All processes and deliverables should be continuously assessed and controlled to assure that they meet the requirements.

Every project manager should determine in what depth to apply the Risk Management process, but since risks are present in all projects, this shouldnt be optional.

Risk management should be considered a fourth dimension of the project management endeavor, with the same relevance as scope, costs and schedule.
27

References
(Nov 10, 1999) Mars Climate Orbiter Mishap Investigation Board Phase I Report. (Mar 13, 2000) Report on Project Management in NASA by the Mars Climate Orbiter Mishap Investigation Board. (Mar 14, 2000) Mars Program Independent Assessment Team Summary Report. Samoviski, D. J., & Judd, E., & Richards, J., & Bauer, E., & Cipolla, N., & Purcarey, I. (Mar 13, 2001). Faster, Better, Cheaper: Policy, Strategic Planning, and Human Resource Alignment [Audit report]. Washington, DC: NASA Headquarters. Edralin, D.M. (2004). Training: A strategic HRM function. Notes on business education, 7 (4), 1-2. Lilley, S. (Aug 2009). Lost In Translation. System Failure Cases, 3(05) 4. (June 2011). [Personal communication between Larry OBrien and Peter Norvig] Retreived November 20, 2012 from http://skeptics.stackexchange.com/questions/7276/was-nasas-mars-climateorbiter-lost-because-engineering-teams-used-different-me Williams, D.R. (Jan 2005). A Crewed Mission to Mars. Retrieved November 20, 2012 from http://nssdc.gsfc.nasa.gov/planetary/mars/marslaun.html Grayzeck, E. (May 2012). NASA NSSDC Mars Climate Orbiter Spacecraft-Details. Retrieved November 21, 2012 from http://nssdc.gsfc.nasa.gov/nmc/spacecraftDisplay.do?id=1998-073A Graham, R. (Nov 2008). FAQ on Failures, Part Two: Mars Climate Orbiter Failure. Retrieved November 21, 2012 from http://www.designnotes.com/companion/failures/MCOcraft.html Department of Defense. (Sep 2006). Retrieved November 26, 2012 from http://vva.msco.mil/Key/key.htm/ Moore, M. (May 2010). NASA-International System of Units - The Metric Measurement System Retrieved November 21, 2012 from http://www.nasa.gov/offices/oce/functions/standards/isu.html

28