Back to Top

Subscribe to INSIGHT

Expanding perspectives every month.

Subscribe

ASK OCE — July 20, 2006 — Vol. 1, Issue 10

 

By Chris Scolese

 

This issue looks at several aspects of project management: some common pitfalls, the evolution of scheduling, the anniversary of one of NASA’s great project management success stories, and a government program that has had trouble meeting its initial performance goals. The common element underlying every aspect of project management is risk — risk is associated with cost, schedule, technical performance, and safety. Our new programs and projects benefit when our development approach accounts for risk in a manner that allows for flexibility and mitigations across the life cycle.

Development risk is somewhat unique at NASA because nearly everything we build is one of a kind. I tell all new project managers and engineers that no two identical spacecraft are the same. Our job is really to do the things that haven’t been done before, with a few exceptions. We do support some operational agencies, such as NOAA. But we fundamentally do research, either for aeronautics and technology, in space systems, or in pure scientific research, which tries to understand the workings of the universe, the solar system, and the Earth.

In the last decade and a half we haven’t developed any new human systems. Space Station is the last, with a design that came from the early 1990s. Most of our developmental experience since then has been with robotic spacecraft. So how do we take that and use it to develop the missions that will comprise the Vision for Space Exploration?

NASA is a government agency where funding is appropriated and we have to justify that funding and show how we’re going to use it. That can be a lot trickier than it sounds. What’s the value of going to Mars? What’s the value of a rock from the Moon? What’s the value of biological research on the International Space Station (ISS)? What’s the value of discovering a new galaxy, a new solar system outside of the Earth? Those are very difficult things to put a price tag on.

When we’re talking about our value, how do we measure things? We use a risk-based approach. We trade the dollars that we’re willing to spend for the risk of mission success. What that success means oftentimes, with the exception of communications, is typically in the eye of the beholder. Clearly if we’re going into Earth’s orbit with anything, the tolerance for risk is very, very low. Failure is just not an option.

The ISS poses unique challenges in terms of risk management. Unlike a single mission with a discrete beginning, middle, and end, the ISS is inhabited at the same time that it is under development. It faces both maintenance risks associated with its ongoing use on orbit as well as the cost, schedule, and technical risks of its continuing construction. As far as its risk profile is concerned, we consider it developmental, not operational, since it still carries risks associated with its completion. Given its dependence on the Shuttle fleet for the delivery of materials, and the critical contributions of our international partners, sound risk management practices are critical to its success.

When we’re going to the distant planets such as Pluto or Saturn, however, it’s a given that we might run into problems. Planetary missions are incredibly difficult. Cassini traveled almost a decade to get to Saturn. Lots of things could have gone wrong along the way. We had to fly through the rings of Saturn, which were a great unknown. When we land on another planet, as we did on Mars in 2004, a rock on the surface could have been pointing the wrong way. The land could be a little different than we thought. Risk was our measure, and even then there was always an unquantifiable portion of the analysis.

How do we get around that? As we’re looking at the Vision for Space Exploration, we’re taking advantage of what we’ve learned over the last fifteen years of developing robotic spacecraft and the International Space Station and applying that to manage our risk, determine our requirements, maximize our flexibility, look at each option, and see if it fits the risk criteria that we feel are acceptable. Clearly we’ll be carrying crew beyond Earth-orbit, and that changes our risk tolerance. But at the same time, we have to make sure that the missions that we do are worthwhile, so we have to look at the value of the missions that we’re trying to accomplish.

In addition, we have to start taking advantage of some of the things that have come out of the robotic missions such as lights-out operation. With today’s satellites, you can call your cell phone or check your email and the spacecraft will tell you how it’s doing. Again, it’s trading risk for value. We have to do the same things to get to the Moon and Mars we’ve been doing for a while with the robotics missions.

At the same time we have to learn how to do low-rate manufacturing. Software is certainly going to advance. We’re going to need one kind of software to get into orbit, stay there, and accomplish our missions, another kind to do lunar sorties, another kind to do the lunar landings, and that will all be done according to the best risk-based practices for software development. We’ll have to have evolutionary designs as we go from Earth orbit back to the Moon and beyond to other capabilities. All those pieces will play into the missions that help us achieve the Vision for Space Exploration. Many of those are already being developed. As always, our approach will be based on risk.

 

In This Issue

Message from the Chief Engineer

NASA on the Hill: Congress Recommends $16.7B for NASA in FY07

This Week in NASA History: 30th Anniversary of First Mars Landing

Frank Martin’s Seven Deadly Sins of Project Management

GAO: TSAT Program Not Meeting Performance Goals

ASK OCE Interview: Five Questions for Dr. Henry Petroski

The Future of U.S.-China Space Cooperation

Fifty Years on the Critical Path

A View from Outside: Bigelow Launches Inflatable Space Module

About the Author

Share With Your Colleagues