Academy Sharing Knowledge

The NASA Source for Project Management and Engineering Excellence | APPEL S U M M E R | 2 0 0 6

National Aeronautics and Space Administration

Inside

HENRY PETROSKI ON SUCCESS THROUGH FAILURE

INTERVIEW WITH REX GEVEDEN

* INTERNATIONAL COLLABORATION ON CASSINI-HUYGENS
O N T H E C O V ER

In 1987, Ross Barron Storey was approached by Stanford University and asked to create a series of art pieces 

for Gravity Probe B. This drawing shows the satellite that was built to house and transport four highly sensitive 

gyroscopes and a heavy lead dewar that dampens magnetic forces. NASA and Stanford University developed 

Gravity Probe B to test two predictions of Albert Einstein’s general theory of relativity. Precise measurements of 

tiny changes in the direction of spin of Gravity Probe B’s gyroscopes as it orbits the Earth will show how space 

and time are warped by the presence of our planet.
23 15 8

D E PA RT M E N T S

3 

In This Issue 

4 

From the Director

48

Knowledge in Brief

49

ASK Bookshelf

50

The Knowledge Notebook

52

ASK Interactive

I N S I G H T S

12

Leaders’ Responsibility 

to Develop Future Leaders 

BY GUS GUASTAFERRO Project leaders need 

to ensure project success and provide 

career development opportunities for 

promising team members.

15

Interview with Rex Geveden

BY DON COHEN In conversation with 

Cohen and Ed Hoffman, NASA’s Associate 

Administrator talks about the importance 

of clear technical authority in the Agency 

and about how project managers develop 

their skills.

23

Success Through Failure 

BY HENRY PETROSKI The noted engineering 

writer discusses how failure shapes good 

design and repeated success can ultimately 

lead to disaster.

30

Sharing Responsibility for Risk 

BY BRENT ROBERTSON AND JERRY KLEIN

One project takes risk management a step 

further by creating metrics to measure how 

successful risk management efforts have 

been.

35

The “Fifth Dimension” of Program 

and Project Management

BY WILLIAM H. GERSTENMAIER A candid look 

at how politics and people’s perceptions 

can influence a project’s outcome. 

42

The Impact of Fear 

on Project Success

BY FREDERICK MANZER Fear may not make 

your employees work harder; it may actually 

cause them to hide the truth, which can 

lead to project failure.

S T O R I E S

5

Goddard’s SEED Program: 

Growing Systems Engineers 

BY THE SEED TEAM WITH DON COHEN 

The Goddard Systems Engineering 

Education Development program uses 

hands-on project experience to teach 

systems engineering expertise.

8

Cassini-Huygens: International 

Cooperation for Astronomical 

Achievement

BY KERRY ELLIS Collaborating with foreign 

space agencies has its own unique challenges. 

20

Unexpected Delays Equal 

a Chance to Innovate

BY HUGH WOODWARD When a priority 

project suddenly faces cancellation, a team 

avoids discouragement and uses the delay 

to test their ideas and improve the design.

26

A Powerful Communication Tool: 

The Engineering White Paper

BY JAMES WOOD A chief engineer uses 

a white paper to test his logic and 

communicate effectively with other 

members of a technical review team. 

33

Featured Invention: 

Langley Soluble Imide 

BY BEN BRUNEAU A happy accident creates 

one of the most versatile polymers available, 

and its uses are growing—even in the 

medical field. 

38

Gravity Probe B: Testing Einstein...

with a Management Experiment?

BY EDWARD S. CALDER AND BRADLEY T. JONES 

Giving Stanford University management 

responsibility for the complex Gravity Probe B

project was an experiment that uncovered 

important lessons about NASA collaborations 

with university prime contractors. 

45

University Collaborations: 

Teaching and Learning

BY KEVIN VIPAVETZ One NASA project 

manager learns some of the dos and don’ts 

of working with university students.

Contents

ASK MAGAZINE | 1
The Academy of Program/Project and Engineering Leadership (APPEL) and ASK 

Magazine help NASA managers and project teams accomplish today’s missions and 

meet tomorrow’s challenges by sponsoring knowledge-sharing events and publications, 

providing performance enhancement services and tools, supporting career development 

programs, and creating opportunities for project management and engineering 

collaboration with universities, professional associations, industry partners, and other 

government agencies.

ASK Magazine grew out of the previous academy, Academy of Program/Project 

Leadership, and its Knowledge Sharing Initiative, designed for program/project 

managers to share best practices and lessons learned with fellow practitioners across 

the Agency. Reflecting APPEL’s new responsibility for engineering development and 

the challenges of NASA’s new mission, ASK includes articles that explore engineering 

achievements as well as insight into broader issues of organizational knowledge, 

learning, and collaboration. We at APPEL Knowledge Sharing believe that stories 

recounting the real-life experiences of practitioners communicate important practical 

wisdom. By telling their stories, managers, scientists, and engineers share valuable 

experience-based knowledge and foster a community of reflective practitioners. The 

stories that appear in ASK are written by the “best of the best” project managers and 

engineers, primarily from NASA, but also from other government agencies, academia, 

and industry. Who better than a project manager or engineer to help a colleague address 

a critical issue on a project? Big projects, small projects—they’re all here in ASK.

You can help ASK provide the stories you need and want by letting our editors know 

what you think about what you read here and by sharing your own stories. To submit 

stories or ask questions about editorial policy, contact Don Cohen, Managing Editor, 

doncohen@rcn.com, 781-860-5270.

For inquiries about APPEL Knowledge Sharing programs and products, please contact 

the Knowledge Sharing Project Manager, Tina Chindgren, ASRC Management Services, 

6303 Ivy Lane, Suite 800, Greenbelt, MD 20770; tina.chindgren@asrcms.com; 

301-837-9069. 

Staff

APPEL DIRECTOR AND PUBLISHER

Dr. Edward Hoffman

ehoffman@nasa.gov

EDITOR-IN-CHIEF

Laurence Prusak

lprusak@msn.com

MANAGING EDITOR

Don Cohen

doncohen@rcn.com

TECHNICAL EDITOR

Kerry Ellis

kerry.ellis@asrcms.com

KNOWLEDGE SHARING MANAGER

Tina Chindgren

tina.chindgren@asrcms.com

KNOWLEDGE SHARING ANALYSTS

Ben Bruneau

ben.bruneau@asrcms.com

Johanna Schultz

johanna.schultz@asrcms.com

DESIGN

Hirshorn Zuckerman 

Design Group, Inc.

www.hzdg.com

SENIOR PRINTING SPECIALIST

Jeffrey McLean

jmclean@hq.nasa.gov

PRINTING

GraphTec
In one way or another, many of the articles in this issue of 

ASK are about the importance of seeing the big picture.

It is all too easy to become so immersed in the immediate 

technical or administrative demands of a project, in today’s 

crisis, in e-mails and phone messages clamoring for 

responses, or in the particular challenges of your specific 

task, that you lose sight of the larger aims of all this work—and 

lose sight, too, of the resources, help, and creative solutions 

lying just outside your field of vision. Sometimes a focused, 

heads-down effort is necessary to solve a knotty problem; 

more often, raising your head to look at the big picture leads 

to the best answers, even to technical problems.

More than once on the Cassini-Huygens project (“CassiniHuygens: International Cooperation for Astronomical 

Achievement”), for instance, the ability of team members to 

take a step or two back from apparent conflicts between 

opportunities to do science and budget constraints and 

between the plans of different groups of scientists opened 

the door to approaches that satisfied everyone and ensured a 

rich flow of science data from the mission. That project offers 

proof of Ed Hoffman’s claim that every successful project’s 

achievements depend on creative inspirations—both 

managerial and technical—not found in textbooks or policy 

documents. In “Fostering Innovation: Necessity Is the Mother 

of Invention,” Hoffman argues that space flight success has 

demanded and continues to demand innovation, and that we 

therefore need to be intentional about fostering creativity. Part 

of that effort, he suggests, involves encouraging collaboration 

and open dialogue—ways of getting a broader view, a bigger 

picture, than any solitary individual can have. The new risk 

management system being used on the Solar Dynamics 

Observatory project applies this idea to risk management by 

making it everyone’s responsibility and mandating regular 

meetings where people identify risks and devise mitigation 

plans. William Gerstenmaier’s “The ‘Fifth Dimension’ of 

Program and Project Management” recommends a big 

picture view that includes the “politics” of a project, by 

which he means the perceptions and expectations insiders 

and outsiders have that are likely to influence the support 

and recognition a project gets at least as powerfully as its 

technical achievements.

Big picture thinking extends beyond the boundaries of 

projects to the long-term needs and goals of the Agency. 

So Gus Guastaferro (“Leaders’ Responsibility to Develop 

Future Leaders”) writes that project and program managers 

should look beyond project success (as essential as that 

is) and concern themselves with developing the careers of 

their most promising team members, fostering the talent 

future programs will draw on. Some of that development 

comes through courses; much of it comes from being 

trusted with challenging new responsibilities. In the 

interview, Rex Geveden describes how both of those ways 

of learning played a role in his development, and especially 

how much he gained from his responsibility for Gravity 

Probe B, a project noted for extremely complex technical 

and managerial challenges. (See also, “Gravity Probe B: 

Testing Einstein...with a Management Experiment?”)

Goddard’s program for training systems engineers 

(“Goddard’s SEED Program: Growing Systems Engineers”) 

also looks to NASA’s future needs for talented and 

experienced project leaders. And, since the heart of 

systems thinking is to look at the relationship of parts to 

the whole, it is all about giving participants a big picture 

perspective. The job of systems engineers is to understand 

how interdependent system elements influence one 

another—to look at them in the context of the big picture.

Don Cohen

Managing Editor

In This Issue

ASK MAGAZINE | 3
“Rocket science” has become a catchphrase for 

anything that is extremely difficult, and the popular 

understanding is right: rocket science deals with 

technological marvels and the daunting challenges 

of complex systems. It wrestles with problems that 

have never been solved before and faces issues that 

demand groundbreaking approaches.

Innovation and creativity have been at the 

heart of space flight history. At the beginning of the 

Apollo era, Wernher von Braun collected informal, 

yet disciplined, one-page weekly notes on important 

events from engineers and technicians two levels 

below him. This system of “Monday Notes” 

provided open communication about problems 

and creative solutions unfiltered by bureaucracy. 

Before and during Apollo, NASA relied on ad 

hoc committees to identify problems and generate 

solutions. Robert Gilruth, Langley Assistant 

Director at the time, established the Space Task 

Group to develop early concepts of space flight. He 

emphasized strong discipline expertise coupled with 

a collaborative approach for generating solutions to 

technical problems. There were no blueprints for 

going to the moon, so problems had to be solved 

through open, creative, and disciplined dialogue. 

Cooperative creative approaches were the norm 

during this period of space flight development. 

The outcome of every great endeavor has been 

determined by individuals able to create new answers 

to previously unanswerable questions, who were 

forced to innovate because doing things the usual way 

would have meant failure. Most experienced project 

managers will tell you how their teams found new 

ways to be successful—stories of creative inspirations 

not found in policy documents or textbooks on 

project management. Most of those stories describe 

creative responses to technological challenges, but 

the unending organizational and management 

challenges of space flight also demand innovation. 

As important as they are, innovation and 

creativity are often treated as an afterthought—

essential but not amenable to planning or 

nurturing. Many tend to think that putting the 

right governance structure in place and the right 

people on the team will automatically generate 

leadership, high performance, and creativity. Some 

believe that you either have leadership ability 

or creativity or you don’t, so there is no point in 

trying to foster those qualities. As a result, a lot of 

energy and discussion are devoted to organizational 

design, requirements definition, risk management, 

and earned value, and very little to creativity.

The early focus of our exploration mission has 

been to establish the best governance model, the 

right leadership, and mission requirements. Charting 

the best path involves searching for lessons learned 

from our past and relying on the best technical and 

programmatic practices we can find. The process 

has been rigorous and thoughtful, but we may be 

neglecting the need to design for innovation.

Perhaps, having succeeded before, we think 

we only have to follow past practice to succeed 

again. That is a recipe for failure. Every important 

technological leap and, I would say, every successful 

project is a story of new approaches, unimagined at 

the beginning, that led to breakthroughs necessary 

for mission success.

If history is any indicator, our ability to 

innovate will determine our success, or lack of 

it. Since that is the case, we need more dialogue 

on fostering innovation and valuing the creative 

process. We can’t leave creativity to chance. ●

From the Director

Fostering Innovation: 

Necessity Is the Mother of Invention

BY ED HOFFMAN 

4 | ASK MAGAZINE
Goddard’s 

SEED Program: 

Growing Systems Engineers

BY THE SEED TEAM WITH DON COHEN

 I

n 1999, Becky Derro had been a mechanical engineer 

at Goddard Space Flight Center for seven years 

and was lead mechanical engineer on COR-1, a 

coronagraph that is part of the Solar Terrestrial 

Relations Observatory (STEREO) mission, 

when she decided that she wanted to try 

something different. “I do better in a new, 

scary situation,” she says. “I think it keeps 

you sharp.” As someone always interested 

in what other members of the project team 

were doing, she wanted to understand more 

about the “big picture”—how the various 

parts of a project fit together. Her desire 

for a new challenge and curiosity about the 

many technical aspects of a project made her a 

good candidate for Goddard’s newly established 

Systems Engineering Education Development 

program, known as SEED.

STORY | ASK MAGAZINE | 5
A “big picture” approach is the essence of systems thinking 

and systems engineering. Jamie Britt, a current SEED participant, 

explains that systems engineering looks at the interdependence 

of project elements, “how changes in one part of a mission ripple 

through to the others.” A good systems engineer, he adds, “keeps 

the big picture in his head.” He or she understands the technical 

requirements of the project as a whole and the connections or 

interfaces between technical elements.

Carolyn Casey, who used her knowledge of applied 

behavioral science to help create SEED, wanted a program that 

would provide the real-life expertise and experience effective 

systems engineers need. “There are a lot of leadership programs 

out there,” she says, “but not a lot of good leaders.” To make sure 

that the SEED curriculum would offer the learning that really 

matters, the program’s designers gathered a group of experts—

people who actually do the job—and asked them to describe 

what they do and explain what is important to doing the work 

well. The program addresses a broad range of skills and the 

connections between them. “We took a systems approach to 

leadership development,” says Casey.

The heart of SEED is the series of hands-on project 

assignments participants take on during the program’s twoyear span. These rotations typically last no more than six 

months and give participants some of the varied experience 

that effective systems engineers must have. This kind of 

learning is hard to come by if one is not in the program, since 

so many NASA project assignments last for years. Outside 

SEED, leaving a project after six months is usually a sign of 

failure or incompatibility.

SEED participants on these brief assignments are not just 

observers. “We look for great development opportunities,” says 

Jennifer Bracken, SEED’s program manager. The cost of the 

rotations comes out of project budgets, and project managers 

agree to them because they expect to get productive work from 

these able and highly motivated people, not just to provide an 

educational opportunity. A mentor on the project team helps 

SEEDlings (as they are sometimes called) quickly understand 

project aims and requirements and reflects with them on their 

experience. Mentoring is an essential part of the program, deputy 

program manager Carl Wales notes. Sometimes, Britt admits, 

you “flounder around a bit” at the beginning of a rotation until a 

member of the project team has time to help you, but when that 

help comes, you get the “aha moment” that makes it possible for 

you to understand what the project is about and contribute to it. 

At the end of each rotation, participants debrief with the SEED 

Advisory Board, describing what they have learned and what, in 

retrospect, they would have done differently.

Like Becky Derro, Evan Webb knew in the late nineties 

that he wanted to enlarge his experience and learn about project 

elements beyond his expertise in command and data handling. 

Before SEED existed, he was trying to find a way to rotate 

among projects to get that broader perspective. He was among 

the first to apply to the program and also became a member of 

the first group of SEEDlings.

These hands-on experiences teach lessons about the reallife complexities, problems, and satisfactions of project work 

that can never be duplicated in the classroom, and they build 

the kind of confidence that only comes from doing real work 

well. But formal classes have an important, if secondary, role 

in SEED. Participants take Academy of Program/Project and 

Engineering Leadership (APPEL) courses, locally developed 

classes, and university courses that teach skills essential to 

good systems engineering. Britt notes, “The program acts as a 

guidance counselor for APPEL courses,” directing SEEDlings to 

Jamie Britt (left) sits with Jim Kellogg, his mentor and a graduate of the SEED program.

6 | ASK MAGAZINE
the ones they need. And, he says, “part of your job description is 

to take courses,” so you avoid the danger of becoming so buried 

in project responsibilities that you have no time for courses.

Derro and Webb single out a nuts-and-bolts course in how 

to write technical requirements as especially valuable. Webb 

quickly had a chance to put this skill to work as the spacecraft 

systems engineer on Space Technology 5 (ST-5), a project 

to develop and test three micro-satellites. ST-5 undertook a 

significant mission redesign—switching from a large to a smaller 

launch vehicle—in the middle of Phase C (normally the final 

design stage). Webb was responsible for the requirements for 

the constellation of three spacecraft and the science validation 

requirements. The insights he had received into writing technical 

requirements, especially about what to change and what to leave 

alone, made it possible to meet this redesign challenge. Many 

of the classroom elements of SEED also emphasize real-world 

know-how, featuring advice and stories of life “in the trenches” 

told by respected NASA veterans.

Human systems and communication skills are also an 

important part of the SEED program. Derro and Webb agree 

that the human element is the main source of project success 

or failure and, says Webb, “You have to deal with the different 

expectations of people on the team. This means effective 

communication, and communication is both talking and 

listening. You have to listen carefully to subsystems people 

to understand their viewpoints,” he adds. “You have to read 

between the lines and then ask the right questions.” Derro 

describes a situation in which her communications training 

prepared her to deal with a conflict between bickering team 

members. She learned that simply changing the way she 

talked—adjusting her voice and posture—communicated a 

seriousness that earned respect and made it possible for her 

to help resolve the problem. Dealing effectively with people 

means engaging with the subtle and messy human dimension 

of projects. Part of being a good systems engineer, says Carolyn 

Casey, leadership and career development manager, is knowing 

you cannot reduce everything to the clear-cut engineering 

choices and being comfortable with that ambiguity. 

A technical background that gains the respect of the team 

and helps the systems engineer understand and evaluate technical 

issues is important, but the ability to ask good questions, 

communicate clearly, and—as always—focus on the big picture 

is what defines successful systems engineering. Before entering 

the SEED program, Derro thought a systems engineer needed 

to be an expert on everything, but duplicating the specialized 

knowledge of team members is neither possible nor desirable. 

In fact, Webb says, even suggesting faulty technical solutions 

has its value. “I come up with a lot of ideas that are wrong,” he 

says. In the process of explaining to the systems engineer why 

his proposed approach won’t work, specialized engineers clarify 

their own thinking. Occasionally, while trying to explain why 

the solution is flawed, they discover that it is possible after all 

and a good choice.

SEED has advanced Webb and Derro’s careers more 

quickly than either expected. Evan Webb was on his last 

rotation, on ST-5, when the mission systems engineer left 

for other work and Webb successfully competed to take 

the job. Becky Derro was at the end of her two-year SEED 

program when a friend and branch manager encouraged her 

to apply for a senior systems engineer position on a program to 

develop an international instrument in cooperation with the 

European Space Agency. Although she was younger and less 

experienced than other candidates, she got the job, thanks, in 

part, to the confidence and competence she gained from the 

program. A member of the selecting panel who had known 

her before SEED commented on how dramatically she had 

matured, saying, “She impressed all the interviewers with her 

poise, knowledge, and leadership qualities. You could really 

see that the SEED program had been a major influence in her 

development.” Derro herself has said, “SEED gave me the kick 

in the pants I needed to look at career development. I thought 

it just happened, but you have to steer it somewhere.”

Derro and Webb consider it part of their job to identify 

other people who they believe would be good systems 

engineers and encourage them to apply to the program. Not 

all SEED participants become systems engineers, of course. 

Some choose to return to their work on subsystems. Even in 

those cases, Carl Wales says, the program is a success, both 

because it helps those individuals discover that they really do 

prefer more focused work and because knowledge of systems 

engineering principles has value for every member of a project 

team—being aware of how a particular component relates to 

the whole helps ensure that the subsystem and the project will 

be successful. ●

THESE HANDS-ON EXPERIENCES TEACH LESSONS ABOUT THE REAL-LIFE COMPLEXITIES, 

PROBLEMS, AND SATISFACTIONS OF PROJECT WORK THAT CAN NEVER BE DUPLICATED IN 

THE CLASSROOM, AND THEY BUILD THE KIND OF CONFIDENCE THAT ONLY COMES FROM 

DOING REAL WORK WELL.

ASK MAGAZINE | 7
 Cassini-Huygens: 

International Cooperation 

for Astronomical Achievement

BY KERRY ELLIS

8 | ASK MAGAZINE | STORY
Many project managers tout communication and collaboration 

as important elements for building a successful team. But what 

happens when an ocean separates team members? Tougher 

still, what if you throw in a few different languages? Is it still 

possible to succeed? Cassini-Huygens’ launch on October 15, 

1997, and its successful science data return imply the answer is 

“yes,” but language and time zone differences were the least of 

its challenges.

When Robert Mitchell joined the Cassini team as project 

manager in June 1998, he knew he was walking into a complex 

environment. The project was an international collaboration 

among seventeen nations that were building the spacecraft and 

more than 250 scientists worldwide who would study the data 

streaming back from Saturn. NASA’s Jet Propulsion Laboratory 

(JPL) built the Cassini orbiter while the European Space Agency 

(ESA) built the Huygens probe and the Italian Space Agency 

provided communications equipment and major parts for three 

instruments on the orbiter. 

 Of the scientists supporting the combined Cassini and 

Huygens missions, slightly more than half are Europeans. Nearly 

180 engineers also support the effort. The scientists and engineers 

on the team find it challenging to coordinate communication. 

Because of its distributed nature, the Cassini team holds many 

of its planning meetings through teleconferences, which time 

differences make difficult to schedule—8:00 a.m. in California 

is 5:00 p.m. in Italy, France, and Germany. The scheduling 

problem means scientists participate in observation planning 

to varying degrees, but they all receive the data equally. The 

team also has three Project Science Group meetings each year. 

The formal agreement between NASA, ESA, and Agenzia 

Spaziole Italiana (Italy) is that two of those meetings will be 

in the United States and one will be in Europe each year, “but 

occasionally we reverse that to help maintain a sense of equal 

partnership,” Mitchell says. This kind of balance and cooperation 

characterized the project as a whole and, more than once, a 

cooperative search to solve a technical problem both served the 

mission and resolved apparent conflicts between groups.

An earlier decision not to perform cruise science during 

Cassini-Huygens’ seven-year trip to Saturn was one of the first 

technical challenges. This decision, made for budgetary reasons, 

caused significant conflicts within the project, especially between 

the science community, which wanted to take advantage of the 

ASK MAGAZINE | 9
opportunity to do new science, and members of the project 

management team, who needed to keep limited engineering 

staff focused on preparing for the spacecraft’s arrival at Saturn. 

Mitchell asked the two communities to develop a solution 

together that would allow cruise science at no additional cost. 

“It just seemed that we were missing out on an opportunity 

to do new, unique science,” Mitchell explains. “Perhaps more 

importantly, we were missing the opportunity to find out how 

this machine worked.” The team was already developing nearly 

all the ground software and much of the flight software during 

Cassini-Huygens’ cruise to Saturn, which had always been the plan 

given the long flight time to the planet. It became apparent that 

they could be more effective if they exercised the system as they 

went. Pursuing cruise science improved the working environment 

and attitudes around the project, and it also helped increase the 

capabilities of the systems operating at Saturn and on the ground 

today. The cruise science decision made it possible to improve the 

technology, gather more data, and bring people together.

That wasn’t the last time testing the system would be an 

issue. A previously proposed in-flight test of the probe-to-orbiter 

relay link had been denied. It was a relatively simple and riskfree test to perform, so Mitchell agreed to do it. The team asked 

the Goldstone Deep Space Network (DSN) station located near 

Barstow, California, to transmit a signal to Cassini that would 

simulate the signal coming from Huygens during the relay. The 

team would then record the signal on board and play it back 

to Earth in the same manner that would be used during the 

probe’s descent to the surface of Titan. They originally proposed 

using only a carrier signal, but one of the ESA engineers, Boris 

Smeds, pushed to make it a full simulation with telemetry. He 

even offered to develop everything on his laptop and go to the 

DSN station to implement it. “Most people thought this was 

overkill, but we agreed to let him do it,” Mitchell says. As it 

turned out, the carrier signal was received just fine, but the 

telemetry was not. If they had done no test, or just the carrier 

test, the team would have lost a significant amount of Huygens’ 

data and would not have known about the problem until after 

the mission was completed. 

The problem was a flaw in the design of the receiver, 

which was part of the Huygens system but carried on the 

Cassini spacecraft. As Huygens descended into Titan’s murky 

atmosphere, it would transmit data to Cassini through the 

receiver. On many deep space missions, engineers would send 

new software and parameters to the system to fix the problem, 

but the software and parameters were permanently burned into 

firmware in Cassini’s receiver and could not be changed. Solving 

the telemetry problem in a sense pitted the Huygens scientists 

against the Cassini scientists because the most viable solution 

threatened Cassini’s science activities. Prior to discovering the 

anomaly, the orbiter was supposed to complete its data relay 

with the probe prior to its closest approach to Titan. From the 

perspective of the probe, which entered Titan’s atmosphere about 

four hours before the orbiter would reach its closest approach, 

the orbiter seemed to be coming straight down from overhead 

and then zipping by at the last minute. Since the probe slowed 

dramatically once it was captured by the moon’s atmosphere, the 

orbiter was closing in on it at about 6 km/sec, which was exactly 

the problem. The Doppler effect caused by this closing speed 

changed the frequency received by the orbiter. The solution 

was to change the orbiter’s flyby altitude at Titan from 1,200 

kilometers to about 60,000 kilometers so it was flying off to 

the side of the probe during the relay instead of coming straight 

in. This reduced the maximum closing speed by about half at 

the start of the relay and to nearly zero at its closest approach, 

which substantially reduced the change in frequency seen in the 

original design. 

But changing Cassini’s trajectory presented a new problem. 

It would require using a significant portion of the propellant 

reserves otherwise available for tour anomalies and extended 

mission opportunities. It would also affect the sequence 

planning work that had already been done for orbiter science 

observations and could change the four-year orbital tour, which 

had been very carefully crafted to rely on Titan’s gravity on 

each flyby. The key to solving this problem lay in shortening 

Cassini’s orbital period when it was inserted into orbit around 

Saturn. Some remarkable brainstorming between the ESA and 

NASA teams came up with changing Cassini’s trajectory so it 

also used Titan’s movement across the sky to compensate for 

the course change. The shorter initial orbit allowed the team 

to insert an additional orbit into their original sequence, which 

accommodated the 60,000-kilometer flyby needed for the probe 

data relay. The next Titan flyby was unaffected by this redesign, 

and from that point on the previously designed tour and science 

observation designs were preserved. 

Photo Credit: NASA/JPL/Space Science Institute

Cassini captures the rough terrain of Rhea, 

another of Saturn’s satellites, during a flyby. 

10 | ASK MAGAZINE
There was surprisingly little finger-pointing about where 

the fault lay in the relay mishap. The team focused instead on 

making the program work. “One thing that was a big help with 

this,” says Mitchell, “was after we had spent a fair amount of 

NASA-funded time and resources (like propellant) on fixing 

the problem, the ESA Director of Engineering offered to send 

three ESA engineers to JPL at his expense to help offset what 

we had spent on the problem, since he was prohibited from 

sending any money over here.” Two of the engineers remained 

for at least three years. The third position rotated among a series 

of engineers who cycled in and out. “It worked out very well 

having them right here on the same time we were on and feeling 

very much a part of the overall effort,” Mitchell recalls.

Figuring out which of the twelve instruments on Cassini 

would get observing priority at which times was another 

difficult challenge. For budgetary reasons, a scan platform to 

orient Cassini’s instruments was eliminated from the design, 

which means all instruments are bolted solid to the spacecraft 

chassis. In order to point an instrument at a target, the entire 

spacecraft has to turn, which isn’t quick or easy to do. It also 

means that at any given time, only one instrument can control 

where the spacecraft points since they are generally located on 

different parts of the chassis. 

Because the process of allocating observing opportunities 

to the different teams was such an involved one, they started 

planning shortly after the Jupiter flyby in December 2000. First, 

each team identified every observation they wanted to make; 

then, based on scientific priorities, they determined who could 

do what. The result was a conflict-free observation timeline. 

“We had a couple of review boards tell us that we were doing too 

much too early and our efforts would be wasted, but we ignored 

this and kept going,” Mitchell recalls. The team felt they hadn’t 

conveyed well enough to the review board the enormity of effort 

scheduling would take. “It wasn’t for lack of trying,” he says, 

“but it’s hard for somebody not involved on a day-to-day basis 

to get a fire hose treatment for two days and really understand 

the picture.” Today the sequencing process is working very well, 

and the process allows for some updates to the early plans based 

on what they learn from Cassini-Huygens in the meantime and 

how the instruments are functioning. With hindsight for how 

the process has worked, Mitchell says he’s glad they started the 

observation design process when they did, and if they could 

change anything, it might be to start the process even earlier.

Being able to maintain those observations with other 

countries by communicating and sharing software tools is 

becoming more of an issue due to International Traffic in 

Arms Regulations (ITAR) restrictions. These U.S. policies and 

rules govern what kinds of information and hardware can be 

shared with foreign nationals. The ITAR definition of sensitive 

“defense articles” includes spacecraft and hardware or software 

that monitors a spacecraft. “It’s hard to know what you can or 

cannot do,” Mitchell explains, “but it generally means you can’t 

share anything concerning spacecraft design and operation.” 

Most of the Europeans understand that ITAR is something 

beyond NASA’s control, but it makes communication difficult. 

NASA works with the U.S. State Department to ameliorate the 

situation, but it isn’t going away. Currently at risk is NASA’s 

ability to share new software tools the Europeans will need 

to continue the sequence design process for Cassini-Huygens. 

Mitchell says, “Our European partners get quite concerned about 

the prospect of us not being able to release the new tools because 

it would effectively put them out of business.” Fortunately, the 

good working relationship between the two teams helps alleviate 

some of the tension ITAR is causing, but they haven’t found a 

final solution to this dilemma. 

Despite these complexities, Cassini-Huygens continues to 

explore Saturn, improving upon previous successful missions to 

examine the ringed planet: Pioneer 11, Voyager 1, and Voyager 2.

The Cassini and Huygens teams also continue to work together 

as the sophisticated instruments on both spacecraft provide them 

with vital data and the best views ever of this region. CassiniHuygens became a collaborative unit that no ocean—or seven 

years of space travel—could separate. ●

PURSUING CRUISE SCIENCE IMPROVED 

THE WORKING ENVIRONMENT AND 

ATTITUDES AROUND THE PROJECT, AND IT 

ALSO HELPED INCREASE THE CAPABILITIES 

OF THE SYSTEMS OPERATING AT SATURN 

AND ON THE GROUND TODAY.

ASK MAGAZINE | 11
Leaders’ Responsibility 

to Develop Future Leaders

BY GUS GUASTAFERRO

Early in my career, just after I completed a special task on the development of the gas chromatograph 

mass spectrometer for the Viking lander, Viking project manager Jim Martin asked me to go to 

Denver to manage the day-to-day activities of the all-up systems test on the entire lander. This meant 

I needed to find a replacement to carry out the final stages of the spectrometer instrument testing. 

I assigned the lead systems engineer, Al Diaz, as the spectrometer project manager, giving him the 

opportunity to take on responsibility for the instrument through launch and flight operations. He 

met the challenge outstandingly and went on to a strong thirty-year career in NASA executive 

leadership. The new responsibility Jim gave me helped both me and Al develop our skills and 

advance our careers.

12 | ASK MAGAZINE | INSIGHT
Looking back on my NASA and industry career in project 

management and executive leadership, I am struck by the 

opportunities I was given by supervisors who cared about 

developing future leaders for the Agency. They made a point 

of providing growth opportunities and on-the-job mentoring 

that helped me realize my leadership potential. While meeting 

the mission objectives of a program or enterprise task, I had 

opportunities to take on responsibilities and make decisions at a 

level that helped me grow as a manager. 

Project and program management focuses—as it should—

on getting the job done, but managers are also responsible for 

helping promising individuals on their teams develop their skills 

and their careers. That attention is important to their futures 

and the future of the Agency.

The Challenge

Project and program leaders must accomplish their mission 

objectives by using assigned resources effectively. This 

challenging responsibility includes assigning key technical and 

administrative personnel to roles that can last a decade or more, 

assignments often made during the formative part of a career. So 

project leads must recognize team members’ career development 

needs as well as their direct contributions to the success of the 

enterprise. Good leaders devote a significant amount of time 

to devising career development plans with each high-potential 

person and establishing formal practices for finding program 

opportunities that promote career growth.

The project leader and the individual team member should 

enter into an agreement that directs primary attention to mission 

success but includes a specific plan for individual development. 

The agreement should provide a framework for rewarding 

performance and dedication to the mission with a commitment 

to provide increased responsibilities that lead to career growth 

opportunities. I suggest that the project leader and the team 

member maintain a mentor relationship and continuously assess 

overall performance.

Resources and Responsibilities 

for Leadership Development

NASA’s strong training and certification programs are an 

important developmental resource, and every opportunity 

should be taken to send promising members of a project team 

to the project management and advanced project management 

courses at Wallops and other NASA facilities. At the same time, 

supervisors need to design and structure opportunities within 

projects to expose high-potential team members to greater 

responsibilities on the job, giving them hands-on challenges 

that stretch individuals and promote learning and confidence. 

These assignments need to be carefully monitored for progress 

and possible adjustment, preferably by continuous mentoring 

during the on-the-job training experience. Here, too, the Academy 

of Program/Project and Engineering Leadership’s pool of specialists 

in project leadership can be helpful, providing mentoring that 

includes elements of the soft side of technical leadership—skills 

including listening, exhibiting vision, recognizing others, ethics, 

and time management. The project leader’s responsibility is to 

recognize the need and request the support.

Lessons from Viking

During work on a high-visibility project, day-to-day problems 

tend to take priority over career development, but an apparently 

hopeless problem within a project can be turned into an 

opportunity to achieve career development goals.

In early 1973 for instance, during the Viking Project 

development phase, it became clear to Jim Martin that challenges 

in manufacturing and testing were delaying development of 

a critical science instrument designed to measure the organic 

chemistry on the surface of Mars. It seemed almost certain that 

this compact, sophisticated instrument would not make the 

1975 launch target. Martin’s solution both satisfied mission 

objectives and created a career development opportunity. 

He requested that I accept the challenge of completing the 

instrument development and use it as an opportunity to develop 

my project management skills.

At the time of the reassignment, I was Martin’s Deputy 

Project Manager for Management Operations. My new 

assignment gave me direct authority over the three hardware 

contractors and a technical interface with the assigned scientist. 

I temporarily relocated to Southern California so I could spend 

enough time at the contractor’s facilities to understand everyone’s 

role in the project and develop a list of the top technical and 

operational issues. I redefined assignments with each member 

of the team and set up a daily meeting to assess progress against 

plans. I also found that giving Litton Industries system integration 

responsibilities over Perkin Elmer and Beckman Industries was 

critical to tying the three major hardware elements together. 

Becoming a knowledgeable customer and adding frequent 

PROJECT AND PROGRAM MANAGEMENT 

FOCUSES—AS IT SHOULD—ON GETTING 

THE JOB DONE, BUT MANAGERS ARE ALSO 

RESPONSIBLE FOR HELPING PROMISING 

INDIVIDUALS ON THEIR TEAMS DEVELOP 

THEIR SKILLS AND THEIR CAREERS.

ASK MAGAZINE | 13
ANGELO “GUS” GUASTAFERRO held the first of three 

leadership management positions in the Viking Mars Mission that 

successfully landed two spacecraft on the planet in 1976. He has 

been Director of Planetary Programs at NASA, Deputy Director of 

Ames Research Center, and Vice President of Lockheed Martin in 

charge of Civil Space. Since 1998, he has been a lecturer and a 

consultant for NASA and other organizations.

assessment of progress improved communications and allowed 

for effective decision making. With the help of a very dedicated 

team of NASA, academic, and contractor personnel, I met the 

objective of completing the instrument development on time.

My supervisor gave me an opportunity to develop as a 

seasoned project manager, building confidence to continue my 

career as a major contributor to NASA. Also, his actions served 

as a model for how I would treat the people assigned to me in 

the future.

Viking also provides an example of how solving a difficult 

personnel decision involving one of your key people can turn 

into a career development opportunity for another. In 1972, the 

mission director assigned to the Viking Project received a Sloan 

Fellowship to attend Massachusetts Institute of Technology 

(MIT) for a year. Martin felt that losing Tom Young at this 

critical time could adversely affect planning for the 1975 mission 

operation phase of the program. Nevertheless, he chose to turn 

the challenge into an opportunity for two of his key people. He 

allowed Young to attend the program and assigned Dr. Howard 

Robins as his replacement for the year. The decision entailed 

risk, but I believe Jim Martin had full knowledge of Dr. Robins’ 

potential. And he used the time between Young’s selection and 

his departure for MIT as an opportunity for Robins to become 

familiar with the current challenges and understand his new 

responsibilities. Had he found that Dr. Robins was not up to 

the challenge, he would have made a midcourse correction. As 

it happened, the project was well served and two future NASA 

and industry leaders were developed as a by-product of the 

Viking mission to Mars. 

Other Shared Experiences

When I left Langley Research Center to assume the position of 

Director of the Planetary Division in the Office of Space Science 

at NASA Headquarters in the early 1980s, I inherited an existing 

staff of technical, scientific, and administrative personnel. One 

of those people was a very young secretary who recently had 

left college to start a career at NASA. She clearly demonstrated 

natural skills above her assignment. I requested that she apply 

for a vacant position as my administrative assistant. She got the 

position and did an exceptional job. She also agreed to return to 

an evening undergraduate program while continuing to perform 

her duties. Eventually, she went on to receive her master’s degree 

and attend the Harvard University Program for Government. 

Today, she is a key member of the executive corps of NASA. I 

don’t take credit for her success, but I believe that recognizing 

and encouraging her ability helped get her started. I was helping 

her in the same way I had been helped years before.

A final story: As a vice president at Lockheed Martin, I 

supervised project managers assigned to a variety of NASA 

programs. In one case, it was obvious that the Lockheed Martin 

project manager who provided the clever design that won a 

contract for one of the first Discovery Missions of the NASA 

Space Science Program had a conflict with the project manager 

assigned by NASA. I turned this problem into an opportunity 

by assigning an outstanding systems engineer from the Hubble 

Space Telescope to complete the development and launch of this 

very critical program and giving the very bright and capable 

engineer who provided the winning design a new assignment 

that helped advance his career. As a result, the mission succeeded 

and two professional technical careers advanced.

Leaders Developing Leaders: 

Some Lessons Learned 

1. Never lose your capacity to make difficult decisions 

and to change.

2. Never judge or classify assigned people too quickly; 

assume competency.

3. Be willing to replace the weak, mentor the marginal, 

and reward the achievers.

4. Be generous at all times; treat everyone with 

professional dignity.

5. Remember that the greatest builder of confidence 

is to complete difficult tasks successfully.

6. Accept the task of sustaining leadership for future 

projects through planned mentoring.

7. Learn to share responsibilities by using the skills 

of others with confidence and appreciation.

8. Never lose your capacity for enthusiasm.

9. Remember that effective communication is the 

greatest and most important challenge. ●

14 | ASK MAGAZINE
Don Cohen and Ed Hoffman met with 

NASA’s Associate Administrator to talk about 

his NASA career and his view of the Agency’s 

current and future challenges.

I N T E R V I E W W I T H

COHEN: What do you see as your role 

in helping NASA achieve its mission?

GEVEDEN: The Administrator recreated the 

position of the Associate Administrator, 

which existed in the Apollo era and went 

away later. It’s the top nonpolitical job 

in the Agency. Griffin wanted someone 

who could provide continuity from 

one administration to the next, who 

could understand why we organized 

and aligned ourselves the way we did, 

and could communicate our budget 

priorities. That’s my strategic role. My 

practical role is to be in charge of the 

technical portfolio. All the mission 

directors, associate administrators, and 

field center directors report to the 

Administrator through me. Griffin is 

trying to create a meritocracy in which 

the best ideas thrive. He has tried to fill 

major positions—this job, I hope—with 

strong technical managers, believing, 

as I do, that executive management is 

not subject-matter independent. I don’t 

think you could plug me into Bank 

of America or American Airlines and 

imagine that I would be very effective, at 

least in the short term. The Administrator 

wants managers who understand the 

space business and are good managers 

in addition to that. So you see the 

top echelon of the Agency populated 

with program managers, scientists, and 

engineering managers who have worked 

their way up the hierarchy.

 Rex 

 Geveden

BY DON COHEN

Photo Credit: NASA/Bill Ingalls

INSIGHT | ASK MAGAZINE | 15
COHEN: Can you describe a specific 

instance where your technical background 

made an important difference?

GEVEDEN: The Pluto New Horizons 

program was scheduled to launch—and, 

in fact, did launch—in January this year. 

It had a nuclear component on board, 

and there were significant problems 

with the nuclear launch approval. 

There also turned out to be qualification 

issues having to do with structural 

problems on the RP-1 tank of the Atlas V

rocket that was launching the system. 

The Administrator asked me to get 

personally involved in the nuclear launch 

approval, which was both a technical 

and an organizational issue. The RP-1

tank was technical. I was involved in 

getting both of those issues resolved 

so we could make the launch window. 

Launching this January gave us a 

Jupiter gravity assist—a slingshot effect 

around Jupiter that gets us to Pluto 

five years faster. Had we delayed the 

launch a year, it would have cost the 

Agency another $100 million and the 

spacecraft would have had to run another 

five years. So it was important to launch 

successfully on time.

COHEN: What kind of action did you take 

to help resolve these problems?

GEVEDEN: The effort to clear the 

radiological health hurdles and get 

approval for this launch was disorganized 

and politically fractious; I helped pull 

that team together so we could submit 

a nuclear launch request to the White 

House. For the RP-1 tank, I was involved 

at the top levels of the engineering review 

of the resolution of that problem.

HOFFMAN: When engineers are concerned 

about some issue about the rocket that 

could affect the launch, you deal with the 

question of risk in the context of a tight 

launch window. If you don’t have a strong 

technical background, how can you make 

that decision?

GEVEDEN: We’ve been driving for a clear 

separation between institutional authority 

and program authority in the Agency. 

The authority has been muddled in the 

past. When Griffin came to the Agency, 

he said, “We’re going to have a clear chain 

of command all the way to the top of the 

Agency for technical authority and a clear 

chain of command all the way to the top 

AN INTERESTING THING about project management IS THAT 

YOU FIGURE OUT all the things THAT SHOULD HAVE been done

WHEN YOU GET ABOUT HALFWAY THROUGH.

16 | ASK MAGAZINE
for programmatic authority. That’s the 

way we’ll get technical independence.”

COHEN: You’re the point where they 

connect. 

GEVEDEN: Yes, which means having 

the ability to adjudicate a technical or 

programmatic issue at the top of the 

Agency. That’s what happened in the case 

of the RP-1 tank.

HOFFMAN: To me, the new governance 

model makes sure you have a strong, 

technically independent engineering 

capability that can raise issues that are core 

to engineering and strong, independent 

project management that reports to the 

mission organizations and ultimately, if 

there are differences, to your position.

GEVEDEN: Over the years, our program and 

project management became almost too 

muscular. I think the CAIB [Columbia 

Accident Investigation Board] was right 

in saying program authority was excessive. 

We’ve had a program-dominant culture. 

If the program manager said, “I’d like 

to improve the factor of safety on that 

structure, but I don’t have time,” that 

was the end of the discussion. We want 

sufficient strength on the engineering 

side to hear the other argument, whatever 

the eventual outcome. That technical 

independence is part of technical 

excellence. The other part has to do 

with the selection of engineering fellows, 

who are thought leaders in the Agency 

in certain technical disciplines, and the 

ones who approve deviations to NASAwide standards when deviations need to 

be approved. It’s a whole package that has 

to do with reemphasizing the importance 

of engineering in the Agency.

COHEN: Do you think NASA has been 

effective at getting support from the 

public and government?

GEVEDEN: The Agency’s biggest successes 

in the last decade or two have tended to 

be in the science side of our business. 

Everyone recognizes the importance of 

the Hubble Space Telescope. To a lesser 

extent, people recognize Chandra and 

Spitzer for doing x-ray and infrared 

images of the universe. Almost everyone 

knows about the Mars rovers that are on 

the Martian surface right now, or Galileo 

and the Huygens probe that we dropped 

onto Titan this past year. The scienceattentive public has been excited about 

that part of NASA’s business for years. 

The other part of the business—human 

space flight—has not generated as much 

excitement because we’ve basically been 

in low Earth orbit for thirty years. The 

building of the International Space 

Station has been an amazing thing. But 

I think we could have done better things 

with the money we’ve spent on human 

space flight. Having said that, I don’t 

think it’s NASA’s job to sell. We’re an 

executive branch of the government and 

execute the priorities of the president 

and Congress. We never will and never 

should have an advertising budget. We’re 

precluded from lobbying. It is our mission 

to communicate what we’re doing and 

communicate the knowledge we acquire. 

We do the business of the government 

in civil space, and we hope that we have 

a compelling vision that the people and 

Congress support.

COHEN: You’ve talked elsewhere about 

watching the first shuttle launch on 

television as an inspiring, careerturning moment for you. Is there 

some equivalent inspiration for young 

technically minded people today?

GEVEDEN: Yes. Our vision for exploration. 

The president of the United States came 

to this building and announced a new 

vision for space exploration. We have a 

compelling vision for the human space 

flight program for the first time in forty 

years. We’ll launch an exciting robotic 

mission to the moon in ’08. We’ll test 

launch our new crew vehicle by the 

beginning of the next decade. We will be 

building an outpost on the moon—it won’t 

be a flags-and-footprints campaign; we’ll 

be doing exciting things on the surface. 

Then we’ll be planning for Mars. I think 

people who want to study engineering will 

rally around the program.

COHEN: In conversations I’ve been 

having within NASA, people emphasize 

the importance of collaboration and 

knowledge sharing across the Agency 

to achieve the mission. Do you see 

collaboration as especially important?

GEVEDEN: Absolutely, and I believe 

collaboration is ultimately a human 

undertaking. A lot of people imagine that 

the solution to collaboration is a great 

software tool, but the idea that someone 

is going to log on to their computer in 

the morning and be in their community 

sharing information is a pipe dream. This 

is where I think Ed Hoffman got it right. 

The way to make collaboration work is 

partly technical but primarily a human 

ASK MAGAZINE | 17
endeavor. That’s one of the reasons I’ve 

liked the stories in ASK Magazine. I also 

like face-to-face human contact. In a 

Q&A at a risk management conference, 

somebody asked me, “How are we going 

to capture the knowledge of Apollo and 

Spacelab and the shuttle people who are 

retiring from the Agency?” I think the 

speaker imagined a knowledge system, 

but my answer was, “Go get the people.” 

For the Exploration Systems Architecture 

Study—done primarily by in-house 

people and some very smart consultants—

we put together a graybeard review team 

that had the likes of Bob Seamans and 

Jay Greene on it. Bob had my job in the 

sixties. Jay Greene, who was the chief 

engineer on the space station and had 

been launch director on Challenger, is 

a famous technical curmudgeon in the 

Agency. I think this computer [the brain] 

is a lot more complex than that one [the 

machine on the desk]. Unless people 

understand that, they’re going to keep 

going down the wrong path.

COHEN: Some corporate efforts to 

capture retirees’ knowledge result in 

videos and documents no one looks at.

GEVEDEN: That’s a common story. Years 

ago, someone briefed me on all the 

great lessons stored in NASA’s Lessons 

Learned Information System. How many 

times have I logged on to it in my career? 

Zero. It may work for some people, but it 

doesn’t for me.

HOFFMAN: A study we did found that 

23 percent of project managers used that 

kind of system. Project complexity means 

that you’re going to call an expert if you 

have a problem. You have to go to the 

tacit knowledge of experts who’ve dealt 

with the same problem.

COHEN: Are there other things NASA 

might do to support knowledge sharing?

GEVEDEN: The other day we met with 

some folks from Northrop Grumman 

who said that some old-timers at the 

Grumman New York operation are 

voluntarily archiving design drawings, 

organizing them so they’d be useful to 

the present generation of lunar explorers. 

It occurred to me that we might pull 

together a mentoring program pairing 

retired smart people with younger people 

now in the system. That could be a lowcost way to bring in people who don’t 

want to be consultants or full-time 

employees but want to give something 

back. Eighty percent of the people at 

NASA are here because of the vision, the 

missions. People will do extraordinary, 

unexpected things because they love the 

space program deeply.

HOFFMAN: You should talk about how 

your career evolved. I think Rex has 

proven the value of hands-on experience 

combined with the tools that have been 

available—the mentoring support and 

training experience.

GEVEDEN: I have invested a lot in career 

development over the years. I’m a goal 

setter. I write down and track goals 

related to career, family, and other areas 

at least on an annual basis in a pretty 

detailed way. When I wrote my first set 

of NASA-related goals, I said I wanted 

to be a project manager and a program 

manager. Then I wanted to manage 

people who manage projects and 

programs. It was about that time that I 

first ran into Ed, who was the leader in 

NASA in figuring out that it was going to 

be important for the Agency to develop 

a project management career path. 

He understood that NASA was about 

programs and projects: mission success 

not just in terms of flight success—which 

was the biggest thing—but delivering 

projects on cost and on schedule. We 

were entering an era in which budgets 

were not unconstrained like they were 

in Apollo; they required more discipline 

and more project management capability. 

NASA eventually developed a Project 

Management Development Process—

PMDP. I was a guinea pig, one of the 

four at my field center to get involved, 

and went through the certification 

efforts about ten years ago. I took the 

requisite training and tried to check off 

the experiential boxes that would get me 

certified to level four, the top level in 

our system. I ended up being the first 

person certified level four and featured 

that prominently in my job applications 

and in my résumé. General Dailey, who 

was the deputy of the Agency, gave my 

certificate to me in a public setting and 

created a lot of buzz.

HOFFMAN: Some people wait for the 

organization to take care of them. But 

if you wait at the bus stop, the bus may 

not be going where you want. Rex is an 

example of taking personal responsibility 

for using organizational resources. NASA 

is blessed with resources, but people need 

to take responsibility for figuring out 

what is right for them.

18 | ASK MAGAZINE
GEVEDEN: I happened to be coming along 

when the Agency was clamoring for 

project and program managers with any 

amount of experience. I went from doing 

projects that you could put on a chair to 

running an observatory-size spacecraft—

Gravity Probe B, which was a 7,000-

lb. engineering marvel, an amazingly 

complex spacecraft. It was a baptism of 

fire for me. It was the best way for me to 

learn, but it was not without some risk to 

the Agency.

COHEN: What were some of the 

challenges?

GEVEDEN: I had never worked with a large 

prime contractor before. I hadn’t had 

experience interfacing launch vehicles 

to spacecraft, not in a big way. I dealt 

with senior-grade people from university 

and industry, and it was hard for me to 

understand and exercise my authority 

when I was so outranked. An interesting 

thing about project management is that 

you figure out all the things that should 

have been done when you get about 

halfway through. Some you can fix and 

some you can’t. Gravity Probe B was 

a management experiment—that was 

the way it was described in the program 

commitment agreement. The idea was 

that NASA would stand back and let the 

contractor, Stanford University, succeed 

or fail. But there’s no tolerance for 

programmatic failure or mission failure 

in the Agency, and there shouldn’t be.

COHEN: So you couldn’t step back?

GEVEDEN: Growing our authority over 

time and trying to do it in a way that 

wouldn’t disrupt the program and the 

stakeholder relationships was a balancing 

act that helped me develop as a manager. 

One of the miracles of the program was 

how the Stanford team grew. Some young 

Ph.D.s and post-docs developed technical 

program management skills very quickly. 

It was amazing to watch those guys mature 

and blossom. There were something like 

seventy-nine Ph.D.s awarded at Stanford 

on the Gravity B program.

COHEN: Should program and project 

managers coming up now take on 

projects that are a stretch?

GEVEDEN: Yes. Pick your energetic, 

talented, ambitious folks and give them 

a stretch. I would rather do that than be 

safe and give the program to someone 

with more experience but less drive and 

less reach.

HOFFMAN: One last question: What do 

you hope to accomplish in this position 

in the next five years?

GEVEDEN: One thing, because I believe 

so strongly in the program, is to make 

sure we have a thoroughgoing, highly 

supported exploration program. Space 

exploration is one of the ways that great 

nations assert their leadership. It’s an 

expression of our autonomy, our culture, 

our way of life. Another thing I’d like 

to do is to see that processes around 

governance and technical authority 

become so good and so embedded that 

they can survive the transition from 

one administrator to the next. I believe 

that we’re organized and executing now 

better than I’ve ever seen before. I would 

like to help preserve that legacy. ●

I BELIEVE THAT WE’RE organized and executing NOW 

BETTER THAN I’VE ever seen before. I WOULD LIKE TO 

HELP preserve THAT LEGACY.

ASK MAGAZINE | 19
Unexpected Delays 

Equal a Chance 

to Innovate

 BY HUGH WOODWARD

20 | ASK MAGAZINE | STORY
It started like any other project. We had a scope statement, a 

diverse team, a list of interested contractors, and the enthusiastic 

support of management. We even had binders with an indexed 

list of the techniques deemed essential for successful projects: 

communication, change management, risk management, and 

all the others. Although we had challenging cost and schedule 

requirements, we knew we had an excellent plan. Nothing 

could prevent us from delivering this project on time and under 

budget. At least, that is what we thought!

The first hint of a problem came in the form of questions 

about our spending curve. The company was concerned about 

its overall capital spending and was looking for opportunities 

to delay major expenditures into the next fiscal year. We were 

able to oblige initially. We reassessed our schedule and proudly 

offered a new plan with the most expensive work deferred to late 

in the project. The best news was that we would still meet our 

original cost and schedule commitments.

Our excitement was short lived. No sooner had we submitted 

our new plan than we were asked to reduce early spending even 

more. In fact, each new plan drew the same request. Eventually, 

we had to admit we could no longer complete the project on 

time. That is when the second blow hit us. We were informed 

the project was no longer a top priority. In fact, some members 

of management wanted to cancel it. Morale within the project 

team plummeted. Just a few short weeks earlier, our project had 

been priority number one. Success was guaranteed. Now we 

were on the verge of being shut down.

Our project was intended to increase production by 

modifying twenty-one paper machines at four manufacturing 

plants located throughout the United States. We planned to 

install control devices designed to reduce defects and allow us to 

speed up the machines. Some of the technology was new, even 

unproven, but our technical experts assured us it would work. 

A “no brainer,” they called it. We probably should have known 

better, but we didn’t, and confidently developed a list of which 

devices were to be installed on which machines and how much 

additional production we could expect from each.

However, our sales volume was not developing as anticipated. 

As disappointing monthly sales reports continued to accumulate, 

management became increasingly reluctant to spend money on 

increasing production. Eventually we were ordered to put the 

project on hold but to be ready to restart at any moment.

It was time for a new strategy. Since we were no longer 

under a time constraint, we decided to reduce our risk by 

prototyping each of the technologies included in the original 

scope. We installed and tested each device on a different paper 

machine. To our surprise, some did not work as intended. 

Some produced unintended side effects that actually decreased 

production. But fortunately, not all were failures. Some 

worked much better than we expected, enabling us to increase 

Sometimes a delay is the best thing that can happen to a project. While I was program 

manager, funding problems that slowed and threatened to cancel our plans to improve the 

efficiency of our paper manufacturing processes gave us time to prototype and test new 

technologies repeatedly. As a result, we developed solutions that were even better than our 

initial overconfident estimates of how well untried improvements would work.

ASK MAGAZINE | 21
the production rate by two or three times the amount we had 

initially estimated.

The obvious solution at this point was to modify our scope. 

Clearly, we could achieve the same overall production increase 

by just installing the devices that worked best and abandoning 

the others. But an even better strategy began to emerge. As the 

technical experts analyzed the results of our prototypes, they 

came up with new ideas. The experts identified modifications 

that could work even better than the devices that had proven 

successful. So we prototyped these ideas, too. It no longer 

surprised us that some worked and some did not. The results 

prompted even more ideas.

To help generate more new ideas, we looked to the 

manufacturing plants. These plants have process engineers who 

continually work to improve efficiency. They collect loss data 

and then look for ways to reduce the most prevalent losses. In 

tissue manufacturing, for instance, the most significant loss 

almost always comes from “sheet breaks.” The dry paper comes 

off the end of a paper machine at 4,000 feet per minute or more; 

when it breaks, the machine has to be shut down for several 

minutes while the mess is cleaned up. The process engineers try 

to identify and eliminate the causes of sheet breaks.

To encourage the development and propagation of 

successful ideas, my project team conducted its meetings at each 

of the manufacturing sites in turn. Our agenda at each meeting 

included presentations by the local process engineers of their 

problems and the ways they were solving them. Invariably, the 

visitors from other plants saw opportunities to apply the ideas at 

their plants, and we adopted them as part of our project.

Eventually, the company’s sales began to recover and 

management started asking for increased production. By 

this time, we had a menu of proven technologies ready for 

installation. We were therefore able to quickly reapply the 

modifications that provided the best return on investment. We 

now had a proven strategy, and we resisted the temptation to 

deviate. We continued to encourage new ideas, but insisted on 

testing them on a single paper machine before declaring them 

ready for reapplication. 

We eventually ran out of money five years after the project 

was initially authorized, and more than three years after our 

original completion date. But by that time, we had achieved 

three times the production increase we had initially promised. 

We still had to complete the paperwork to explain why we 

changed the scope and missed our completion date, of course, 

but nobody really cared. The real project objective was to 

increase production at an affordable cost, and we had succeeded 

beyond our wildest dreams.

Real evidence of success came when the company asked us 

to submit paperwork for a new project. This time, we admitted 

our scope was a guess and sure to be wrong. But management did 

not care. They just told us to continue with the same approach 

and gave us the amount we requested. It was the easiest project 

approval I ever experienced. 

If our project had not been delayed by funding problems, we 

would have fulfilled our initial cost and schedule commitments 

but produced only a fraction of the production increase we 

promised. Fortunately, we were able to turn those problems 

into an opportunity to develop and test innovative technology 

that far outperformed our initial expectations. And we delivered 

what the company really wanted: additional production at an 

affordable cost. ●

WE EVENTUALLY RAN OUT OF MONEY FIVE YEARS AFTER THE PROJECT WAS INITIALLY 

AUTHORIZED, AND MORE THAN THREE YEARS AFTER OUR ORIGINAL COMPLETION DATE. 

BUT BY THAT TIME, WE HAD ACHIEVED THREE TIMES THE PRODUCTION INCREASE WE HAD 

INITIALLY PROMISED.

HUGH WOODWARD practiced project and program management 

for more than twenty-five years at the Procter & Gamble Company. 

He is a former Chair of the Project Management Institute and now 

helps companies eliminate unproductive effort and unnecessary 

costs as President of Macquarie Business Concepts.

22 | ASK MAGAZINE
Success Through Failure

BY HENRY PETROSKI

“Nothing succeeds like success” is an old saw with many different teeth—some still sharp and 

incising, some worn down from overuse, some entirely broken off from abuse. In fact, the saying 

borders on tautology, for who would deny that a success is a success is a success? We know success 

when we see it, and nothing is quite like it. Successful products, people, and business models are 

the stuff of best sellers and motivational speeches, but success is, in fact, a dangerous guide to follow 

too closely.

INSIGHT | ASK MAGAZINE | 23
Imagine what would have happened if the Titanic had not

struck an iceberg and sunk on her maiden voyage. Her 

reputation as an “unsinkable” ship would have been reinforced. 

Imagine further that she had returned to England and 

continued to cross and recross the North Atlantic without 

incident. Her success would have been evident to everyone, and 

competing steamship companies would have wanted to model 

their new ships after her. 

Indeed, they would have wanted to build even larger ships—

and they would have wanted to build them more cheaply and 

sleekly. There would have been a natural trend toward lighter 

and lighter hulls, and fewer and fewer lifeboats. Of course, the 

latent weakness of the Titanic’s design would have remained, in 

her and her imitators. It would have been only a matter of time 

before the position of one of them coincided with an iceberg and 

the theretofore unimaginable occurred.

The tragedy of the Titanic prevented all that from happening. 

It was her failure that revealed the weakness of her design. The 

tragic failure also made clear what should have been obvious—

that a ship should carry enough lifeboats to save all the lives 

on board. Titanic’s sinking also pointed out the foolishness of 

turning off radios overnight, for had that not been common 

practice with the new technology, nearby ships may have sped 

to the rescue.

A success is just that—a success. It is something that works 

well for a variety of reasons, not the least of which may be luck. 

But a true success often works precisely because its designers 

thought first about failure. Indeed, one simple definition of 

success might be the obviation of failure.

Engineers are often called upon to design and build 

something that has never been tried before. Because of its 

novelty, the structure cannot simply be modeled after a successful 

example, for there is none. This was certainly the case in the 

mid-nineteenth century when the railroads were still relatively 

new and there were no bridges capable of carrying them over 

great waterways and gorges. Existing bridges had been designed 

for much lighter traffic, like pedestrians and carriages.

The suspension bridge seemed to be the logical choice for 

the railroads, but suspension-bridge roadways were light and 

flexible, and many had been blown down in the wind. British 

engineers took this lack of successful models as the reason to 

come up with radically new bridge designs, which were often 

prohibitively expensive to build and technologically obsolete 

almost before they were completed.

The German-born American engineer John Roebling, the 

bicentennial of whose birth is being celebrated this year, looked 

at the history of suspension-bridge failures in a different way. He 

studied them and distilled from them principles for a successful 

design. He took as his starting point the incontrovertible fact that 

wind was the greatest enemy of such bridges, and he devised ways 

to keep the bridge decks from being moved to failure by the wind. 

Among his methods were employing heavy decks that did 

not move easily in the wind, stiffening trusswork to minimize 

deflections, and steadying cables to check any motions that might 

develop. He applied these principles to his 1854 bridge across the 

Niagara Gorge, and it provided a dramatic counterexample to 

the British hypothesis that a suspension bridge could not carry 

railroad trains and survive heavy winds. The diagonal cables 

of Roebling’s subsequent masterpiece, the Brooklyn Bridge, 

symbolize the lessons he learned from studying failures.

Ironically, the Brooklyn Bridge, completed in 1883, served not 

as a model of how to learn from failure but as one to be emulated 

as a success. Subsequent suspension bridges, designed by other 

engineers over the next half century, successively did away with 

the stay cables, the trusswork, and finally the deck weight that 

Roebling had so deliberately used to fend off failure.

At first, the size of the main span of the suspended structures 

increased in small increments. The 1,600-foot inter-tower span 

of the Williamsburg Bridge, completed in 1903, was only a 

few feet longer than that of the Brooklyn Bridge, but like all 

subsequent record-setting suspension bridges it was designed 

without stays. However, it did have an extremely deep truss, 

which made it look ungainly.

Over the next two decades, the main span of suspension 

bridges was increased only gradually. When the Benjamin 

Franklin Bridge opened in 1926, its world-record 1,750-foot 

span was less than 10 percent greater than that of the Brooklyn 

Bridge, which was then more than forty years old. But bridges 

like the Williamsburg, Manhattan, and Ben Franklin, serving 

the traffic of large cities and carrying mass transit tracks, were 

necessarily wide and consequently heavy, and they all had very 

visible stiffening trusses.

The next dramatic departure from Roebling’s recipe for 

failure-based success was achieved in the George Washington 

24 | ASK MAGAZINE
Bridge, which was completed in 1931. This enormous structure, 

with a main span of 3,500 feet, almost doubled the record, 

representing an amazing 95 percent increase over the previous 

record holder, the Ambassador Bridge in Detroit.

However, the George Washington Bridge not only represented 

a great reach beyond the envelope of experience, it also represented 

a new direction in the design of suspension bridges. In having 

no stiffening truss at all, it did away with another of Roebling’s 

specifications for dealing with the wind. But the George Washington 

Bridge was an enormous success, in large part because its cables and 

deck were so massive that their inertia ensured that the wind would 

not move them to any appreciable extent. 

The success of the George Washington Bridge ushered in a 

new era of suspension bridge design, one that was characterized 

by an aesthetic of slenderness. This soon became the goal 

for virtually all suspension bridges designed and built in the 

1930s, including the Golden Gate Bridge, which opened in 

1937. At 4,200 feet between towers, that San Francisco bridge 

represented another 20 percent leap in length. And even though 

it incorporated a deck truss, it furthered the aesthetic of lightness 

and slenderness of appearance.

The culmination of this steady paring down of Roebling’s 

design principles was reached in the late 1930s, when bridges 

were increasingly being built longer, lighter, and more slender. 

However, unlike the George Washington and the Golden Gate, 

which were designed to carry a relatively large number of lanes of 

traffic, many of the newer bridges were designed for remote areas 

where traffic projections called for as few as two lanes and virtually 

no sidewalks, which made for spans that were not only long but 

also exceedingly narrow. And, in keeping with the new aesthetic, 

the roadways were also very shallow, making for structures that 

provided little stiffness against bending and twisting.

The deck of the Bronx-Whitestone Bridge, completed in 

1939 just in time to carry traffic to the World’s Fair in Flushing 

Meadows, began to undulate in the wind, as did that of the 

Deer Isle Bridge in Maine, which opened that same year. Other 

contemporary bridges also proved to be susceptible to the wind 

and exhibited excessive movement of their roadways. Engineers 

disagreed on the cause and remedy of the unexpected motion, 

and also on exactly how to retrofit the bridges with cables to 

check it. Still, no one appears to have feared that the bridges 

were in imminent danger of collapse.

The Tacoma Narrows Bridge, completed in 1940, at 

first behaved in much the same way, with its deck rising and 

falling in great undulations. The fun of driving over it actually 

increased beyond all expectations the amount of traffic using 

the bridge, which had come to be nicknamed Galloping 

Gertie. The fun lasted for only four months, however, at the 

end of which the bridge deck began to move in a new way. It 

started to twist with great amplitude, and after only hours of 

such motion its deck collapsed into the arm of Puget Sound 

that it had been designed to cross. 

The story of suspension bridges from the Brooklyn to the 

Tacoma Narrows provides a classic case history in the value 

of designing against failure and the danger of gaining undue 

confidence from successful achievements. Today, there is a new 

type of bridge whose evolution may be following all too closely 

more recent models of success. 

A cable-stayed bridge may be thought of as a Brooklyn 

Bridge without the swooping suspension cables. The new form 

lends itself to considerable aesthetic variation in how its cables 

are arranged, and so it has become the bridge type of choice 

for signature spans. The cable-stayed Leonard P. Zakim Bunker 

Hill Bridge crowned Boston’s Big Dig, and Charleston’s new 

cable-stayed Ravenel Bridge has already become that city’s 

new symbol.

But as cable-stayed bridges have grown in length and 

daring, their cables have been stubbornly difficult to control 

in the wind. Many such bridges have had to be retrofitted 

with damping devices to check the cable motion. Even though 

the aerodynamic phenomena involved are not completely 

understood, longer and sleeker cable-stayed bridges continue to 

be designed and built around the world. It is as if the history 

of suspension bridges was being repeated. Let us hope that the 

precursors to failure become understood before the models of 

success are pushed too far. ●

...A TRUE SUCCESS OFTEN WORKS PRECISELY BECAUSE ITS DESIGNERS THOUGHT 

FIRST ABOUT FAILURE. INDEED, ONE SIMPLE DEFINITION OF SUCCESS MIGHT BE 

THE OBVIATION OF FAILURE.

HENRY PETROSKI is the Aleksandar S. Vesic Professor of Civil 

Engineering and a professor of history at Duke University. He is 

the author of Pushing the Limits: New Adventures in Engineering 

and other books on engineering and design. His latest, Success 

Through Failure: The Paradox of Design, has just been published 

by Princeton University Press. 

ASK MAGAZINE | 25
On Launch Complex 41 at Cape Canaveral 

Air Force Station in Florida, the fifth and 

final solid rocket booster nears the top of 

the Lockheed Martin Atlas V rocket in the 

Vertical Integration Facility.

Photo Credit: NASA WHITE PAPER

ENGINEERING 

THE

BY JAMES WOOD

26 | ASK MAGAZINE | STORY
The New Horizons mission encountered an issue with the Atlas V booster RP-1 fuel 

tank four months before launch—a remarkably complex problem that involved 

NASA Headquarters, Safety and Mission Assurance, NASA Engineering and 

Safety Center, and the folks at Lockheed Martin who designed the system. We 

needed a way to communicate the facts and logic of the situation in greater 

detail than a typical briefing package provided. PowerPoint was not going to 

cut it. Engineers have a terrible rap for not being able to write and, to be fair, 

most aren’t asked to do so. If I’m not asked to do something and I don’t push 

myself to do it on my own, I won’t ever cultivate the skill, and writing a clear, 

complete white paper is a skill worth cultivating. Photo Credit: NASA

(Left to right) David Kusnierkiewicz, New Horizons mission system engineer; 

Glen Fountain, Applied Physics Lab project manager; and Alan Stern, principal 

investigator from Southwest Research Institute, take part in a dress rehearsal for 

the New Horizons launch at their consoles in the Atlas V Space Flight Operations 

Center on Cape Canaveral Air Force Station.

ASK MAGAZINE | 27
I wrote a lengthy paper describing the Atlas V RP-1 qualification 

tank failure and our resolution for the Pluto New Horizons 

mission because I realized we needed a better way to communicate 

our approach for acquiring and evaluating the data required 

to make a very tough flightworthiness decision. We needed 

to articulate specific details and our logical framework in a 

manner that people who had to come to grips with the issue on 

multiple levels—technical, management, mission assurance—

could understand. 

Writing out the logic that leads to a conclusion is a great 

way to clarify your reasoning to yourself and others. When I 

write things down, I’m forced to tighten my logic. Many of us 

think well “on our feet,” but there’s always a danger that the 

logic developed during a rapid interchange of ideas and solutions 

has crucial defects that aren’t immediately apparent. Darren 

Bedell and I, the chief engineers in the Kennedy Space Center 

Launch Services Program, subscribe to the rule that our logic 

for resolving a problem has to make sense when written down. 

I might have something of a preconceived opinion (admit it, 

most of us do), but when I start writing it out, I find that, wait 

a minute...this piece of evidence fits here, that fits there, and 

then, you know, something else might not fit at all anymore. 

That’s when we realize the logic has a flaw, and we need new 

logic, or more data, or fresh input—and often all three.

Putting the details and logic in a form that can be read, reread, and studied also communicates complex problems better 

than a set of PowerPoint charts accompanied by a verbal briefing. 

The specifics of the New Horizons problem were difficult to 

communicate. You could explain them with spoken words and 

charts to a manager or stakeholder who then might say, “OK, I 

get it, this makes sense.” But when that person talks to the next 

person, who talks to the next person, and so on up the chain, 

you end up playing the telephone game. Even with the best of 

intentions, things get lost or distorted. Especially for a complex 

issue like this one, a single wrong or missing detail can be worse 

than knowing nothing. In addition to testing our reasoning, the 

white paper helped accurately communicate all the important 

information to everyone involved. 

Managers of technical review processes have to keep in 

mind that many people don’t process information very well in a 

meeting. And people miss meetings or parts of meetings. Before 

starting the white paper, I had already been convening eight-hour 

Engineering Review Boards (ERBs) where we hammered out 

decisions one after another. We can do it—we’re used to doing 

it, we’re capable of doing it, and practice has schooled our minds 

to think reasonably well in those forums. But that doesn’t mean 

Technicians install strips of the New Horizons mission decal on the spacecraft 

fairing in the Payload Hazardous Servicing Facility.

Photo Credit: NASA

28 | ASK MAGAZINE
that somebody who wasn’t schooled in those forums won’t have 

a valid point. So I asked myself, “What’s another way I could 

communicate what we developed in that forum?” We write down 

our recommendations and rationale from ERBs, but usually not 

in the kind of detail that would help someone understand what 

led to our conclusions. The paper for the New Horizons booster 

RP-1 tank ended up being forty pages long, because that’s what it 

took to convey the important thoughts clearly. 

You simply can’t hand somebody a briefing package and 

expect him or her to understand the rationale for a decision if 

they haven’t been exposed to the meeting where the material was 

presented and discussed. I see that mistake made over and over 

again. Sometimes you can get the gist of a discussion from the 

package, and sometimes you can’t. The RP-1 problem was an 

issue where the briefing package couldn’t tell you the real story. 

A white paper allows you to communicate to a wider 

audience, so people don’t fall victim to the telephone game, and 

you reach people who are technically capable of criticizing your 

logic and your data but could not attend your review boards. 

Ralph Roe of the NASA Engineering and Safety Center couldn’t 

attend a single one of my review boards, but he provided very 

effective and useful input through criticism of the white paper 

and offered recommendations for strengthening our logic. One 

of his immediate observations after reading an early draft was 

we had failed to provide a rationale for adequate fatigue life, 

which is the amount of strain our parts can take before they fail. 

We had discussed our fatigue life rationale in many forums, but 

it didn’t appear on any charts. Neither had we done a thorough 

job of writing that rationale down. I ended up writing another 

ten pages to express our logic and, in the process, found that our 

rationale was actually stronger than we’d originally thought. 

Providing folks an opportunity to offer constructive, informed 

input outside the lengthy and intense technical meetings adds 

considerable strength to the technical approach to a complex 

problem. I run forums open to everyone as long as they don’t 

bring up cost and schedule, but not everybody can engage 

verbally or devote time to those forums. That’s an important 

lesson learned for me. 

After New Horizons, Darren Bedell, our other chief 

engineer, said, “You know, that worked exceptionally well. I’ve 

got another problem—it’s not similar, but it’s complex. People 

are being victimized by the telephone game, and we’ve held 

these awful, lengthy ERBs. Let me write down what we did and 

why and try that out for people to review and criticize and offer 

their comments.” It worked beautifully. I understand that the 

folks working to resolve the shuttle external tank foam issues 

have also made excellent use of this strategy.

The white paper tool was always in our toolbox, but I think 

we now know better how to use it effectively. You don’t often see 

NASA technical managers writing long narratives explaining 

why they did what they did and how all the details fit together, 

but that may be the best way to capture the logic and context 

of complex decisions. It can be useful both to people at the 

management level who have not been directly involved in the 

work and to somebody who’s down deep in the mud with me 

and my team. White papers are a labor-intensive tool best used 

when no other will do the job. Writing a twenty- to forty-page 

white paper for every decision you make is not possible or 

necessary, and not everyone is used to writing, but we should 

use it more. Sometimes it’s the only way to go. ●

ASK Magazine would like to extend special thanks to Matt Kohut, 

member of the APPEL team and editor of the ASK OCE newsletter, 

for his assistance.

JAMES WOOD is one of the two chief engineers for NASA’s 

Launch Services Program. After receiving a B.S. in physics, 

he worked in the industry as a guidance and control systems 

engineer for several years before joining NASA in 1995. He has 

been the chief engineer for thirty-five missions since joining the 

Launch Services Program in 1999.

YOU SIMPLY CAN’T HAND SOMEBODY A BRIEFING PACKAGE AND EXPECT HIM OR HER TO 

UNDERSTAND THE RATIONALE FOR A DECISION IF THEY HAVEN’T BEEN EXPOSED TO THE 

MEETING WHERE THE MATERIAL WAS PRESENTED AND DISCUSSED. I SEE THAT MISTAKE 

MADE OVER AND OVER AGAIN.

ASK MAGAZINE | 29
Sharing Responsibility 

for Risk

BY BRENT ROBERTSON AND JERRY KLEIN

The Solar Dynamics Observatory (SDO) mission will help 

us better understand the dynamic structure of the sun and 

what drives solar processes and space weather. Goddard is 

building the spacecraft in house, managing and integrating 

the instruments, developing the ground system and mission 

operations, and will perform observatory environmental testing. 

We have a compelling mission with well-defined requirements, 

adequate funding, a seasoned project management team, a 

resources staff capable of miracles, experienced instrument 

teams, strong systems and quality assurance engineering, topnotch engineers, and Center management eager to help with 

problems. It’s what I consider a dream team for anticipating 

and correcting problems. But would this expertise really 

matter when we were using a risk management process none 

of us had used before? 

SDO is one of the first Goddard in-house flight projects 

to use the formal continuous risk management process now 

required by NASA Headquarters. Our risk management plan 

required approval from the Goddard Office of System Safety 

and Mission Assurance to ensure that all the elements in the 

NASA standards and guidelines were adequately addressed. 

Since we know that communication is critical to managing 

risk successfully, we included a risk management coordinator 

in our plan to solicit potential risks from project personnel and 

help disseminate risk data throughout the project. 

Unlike risk management tools used only by the project 

manager, our risk management system is integrated into the 

SDO project culture. Everyone is responsible for identifying 

and mitigating risks. Each month, we solicit new risks through 

an interview process and discover others in meetings, vendor 

status reports, hallway discussions, voicemails, and e-mails. 

We collaboratively develop mitigation plans for each risk, then 

discuss the risk and our plan to alleviate it at a monthly risk 

meeting with project senior staff. We are uncovering more 

potential risks because we have a group instead of one person 

looking for them. Because everyone has their special areas of 

expertise, they are better able to point out issues within their 

subsystems than an outsider would. 

Many NASA accident investigations point to poor 

communication as an important factor: someone in the project’s 

rank and file sees a problem but does not successfully report 

it to the top. Our risk management system, which makes risk 

everyone’s business, improves communication, giving people 

permission—in fact requiring them—to report perceived 

problems up the chain. For example, special meetings with our 

subsystem teams have not turned up any additional risks because 

their concerns have already been successfully communicated. 

Working as a team to manage risk also helps create a common 

vision across the project, giving people a better idea of the shared 

goal and helping them see beyond their own part of the project 

at the subsystem or component level.

So we believed our new risk management system worked 

well, but I wanted to measure its effectiveness, if possible. I 

did a quick search that turned up a lot of material about risk 

Wouldn’t it be nice to have a project management crystal ball that revealed all problems before they 

occurred? Then they could be anticipated, mitigated, and dealt with before they affected technical 

performance, schedule, or cost. As the Observatory Manager for a large space science mission at 

NASA’s Goddard Space Flight Center, I didn’t have a crystal ball, so I wondered how good our team 

was at preventing problems before they occur. 

30 | ASK MAGAZINE | INSIGHT
management systems but little information on their metrics. I 

realized we could measure effectiveness by how many active, 

retired, or accepted risks we had and how long it took us to 

mitigate them and at what cost. Active risks are reviewed 

regularly at the monthly risk management meetings. Retired 

risks are those whose likelihood has been reduced to zero. 

Accepted risks are those we accept with process controls to 

mitigate single-point failures, where a single component failure 

could end the mission (for instance, premature deployment 

of solar arrays, structural failure, propellant leaks) or those 

we think are beyond our project control (for example, new 

launch vehicle certification or contractor/vendor internal 

infrastructure issues). 

A review of SDO risks from the project formulation to the 

implementation phase revealed that by the time of the Critical 

Design Review roughly 50 percent of all risks had been retired. 

The number of active risks decreased slightly over the same 

period of time, and the number of accepted risks remained a 

relatively small percentage (about 15 percent). A closer look 

at our retired risks showed that approximately 80 percent of 

retired risks had been retired within a year of being entered 

into the system. If a project is able to retire risks faster than 

new risks are generated, it allows the team to concentrate on 

a manageable number of active risks. Retiring risks quickly 

assures our team members that management is serious 

about mitigating their risks, which improves the working 

environment and encourages everyone to bring problems to 

light. And as our active risks continue to decrease with time, 

we are decreasing our risk exposure. 

Project contingency spending is another measurable 

indicator of risk management system performance. Forty-five 

percent of our contingency fund expenditures were used to 

deal with risks our system had identified. If we had found 

that funds were being spent on issues our system missed, we 

would know it needed improvement. When we uncovered 

manufacturing issues with the Ka-Band Transmitter, a new 

technology our in-house engineers were developing to meet 

SDO’s high data volume requirements, the project brought on 

an experienced vendor in a parallel effort to build the Ka-Band 

Transmitter engineering test unit and flight unit and mitigate 

Team members monitor the observatory’s integration at Goddard Space 

Flight Center.

ASK MAGAZINE | 31
the potential delay we would face if we fixed the problems by 

ourselves. Because we prioritized risks effectively and identified 

them early, we spent most of our contingency money on what 

could have become more serious problems later. We were not 

blindsided by as many big, expensive problems as we would 

have been without the system.

Until an effective crystal ball comes along, some 

unforeseen problems will always occur, even with the best 

risk management process. We discovered an error in a flight 

dynamics model months after the Critical Design Review. Our 

engineers had assumed that the term “solar north celestial pole” 

in commercial off-the-shelf software was solar north when, in 

fact, it was Earth north. When we corrected the model, the 

spacecraft blocked the high gain antenna field of view during 

certain times of the year. The good news was we caught the 

error prior to launch, but design changes and operational 

workarounds were required to fix the problem. Our team put 

out the word to verify all other engineering models to ensure 

this didn’t happen again (lesson learned). 

A look back over the past three years revealed that we 

have reported a total of fifteen issues to our Goddard Program 

Management Council. Of these, about 70 percent were 

identified and tracked as risks before they became issues. Our 

team was finding nearly three-quarters of all cost, schedule, or 

technical risks before they could affect the project with major 

delays or mechanical failure—an impressive result. That kind 

of statistic and outstanding teamwork and communication 

suggest that our risk management system is a success. ●

OUR RISK MANAGEMENT SYSTEM, 

WHICH MAKES RISK EVERYONE’S 

BUSINESS, IMPROVES COMMUNICATION, 

GIVING PEOPLE PERMISSION—IN FACT 

REQUIRING THEM—TO REPORT 

PERCEIVED PROBLEMS UP THE CHAIN.

JERRY KLEIN is the Risk Management Coordinator for the Solar 

Dynamics Observatory Project at Goddard Space Flight Center. 

gerald.a.klein.1@gsfc.nasa.gov

BRENT ROBERTSON is the Observatory Manager for the Solar 

Dynamics Observatory Project at Goddard Space Flight Center. He 

is responsible for managing the overall Observatory development 

effort, including the Goddard in-house spacecraft. Prior to this 

position, Brent held a number of positions at Goddard, including 

Associate Division Chief, Branch Head, and Lead Engineer. 

brent.robertson@nasa.gov

32 | ASK MAGAZINE
Featured Invention: 

Langley Soluble Imide

BY BEN BRUNEAU

The Inventions and Contributions Board works closely with 

the NASA General Counsel each year to help determine and 

fund the NASA Invention of the Year. The 2005 winning team 

is from the Kennedy Space Center for their invention, Emulsified 

Zero-Valent Iron (EZVI). More information about EZVI and 

past NASA Invention of the Year technology can be found at 

http://icb.nasa.gov/invention.html. 

In this issue of ASK Magazine, we will review a past invention 

from the Langley Research Center, LaRC Soluble Imide, which 

is an extremely tough, lightweight thermoplastic that is not only 

solvent-resistant but also has the ability to withstand temperature 

ranges from cryogenic levels to 200 degrees Celsius.

If you would like any more information about these technologies, 

or any technologies listed on our Web site, please feel free to contact 

me at roger.forsgren@nasa.gov.

–Roger Forsgren, Director of the Inventions 

and Contributions Board

Langley Research Center’s Soluble Imide, a high-performance 

polymer resin, was discovered while working on a project that 

never flew, a mach 2.2 aircraft. Robert Bryant was working 

with a team whose assignment was to develop adhesives and 

composites that would be required for the primary structural 

pieces of the high-speed aircraft. The soluble imide, known as 

LaRC-SI, was discovered in the laboratory by accident. After 

putting the components for a high-performance polymer into 

a reactor, a device for creating a controlled chemical reaction, 

Bryant expected to see the polymer precipitate as a powder once 

the two-stage reaction was complete, but it didn’t. Thinking 

he had messed something up, he repeated the reactor process 

with the same, unexpected results, then went down the hall to 

have a colleague run the reaction and double-check Bryant’s 

conclusions. His colleague got the same reaction. 

“What is unique about SI is the way that it lends itself to 

ease in processing,” Bryant says. Most polyimides can only be 

solution processed after the 

first stage of their chemical reaction, 

requiring complex curing cycles to complete the last 

reaction sequence. LaRC-SI remains soluble in its final 

form, so no further chemical processing is required to produce 

final articles, like thin films and varnishes. Since producing SI 

does not require complex manufacturing techniques, it can 

be processed into useful forms for a variety of applications—

mechanical parts, magnetic components, ceramics, highly filled 

parts, adhesives, composites, flexible circuits, multilayer printed 

circuits, and coatings on fiber-optics, wires, and metals.

The team Bryant was working with was too busy with the 

aircraft project to further develop the polymer resin. But Bryant 

thought it was worth developing, so he created a scenario for 

funding development and submitted it to the chief scientist at 

Langley. He received full funding and left the high-speed civil 

transport project to develop LaRC-SI. 

Once he knew he had a product with many important 

applications, Bryant realized he needed to make potential users 

aware of it. He contacted a small company that agreed to make 

the base resin solution and dry powder of his new polymer, 

which saved him the time and cost of making a new polymer 

for each potential user. Then he needed to demonstrate the 

advantages his material could provide to industry. “I set out to 

prove how this could be used in different fabrication processes 

by making and testing the polymer using a variety of processes,” 

Bryant explains. But gaining people’s attention involved more 

than proof; it required promotion and samples. 

“We put together a data sheet and articles so people could 

read about the polymer if they were interested,” Bryant says. He 

believed that providing a key application would also help create 

enough interest for LaRC-SI to really take off. “The personal 

computer didn’t go anywhere until somebody developed a killer 

application, which was the spreadsheet. So we had to develop a 

One of the invention’s many benefits is in its use as a flexible coating 

for electronic circuits.

STORY | ASK MAGAZINE | 33
killer application,” he says. “That application was using this to 

laminate metals and ceramics to make actuators [a mechanical 

device for moving or controlling something].” There are many 

applications for an actuator with no traditional moving parts: 

valves, switches, speakers, force sensors, and accelerometers. 

For Bryant’s team, the first application was a familiar product: 

a valve. LaRC-SI’s performance in this application led to 

customers asking where they could get their hands on the new 

material or new device and experiment with them, which led to 

new items being developed.

Bryant observed how important marketing his new product 

was in getting people to see the value of using it in their own 

applications and products. He noted that many useful ideas 

and inventions never take off because they are not promoted or 

demonstrated enough to become well known. “People come up 

with different things every day,” he says. “In my case, and what 

I feel applies to all cases, you eventually have to say, ‘OK, you’ve 

developed something a little bit different. How can you show its 

advantage over what’s already out there?’” NASA’s name helped 

tremendously in creating this recognition and respect for the SI 

polymer. “People really recognize the NASA logo and NASA 

as a preeminent center for scientific development,” Bryant says. 

“Without that recognition, my invention may not have gone 

where it has gone. The fact that I work for NASA is an important 

part of this equation.”

Bryant also sees the importance of letting customers develop 

the invented product or materials further. He noted that some 

inventors can become too wrapped up in creating the perfect 

product for their newly invented material when they should be 

concentrating on getting it into as many different customers’ 

hands as possible. These customers are key to developing new 

uses for the material. Bryant explains, “When you invent 

something, you really have to get the stuff moving because the 

only way people benefit from it is by having access to it. A journal 

paper is nice, but it doesn’t give anybody access. It only gives 

them knowledge to go off and hopefully develop something 

themselves.” He said he learned this lesson the hard way by 

observing senior colleagues go through similar experiences. 

Because of Bryant’s efforts, the polymer resin’s use has taken 

off in many different areas. Langley, Jet Propulsion Laboratory, 

and Glenn Research Center engineers are working on using the 

SI polymer in electronic applications, including experiments to 

use the new material to replace circuit boards. Bryant explains, 

“The idea is to eliminate the circuit board and use the actual 

structure of the satellite as the circuit board instead. I think the 

actual applications of this are still a few years away, but we’ve been 

able to demonstrate it’s possible.” By prefabricating the polymer 

boards, bonding them to the structure during fabrication, and 

then soldering or gluing the electrical components to the LaRCSI circuit board, the need for a separate support structure, circuit 

board mounting hanger, and heat sink is eliminated. The new 

configuration still carries the load, but it also serves as a heat sink 

and an electrical panel, so more can fit into a smaller space.

In the commercial sector, the polymer resin is being used 

to make ceramic actuators. These are used in machine tools, 

wireless switching applications, transformers, and many other 

devices. The largest and most valuable application is in wire 

coating. Several medical products, including pacemakers, plan 

to use this polymer resin to coat wires, which is the first big 

change in this system in twenty years. LaRC-SI, in addition to 

being physically durable, is also biologically inert, so it is not 

readily attacked by the body’s immune system or degraded by 

biological fluids. 

The SI polymer resin was never used in the high-speed 

aircraft program for which it was developed, but this is not 

uncommon. “You meet the milestones and goals of a program, 

and while you are doing that, you spin off so much other 

relevant technology,” Bryant says. “The trick is letting other 

people know what you’ve discovered after you’ve stumbled 

upon it. In my case, if I hadn’t pursued developing and 

marketing the polymer, this innovation would have died with 

the original program.” ●

34 | ASK MAGAZINE
The “Fifth Dimension” of Program 

and Project Management

BY WILLIAM H. GERSTENMAIER 

A lot of tools and techniques exist to control these four dimensions. 

Earned value management and similar tools can be used to look at 

cost and schedule performance and evaluate the project’s chances 

of coming in on time and on budget. A slew of cost-estimating 

tools and techniques can do modeling at all stages of project 

design and implementation. Managers are known to wake up in 

cold sweats in the middle of the night with visions of S-curves, 

Gantt charts, and PERT charts dancing in their heads. Risk 

analysis is a big part of what managers do nowadays, especially for 

us in space operations, and tools like probabilistic risk assessment 

help managers get a handle on their risk exposure. These tools 

let managers do rigorous “what if?” analyses that lead to a good 

understanding of all the risks facing the project and developing 

contingency plans to offset those risks.

Obviously, no project will succeed unless the manager 

understands and thoroughly masters these four dimensions 

Any project or program manager will tell you 

that the key to successful execution lies in 

mastering a toolkit of basic techniques. No one 

will be surprised (I hope!) to know that these 

techniques involve learning how to measure and 

manipulate the dimensions of cost, schedule, 

performance or technical capability, and risk. 

Basically, these are the standard-issue dials that 

the manager is able to monitor and the knobs 

that can be tuned to get the hardware out the 

door, doing what it’s supposed to do, on time 

and on budget. The good managers can do this 

reliably, over and over again, for a wide variety of 

different missions.

(Clockwise from upper left) The Hubble Space Telescope; the Bug Nebula as seen 

by Hubble; Dr. Peter Tsou handles the Stardust sample return; Mars rover Spirit 

modeled on images of “Husband Hill”; Jupiter and Io photographed by Cassini. 

Each of these projects has been perceived as a success.

INSIGHT | ASK MAGAZINE | 35
of project management. They are the bread and butter of the 

profession. However, as projects and programs get bigger, more 

complex, and more visible, the manager is forced to realize that 

understanding these four dimensions represents a necessary, but 

not sufficient, foundation for success. There is a “fifth dimension” 

of project and program management: politics. Now, by “politics” 

I mean the set of expectations and perceptions that people inside 

and outside the organization develop, both in their own minds 

and collectively, about what the project is really all about, and the 

methods by which they seek to influence the process. 

Politics in this context are forces not directly related to cost, 

schedule, and performance and that cannot be controlled using 

the classical tools of project and program management. But 

because your project or program is embedded within the context 

of a larger effort, these political forces can play a big role in 

overall mission success. Your project or program may be part of 

the vision of the company or the government, or be aligned with 

the corporate goals of skills development not directly related to 

the publicly stated technical goals. Every stakeholder (literally, 

anyone who has an interest in an enterprise or outcome) may 

have different, even conflicting, reasons for pursuing a project. 

Expectations and perceptions about the project develop even 

before the project begins. These perceptions may have limited 

basis in actual fact and can come from media reports, other 

external sources, or even from overzealous proponents within 

the project itself. The media in particular is often structured 

to respond more readily to something new or different, and 

differences in expectations, perceptions, and the reality on 

the shop floor or in mission control can make great news. For 

example, an external stakeholder can perceive that your project 

may be “easy” or “hard,” depending upon his or her comparison 

of this project with similar projects in the past. This expectation 

may be either accurate or inaccurate, but it is very real in the 

mind of the evaluator and can be difficult, if not impossible, to 

change. Space flight projects, for instance, are often expected to 

be like aircraft projects, even though the amount of energy that 

needs to be controlled for space flight is an order of magnitude 

higher. And while NASA is expected to deliver excellent 

technical results, the perception of NASA’s ability to control 

cost and schedule performance is often quite poor.

Because these political issues of expectations are so important, 

care must be exercised in managing these expectations and 

perceptions in the early stages of the project. For example, the 

early justifications for the Space Shuttle in the 1970s assumed 

that the system would operate like an airline, flying up to sixty 

times per year and at a cost of $100 per pound of payload, 

thereby making all other launch vehicles obsolete. Obviously, 

even in our best years when commercial operations were heavily 

subsidized by the government, the shuttle ended up pushing far 

too much technology in terms of thermal protection, engine 

performance, materials science, etc., to ever realize these sorts 

of mission tempos. Because the shuttle was originally pitched 

as a low-cost space “truck,” its incredible capabilities and its 

role as a versatile work platform are often discounted or ignored 

by skeptical stakeholders. Similarly, the International Space 

Station was going to be a “world-class” research facility, while 

the actual design and assembly of this—the largest complex 

ever flown in space—was pitched as easy and inexpensive. 

This pitch completely understated the fact that, while the basic 

technology used in the construction of the space station was 

well understood, the sheer scale of the assembly challenge and 

the complexities of managing a fully international project were 

greatly underappreciated by many stakeholders. These kinds of 

misleading initial expectations can haunt a project throughout its 

life and make the job of a project manager extremely difficult. 

Big projects and programs, of course, mean more stakeholders. 

The politically astute manager will have an almost instinctive 

grasp of what this growing circle of stakeholders will find most 

compelling about the project and how to use that innate sense of 

excitement to build support for the mission. Think about some 

of the biggest space successes in recent history: the Hubble Space 

Telescope; the rovers Spirit and Opportunity on Mars; Stardust; 

Cassini-Huygens. Not only were these projects hugely successful 

from a technical standpoint, but they have also become widely 

perceived as being hugely successful. It’s tough to say exactly what 

it is about a successful technical project that will resonate with 

people. Maybe it was the fact that Hubble returned pictures in 

visible light rather than some other wavelength. Maybe it was 

bringing primordial samples of the sun back to Earth for people 

to actually touch. Maybe it’s the cool factor of driving around 

the deserts of another planet, or hearing the wind whistle past as 

a probe screams through the atmosphere of a distant moon. One 

way or another, every successful effort has involved nurturing 

the kinds of personal connections between stakeholders and 

36 | ASK MAGAZINE
the project that build long-term support. Managing the biggest, 

most visible projects means always being aware of why the project 

is important, why people should or would care, and what the 

manager can do to share their own sense of excitement as broadly 

and effectively as possible.

Perceptions can change over time as the benefits of a project 

become clearer. This was certainly the case in the Lewis and Clark 

expedition, which ended up costing more than ten times its initial 

Congressional appropriation. That expedition, or the Hubble 

Space Telescope in our own time, proves that astute managers 

can overcome a project’s early problems if the fundamentals 

of good project and program management are observed and 

mission success trumps the initial set of negative perceptions. 

By being aware of the effect that external stakeholders’ negative 

perceptions can have on mission execution, the politically savvy 

project manager can avoid inadvertently reinforcing these 

perceptions and better communicate with target audiences. 

The problem with trying to manage the political dimension 

to minimize the negative effects on mission success is that 

communication technology does not stand still. The Internet, 

in particular, is changing the way big projects are perceived and 

evaluated by external stakeholders and the public in two ways: 

(1) by providing anyone with a computer a huge volume of data 

upon which to form opinions and (2) by providing alternative 

avenues for well-intentioned personnel within a project to 

“leak” information outside the normal internal channels of 

communication. Leaks, in particular, can turn a very technical, 

nuanced discussion within the community into a public 

debate where people with vastly differing agendas are given 

the opportunity to pursue diverging interests at the expense of 

intelligent and logical decision making. Even traditional news 

sources are being radically changed by Web logs or “blogs.” While 

traditional news sources typically have a number of policies that 

address issues like source citation, collaboration, and editorial 

review, blogs are not so restricted. Information on such blogs can 

therefore be put out very quickly, but the quality and accuracy of 

that information can be proportionally diminished.

The immediate reaction of the manager might be to attempt 

to intercept and stop these external lines of communication from 

taking place. I think this approach is wrong, both on practical 

and philosophical grounds. Attempting to impose draconian 

communication requirements on a team is at best an example 

of attacking the symptoms while leaving the underlying cause

unaddressed; at worst, heavy-handed tactics demonstrate better 

than anything else that there are systemic communication 

problems within the project that will eventually lead to mission 

failure. Instead, rapid advances in alternative communication 

avenues mean that managers should work harder than ever 

to improve the internal lines of communication within their 

organizations. Employees must trust that they will quickly get 

the best information on decisions from their own organization 

and managers. This trust must be built on strong and mutually 

respected lines of communication both within the organization 

and between the organization and the outside world. 

Successful organizations understand that all stakeholders, 

internal and external, have a legitimate interest in project 

information. These demands mean that managers operating in 

the fifth dimension must become communication experts adept 

at tailoring style and context for specific audiences. For example, 

an engineering team demands precision and technical accuracy 

to come up with the best technical decisions possible, but a 

Congressional staffer who is responsible for overseeing literally 

dozens of different federal agencies naturally has very different 

data requirements. Understanding the role of communication 

inside and outside the engineering organization therefore 

becomes the sine qua non for managers of highly visible projects 

operating in the fifth dimension.

Just as an athlete cannot make it to the Olympics without 

extraordinary physical ability, a good manager must master the 

first four dimensions of project and program management to be 

successful. However, mastering the tools and techniques of cost, 

schedule, performance, and risk management is not enough to 

guarantee the gold medal. To win the gold, Olympians must 

possess other characteristics that give them a slight edge over the 

competition. Being aware of the fifth dimension of project and 

program management and learning to operate effectively in this 

dimension can lead you to become a gold medal manager. ●

BY BEING AWARE OF THE EFFECT THAT EXTERNAL STAKEHOLDERS’ NEGATIVE 

PERCEPTIONS CAN HAVE ON MISSION EXECUTION, THE POLITICALLY SAVVY 

PROJECT MANAGER CAN AVOID INADVERTENTLY REINFORCING THESE PERCEPTIONS 

AND BETTER COMMUNICATE WITH TARGET AUDIENCES.

WILLIAM H. GERSTENMAIER is the Associate Administrator 

for Space Operations. In this position, he directs NASA’s human 

exploration of space. He also has programmatic oversight 

for the International Space Station, Space Shuttle, space 

communications, and space launch vehicles.Photo Credit: NASA/Bill Ingalls

ASK MAGAZINE | 37
 Gravity Probe B:

Testing Einstein...

with a Management Experiment?

BY EDWARD S. CALDER AND BRADLEY T. JONES

The completed space vehicle undergoing thermal vacuum environment testing.

Photo Credit: Lockheed Martin Corporation/Russ Underwood

38 | ASK MAGAZINE | STORY
Gravity Probe B (GP-B) has been called the most sophisticated object ever placed in space. Whether this is 

true or not, it is certainly one of NASA’s most complex missions and occupies a unique place in space science 

history. GP-B embodies all aspects of an ideal NASA mission: advancing science (testing Einstein’s general 

theory of relativity), meeting daunting technological challenges (gyroscopes that required an environment 

with no drag and near absolute zero temperatures), teamwork (Stanford University–NASA–Lockheed 

Martin), and public value (more than ninety Ph.D.s were earned on GP-B-related projects). While the 

scientific value and technological achievements have been well documented, relatively little attention 

has been given to the management of this extraordinarily complex mission. How was its management 

structured? How was the balance between radical innovation and reliability achieved? What practices can 

be extracted from the GP-B program that might be applied to other missions?

Management Story

GP-B began like many other NASA–university collaborations: 

a group of scientists conceive an important scientific experiment 

that requires a space environment. In the case of GP-B, the idea 

emerged from a 1959 discussion at Stanford between Professors 

Leonard Schiff and William Fairbank of the physics department 

and Professor Robert Cannon of the aero/astro department. 

The experiment they envisioned would measure the relativistic 

precession of an orbiting gyroscope (that is, the motion of its axis), 

thereby testing two aspects of the general theory of relativity: 

the warping of space-time caused by the Earth’s mass (geodetic 

effect) and by the Earth’s rotation (frame-dragging). In 1964, 

NASA decided to fund a small group of Stanford researchers to 

develop the basic science requirements and technology. Stanford 

and Marshall Space Flight Center collaborated on some 

technologies, including oversight assistance on subcontracts to 

industry for gyroscope and telescope hardware, development of 

the insulating container or dewar, and testing of many basic 

features of the final design. 

In 1985 GP-B entered a new phase that became known as 

the management experiment when then-NASA Administrator 

James Beggs commented that GP-B was to be an interesting 

management experiment in addition to an interesting scientific 

experiment. The management experiment was an agreement 

between NASA Headquarters, Marshall, and Stanford 

University that made Stanford the prime contractor, responsible 

for managing the entire program with minimal NASA oversight. 

The decision followed a recommendation from the Space Studies 

Board to NASA HQ in mid-1983 that in a mission such as GP-B,

where the science instrument (payload) and spacecraft are 

much more closely integrated than in typical space programs, 

separating the two would be gravely detrimental. The agreement 

was predicated on Stanford’s intent to set up a much stronger 

management structure than is typical at universities.

In the following years, Stanford made substantial progress 

on the novel technologies needed to achieve the precision 

required for GP-B’s demanding objectives. In order to measure 

geodetic and frame-dragging effects, extremely small angle 

changes (forty-two milli-arc seconds) needed to be detected and 

measured. (One milli-arc second is equal to the width of one 

human hair as seen from ten miles away.) This precision placed 

extremely tight tolerances on much of the GP-B hardware. The 

gyroscopes, for instance, are the most perfectly spherical objects 

known to mankind. 

ASK MAGAZINE | 39
To assist Stanford with development, Lockheed Martin was 

awarded the subcontract for the spacecraft and some components 

of the payload. This contract was under Stanford’s control and 

represented a substantial increase in the university’s managerial 

responsibilities. During this phase, GP-B also began a process of 

incremental prototyping—that is, developing an initial system 

design and then building actual hardware, while recognizing 

that a process of redesign and rebuilding would be necessary. 

The advantage to this approach lies in the learning derived 

from building hardware, both in terms of process and concept 

evolution. Given the complex and radical innovation necessary 

for GP-B’s technology, incremental prototyping contributed 

crucially to the ultimate success of the program.

Around 1998, the management experiment was terminated 

when the GP-B team encountered two significant technical 

problems involving the payload system: one necessitated the 

removal and replacement of one of the four gyroscopes and the 

other repairing a broken thermal contact between the probe and 

dewar. While the GP-B team resolved both issues skillfully, the 

associated delays to schedule and cost contributed to a growing 

feeling among NASA personnel that the Stanford team had 

entered a stage of development for which it didn’t have sufficient 

experience. This view was made explicit by an independent review 

team that went so far as to recommend that Lockheed Martin 

be made the prime contractor. NASA concluded that Stanford 

would remain the prime to preserve the scientific integrity and 

coherence of the mission, but additional NASA personnel would 

be needed to help run the program. NASA took a much more 

proactive approach to GP-B, involving many NASA employees 

at various levels of decision making and oversight. Gravity Probe 

B increasingly resembled a typical NASA program.

Management Lessons Learned

Was the management experiment a success, or does the fact that 

NASA intervened at the end indicate that a university is not 

capable of being the prime contractor? The remarkable progress 

made while the program was under Stanford’s direction shows 

the value of making a university the prime contractor. At the 

same time, the fact that NASA needed to step in and mitigate 

a perceived growing risk indicates that some improvements are 

necessary for this type of collaboration to work.

Universities and government/industry operate in vastly 

different environments and have distinct capabilities and 

cultures to address their different challenges. Universities are 

flat organizations with little in the way of standardized processes 

(at the project level); they excel at radical innovation. The 

government and private industry mainly comprise hierarchical 

organizations with strong institutionalized processes that excel 

at incremental innovation. University projects generally involve 

small teams and therefore have little need for collaboration 

management. Government/industry projects are usually 

large collaborations that require rigorous boundary and 

collaboration management. These differences have significant 

implications for collaborative projects such as GP-B. In order 

for collaborative research to become valuable and successful, the 

program leadership must strategically leverage these differences 

in capability while managing the differences in culture.

Managing organizational differences is one of NASA’s most 

important responsibilities in collaborating with universities. It 

can be done by recognizing and managing contextual transitions 

and establishing an appropriate risk management system. A 

contextual transition is a change in the requirements, processes, 

and even the nature of the program. These transformations are 

not clear and sudden. They can last months or years, making 

them difficult for NASA or the university to recognize. While 

the standard NASA five-phase classification scheme is a 

comprehensive and convenient way to look at program evolution, 

a more fundamental change for NASA–university collaborations 

is the beginning of flight hardware development. Moving from 

research and prototyping to building flight hardware is a shift that 

requires traditional aerospace processes like quality assurance, 

operations procedures, and configuration management. These 

processes, which ensure reliability and reduce programmatic 

risk, generally impair creative research and development, which 

thrives in an environment with fewer constraints and more 

freedom to quickly try new ideas. NASA can help universities 

recognize the point at which they should begin incorporating 

Photo Credit: Lockheed Martin Corporation/Russ Underwood

The space vehicle during the encapsulation process atop the Delta II launch vehicle. 

40 | ASK MAGAZINE
aerospace processes and aerospace-experienced managers in 

their teams. It must be done early enough to give university 

researchers competence in such practices when appropriate, 

but not so early that NASA hinders the innovation gained by 

working with universities. Gradual implementation achieves the 

best results.

In addition to recognizing when this transition should 

take place, NASA should help implement these aerospace 

processes. The GP-B program showed that universities are 

indeed capable of adopting aerospace processes; by the end 

of the program, GP-B produced a number of researchers who 

were highly skilled at building flight hardware, in addition to 

being technically creative. NASA has a clear role in ensuring 

that universities provide the training and experience their young 

researchers need to mature into able aerospace researchers. Clear 

guidelines and one-off training sessions can help, but important 

tacit knowledge is more effectively transferred by embedding 

experienced NASA or industry personnel in university teams. 

For instance, one individual who originally came to Stanford 

as an undergraduate and remained to pursue a graduate degree 

had no aerospace program experience prior to GP-B. The project 

gave him an opportunity to apply his deep classroom knowledge 

to flight hardware design and development processes. Working 

with his Lockheed Martin colleagues, he developed an expert 

knowledge of the requirements and skills necessary to design 

and build flight hardware. Eventually he completed his Ph.D. at 

Stanford and became the team lead for one of the most critical 

components of the space vehicle. He has proved an extremely 

able program manager. 

Another component of managing the gradual transition 

from research to flight hardware development is ensuring 

the university’s management team has the relevant skills and 

experience for each stage. For a long time, Stanford had a 

program manager who possessed a strong technical background 

and aerospace management experience. After his departure, 

Stanford promoted a number of its senior scientists to program 

manager; they were technically excellent but didn’t have the 

experience necessary to manage a full-scale aerospace program 

or the practical knowledge of how to develop a flightworthy 

spacecraft. Eventually a program management team was put 

in place that possessed the appropriate experience—depth 

in aerospace management and a sufficient understanding of 

the science—which allowed the program to run smoothly up 

through launch and mission operations. In this kind of case, 

NASA can help the university recognize the need for a shift in 

its management team’s competencies and identify appropriate 

external candidates or ensure the university is cultivating 

appropriate personnel internally.

NASA should also take an active role in instituting a risk 

management system and helping mitigate risks that stem from 

university inexperience in flight programs. Initially, GP-B suffered 

from an inadequate system for assessing and alleviating risk. 

NASA oversight was often misplaced, focusing too much effort 

on non-issues and not enough on the more serious problems. For 

example, while moving the payload from Stanford to Lockheed 

Martin, the wrong type of gas was connected to the dewar. The 

reason for the mishap became obvious after the fact: different 

gasses were stored in the same color bottle. NASA brought in a 

large team to analyze the failure and provide corrective action, 

but this added little value; the Stanford team understood the 

mistake and easily provided corrective measures. It would have 

been much more valuable to seek out similar process problems 

instead of dwelling on ones for which the solution was evident. 

NASA’s motivation was correct, but an ineffective risk system 

makes it difficult to properly judge perceived risks and increases 

the danger of overreacting to minor risks and underreacting to 

major risks. Before a more structured risk system was put in 

place, Stanford’s fear of NASA overreaction to such problems 

limited communication. Much of the university team’s time was 

spent providing status briefings to NASA rather than solving 

the issue at hand. After helping establish a new risk management 

system that scaled the reaction to the risk, Marshall was able to 

provide appropriate and more effective oversight and improved 

the character of the collaboration dramatically. With the tension 

of uncertainty and inappropriate responses removed, a sense of 

partnership and respect increased and contributed to improved 

program performance.

The goal of any true experiment is to learn something. 

GP-B proved to be not only a great science experiment but a 

great management experiment. The successful launch and onorbit operation of Gravity Probe B is a testament to the value 

of working with universities. The management lessons that 

emerged put NASA in a better position to take advantage of this 

potent resource for challenging future missions. ●

EDWARD S. CALDER spent five years on GP-B as a member 

of the Cryogenics Team and was the Cryogenics Operations 

Lead at the launch site. He is currently a consultant, focusing 

on organizational behavior, management, and emerging 

technologies. Edward received a Bachelor of Science in Physics 

from Northwestern University and a Master of Science in 

Technology and Policy from MIT. ncalder@mit.edu

BRADLEY T. JONES spent three and a half years on GP-B as the 

Launch Team Lead and a Flight Director. He is currently a NASA 

employee at the Johnson Space Center and a part-time master’s 

student at Stanford University in aeronautics and astronautics. 

Bradley received a Bachelor of Science in Civil Engineering from 

Texas A&M in 1999 and a Master of Engineering in Management 

and Systems Engineering from Cornell University in 2002. 

bradley.t.jones@nasa.gov

ASK MAGAZINE | 41
The Impact of Fear 

on Project Success

BY FREDERICK MANZER

Have you ever thought, “This will never work, but if I tell management they’ll fire me”? Have you 

suppressed information, such as a growing estimate at completion, to prevent unwanted attention, 

criticism, or help? Would you pad an estimate to ensure you could meet promised numbers even 

when things do not go as planned? These may be understandable responses in your organization, 

but they are destructive to the people, the project, and the organization. These “fear” responses 

substitute self-protection for the honest communication that brings long-term success.

42 | ASK MAGAZINE | INSIGHT
You may be in a fear-based environment if one or more 

of the following are true: 

• Assignment of blame begins the problem resolution 

process.

• Bullying or making threats is part of task assignment.

• “Real” numbers require significant scrubbing or 

cutting.

• Unpleasant surprises typically accompany final project 

activities.

• Problems always show up first as history.

• Excuses are not authorized.

• Personal objectives tie to project results the individual 

does not control.

• Avoiding blame for failure equals success.

Changing the performance focus from “avoiding failure” 

to “achieving success” requires attention to behaviors as well as 

results. Results are the product of correct behaviors.

Fear and Management

Some managers use fear as a tool to force action. They set tough 

goals (usually around cost or schedule) and pressure people to meet 

them. Some of the common fears that affect project work are

• Criticism—Enissophobia 

• Making decisions—Decidophobia

• Neglecting duty or responsibility—Paralipophobia

• Failure—Atychiphobia or kakorrhaphiophobia 

• Imperfection—Atelophobia

• Punishment—Poinephobia

• Being ridiculed—Catagelophobia or katagelophobia

Fear-based management can motivate people to work 

hard, especially in the short run, but it often leads to protective 

behaviors that undermine projects. Projects proceed without 

reported problems and continue to forecast success even when 

failure becomes certain. One software development project I 

reviewed suffered from poinephobia, the fear of punishment. 

The team reported performance as exactly on cost and 

schedule until the customer discovered only 70 percent of the 

requirements were addressed. Once the problem was identified, 

the team admitted it had manipulated the performance data 

to show good performance and avoid punishment from the 

project manager. This misinformation caused a delivery delay 

of nine months while the required functionality was added. 

Fear-driven self-protective behaviors include

• Hidden reserves—Individuals pad their estimates to 

ensure they do not fail for reasons beyond their control or 

to insulate against reduced budgets (atychiphobia);

• Manipulated performance—When variance from 

the baseline causes penalties, then data manipulation 

becomes the approach (enissophobia);

• Hidden problems—Shooting the messenger creates 

a lack of messengers, not a reduction in problems 

(poinephobia);

• Ignoring risk—If the risk identifier becomes the owner or 

is branded as “negative,” then risks remain unidentified 

(atelophobia).

These phobias often originate in the popular objectiveor results-oriented management approach. Managers increase 

pressure and determine whom to blame instead of finding 

solutions. The individuals, meanwhile, focus on avoiding 

blame and creating good performance reviews. The outcome 

is continuous suboptimization of the projects, high stress, and 

unnecessary project failure. 

A Wiser Alternative

This management-by-objectives process holds individuals 

accountable for results beyond their control. Once individuals 

ASK MAGAZINE | 43
cannot control their results, fear takes over. It’s better to focus 

on what they can control: Are people doing the best they can? 

Can they provide you with better data and better decisions 

sooner? Creating inspiration instead of fear to challenge your 

team’s performance requires an alternative approach based on 

two changes.

Responsibility Assignment

Every stakeholder contributes to achieving project outcomes. 

A customer who sets unreasonable objectives, a salesperson 

who accepts them, a manager who fails to recognize problems, 

and a worker who does not make his best effort become equal 

participants in failure. Rather than holding the worker ultimately 

responsible for the failings of all, each stakeholder must accept 

and correct his or her share of the cause. 

• If the customer objective is unattainable, tell the 

customer.

• If marketing makes undeliverable promises, hold them 

responsible, not the performers.

• If development requires special tools or people, assign 

them or do not expect the required results.

• If integration and testing requires six weeks, it will still 

require six weeks even if inputs are late. Cutting time 

results in a poorly tested product.

Solving difficult problems requires open and honest 

communication, a frank—and fearless—discussion of the 

problems and alternatives available under the circumstances. 

By focusing on the inhibitors—the things that will prevent 

success—and getting the right people to remove them, success 

becomes possible.

Behavior Management

Success requires identifying and measuring desired behaviors as 

well as results. Known as process management when managing 

the quality of products, whether hardware or software, the same 

rules apply when managing people. Inspiring the right behaviors 

produces the best possible results. Challenge people to find 

solutions by asking, “What can we do to make this happen?” 

instead of reiterating that the deadline is important. Reward 

innovation and imagination. Never punish honesty. When 

the fear of failure is removed, individuals will accept greater 

challenges and managers will receive better information. In the 

end, it’s important to remember that people can give their best 

effort, but they cannot always guarantee results.

More Than Outcomes

It’s important to set performance goals based on effort, not on 

how a project turns out. Changing the environment requires 

trust and communication. People should feel safe in identifying 

their fears, concerns, and risks and asking for help. This will 

not only inspire your team to focus on prevention rather than 

correction and speak up early if they foresee problems, but it 

can also lead to personal growth and organizational success. 

Removing fear removes limits and challenges your team to 

think outside the box instead of locking themselves inside it. ●

FREDERICK MANZER is currently a senior consultant 

at Strategy Bridge International, Inc., and has been the 

lead project management consultant and instructor since 

2005. He has taught and developed more than 200 project 

management courses for Strategy Bridge International, Center 

for Systems Management, and the National Reconnaissance 

Office Acquisition Center of Excellence.

44 | ASK MAGAZINE
 UNIVERSITY 

COLLABORATIONS:

Teaching and Learning

BY KEVIN VIPAVETZ

When Tom Shull, my supervisor, told me the Virginia Space Grant Consortium (VSGC) might ask 

for project management and communications support for a university research balloon project, 

I thought about how I was already juggling four projects and didn’t have time to volunteer. I also 

realized I wouldn’t be here today without the help and mentorship of many others at Langley Research 

Center. When Anne Pierce, the Program and Development Specialist from VSGC, called and said, 

“I heard that you are an expert in best project management practices and can help us develop the 

communication system for the project, and that you are the best of the best. We really need your 

help,” she knew how to butter a person up. I heard myself say, “Sure, I’d be glad to help.” 

Photo Credit: NASA

STORY | ASK MAGAZINE | 45
Virginia Student Balloon Launch Program

The Virginia Student Balloon Launch Program focused on 

mentorship and providing “real-world” experience for students—

an excellent idea. It involved a coalition of five Virginia universities 

and built on a prior balloon research project. As an atmospheric 

science experiment, it would measure products of combustion 

concentrations in the stratosphere (hydrocarbons and sulfur 

dioxide). The balloon would be launched from NASA Wallops 

Flight Facility between July and August, which, I learned 

later, was not the best choice when working with students near 

graduation.

Universities provide important basic research and innovative 

ideas that can be developed into cutting-edge technologies for 

NASA. They are also our main source for future scientists, 

engineers, technicians, and managers. So projects like this are 

important. You deal mostly with students who are book savvy 

but need project management skills and guidance. That’s what 

the projects are for—providing hands-on experience—but 

it can mean you need to fix things you had not originally 

anticipated. By realizing what experience the students needed 

and adjusting my expectations (these were not, after all, my 

seasoned Langley colleagues), I might have foreseen more of 

the unexpected challenges we faced during this project. 

At the kickoff meeting, I learned that total funding for 

the project was $35,000, far too little to support the dozen 

or so NASA personnel who would be involved from Langley 

and Wallops and to procure hardware. I also learned that we 

needed to provide an additional mission control room for 

back-up telemetry to launch site operations (a decision that 

proved essential for gathering our data on launch day). The 

project Critical Design Review (CDR) was a month away, 

which seemed like good news. I thought I was coming in at 

the beginning of the project, but a successful CDR means that 

design drawings are near completion, interfaces are understood, 

much of the software code is done, and the project is ready to 

build and procure the hardware. During the meeting, I was 

asked to participate and help assess the CDR. Then I didn’t 

hear from anyone for a month. 

The Critical Design Review

Of the 100 or so students who were involved in the project, six 

seniors had been assigned to me. I didn’t have any luck reaching 

them after the kickoff meeting and began to wonder if the CDR 

was still scheduled. A couple days prior to the CDR, I started 

receiving requests for help. Though the students had a camera and 

a data instrument, they did not know how to get the video and data 

sent from the balloon to the ground stations. I asked how we had 

already procured hardware when we hadn’t yet passed the CDR 

because these reviews are meant to help develop an end-to-end 

design for a compatibly integrated working system. What should 

have been—and I assumed had been—done up front was gather 

the stakeholders and put a complete concept together. I now push 

for this crucial step at the beginning of any project I am on.

Since the CDR was only a couple of days away, we 

didn’t have time to put a detailed design together. Instead, I 

recommended we look for off-the-shelf university equipment 

or compatible government hardware we could borrow. Because 

we didn’t have funding for a telemetry system, we would 

have to use one of Langley’s. I told the students to build and 

interface their hardware around this, then put together a CDR 

presentation showing how this would be integrated with the 

science instrument and ground operations. For a project of 

this size, we could get away with putting a working subsystem 

together without going through a full CDR process, but this 

would not produce detailed reports that could transfer the 

knowledge to the next balloon research team. 

A couple of hundred people from the participating 

universities and members of the Aerospace Business Roundtable 

attended the CDR. The Roundtable provided further 

mentorship and assistance to the students and monitored the 

NASA–university collaboration. In addition, an Education 

Outreach Program was developing an interactive Web site to 

involve students from kindergarten to college across the globe 

in the program. Tom, my supervisor, accompanied me, and we 

sat next to a group of local newspaper reporters. I was starting 

to get a headache. 

When my group presented, their chart showed a box 

diagram depicting a video camera, digital camera, controls, 

and global positioning system with a magical line connected 

to an unnamed box and then to a balloon antenna. On the 

ground, the chart showed a receiving antenna connected by 

more magical lines to two unnamed boxes connected to a 

monitor, network, and receiving computer. Well, I knew they 

were inexperienced. Afterward, my supervisor said to me, 

UNIVERSITIES PROVIDE IMPORTANT BASIC RESEARCH AND INNOVATIVE IDEAS THAT CAN 

BE DEVELOPED INTO CUTTING-EDGE TECHNOLOGIES FOR NASA. THEY ARE ALSO OUR 

MAIN SOURCE FOR FUTURE SCIENTISTS, ENGINEERS, TECHNICIANS, AND MANAGERS.

46 | ASK MAGAZINE
KEVIN VIPAVETZ is a systems engineer and the Center Spectrum 

Manager at Langley Research Center. During the last twentythree years, he has managed and provided engineering expertise 

for numerous instruments and subsystems in aeronautics, 

atmospheric science, the International Space Station, and the 

Space Shuttle.

“Looks like you have a lot of work to do, but I’m sure that you 

can take care of it.” 

Since everyone was there, I asked for a copy of the 

presentation and contact information for the faculty members 

in charge of the students, and I scheduled a meeting with 

the program manager. Then I asked for a copy of the system 

requirements. There were no requirement documents. I 

assigned one of the students to collect what he thought the 

requirements were and send them to me. 

Getting It Done

When I got back to Langley, I immediately set up a schedule 

and several meetings. The next day I received a fax with a page 

of goals on the mission; these were the students’ requirements. 

I could see this was going to take some major work. I began 

putting together several requirement documents by using the 

students’ CDR presentation and contacting the university 

professors, who were very helpful, to develop the rationales and 

understand the objectives of the mission. This process played 

a big role in my seeing what needed to be done to achieve the 

project’s goals, and it set me on a path to understand industry 

best practices in this area.

The students did good work on a quick turnaround. They 

provided the hardware structure that held all the communication 

components for the gondola design, the electronics, command 

and control interfaces, cameras and video, global positioning 

system integration, and power distribution. They determined 

how the telemetry data would be acquired and transmitted and 

developed a simulation system to test the hardware and software. 

Once we had all the pieces, I wrote up a ground operations 

checklist and coordinated with our ground station at Wallops. 

With a strong process in place, our team moved rapidly 

to meet our development goals. Over the next several months, 

the telemetry subsystem took shape and our spirits rose. By 

June the subsystem had completed its tests and was integrated 

with the rest of the payload. The payload passed environmental 

testing. We were ready to go. We were also ahead of schedule.

A Funny Thing About Seniors 

For a month and a half we were on standby until the weather 

was right for the launch. About mid-August, we got the go 

ahead. Our team needed to be operating by 5:00 a.m. the next 

morning. I got in early and set up the ground telemetry with the 

Langley Mission Control Room operators. I could see from the 

Web site that we were getting visits from as far away as Australia; 

the project was generating a lot of interest. It was getting close to 

launch time, but none of the students had arrived. Time passed. 

Launch time was only a few minutes away. I called Wallops 

Mission Control and notified them that the students were not 

here. They asked if I could set up their computer at Langley, 

and it was then that I realized two things: one, I had incorrectly 

assumed that the students had procedures for operating the 

ground data processing computer (there were no computer 

procedures in the control room, and no one had the password 

to get computer access) and two, launching in the summer time 

may not have been a good idea. The seniors had graduated and 

moved on, and I had no way of getting data from the computer. 

I sat quietly over the next several hours and watched the 

flight on the video screen. The balloon soared to around 90,000 

feet. It followed a vertical circular pattern, first going over 

the Atlantic Ocean then coming back to Wallops. When the 

balloon was in the right flight position, the payload separated 

and parachuted down. I watched the payload descend until it 

went behind the horizon. Then I heard quite a bit of buzz on 

the intercom. A vehicle had hit the payload as it crossed over 

a road. Despite these difficulties, the instruments worked and 

the data was recovered. 

This was not the easiest or most satisfying project I’ve ever 

worked on, but I think the students learned from their handson experience and gained some sense of what work like this 

requires. And I learned some important lessons: never assume; 

communicate early and often; and make sure your operation 

documents are complete so someone can fill in for an absent 

team member and you preserve project knowledge. ●

ASK MAGAZINE | 47
Knowledge in Brief

Documents or Dialogue?

Early knowledge management projects usually focused either 

on collecting and sharing documents or connecting people. As 

these examples suggest, neither of those strategies is always the 

right one—the choice should depend partly on what you are 

trying to communicate. And sometimes combining collection 

and connection enhances the value of both approaches.

British Petroleum: Access to Experts

British Petroleum’s Virtual Teamwork program, developed in 

the mid-nineties, used videoconferencing and shared computer 

applications to connect engineers responsible for developing 

and maintaining drilling projects. In some cases, off-site experts 

who could talk to and see their on-site colleagues (and be shown 

a diagram or a faulty part) helped fix problems that stumped 

less experienced engineers and were too complex or unusual for 

“textbook” solutions.

BP’s Peer Assist program, which encourages teams about to 

embark on a new project to invite people who have done similar 

work to meet and talk with them, is based on the same belief 

that bringing people together communicates richer and subtler 

understanding than documents and databases ever can. It’s a 

way to acquire know-how, not just information.

Recently, though, the company has begun to give attention 

to documenting some of what its engineers have learned from 

experience in an effort to lengthen corporate “memory” and 

capture some of what soon-to-retire employees know.

Partners HealthCare’s Decision-Support System

Partners HealthCare, a group of hospitals and other health care 

facilities in the Boston area, has been developing a system that 

captures and combines patient histories and the latest information 

on treatments, drug uses, and interactions. When physicians use 

the system to write prescriptions or order tests, it alerts them to 

potential problems and recommended treatments.

The creators of the system say that it is not meant to replace 

the diagnostic skills or judgments of experienced doctors. It does 

draw from the vast and growing stock of medical information 

to give doctors what they need at the moment. And it reminds 

them of some of the basics of “apple pie” medicine—the standard 

procedures that all doctors know but sometimes forget to apply.

Collect and Connect at McKinsey and MITRE

McKinsey, the highly respected consulting company, and 

MITRE Corporation have both invested in online systems 

that combine document collection with sophisticated expertise 

locators that help people connect with colleagues who have 

knowledge they need. Unlike so-called self-reporting expertise 

locators, which depend on people’s own descriptions of their 

skills, the McKinsey and MITRE locators use time spent on 

projects and documents submitted to determine who knows 

what about a given subject. This approach seems to give more 

useful and current results than self-reporting systems.

Users have described the benefits of having easy access to 

both documents and people. In some cases, a call to the expert 

helps explain and expand on information in a document. 

Sometimes studying a document before calling the author makes 

it possible to ask smarter, more productive questions when that 

person-to-person connection is made. ●

48 | ASK MAGAZINE
ASK Bookshelf

Inside NASA: High Technology and Organizational 

Change in the U.S. Space Program, by Howard E. 

McCurdy (Baltimore: The Johns Hopkins University 

Press, 1993)

Howard McCurdy’s Inside NASA describes how and why 

NASA’s strong technical culture changed as the Agency 

grew older. The agencies brought together to form NASA 

were proponents of outsanding technical capability, which 

allowed innovation to flourish. According to McCurdy, some 

of the cultural beliefs NASA began with and lost or lessened 

along the way include in-house technical capability, the 

importance of hands-on work, and the ability to attract an 

exceptional workforce. 

In its early years, NASA recognized that risk and failure 

were inherent in its ambitious projects and goals. The early 

culture sought situations where failure could occur and worked 

to solve problems through the sharing of ideas and viewpoints. 

By normalizing risk, accepting failure, and anticipating 

trouble, NASA created an atmosphere in which these things 

could be discussed openly. Handling risk required open 

discussions in which midlevel managers and engineers could 

voice warnings and dissent without restraint. This openness 

was crucial for success. 

McCurdy argues that much of NASA’s strong technical 

culture was lost during the budget scale-back that occurred after 

reaching the moon. The Agency let trade, craft, and technical 

support employees go and wrote contracts for the same services as 

a way of adjusting to descending personnel ceilings. Relying on 

contracting diminished the importance of in-house personnel, 

reduced the opportunity for hands-on work, and turned NASA 

scientists and engineers into contract administrators. According 

to McCurdy, no single factor affected NASA’s technical culture 

more than the increased use of contractors. 

McCurdy explains that cultures consist—at a minimum—

of practices, beliefs, and assumptions. “Practices in NASA 

changed considerably,” he writes. “Beliefs changed some. 

Assumptions changed hardly at all. The overall culture changed 

in the sense that the remaining beliefs and assumptions lost 

their power to elicit appropriate practices.”

Space Race: The Epic Battle Between America 

and the Soviet Union for Dominion of Space, by 

Deborah Cadbury (New York: HarperCollins, 2006)

To tell the story of the Cold War competition between the United 

States and USSR for space flight achievement that culminated 

in Neil Armstrong’s “small step” onto the surface of the moon, 

Deborah Cadbury focuses on two figures: Wernher von Braun 

and Sergei Korolev, the chief Soviet rocket designer. Shifting 

back and forth between them, she dramatizes their efforts to 

win support for their similar visions of space exploration and the 

technical, political, and personal challenges they wrestled with 

in pursuit of their goal.

This is not the book to go to for a clear and careful analysis 

of the technology of Vostok or Apollo. Rocket science is not 

Cadbury’s strong suit. There are technical errors in the book 

and sentences that read like faulty transcriptions of technical 

explanations the author didn’t quite understand.

But there are good reasons to read this book. Foremost 

among them is how vividly it portrays the factors other than 

technology that influenced and eventually decided the space race. 

American and Soviet engineers accomplished great things, but 

the technological challenges they overcame were in some ways 

easier to deal with than the political pressures, organizational 

difficulties, and institutional and personal rivalries that 

sometimes threatened the programs. Cadbury shows just how 

complex and complexly human the space race was. And she 

doesn’t shy away from the moral implications of von Braun’s 

work in Nazi Germany and the intertwining of the noble goal 

of space exploration and the desire for military supremacy. But 

the book’s novelistic evocation of the first manned flights and 

the lunar landing remind us just how thrilling those events were 

and how great an accomplishment it was to touch the moon. ●

From time to time, the editors will offer brief reviews of books they believe will especially interest 

ASK readers. Here are descriptions of two books, very different from one another, that we admire.

ASK MAGAZINE | 49
The Knowledge Notebook

Don’t Neglect Social Knowledge

BY LAURENCE PRUSAK

During the last decade or so, journalists and 

executives of many organizations have talked a lot 

about a set of related words that includes knowledge, 

expertise, talent, human capital, know-how, 

capabilities and capacities, skills, and intelligence. 

I’m sure readers of this column have heard some 

of that talk. This focus on terms associated with 

knowledge is not particularly surprising. In the 

past few years, organizations in the United States 

spent as much on knowledge and knowledgesupporting tools and activities as they do on capital 

goods. This is a first for an advanced industrial (or 

what used to be an industrial) nation. Although 

the event wasn’t much noted in the popular press, 

it is a significant milestone on the road to a twentyfirst century knowledge-based economy.

So those words are undoubtedly important, but 

there is no real consensus about what we mean by 

them and, even more disturbing, I don’t think leaders 

of organizations have a precise idea of why they spend 

so much time and money hunting for employees with 

the elusive qualities those words represent. 

Well, one answer is obvious. You just can’t 

do some tasks, and especially complex projectlike tasks, without people who have the expertise 

needed to do them—and by “expertise” I mean 

know-how based on experience, not just technical 

information available in books and manuals. 

This kind of know-how accounts for much of the 

efficiency in project work, since it relies on “rules 

of thumb” (or, to use a fancier word, heuristics) 

developed over time that make it possible to make 

good decisions and choices quickly and avoid 

pitfalls that experience teaches people to expect 

and recognize. The undeniable importance of this 

kind of expertise is one reason organizations spend 

so much on what, for lack of a better word, we can 

call “knowledge.”

And yet, all this scurrying about after 

knowledge and intelligence misses something 

important. Is an organization’s value and 

effectiveness merely a function of its brainpower 

and its expertise at particular tasks, even in an 

economy that works more and more with ideas 

and less and less with things? Would you want 

to invest all your savings in a company that was 

a pure meritocracy of skill? I suspect many of you 

would answer no, possibly without being especially 

clear on why you feel that way. But you’d be right. 

Winning the war for talent is no guarantee at all 

that an organization will thrive, if talent is defined 

too narrowly as technical skill and knowledge. In 

fact, you might want to bet against it.

What these equations of individual expertise 

with effectiveness leave out is the simple fact that 

knowledge, however we define it, is profoundly 

social, both in its origins and in its use. It is not 

a stand-alone entity—a Spock-like brain ready to 

give brilliant answers to any question or implant all 

its knowledge in someone else by way of a Vulcan 

mind meld. Terms like “human capital” suggest 

that the value of knowledge resides in individual 

brains but, in real life, knowledge needs just as 

much coordination as logistics or manufacturing. 

How does this coordination happen? Not 

necessarily through leadership (though that isn’t a 

bad thing) but thanks to the social skills of people 

who help generate, develop, translate, encourage, 

transfer, and distribute knowledge throughout an 

organization. Being smart is important, but so are 

different mental skills like empathy, articulateness, 

imagination, cooperativeness, and patience. I’m 

50 | ASK MAGAZINE
not saying that people with those qualities aren’t very bright; 

often they are. But those social skills are different from what 

we usually think of as knowledge. Without them, though, 

knowledge is unlikely to thrive or be put to productive use 

in complex organizations or in teams working on challenging 

projects. I have heard people at NASA say that they know 

within the first week or two whether their project will succeed. 

Almost always, that judgment has to do with whether the team 

has the right mix of social skills, not whether it has the requisite 

technical knowledge.

Many of the articles in ASK illustrate the importance of 

social knowledge to project work—in fact, to any situation where 

two or more people work together toward a common goal. Social 

knowledge tells people how to earn and build trust, encourage 

cooperation, inspire commitment, communicate openly and 

clearly, and deal creatively with conflict and disappointment. It 

creates the conditions that make it possible for groups to pool 

their technical knowledge to solve problems together.

I know of organizations that refused to hire very skilled 

individuals, people renowned in their fields of expertise, because 

they were solo acts, operating in isolation. While they might 

accomplish some demanding tasks, employing them would be 

sending a destructive message to other employees: “We don’t care 

about social values or cooperation—only individual talent.” In 

the long run (and probably sooner rather than later), this would 

be a disaster for collaboration and overall success.

The sort of employees that knowledge-intensive organizations 

should hire need to balance expert knowledge and high social 

skills that support knowledge coordination. In fact, it’s possible 

that knowledge about knowledge and about how people share 

and use knowledge will prove to be the resource organizations 

will need most in our ever more complex world. ●

YOU JUST CAN’T DO SOME TASKS, AND 

ESPECIALLY COMPLEX PROJECT-LIKE 

TASKS, WITHOUT PEOPLE WHO HAVE 

THE EXPERTISE NEEDED TO DO THEM—

AND BY “EXPERTISE” I MEAN KNOWHOW BASED ON EXPERIENCE, NOT JUST 

TECHNICAL INFORMATION AVAILABLE IN 

BOOKS AND MANUALS.

ASK MAGAZINE | 51
ASKinteractive

For More on Our Stories

Additional information pertaining to articles featured in 

this issue can be found by visiting the following Web sites:

Gravity Probe B

http://www.gravityprobeb.com/

Gravity Probe B: A Management Study 

http://web.mit.edu/ncalder/www/GPB_Final.pdf

Solar Dynamics Observatory 

http://sdo.gsfc.nasa.gov/

We welcome your comments on what you’ve read in this issue of ASK and your suggestions for articles you 

would like to see in future issues. Share your thoughts with us at ASKmagazine@asrcms.com.

Web of Knowledge

Listen to best practices in project/program management 

and engineering from the practitioners themselves. Watch 

videos of the best of the best from this year’s Masters 

Forum 12 online at http://appel.nasa.gov/node/424 and 

search among the 305 video nuggets from Process Based 

Mission Assurance within the Office of Safety and Mission 

Assurance at http://pbma.hq.nasa.gov/videolibrary_main. 

Find specific video clips by speaker, text within the title, 

text within the video transcript, by framework sections, 

or any combination of these search parameters.

NASA in the News

NASA’s PM Challenge 2007, the Agency’s fourth annual project management conference, will be 

held February 6–7, 2007, in Galveston, Texas, near the Johnson Space Center. This year’s theme is 

“Knowledge Sharing.” As a mission-driven organization, NASA continuously strives for improvement 

in program and project management. By sharing knowledge, project teams enhance the likelihood 

of mission success with more effective, efficient, and innovative ways to manage programs and 

projects. PM Challenge 2006 included nearly 1,000 attendees and more than 100 speakers. The 

2007 conference will feature twelve tracks, including Spotlight on Systems Engineering, Mission 

Success Stories, Risky Business, Knowledge Works, and much more!

For more information, including the “Call for Speakers,” visit http://pmchallenge.gsfc.nasa.gov. 

To be placed on the distribution list, contact Niloo Naderi at niloofar.naderi.1@gsfc.nasa.gov. 

To read more about the 2006 conference and its outstanding rating, view PM Perspectives

magazine online: http://pmperspectives.gsfc.nasa.gov.

feedback

52 | ASK MAGAZINE

National Aeronautics and Space Administration

NASA Headquarters

300 E Street SW

Washington, DC 20546

www.nasa.gov

NP-2006-07-438-HQ