Experiences in managing a "faster, better, cheaper" deep space project

David H.Lehman, Mars TeleSat Project Manager, Jet Propulsion Laboratory of the California Institute of Technology
Leslie L. Livesay, Space Technology 3 Project Manager, Jet Propulsion Laboratory of the California Institute of Technology
Marc D. Rayman, Deep Space 1 Mission Director, Jet Propulsion Laboratory of the California Institute of Technology
Philip Varghese, Deep Space 1 Project Manager, Jet Propulsion Laboratory of the California Institute of Technology

The expression “faster, better, cheaper” or FBC is becoming the “mantra” for many new projects. This is especially true for projects in organizations faced with intense competition to finish the development as fast as possible, while keeping costs to a minimum. To many the term FBC is both ambiguous and confusing. Many ask how it is possible for a project to be faster, better and cheaper, all at the same time. In this paper, lessons learned with respect to the “principles of NASA FBC project management” on a mission called Deep Space 1 (DS1) will be presented.

Concept studies of the DS1 project were initiated in July of 1995 and the DS1 spacecraft was launched in October 1998. DS1's prime mission was successfully completed in September of 1999 (Rayman, Varghese, Lehman, & Livesay, 1999). DS1 was chartered to flight validate 12 high-risk, high-payoff advanced technologies important for future space and Earth science programs on both a fast schedule and a low budget. Advanced technologies flight-tested during the mission included ion propulsion, high-power solar concentrator arrays, three on-board autonomy technologies, two low-mass science instrument packages, and several telecommunications and microelectronics devices. Among its firsts, DS1 was the first deep space mission to use ion propulsion to actually go somewhere (asteroid Braille in July of 1999) and the first mission to use a totally autonomous on-board navigation system. In addition, another of its autonomous systems, called the Remote Agent Experiment, was awarded NASA's 1999 Software of the Year award.

The authors were the project management team throughout DS1's development and operations phase and they experienced all “ups and downs” of the project. At its peak this $152M project employed over 200 people. DS1 was a successful project and achieved all of its mission objectives. This was achieved in the face of many setbacks and problems with getting high-risk, high-payoff technologies (with large unknowns at the beginning) ready to launch in a short period; in addition the spacecraft, even with its new technology subsystems, had to survive the rigors of launch and the radiation and temperature environment of deep space. Throughout the development and launch of the spacecraft and its mission operations phase, the project team had to deal with the paradox of developing and operating “high-risk technologies” on a short fused schedule, at a relatively low cost with a “take risk but don't fail” mission philosophy.

Based on the experiences during the DS1 project life's cycle, the lessons learned with respect to nine project management principles, cited by Laufer and Hoffman (1996), in thier rules for managing “Faster, Better, Cheaper” projects, will be addressed:

Principal 1: Systematic and Integrated Planning

DS1 had only a two-month pre-project phase prior to initiation. This early phase was too short to formalize project requirements sufficiently, and consequently the Project entered implementation without an approved set of objectives and success criteria. Not until a year later were a coherent set of technical requirements and cost cap defined. This delay led to many challenges for the project team, and ultimately required significant overtime for team members, especially from the final year prior to launch through the first nine months of mission operations.

“The idea that the customer clearly knows … what they want is expecting too much" (Laufer & Hoffman, 1996). On DS1, the risk the customer was willing to take varied over the course of the development. Early on, a high-risk posture was requested by the customer in an attempt to force “break-through” advances in technology. The project team felt the risk was too high and that they had insufficient resources. These conflicts lead to delays in getting the project formally approved. Nevertheless, the risk exposure of the finally approved project was higher than normal for a “standard” deep space project. When the customer changed (as happens frequently), this discrepancy between actual versus assumed risk level became more and more disconcerting, especially as the launch date “loomed closer.” Needless to say, by this time the project risk level was not easily changed. This led to many additional reviews and rework of the spacecraft and other mission elements, but ultimately it was decided to launch even though the risk of mission failure was above the “comfort level” of the customer.

Exhibit 1

Exhibit 1

Principal 2:Timely Decisions Adjusted to Uncertainty

Early in the development phase of DS1, a key decision was required to “de-manifest or de-scope” two of the advanced technologies on the spacecraft (called the 3D Stack and the Remote Agent technologies). The information to make that decision was available to the project manager, but for political and other reasons the decision was delayed. Six months later, it was absolutely required to make the decision in order for the project to survive. At this time the decision was finally made and, ultimately, this delay was a factor in the three-and-a-half-month launch delay and 6% cost overrun of the project. The lesson learned is that delaying decisions, regardless of the reason, can cripple a FPC project needlessly.

Principal 3: Isolation and Absorption (or Adequate Margins) (or Risk Management)

Good managers know that creating reserves (or margins) at the beginning of a project is an effective means of absorbing uncertainty (or managing risk). The DS1 project did not have acceptable margins at Project start. Exhibit 1 is a list of margins the project team wanted from the beginning, what we got at the beginning, and the end result.

The message from the above is that you must have adequate reserves at the beginning of the project. We also learned that tasks with “large uncertainty” will become the new critical paths of tomorrow if not managed effectively. To manage this problem, the project management team was forced to personally oversee daily progress for the spacecraft's transponder, main power supply, and ion propulsion system in an attempt to minimize the impact these critical path deliveries had on the overall flight system development schedule.

On DS1 many of the new technologies were required for the operation of the spacecraft, and were not just enhancements on board for testing. These items by their very nature were high risk. (Because if they had not been high risk, flight on DS1 would not have been required.) For these items it is essential that back-ups (a form of risk management) be available if possible. On DS1, one of the technologies (an autonomy experiment called Remote Agent) should have had a back up but it did not. We paid dearly for this while we scrambled to create a replacement for the software when we ran into problems; this hurt us and was a factor that led to the schedule delay and the cost overrun.

Principal 4: Inward and Outward Leadership

“Leadership means coping with uncertainty and change. Managing means coping with complexity in stable conditions. Good project managers have to assume both roles, leadership and managerial. They are expected to do the right things (lead), and to do them right (manage). They see themselves as responsible for motivating the multiple internal and external participants of the project" (Laufer & Hoffman, 1996).To make DS1 happen, we had to work hard to build effective partnerships with various organizations, both to keep costs down and to ensure a successful mission. These partnerships included items such as the main spacecraft bus, the launch vehicle, most of the technologies and their associated sponsors and lead engineers, spare hardware from other projects, and the use of facilities at various agencies. The partners included other projects at JPL and other NASA centers, commercial organizations, and other government agencies, both in the US and in Europe. On a fast-paced project like DS1, this makes schedule management extremely difficult, because your partners don't always have the same skills, concerns, objectives or goals as you do. The project manager should remember that the number of partners on a project is inversely related to the ability to control the “rudder” of the project. This means that the project manager has to work extra hard to build “effective” coalitions to keep the project team working smoothly together.

Principal 5:Teamwork

The DS1 organization included an Industry Partner with responsibility to deliver the core spacecraft bus. Our short schedule necessitated the team begin work on the design while defining roles and responsibilities, identifying team strengths and weaknesses, and developing a common language and understanding of institutional differences. This painful process could have been minimized if the core project team had taken the time up front to clearly define the teaming arrangement.

Early on, the project manager wanted to co-locate the team in one building to improve teamwork and to improve intra-team communications. However, this collocation was not a priority of the senior management and the collocation did not occur until three months prior to launch. This collocation helped immensely in increasing the rate of closing open issues and streamlining the process of operating the spacecraft after launch.

The project had many team lunches and after-work parties together; we also had numerous “all-hands” meetings to help develop the teamwork necessary in all successful projects. We worked hard to develop a “badgeless” environment for all our different partners. Needless to say, a project manager can never do enough to build a good team-working environment.

Principal 6: Overlapping Project Phases

“The true causes for acceleration and deceleration of project schedule occur at the beginning of the project but become conspicuous only during the advanced phases …” (Laufer & Hoffman, 1996). We did not have sufficient funding authority to fully fund the development of the spacecraft and ground system until one and a half years after project start. This funding delay resulted in delays in development of the hardware required for the flight system. The impact of this late delivery of funds (like the simple rule stated) was not felt until much later when we realized that we would have to delay the launch. For FBC projects, the lesson learned is that because the phases of the project overlap so much, adequate funding is needed “up-front” to ensure success.

Principal 7: Simple Procedures

After a year on the project, we finally settled upon a one-page project requirements document. This document was easy to understand and it had both the key project “requirements” (including technical as well as the cost and schedule requirements) and “goals.” The understanding with the customer was that the project “goals” could be dropped or de-scoped in order to meet the “requirements” if we ran into development problems. This list was very helpful to the project and was easy to understand by most of the team.

Principal 8: Intensive Communications

“How well you communicate is determined by how well you are understood, not by how well you express yourself" (Laufer & Hoffman, 1996). Though project management personnel understood the key “requirements” and “goals” of the project, not all team members did. We thought we had good communications to all team members, but in our case it was not sufficient. What was a “goal” to us was a “requirement” to certain team members who were responsible for one of the mission's experiments. The project management did not do a sufficient job of explaining this to these team members—that it was possible to descope their part of the project to meet the “requirements.” This lack of communications within the project team was a factor in the launch delay and cost overrun.

Principal 9: Systematic Monitoring

“The need to monitor project performance is based upon the homegrown truth that identifying a small problem is difficult; correcting it is easy. Identifying a big problem is easy; correcting it is difficult" (Laufer & Hoffman, 1996). On DS1 we set up a set of technology readiness “gates” to track or gauge progress in their developments. In all cases, we did not follow our early review plan and not all team members understood our approach to project monitoring. This lack of systematic monitoring cost us in the long run because of downstream schedule delay.

Because we paid so much attention to monitoring the new technologies on DS1, we paid less attention to the “standard” technologies on the spacecraft. This came to “haunt us” when the key power supply for the spacecraft was delivered 12 months late. This late delivery led directly to the spacecraft launching three and a half months late. More effective peer reviews, especially early in the development phase, would have likely caught the problems we had with the power supply and possibly other problems we had during the development phase.

We have quoted extensively from the work of Laufer in this paper, but one principal that we learned on DS1 (which is likely the most important from the standpoint of the project and which one of the authors first heard from Laufer himself) is not listed in the reference (Laufer & Hoffman, 1996). This we list here as principle #10 as follows.

Principal 10: Perseverance (or Adopt the Will to Succeed)

Many critics said that DS1 could not be done, especially in the early years. It was too much to develop, launch and operate revolutionary technologies in such a short period of time on a shoestring budget. The key members of the project's staff and the majority of the project team, nevertheless, stayed with the project from the beginning to the end and persevered in spite of many severe setbacks and at great personal sacrifice. To us, the perseverance of the team to get the job done, regardless of the obstacles (both from a technical and bureaucratic nature, was the key to our success). Nevertheless, we hope that future projects will benefit from the lessons of managing DS1 so that they will not face the many problems DS1 encountered or will be able to weather them more smoothly.


The authors gratefully acknowledge the entire DS1 project team for their outstanding work and perseverance to get the job done with such impressive and successful results.

The Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration carried out some of the research described in this paper.


Rayman, M.D., Varghese, P., Lehman, D.H., Livesay, L.L. (1999, October 4-8). Results from the Deep Space 1 Technology Validation Mission. 50th International Astronautical Congress, Amsterdam, The Netherlands, IAA-99-IAA.11.2.01.

Laufer, A., Hoffman, E. (1996). Ninety-Nine Rules for Managing ‘Faster, Better, Cheaper’ Projects. Fast Track Study, NASA, PPMI.

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA



Related Content

  • Project Management Journal

    Determining Contingencies in the Management of Construction Projects member content locked

    By Ortiz, José I. | Pellicer, Eugenio | Molenaar, Keith R. This research describes the managerial approaches that contractors follow to determine different types of contingencies in construction project management. Two large Spanish general contractors were…

  • PM Network

    Snap Precision member content open

    By Fewell, Jesse If you've worked on agile projects, you've likely heard an agile champion make bizarre statements about estimating a budget and schedule. When you press further for estimates, you might get an even…

  • PM Network

    Measure Of Respect member content open

    By Khan, Zahid Are we measuring the right key performance indicators (KPIs)? Project success is usually measured by KPIs related to scope, schedule, budget and quality requirements.

  • PM Network

    Games Plan member content open

    By Fister Gale, Sarah The Olympics capture the world's imagination. But the race begins long before athletes arrive. Cities compete to host the Summer and Winter Games, hoping to take a lead role on the global stage. But…

  • PM Network

    On the Horizon member content open

    A mega-mosque construction project is underway in Algiers, Algeria—but its completion date isn't quite clear. At one point scheduled to open this year, the mosque will become the third largest in…