appl.nasa.gov

Academy Sharing Knowledge

The NASA source for project management

INTERVIEW

Al Diaz

Inside

RESCUING TROUBLED PROJECTS 

RETHINKING COMMUNICATION

HOW TO RECOGNIZE A MASTER PM 

CAIB REPORT REFLECTIONS

ASK Magazine • Issue Eighteen

JUNE 2004
Project managers work in the margins all the time. They are always

working on budgeting what is left. They have a plan. The plan 

has reserves. The conduct of the project is, in essence, the 

management of the depletion of those reserves, so that every

available resource is used to the maximum extent possible. — Al Diaz, from his ASK interview (p. 30)
appl.nasa.gov

Table of Contents

ASK 18 June 2004

STORIES

6 A New Spin

My message to the team was, “This is a good mission. Don’t look down. Together, we’ll find 

a way out of this” BY JOHN CASANI 

10 Fixing What’s Broken

If I hadn’t wondered if the project was in some way cursed, this latest string of problems 

was enough to make me consider the possibility BY FRANK SNOW

14 A Stormy Situation 

When we resumed testing, another instrument showed damage. Now we were both 

confused and in trouble BY LARRY GOSHORN

17 Getting the Cows on Their Feet

Despite our best efforts, we weren’t getting anywhere at all. If anything, we were 

going backwards BY MAJOR NORMAN PATNODE

FEATURES

20 Tell Me about Your Lemonade Stand 

As I looked back over the last five years, it was clear that some of our program managers

consistently generated great results and others did not BY SCOTT TIBBITTS

22 Hanging On by a Thread

To move the aircraft about on the ground, as well as to stabilize it during take off and landing,

we needed to come up with a lightweight solution BY RAY MORGAN 

SPECIAL FEATURE: THE POWER OF STORY 

24 Dressing Up the Naked Truth 

Story is one of the most respectful ways to share knowledge and, thus, one of the most effective

because it allows people to come to their own conclusions BY ANNETTE SIMMONS 

PRACTICES

26 Engineering Memos

Many believe, including me, that the advent of email and PowerPoint has, in some respects,

eroded our culture of engineering communication BY JOHN CASANI

INTERVIEW

30 ASK Talks with Al Diaz 

Goddard Space Flight Center Director Al Diaz talks candidly about what the CAIB report 

will mean for project managers across the agency 

IN THIS ISSUE • 3

ASK Magazine 

Experiences Change

BY DENISE LEE

REVIEW BOARD • 4

FROM THE DIRECTOR’S DESK • 5

High-Performance Projects

and the “Culture Thing”

BY DR. EDWARD HOFFMAN

LETTER FROM THE 

EDITOR-IN-CHIEF • 40

Looking Ahead with

Anticipation

BY DR. ALEXANDER LAUFER

ON THE COVER Preparing the 

spacecraft Galileo for flight, 1989.
2 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

WELCOME TO THE ACADEMY OF PROGRAM AND PROJECT

Leadership (APPL) and ASK Magazine. APPL helps

NASA managers and project teams accomplish today’s

missions and meet tomorrow’s challenges by providing

performance enhancement services and tools, supporting

career development programs, sponsoring knowledge

sharing events and publications, and creating opportunities for project management collaboration with universities, professional associations, industry partners, and

other government agencies.

ASK Magazine grew out of APPL’s Knowledge

Sharing Initiative. The stories that appear in ASK are

written by the “best of the best” project managers,

primarily from NASA, but also from other government

agencies and industry. These stories contain knowledge

and wisdom that are transferable across projects. Who

better than a project manager to help another project

manager address a critical issue on a project? Big projects,

small projects—they’re all here in ASK.

Please direct all inquiries about ASK Magazine editorial

policy to EduTech Ltd., 8455 Colesville Road, Suite 930,

Silver Spring, MD 20910, (301) 585-1030; or email to

editors@edutechltd.com.

APPL DIRECTOR AND PUBLISHER 

Dr. Edward Hoffman 

ehoffman@hq.nasa.gov 

EDITOR-IN-CHIEF

Dr. Alexander Laufer 

allaufer@eng.umd.edu

PROJECT MANAGER: KNOWLEDGE SHARING

Denise Lee

dlee@edutechltd.com 

KNOWLEDGE SHARING MANAGER

Therese Salmon

tsalmon@edutechltd.com 

CONTRIBUTING WRITERS

W. Scott Cameron 

Terry Little 

Ray Morgan

Scott Tibbitts

EDITORIAL ASSISTANT

Michael Derocher

mderocher@edutechltd.com 

DESIGN

Hirshorn Zuckerman Design Group, Inc.

www.hzdg.com 

SENIOR PRINTING SPECIALIST

Jeffrey McLean

jmclean@hq.nasa.gov 

PRINTING

Fontana Lithograph, Inc.

STAFF

ASK ONLINE

http://appl.nasa.gov/ask
THE FIRST ISSUE OF ASK MAGAZINE WAS RELEASED IN

January 2001, the brainchild of Dr. Edward Hoffman

and Dr. Alexander Laufer. I came to work on this project

in May of 2001, and at that time the Knowledge Sharing

Initiative at APPL was a ‘start up’. As with any ‘start up’

the hope within the new team was that we would be

successful, but the question loomed large: What did

success look like? Dr. Edward Hoffman, the APPL

Director, wrote in the first issue of ASK, “ASK will

provide a format that is easy, accessible and open. The

stories and columns that appear in this bi-monthly

magazine will offer simple yet powerful advice, lessons,

insights, humor and narratives that underscore what

makes NASA projects so meaningful—the competence

and passion of the people who work on them.”

We have come a long way since then. Success has

been glimpsed on many occasions. This success, as 

Dr. Hoffman pointed out, can be attributed to the

competence and the passion of our team, and of course

all of the wonderful storytellers over the years. The

Knowledge Sharing team, through their hard work and

dedication, elevated ASK from a ‘start up’ to the awardwinning publication that it is today. I would like to

express the sentiments of the entire APPL team by

commending the work that Todd Post and, more

recently, Jody Brady did in contributing to taking this

publication from obscurity to become a premier project

management publication. The APPL Knowledge

Sharing Initiative with its many tangible benefits and

ASK as its premier product, is now recognized across

NASA, the Federal Government, and the Private Sector

as an example of innovation in government. Todd had

been with ASK from the beginning and was instrumental

in crafting and shaping the magazine. As with any

innovative initiative, there were times when Todd had to

fight and scratch to gain ground and achieve the next

level of success. It was Todd’s unwavering dedication for

which we always remember him. The team and I wish

them all the best as Todd and Jody move on to pursue

new opportunities.

In the next issue of ASK Magazine we will be introducing you to the new Editor, who will be working with

the Editor in Chief, Dr. Alexander Laufer, to launch ASK

to the next level of success. Until then, I will be Acting

Editor and can be contacted for any questions or

requests that you need addressed.

Your comments, as always, are appreciated on the

interviews, stories and columns shared in this issue of

ASK Magazine. •

ASK Magazine Experiences Change

The APPL Knowledge Sharing Initiative with its many tangible benefits and ASK

as its premier product, is now recognized across NASA, the Federal Government,

and the Private Sector as an example of innovation in government

IN THIS ISSUE Denise Lee

ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 3
4 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

REVIEW BOARD

JOHN BRUNSON of the Marshall Space Flight Center is a

member of the NASA Program Management

Council Working Group. He served as project

manager for three separate microgravity

payloads that flew on various Spacelab

missions. His career in the space industry began

in 1980 as a technician working on the first Space Shuttle.

DR. MICHELLE COLLINS works in the Spaceport Engineering &

Technology Research Group at Kennedy Space

Center. She has over 20 years experience in

aerospace spanning engineering, R&D, and

project management. She is on the the Florida

Institute of Technology Dept. of ChE Industrial

Advisory Board, the National Fire Protection Association's Technical

Committee for Halon Alternatives, and the United Nations

Environmental Programme Halon Technical Options Committee.

HECTOR DELGADO is Division Chief of Process Tools and

Techniques in the Safety, Health and

Independent Assessment Directorate at the

Kennedy Space Center. In 1995, he served as

Senior Technical Staff to the NASA Chief

Engineer at NASA Headquarters in Washington,

D.C. He has received many honors and awards including the

Exceptional Service Medal, Silver Snoopy Award, and various

achievement awards.

DR. OWEN GADEKEN is a Professor of Engineering Management

at the Defense Acquisition University where he

has taught Department of Defense program

and project managers for over twenty years. He

retired last year from the Air Force Reserve as a

Colonel and Senior Reservist at the Air Force

Office of Scientific Research. He is a frequent speaker at project

management conferences and symposia.

DR. MICHAEL HECHT has been with NASA since 1982 at the

Jet Propulsion Laboratory (JPL). He is instrument manager and lead investigator for the

MECA soil-analysis payload on the 2007

Phoenix mission to Mars, reprising a role he

played on the cancelled 2001 Mars Surveyor

Lander mission. In the course of his JPL career his has served

in line, program, and project management, and has participated

in research ranging from fundamental semiconductor physics

to martian geophysics.

JODY ZALL KUSEK is a Senior Evaluation Officer at the World

Bank. She is currently involved in supporting

the efforts of seven governments to move to a

focus of performance-based management. She

has spent many years in the area of public

sector reform, serving the Vice President of the

United States, the U.S. Secretary of the Interior, and the U.S.

Secretary of Energy in the areas of Strategic Planning and

Performance Management.

DONALD MARGOLIES retired from the Goddard Space Flight

Center in January 2004. He was Project Manager

for the Advanced Composition Explorer (ACE)

mission, launched in 1997 and still operating

successfully. He received the NASA Medal for

Outstanding Leadership for his work on ACE,

and a NASA Exceptional Service Medal for the Active

Magnetospheric Particle Tracer Explorers (AMPTE) mission.

DR. GERALD MULENBURG is the Manager of the Aeronautics

and Spaceflight Hardware Development

Division at the NASA Ames Research Center.

He has project management experience in

airborne, spaceflight, and ground research

projects with the Air Force, industry, and NASA.

He also served as Executive Director of the California Math

Science Task Force and as Assistant Director of the Lawrence

Hall of Science.

JOAN SALUTE is the Associate Director for projects in the

Information Sciences and Technology Directorate

at Ames Research Center. She has managed many

NASA projects including those involving flight

testing of thermal protection materials, commercial technology, commercial applications of

remote sensing, and remote sensing science projects. She has been

at Ames for twenty years, and was awarded the Sloan Fellowship to

attend Stanford Graduate School of Business.

HARVEY SCHABES is currently assigned to the Systems

Management Office at the Glenn Research

Center. He started his career with NASA in

icing research, and since then has served in

numerous organizations in support of the

Space Station Program.

CHARLIE STEGEMOELLER is Manager of the Johnson Space

Center (JSC) Human Space Life Sciences

Programs Office. He is responsible for the

programmatic and tactical implementation of

the lead center assignments for Space Medicine,

Biomedical Research and Countermeasures,

and Advanced Human Support Technology. He began his

career at NASA in 1985 with JSC Comptroller’s Office as a

technical program analyst.

HUGH WOODWARD is the President of Macquarie Business

Concepts, a consulting firm specializing in

effective project portfolio management. Before

this position, he had a 25-year career with

Procter & Gamble. He served as the Chairman

of the Project Management Institute (PMI) for

consecutive terms in 2000 and 2001. He was elected to the Board

of Directors in 1996, and before being elected as the Chair, served

as vice chair and in several other key leadership roles.
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 5

THE OBVIOUS QUESTION, THEN, FOR EVERY PROJECT LEADER

is: What can you do to establish a culture of high

performance and value?

The starting point is to realize that the project leader

has the greatest impact on a project team’s culture.

Forget about everything else and every other excuse.

Successful project leaders find ways to design cultures of

high performance—cultures where quality and innovation exists side by side and where intrinsic motivation

and personal satisfaction go hand-in-hand.

Leadership shapes the communication, behavior,

rituals, stories, values, and day-to-day performance on a

project. It’s the attitude of the leader that engenders the

support of the team members. Projects which provide

meaningful work, autonomy, and performance feedback

stand out as the optimal cultures.

But what can you do to cultivate a high-performance culture? It doesn’t have to be as glib as, “You either

got it, kid, or you don’t.”

In support of NASA project teams, the Academy of

Program and Project Leadership (APPL) has sponsored

research that has generated a simple yet powerful organizing system for project leadership and culture. Through

APPL’s Performance Enhancement services, this system

provides project leaders the competencies to understand,

predict, and shape performance culture by focusing on four

dimensions: Directing/Organizing, Visioning/Inventing,

Valuing/Honoring, and Relating/Including.

Projects are assessed to formulate improvement

strategies, which may include APPL mentoring and

coaching services from some of the best project leaders

in the world. Some project managers choose to have

their teams participate in a three-day workshop designed

to help understand and improve project culture.

Assessments are repeated after about three months, and

results thus far reveal a statistically significant improvement in project culture.

The success of NASA comes down to the successful

performance of our programs and projects. The project

world is one of complexity, uncertainty, and everchanging variables. High-performance culture is

essential for success—and you, as the project leader, are

the greatest influence on your team’s culture. If you want

it, APPL has support available for you and your project

team. Let me know how I can help.

Dr. Hoffman can be reached at ehoffman@nasa.gov. •

Culture [is] a pattern of basic assumptions—invented, discovered, or developed by a given group 

as it learns to cope with its problems of external adaptation and internal integration—

that has worked well enough to be considered valid and, therefore, to be taught to new members 

as the correct way to perceive, think, and feel in relation to those problems.

— Edgar H. Schein, Organizational Culture and Leadership

High-Performance Projects and 

the “Culture Thing”

The research is in and what it tells us, repeatedly, is that good project cultures

lead to high performance and satisfaction, bad ones to failure and turnover

FROM THE DIRECTOR’S DESK Dr. Edward Hoffman
6 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

THE TROUBLE WAS THAT THE SHUTTLE WAS STILL UNDER WE ADJUST OUR PLANS

development when that schedule was set. As time went Separating the probe from the orbiter wasn’t the real

on, the Shuttle had problems with its high pressure challenge. We needed to do that as the spacecraft

turbines, thermal protection tiles, engines, and more. approached Jupiter, anyway. What we needed was a probe

The early launch dates had to be scrapped. NASA carrier, a spacecraft to service the probe on the way to

Headquarters told us, “We’re going to delay your Jupiter. This required an entirely new development. We

launch two years to allow more time for the Shuttle could do that, if necessary, but I worried that we couldn’t

development to take place. You can slow your develop- get the design completed in time and within our budget.

ment accordingly.” When I told them this at Headquarters, they said, “Well,

Right off the bat, we looked into the celestial maybe you ought to cancel this mission.” I told them that

mechanics and how they would affect us. The difficulty we would find a way.

in launching a spacecraft to Jupiter changes on a year-to- We got every one lined up and working on the new

year basis, in a cyclical pattern that repeats about every development for more than a year—when someone said,

ten or twelve years. In order to achieve the velocity “If the Centaur [an upper stage used on the Titan] could

needed to get from low earth orbit to Jupiter, an upper be adapted for use on the Shuttle, then we could put

stage is required in the Shuttle. For the 1982 launch the these two spacecraft back together.” The Centaur upper

upper stage was adequate, but it could not provide the stage uses liquid hydrogen and liquid oxygen, which is

velocity we would need in 1984. This meant we would much more powerful than the Inertial Upper Stage (IUS)

have to separate the Galileo probe from the Galileo orbiter that we were going to use. So, we started working that

before launch and put each of them on separate Shuttles idea through. Some people didn’t think it would work,

with separate upper stages. some thought it would take too long, and we all worried

When we told the folks at Headquarters this, they about the cost of the thing—but we kept working the

told us, “Okay we’ll give you two Shuttle launches.” problem as we explored all our options.

Getting to Jupiter would be no easy matter, even in the best of conditions—so when we

set our schedule, we aimed at having our Galileo spacecraft ready in time to take

advantage of a window of opportunity in early 1982, when celestial conditions would

favor our mission. We were assigned a berth on the 25th Shuttle mission, scheduled for

February of ’82—the first time the Shuttle would be used for a planetary mission. 
Finally, in early 1986 we were set to launch a large

liquid oxygen/liquid hydrogen upper stage in a rocket

inside the Shuttle with our spacecraft on top of it. We

put everything together, and brought our spacecraft to

Kennedy Space Center for the launch. Then came the

Challenger accident. The Shuttle was grounded.

On top of that, upper management came back to us

and said that we had to be more conservative when we got

back to flight. “We’ve decided that the Centaur upper

stage is too risky; you can’t use it. You can use the IUS,”

they told me. But it was the same story as in 1984: The old

one wouldn’t get us there unless we split Galileo apart.

By this time we already had the spacecraft built—so

splitting it apart was out of the question. Those were the

darkest days for me on this project, but I never gave up hope.

SELLING THE PROJECT

I knew my team would eventually find a way to get

Galileo launched, and I knew what the spacecraft could

deliver—but it wasn’t an easy sell. When I went in front

of senior NASA management, I made an opportunity

cost argument to them. I pointed out that for the

increment of funding we still needed, they could, in

essence, buy an entire mission. The sunk cost didn’t

count because they couldn’t recover that—it was water

under the bridge. So, what was the opportunity cost of

that additional increment that we would need to finish?

Could they buy something of more value for that same

amount of money? 

We were in the middle of the Cold War then, so I

also used the argument that what we were doing would

make a powerful statement to the Soviets. “We’re going

to go to Jupiter, 500 million miles away, and we can

deliver the spacecraft with an accuracy of plus or minus

fifteen miles. That speaks volumes of our capabilities.” I

also told them that we would get data back at higher

rates than previously thought possible. In all, we could

demonstrate an enormous engineering capability to the

rest of the world in a non-threatening way. For if we

could send something like this to Jupiter, think of what

we could do on Earth.

I described how compelling the mission was in

terms of the science return we could expect. I reminded

them that we knew without a doubt that that our target

was rich because Voyager had told us that. We knew that

we had the capability to go into orbit around Jupiter and

stay there for several years and do multiple flybys, close

flybys—the equivalent of ten or more Voyager missions.

There was the opportunity cost again, you see? You

could do with this one spacecraft what it would have

taken ten, or even twenty Voyagers.

I spoke to people on Capitol Hill to relay this

message. The project manager doesn’t do that anymore;

Headquarters does. But even at the time, I got to do

things not usually done because a lot of people had

written our project off. The people on the Hill listened.

In the end, they supported us, and gave us the money to

keep going.

ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 7

Preparing the spacecraft Galileo for flight.
AND WE REGROUP

Galileo was built; we just needed to find a way to get it to

Jupiter. I engaged everyone in the project to think this

thing through. I asked them, “What are other ways to

approach this launch?”

First, we looked at using a Russian launch vehicle

that might be capable of launching our spacecraft.

Though relationships with Russia still weren’t all that

great at that point, we talked to them and found out

what it would take. They were willing to discuss the idea

further with us, but we decided it was too marginal. We

took a look at doing enhancements to other launch

vehicles, but saw that wouldn’t work, either.

People tried to tell me again that this mission was

never going to happen. I never accepted that. I just kept

my team going. People said to me, “Okay that’s it.” I just

shook my head. They said, “How do you know that’s not

it? You haven’t found a solution.” All I told them was,

“Well, we haven’t concluded that there isn’t a solution.”

In order to design our original mission we had

developed the mathematics and trajectory design tools

to do multiple flybys of Jupiter’s moons. So when we

found ourselves without a launch vehicle, we decided to

put that technology to use and see if we could apply it to

solving the problem of getting to Jupiter. My people

sketched out all sorts of approaches to the problem.

Nothing was working.

Still, I kept them focused on the excitement of the

science we hoped to return, and kept them working on

the problem. My message to them was, “This is a good

mission. Keep your eye on the ball. Don’t look down.

Look up. Together, we’ll find a way out of this.” I had to

keep doing that not only with our people here, but with

Congress and with the people at Headquarters.

Then—I’ll never forget the day—I was sitting in my

office one morning when an engineer walked into my

office. He said, “You probably won’t go for this, but I

think I found a way to get to Jupiter.”

He went up to the white board and sketched out a

trajectory. He said, “Here is what we can do. Instead of

going out this way to Jupiter, we’ll start off going to

Venus. We’ll do a gravity assist at Venus to add a bit of

velocity. We’ll come back to the Earth and pick up more

velocity. We’ll go out past the asteroids and then we’ll

come back to the Earth a second time and then back to

the asteroid belt. It will take four years, but we’ll be ready

to go to Jupiter.”

I looked at this guy for a moment, thinking about

the implications. Before I could say anything he said,

“Well, I didn’t think you would like it.”

“Are you kidding?” I asked. “I love it. Let’s do it.”

He said he was worried about the changes we would

need to make the spacecraft capable of handling the

increased thermal environment near Venus and of

handling the new telecommunication geometry that

would be required. “We’ll take care of that part,” I said.

“You just go figure out this trajectory.” He and a couple

of other guys went off and did a more complete analysis

and design.

We would add about four years to the flight with the

time spent around Venus and the two passes by Earth.

Instead of getting to Jupiter in the two years and nine

months we had planned on, it would take about six

years. We had used trajectories before to gain velocity on

space missions, but we had never attempted a “triple”

like this one. It would mean trading trip time for launch

energy, and that had clear disadvantages. But it looked as

though we would only have to make moderate adjustments to our spacecraft design.

That was good enough for me. We would use the

trajectory to get to Jupiter.

8 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 9

Originally called the Jupiter Orbiter Probe,

e Galileo mission described in this story

und evidence that Jupiter’s icy moons

uropa, Ganymede, and Callisto) appear

ife: water, energy

ssion to study the

JOHN CASANI?

evelop the Jupiter

mbitious proposed

the Jovian system

or later. 

th

fo

(E

to have the necessary ingredients for l

and the right chemical content. 

So, who better to kick off a return mi

moons than Galileo project manager

Currently, Casani heads up work to d

Icy Moons Orbiter (JIMO) project, an a

mission that would return an orbiter to 

some eight years after launch in 2011 

Casani began working at the Jet Propulsion Laboratory in

1956. In the 1960s he was spacecraft design leader and

system manager for the Mariner spacecraft that flew to

Venus, Mars, and Mercury. He went on to serve as project

manager on the Voyager, Galileo, and Cassini missions,

and as JPL’s first Chief Engineer, among other positions.

Honors for his work include NASA’s Distinguished

Service, Outstanding Leadership, and Exceptional

Achievement medals. 

Following his 1999 retirement, Casani served on several

JPL review and advisory boards, including heading up

the Mars Polar Lander failure investigation board. But

retirement didn’t stick. Casani returned to the JPL project

management ranks in 2000.

A NEW PHASE

I had been on the project for ten years, three months,

and two days, when my boss was promoted and they

offered me his job overseeing all the flight projects at the

Jet Propulsion Laboratory. It was hard to leave the

project at that point, but I did get to stay involved and

see it launched in 1989—even though I was no longer

the project manager.

I watched with pride as our mission flew the trajectory, delivering valuable science data for Venus, the

Earth and moon, and the asteroid belt. Finally, Galileo

headed for its rendezvous with Jupiter and its moons—

and arrived in December 1995. Its eight years and 35

orbits around Jupiter turned out to be everything we

hoped it would be. Tenacity certainly has its rewards.

We put Galileo to sleep last year. A lot of people were

sorry to see it go. You know, I didn’t think of it that way.

It was out of fuel, and there was nothing much more we

could do with it. It was going to die one way or another.

We decided to send it on a collision course with Jupiter,

sending us back data from the planet’s magnetic field as

it went. We threw a farewell party on Galileo’s last day

and we celebrated its success.

Galileo gave us more science than we could have

hoped for. T.S. Eliot once speculated that the world

would end “not with a bang but a whimper.” Well, we

decided that Galileo deserved to go out with a bang. •

LESSONS

• A project team takes its lead from the project manager.

When managers make clear their own commitment to

and belief in their projects, they empower their teams to

overcome problems that crop up.

• An important part of any project manager’s job is 

to “sell” a project—not just to get the project off the

ground but to keep the project alive when surmountable

obstacles arise. That “selling” may require creative

thinking to frame the project in a way that makes its

value more apparent to project sponsors.

QUESTION

Under what circumstances might a project manager decide that

a project should no longer be “sold”?
10 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

NEAR THE END OF THE DAY, IT WAS TIME FOR THE SIGN Once they got our spacecraft off the table, it was

burst test. For 200 milliseconds we would put a non- fairly obvious what had caused the problem: One of the

feedback force on our system, which meant we couldn’t support bearings on the vibration test bed had failed.

adjust or halt the test in process. Something went This caused an abnormally high level of static friction,

wrong, terribly wrong during the sign burst test. As which the computer read as mass. When it tried to

mission manager, I was standing just ten feet away from compensate by increasing vibration, it shook the spacethe spacecraft when this happened. It sounded like a craft ten times harder than we had planned.

clap of thunder. With the test stopped, we moved in If anyone knows Tom Gavin, Director of Flight

closer to see what had happened—and we knew Projects at JPL, they know that he likes to share a little

immediately that we had damaged our spacecraft. How piece of information with engineers during reviews: “If

much, we didn’t know. you have an anomaly, you’re going to meet a lot of

er

d

We

E

verything looked good as we started the first day of vibration tests on the High Energy Solar Spectrascopic Imag

(HESSI). We chose to do our environmental testing at the Jet Propulsion Laboratory (JPL) in California and, so, we ha

brought our spacecraft there from Spectrum Astro in Arizona.

planned to launch in July 2000. Heading into March that year we were on schedule, under budget, meeting all of o

performance requirements, and ready for the final testing. I remember feeling proud of what the development team, lead 

the University of California at Berkeley and its project manager, Peter Harvey, had accomplished in the last two-and-a-ha

years. We were in the homestretch—or so I thought.

ur

by

lf
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 11

important people.” Well, I started meeting a lot of

important people as soon as word spread about our

testing disaster.

Three days later, I stood in front of the Mishap

Board to open the investigation. The Mishap Board

concluded that two primary factors contributed to the

accident: the absence of a scheduled maintenance

program for the test equipment, and the lack of proper

test procedures.

I don’t think that I was alone in thinking about

Mishap Boards with trepidation. But I learned a lot of

valuable lessons from this one. JPL doesn’t run this

particular test very often, and we should have reviewed

their test procedures thoroughly before allowing our

spacecraft to undergo testing. Because this was a nonfeedback test, it should have been standard procedure to

run a mass simulation before running the test on our

spacecraft, and if we had been thinking straight, we

would have required that. (Now, I don’t care who tells

me something, I insist on seeing it verified.) In the end,

the Board concluded that my team was partially responsible for the accident, and I agreed with them.

PUTTING HESSI BACK TOGETHER AGAIN

I didn’t just accept responsibility for our mishap; I

accepted responsibility for getting the project back on

track. And if I was going to do that, I couldn’t wait for

someone to tell us what to do; we simply got to work. Our

standard support structure (a machined aluminum main

support ring) had broken in two places on each side; the

test snapped it. So, the structure had to be replaced. But

that was only the beginning of our problems.

Then there were the arrays. This was a solar mission

designed to explore the physics of solar flares, and we

wanted it up in July for the peak activity of the 11-year

solar cycle. If we couldn't get up in July, we wanted to get

up as soon as possible. Solar arrays normally require a

long lead time. How could we get new arrays in time?

Well, we got Goddard engineering involved. They found

some solar cells manufactured for the Iridium constellation, which was now bankrupt.

The next problem we faced was the instrument

boxes. We had done a vibration that nobody expected

these boxes to see. We went back to the vendors and

asked, “If we do an ATP [Acceptance Test Plan], will you

re-qualify?” They declined. “Buy another box” was their

response. So, I had to fall back on another organization,

the Quality Assurance Group, that I had previously seen

as little more than an obstacle standing between me and

my launch date. The Quality Assurance Group made me

an offer: If they could get involved in the Acceptance

Test Plan, they would accept the vibration and certify

our boxes. That’s what we did.

But our problems weren’t over. Though it didn’t

break during the vibration test, two months down the

road, our flight cryocooler failed. This was a commercial

product that we had flight qualified. We still had about

four or five of them, but we had to flight qualify at least

one of the remaining coolers. So, we put together a tiger

team to do another ATP and get it done as quickly as

possible—although it was already clear that we wouldn’t

make our launch date, that team worked miraculously,

as far as I was concerned, and eventually they brought

HESSI back to its original condition.

Of course, this is just the technical part handled by

the team. As the mission manager, the person responsible for overseeing all the project’s facets, I had to be off

doing other things—including

reviews. For months we had

operated under the maxim, “If

no one tells you to stop, just

keep going.” So, we had kept

working all along, but if we

were to complete our work

on HESSI, I needed to have

our Recovery Plan approved.

So, while all the technical

work was progressing, I

made our case in front of

several review panels.

After an independent

panel gave us their stamp 

of approval in May, the

Goddard Program Management

Council held a Reconfirmation Readiness Review in

June. An independent expert concluded that we

probably only stood a 60 percent chance of surviving

launch. When you take that to senior management, it’s

likely to be considered too high a risk. We had to

convince them that we understood the system better
12 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

than anyone else did. And you know what? They

accepted this risk; here again, was another organization

that I gained a new appreciation of.

After that, we had a NASA Reconfirmation Review

in August, led by Dr. Ed Weiler, then Associate

Administrator for Space Science. I

had to ask him for the money we

needed to get to launch. I gave a

presentation and when we got to

the slide that showed HESSI

before we started the repairs, he

told me it was a good thing he

hadn’t seen the slides back in

March. “I would have cancelled

you,” he said. But, in the end, he

approved our plan and gave us our

money for a February 2001 launch. All in all, I was

astonished by the level of support from almost everywhere I turned at NASA when I asked for help in recovering this project.

AND EVEN MORE ASTONISHING

A year after the mishap, we were ready. I remember giving

myself a mental pat on the back as I thought about how

well we were doing—all things considered. Then we ran

into another series of problems.

HESSI was scheduled to be air-launched by a

Pegasus rocket (dropped from the belly of an aircraft

flying 39,000 feet over the ocean). The Pegasus started

running into problems on other launches. Our launch

date was pushed back to June. When the time came, we

integrated our spacecraft with the Pegasus at

Vandenberg Air Force Base in California and then flew

across the country to the Kennedy Space Center. We

were just four days from launch when there was another

Pegasus failure—this one on a DoD mission. We were

put on hold.

We pulled out, went back to Vandenberg to wait it

out, and put HESSI in storage. But this time Mother

Nature decided to test us. A major rainstorm swept

through the area, and they had to call out troops to

sandbag our facility because the floods were rising. The

water kept rising—so, in the middle of the night, in the

middle of the flood, in the middle of the rainstorm, we

moved HESSI to another building across a swelling creek.

We got a launch date in February 2002. It took that

long to resolve the various problems with the Pegasus

and to get a new place in the launch queue. Finally, we

brought HESSI back to Kennedy Space Center. Of

course, with our luck, we came in the

middle of another rainstorm. We were

waved off the first time and couldn't

land. So we had to circle the landing

strip with lightening flashing around us

until, finally, we saw a gap in the

weather. We were ready to land.

Then we got a radio call from our

airstrip, “There’s an alligator out there

on the strip. You can’t land.”

At this point, none of us could be

astonished by much. We got someone

on the ground to go out and escort the alligator off the

skid strip. Finally, we landed—another crisis averted.

But then we had to wait for things to dry out,

because our ground system control had been hit by the

rainstorm. If I hadn’t wondered if HESSI was in

someway cursed, this was enough to make me consider

the possibility: Things began to dry up, but our ground

support equipment had been inundated with toads. We

had to go out there, of course, and get rid of all the toads

and put plastic strips around everything so the toads

wouldn't come back. We finally got to our launch date,

the fifth of February, and we were thinking, well, what’s

going to happen today?

COUNTDOWN

I’ll tell you what happened that day. As they say, it was

time to “open the book” four hours before launch. So,

we opened the book—and we were red. One of our

ground antennas had gone down. It was mandatory for

launch. We started working that problem, at the same

time we had to work a series of battery temperature

problems. We did all of this on the skid strip waiting to

get our launch off.

Finally, we got the antenna back and got waivers on

the battery. We got the plane up in the air. We were

within two minutes of our drop zone, when I heard the

launch manager give the abort command. Excessive

static on voice communication with the drop plane

caused the abort. After correcting the problem, we flew
around and headed back to the drop zone. We had only

one more opportunity.

If you’ve ever been involved in a situation like this,

you’re listening to four or five different channels at

once on your headset. You can hear everyone else

talking about any problems they see. I was listening to

all those voices as our plane was about four minutes

from drop, and I looked back down at my telemetry and

saw that the temperature on the battery had finally gone

down to the right spec. All of sudden everything went

quiet on the net.

All I could hear then was the launch countdown. It

went smooth. The Pegasus was dropped with HESSI

abroad, and in eleven minutes we were in orbit. The only

thing I could think at that point was that the gods must

have gotten tired of beating on us. They finally smiled on

the little spacecraft that would not give up.

It’s been more than two years now since launch,

and the scientists are extremely happy with their science.

While they’ve studied solar flares and even taken a look

at the Crab Nebula, I’ve had ample opportunity to reflect

back on our trials with HESSI.

What saved us, time and again? We refused to give

up. But besides tapping reservoirs of perseverance, I also

learned to tap what I now like to call a project’s hidden

resources. I learned to work with and get help from

organizations that I usually didn’t think of as

“resources.” I’m talking about Mishap and Failure

Review boards, program management councils, and the

like. Before HESSI, I tended to think of them as

mountains in the road. But when I was in a deep enough

hole with little margins to play with, I started to see them

in a different light. I asked for help, and I got it. •

LESSONS

• You can never say too much about the value of persistence in the face of adversity. All projects suffer setbacks.

Sometimes the difference between succeeding and failing

on a project is an inexhaustible supply of persistence.

• When confronted by problematic situations, a project

manager with the determination to succeed identifies

and makes use of all available resources. That may

include looking at governing organizations in a new light.

QUESTION

In a crisis situation such as the one described at here at the

beginning of the story, what would you say to a Mishap Board

or Failure Review Board to gain their confidence that you could

lead your team to overcome this setback?

FRANK SNOW has been a member until his death in April 2001. A pioneer in the fields of

of the NASA Explorer Program at solar physics, nuclear astrophysics, cosmic rays, and

Goddard Space Flight Center gamma-ray astronomy, Ramaty served as co-investisince 1992. He was the Ground gator and a founding member of the HESSI team.

Manger for the Advanced “He was a genius,” Snow remembers. “And, the truth

Composition Explorer (ACE), is, we wouldn’t be where we are today if it weren’t for

and mission manager for the Dr. Ramaty. He really believed in this project and he

Reuven Ramaty High Energy Solar Spectroscopic kept pushing and pushing to keep it alive.”

Explorer (RHESSI) and the Galaxy Explorer Now known as RHESSI, the mission continues

(GALEX). He began his career with NASA in 1980. to deliver solar flare data studied by scientists the

The HESSI project described here in Snow’s world over. RHESSI was the first space mission to

story was renamed after launch in honor of Dr. be named after a NASA scientist.

Reuven Ramaty, a Goddard Space Flight scientist

ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 13
14 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

BY LARRY GOSHORN
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 15

At ITT Aerospace, in Fort Wayne, Indiana, we build many different kinds of specialty payloads,

including some of the workhorse instruments on NASA and NOAA’s meteorological satellites.

These instruments provide many of the pictures that you see on the evening news and 

The Weather Channel. I like to think we’re not only in the aerospace business, but also in the

business of protecting lives and property. We take our responsibility seriously, and that means

sometimes we have to make tough decisions.

WE’VE GOT A VERY GOOD ON-ORBIT HISTORY WITH OUR

instruments. Like most folks in this business, however,

we’ve had occasional difficulties during production due

to various technical problems. Some years ago, we had a

problem like this on the Polar Orbiting Environmental

Satellite (POES) instrument program. In this case, our

schedules were slipping, threatening the prime spacecraft contractor’s schedule and putting us in a potential

cost overrun situation.

This program had been going on long enough that

key personnel from the teams at both NASA Goddard

and at our offices in Fort Wayne had changed many

times. For a while, we had an incompatible mix of

personalities, and there was a strained relationship

between the project teams. NASA’s confidence in us was

eroding, and that was showing in the award fees, which

were dropping. The business implications here for a

contractor are severe, because award fees can be the only

profit on certain types of contracts.

At the time, I was ITT’s Director of NASA

Programs and I knew that I needed to take action to

improve the situation. I decided to make certain

personnel changes in our program management office

to provide a more compatible mix. I also assigned

additional systems engineering expertise to our team. In

short order, the relationship and performance started

improving. Things were getting better. Then, the

backslide began when a $10M instrument was damaged

by electrical overstress during final acceptance testing.

Following the root cause investigation, we thought

we understood the problem, and implemented appropriate corrective action. But when we resumed testing,

another instrument showed damage. Now we were both

confused and in trouble. We had two instruments that

were damaged for reasons not understood, and we were

uncertain where the overstress had occurred in the

testing. Once again, our schedule was threatened.

The team faced internal pressures to hold schedule

because ITT was involved in a competition for a new

project. Past performance to schedule was a critical

element of the competition. Should we try to “limp

along” with instrument testing to make at least some

level of schedule progress in parallel with troubleshooting the problem—or should we take the more

radical approach and shut down all testing while we

investigated? What would ITT senior management

think if we shut ourselves down when they knew we

were already in schedule trouble? What would NASA

management think if we shut ourselves down? As the

Eagles put it in their song “Hotel California,” the

decision “could mean heaven or it could mean hell.”

What do you do?

The Skies Begin to Clear 

A decision of this magnitude would affect the entire

team so everyone’s voice was important in making this

decision. I assembled the project team, including technicians, engineers, scientists, and business management—

and we discussed the situation. We all agreed that we

needed to do the right thing, no matter what. The

decision, as you would suspect, was unanimous. We

would shut ourselves down while we investigated. We

could not put additional flight hardware at risk. While all

agreed it was the right thing to do, both NASA and ITT

Inspection of the POES, NOAA-M, Advanced Very High

Resolution Radiometer (AVHRR) instrument scan mirror.
16 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

management hoped that the problems would be found

and resolved quickly.

We worked many long days trying to understand

the causes of the problem using a cooperative team of

both ITT and NASA experts. What we found was not

just one, but up to three potential causes of electrical

overstress. Taking corrective action for one did not

correct the others. All of these issues were caused by

recent changes made in the test process. Misleading

symptoms compounded the problems. The initial

electrical overstress that we were subjecting the instruments to resulted in greater stresses and damage once

the instrument was powered on. The power supplies of

the instrument itself were causing damage due to the

first overstress, which was weakening the part.

The investigation showed that we had recently

“improved” our test labs to reduce the susceptibility to

voltage transients. In keeping with the adage that “one of

the biggest causes of problems is solutions,” we found

that there were potential grounding issues with the new

wiring. In addition, we found that a long interconnect

cable on a new piece of test equipment could generate

200 volts of static charge when moved if we did not have

an adequate bleed-off path. We also found that this

cabling was susceptible to cross-coupling any damaging

static charge on one wire to other wires in the cable,

potentially causing further stress. All of these issues were

factors in our damaged instruments.

After the first instrument was damaged, we stopped

the investigation when we found conclusive evidence of a

cause and corrected it. What we did not do was dig deeper

to investigate the possibilities of multiple causes and

eliminate them all. Following this last round of exhaustive

troubleshooting and repair activities, which took over two

months, the ITT team presented its findings to a NASA

review board explaining the issues, the findings, and the

corrective actions taken. Our final statement was, “We

now feel that it’s safe to resume testing.”

The board agreed with us, and testing was successfully resumed and has been fine ever since. We resumed

instrument deliveries and we were able to recover the

lost schedule in about ten months. Fortunately, we

escaped impacting the spacecraft-level test schedule.

A Forecast for Success

Because all of us, the government and the contractor,

were working together, we were able to take a synergistic

approach to problem solving, even in a pressured

environment, and to agree on what we were doing and

why. Perhaps one of the biggest lessons for the team was

that even some of the bleakest-looking situations can be

overcome when you combine the right level of leadership, teamwork, and persistence with a few tools from

your toolbox. It was not a comfortable decision to make,

but it was the right decision to shut ourselves down.

After this episode, our award fee started moving in

the right direction, and has returned to the excellent

range. The ITT and NASA/NOAA program teams

continue to work diligently together in producing some

of the best meteorological products in U.S. history.

LESSONS

• Leadership requires courage to make the right

decision, even if it is a painful decision.

• Involve the entire team when making critical decisions.

“Involvement” means open and honest communications

that include internal and external customers.

QUESTION

Would you have shut down the project after the first instrument was

damaged, the second one, or only after a third?

As a NASA contractor, LARRY GOSHORN successfully

managed a variety of payload projects, including the GOES

and POES meteorological satellite sensor programs. In 2003,

he retired as the Director of Space Programs at ITT

Aerospace/Communications in Ft. Wayne, Indiana—after

receiving the company’s highest recognitions,the Harold S. Geneen Award and

the Gold Ring of Quality. He was an aerospace program manager for 28 years. 

Goshorn’s story, “A Stormy Situation,” was originally presented at the 7th

APPL Masters Forum of Project Managers, held in Annapolis, Maryland in

August 2003. Many of the stories in ASK Magazine originate as Masters

Forum presentations, including the story by Frank Snow this issue, “Fixing

What’s Broken.” The Masters Forum is held twice a year, bringing together

some of NASA and the industry’s top project managers for three days of

knowledge sharing.

We featured a brief story by Goshorn in Issue 15 of ASK, about a teambuilding exercise involving an elephant, three managers, and a front page

story in the New York Times about a troubled NASA program. It was originally

told impromptu at another Master Forum, and has probably been retold by

the people who were there more times than they can count. (Find the story

online at appl.nasa.gov/ask/issues/15/stories/good_davis.html.)

“ “ The decision “could mean heaven or it could mean hell.”
ETE FRHEI T NOS WO CETH G NITTGE

ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 17

A WHILE BACK, I WAS WORKING ON A TEAM TO

reengineer the Air Force’s logistics process for all the

reparable items in the inventory, everything from engines

to oxygen regulators to electronic circuit cards. After

doing some analysis, some experimenting, and some

prototyping, we were ready to implement our changes. 

IN SIMPLE ENGLISH, WE WERE TRYING TO PUT A PROCESS IN

place where, like Wal-Mart, every customer purchase

provides the tug that causes a replacement to be shipped

overnight from the warehouse to fill the hole on the

shelf before the store opens the next morning. Then, in

response to the hole that’s just been created in the

warehouse, the depot either buys or repairs a unit and

quickly ships it to the warehouse. By implementing this

“Wal-Mart solution” we were sure we could make the

whole system respond quickly to the needs of the warfighters using the items. Although most people understand this process today, at the time it was revolutionary.

by Major Norman Patnode
18 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

My team and I started by explaining all the flaws in

the current procedures and processes, and what we

needed everyone to do differently to address these

problems. We laid it all out in neat, logical presentations

and traveled the globe to make sure everyone got the

message. But still, the masses soldiered on, continuing to

behave in the same old ways.

At that time, the entire system was based on

forecasted demands. Once a year, the item managers, who

were responsible for ensuring that depot repairs satisfied

demands, met with the war-fighters’ staff at a workload

conference to predict what would be needed the following

year. Armed with last year’s data and an enormous set of

computerized forecasting algorithms, they agreed on what

would be repaired during the upcoming year. The item

managers then met with the depot repair shop chiefs, who

were required to keep all their people and machines

gainfully employed, and negotiated a workload plan.

Things had been done this way for the last forty years.

Everyone recognized there were problems with

the process. Actual demand always turned out significantly different than what was forecasted, leaving the

war-fighters with things they didn’t need and holes they

couldn’t fill. Assuming that a more accurate forecast 

was the only way to improve the situation, every year

smart people got busy building 

a better forecast. Yet, after

spending millions of dollars year

after year to incorporate more

data and increase the complexity

of the computer algorithms, the

problems persisted.

This was the state of affairs

when we arrived with our

proposed changes. After months

of explaining, and wrestling with

the item managers to change

their process, I was feeling

extremely frustrated because it

seemed that despite our best eff

anywhere at all. If anything, we were going backwards.

That’s when I went to visit Chief Steve Haskin. Steve

was sharp, full of energy, and above all, practical. He had 26

years of Air Force experience, grew up in Texas in the heart

of cattle country, and I could always count on him to

provide me with sage advice.

As I explained my concerns and frustrations, Steve

interrupted me and said, “Sir, the first thing you have to do

is get the cows on their feet.”

orts, we weren’t getting

I’ll never forget that comment. It floored me. I just

stared at him with what must have been an amusing

expression because Steve laughed out loud before

explaining: “When you’re herding cattle, the first thing

you have to do is get them up off the ground and

moving. Then you can worry about heading them

around in the direction you want to go.

“I think we need to do the same thing,” he

continued. “We need to get these people off their feet

and moving. They’ve been lying here doing the same

thing for the last forty years.”

It was a clarifying moment. We had been trying to

explain logically what changes needed to be made and

why. Now, with Steve’s help, I realized we had to find a

way for them to see it themselves—we had to get them

on their feet. What was needed was some sort of prod;

whether it herded them into the right pasture was irrelevant, but we needed a prod that would get them

up on their feet.

As luck would have it, just that morning we had

demonstrated a new computer system that would let

all the item managers and the repair shops see exactly

what “holes” existed at each war-fighter base location.

I grabbed a few key members of my team, and after

making an animated, emotional appeal, got the

general’s permission to provide

this information to all the repair

shops, and tell them they could

only repair something if it

appeared on this list.

It worked! Predictably, the

item managers went ballistic.

For them, success had meant

delivering what they had

promised the war-fighters at the

workload conference, but now

the repair shops wouldn’t be

paying attention to the negotiated quantities. All that mattered

was the list of the war-fighters’ “holes.” The shop chiefs

weren’t happy, either. In their world efficiency was king.

Success depended on efficiently using all the shops’

budgeted hours, but how could you efficiently plan the

work when you were given a new “to do” list each day?

There were many questions, and we addressed them

all as we met with both the item managers and the shop

chiefs. Eventually we worked out a compromise where the

shops repaired only what was indicated on the “holes” list

each day, but the requirements were prioritized each day

BY IMPLEMENTING THIS

“WAL-MART SOLUTION” WE WERE 

SURE WE COULD MAKE THE

WHOLE SYSTEM RESPOND

QUICKLY TO THE NEEDS OF THE 

WAR-FIGHTERS USING THE ITEMS.
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 19

by usage-predicting software algorithms. It wasn’t the

perfect solution, but it was an excellent short-term win.

Everyone from the war-fighter staff to the shop workers

quickly saw the benefit of letting actual customer demand

drive the repair process.

In a few short months, we stopped repairing

equipment no one wanted, and focused on what was

actually needed. In the next year we eliminated $798M of

inventory and reduced delivery time to the war-fighters by

more than a third. But more importantly, this first step got

everyone on their feet and moving. Without that, we

would never have been successful in rounding everyone

up, coordinating their efforts, and moving the Air Force’s

logistics system in this new direction. •

LESSONS

• There comes a point where you have to stop talking

about what you’re going to do and just give it a try. Results

will change beliefs much faster than words or briefing

charts.

• Most people won’t willingly jump into something they

don’t understand, don’t see a need for, or aren’t confident

they can excel in—you have to give them a push.

QUESTION

Is it time to stop talking and take action on your idea?

SOLD ON STORY

A professor of program management and leadership at the Defense Acquisition University (DAU),

MAJOR NORMAN PATNODE believes that

stories accelerate learning in areas such as

leadership, risk management, and teamwork. Recently, Patnode put

his theory to the test when he introduced the concept of learning

through story to fellow DAU staff. With support from the Academy

of Program and Project Leadership (APPL), Patnode organized a

Knowledge Sharing Workshop in December 2003 modeled on

similar programs run by APPL at NASA centers. 

The workshop was a big success. Patnode reports: “We had nearly

thirty folks participate, and their comments were all positive. Many

shared with the group how they planned to start using stories both

in their classrooms and in their group facilitation work.”

Patnode’s respect for story has another APPL model, as well—the

semi-annual Forum of Master Project Managers. “I gained a tremendous amount when I was invited to the Masters Forum,” explains

Patnode. “While I was there, I learned much from the wonderful

stories that were shared so openly. Since then, as I’ve reflected on

those stories and how I can apply them to what I do, I continue to

find new insights. It seems that each time I reach up and pull one of

those stories back out of my memory, a bunch of other related

stories come tumbling down as well, so I end up reflecting not only

on the original story, but a web of interrelated stories. That’s the

beauty of it—learning from stories is multi-layered and never ends.”

I REALIZED WE HAD TO FIND A WAY

FOR THEM TO SEE IT THEMSELVES—

WE HAD TO GET THEM ON THEIR FEET.
20 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

AT STARSYS, WE EXECUTE MANY FFP PROGRAMS FOR

the development of mechanical systems for spacecraft.

Contracting this way presupposes that we have the

ability to establish and hold scope for a system that has

yet to be defined. To do FFP, it is critical that we have

program managers who are masters at cost control.

Fortunately, we have some “masters” in our

company. They just seem to have a knack for driving to

a financial target. Doesn’t matter if the program has

contingency or not. Doesn’t seem to matter if they use

MS Project, Excel spreadsheets, or the back of an

envelope. Doesn’t even seem to matter whether the

program is set up as a financial challenge or a winner.

Yes, they have systems and the mechanisms for

converging on a cost target, but so do the good—but not

master—program managers.

As I looked back over the last five years, it was clear

that some of our program managers consistently

generated great results and others did not. This got me

to thinking, if I could only figure out their formula,

could it be turned into a recipe for success? I started

talking to some of the managers about this, and one of

their comments struck a chord, “You just do it—

it’s natural, it’s where the fun is.” That got me thinking:

Maybe this isn’t as much of a skills issue as I had 

previously thought.

Stand

ur

L M Te

e

ll e Abou

o

t

n

Yo

m ade

By Scott Tibbitts

FIRM FIXED PRICE (FFP) CONTRACTING IS A SPORTY PROPOSITION. AN FFP

PROGRAM THAT IS SIGNIFICANTLY OVERRUNNING WILL BRING A COMPANY TO

ITS KNEES. CONVERSELY, WHEN SUCCESSFUL, PROFITS CAN BE SUBSTANTIAL. 
It’s accepted practice that good engineers are

created not born. That’s what engineering degrees are 

all about. But this is not always the case for other 

disciplines. Take marketing: These folks seem natural 

at it. They love meeting people, they love developing

relationships, they love explaining things, and they love

enrolling people in their ideas. Could it be that master

program mangers are born not made? 

Maybe Myers-Briggs would have the key. I had a

group of fifteen folks take the Myers-Briggs personality test.

The group included good program managers, the ones 

I regarded as masters, and others who had demonstrated

that their strengths lie elsewhere. And the result was...no

correlation! Yes, I could see some patterns that explained

the individual’s styles, but clearly Myers-Briggs was not an

indicator of who was a master program manager.

I spent a lot of time talking to these masters. What I

found were shared values. The things that they found

fun, interesting, and worthy had some common threads.

For instance, they all loved business and the game of

leveraging what you know to make money. And that

interest went way back. These were the folks with the

lemonade stands, the newspaper routes. I was surprised

by this. Values are the beliefs that develop as a person is

growing up, from the primary influencers in your life

through grade school and high school.

Their similarities carried on into college. The masters

were those who had wanted their MBAs. It wasn’t so

much what they had learned from their MBA as it was

their passion about getting one. To a person, they had all

thought about starting their own business, but for

whatever reason had chosen to take a less risky path.

The most interesting thing was what really made for

a “great day” for these people. It wasn’t limited to finding

a great design, or converging on a technical solution.

Business wins were the things that made them smile,

high-five, and carry on about how much they loved what

they did—finding the technical solution that would save

$50,000 or that resulted in the favorable negotiation of

a contract element. Try to get a great designer excited

about a favorable negotiation of a contract element!

Now, whenever I interview a project manager there

are a couple of things I know to ask to gain insight into

their values. For instance, I’ll ask, “So, did you ever run

a lemonade stand?”

Some folks look dumbfounded. You may as well be

asking them to talk about their root canal. But masters

“light up” at this point and respond with something like,

“Oh yeah, ever since I was a kid I loved making money.”

Masters tend to think in terms of leveraging what they

know to create an enterprise that makes money. I don’t

just ask them about their lemonade stands, but it’s not

such a bad place to start. This is values-based interviewing, and it is actually an easy way to get at what

makes people tick.

Yes, we need to give our project managers the right

resources—the tools, the qualified technical expertise,

and the training—but it’s a mistake to assume that we

can “grow” any given engineer into an effective project

manager. We put our projects at risk if we do so. The

lesson here is that we must seek out PMs with a passion

for the business of projects. This is something to

consider, too, as we recruit and groom tomorrow’s

project leaders.

Business wins were the things that made them

smile, high-five, and carry on about how much they

loved what they did. •

ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 21

As president of Starsys Research in

Boulder, Colorado, SCOTT TIBBITTS

has overseen the production of more than

2,000 mechanisms flown on more than

200 spacecraft. Tibbitts’s first ASK feature,

“Fly Away,” appeared in Issue16.

Business wins were the things that made 

them smile, high-five, and carry on 

about how much they loved what they did. 
22 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

Hanging

On by

aT

byR

h

ayM

r

or

e

gan

ad
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 23

THE FIRST SOLAR PLANE WE DEVELOPED AT

AeroVironment was named the Gossamer Penguin.

The word “gossamer” was an apt description of the

appearance of this strange-looking aircraft that had a

structural weight of only 54 pounds, with a wing span

of 71 feet.

Much was sacrificed to save weight and maximize

span, and this presented serious problems when

handling the aircraft on the ground. The Penguin was

barely strong enough to stay together in the light winds

and low turbulence of the early

morning. Moving the Penguin

back to the hangar at the end of

a morning flight was much like

walking a 71-foot span kite

home from the park.

To move the aircraft about

on the ground, as well as to

stabilize it during take off and

landing, we needed to come up

with a lightweight solution. An

obvious one would be to assign 

each wing tip. A walker would simply pull down on the

wing that was being lifted up by the gusts. The tips of the

Penguin, however, were over eight feet above the

ground. If the aircraft was allowed to tip far enough to

one side for ground crew to hold it, then it would have

already raised the other tip high into the wind. At that

point, the aircraft was likely to flip over.

To solve that problem, we used a string of Kevlar®

tied to each tip. It was extremely light and thin, so 

the performance penalty of carrying the string along in

flight was negligible. Unfortunately, this elegantly simple

solution had one minor flaw, which, like all such flaws,

was discovered the hard way.

When the winds were calm the string worked very

well, and kept the wings level and away from the ground.

But when a strong wind caught us walking the Penguin

home, it required some tension on both strings simultaneously to keep it balanced on the dolly set under the

main wheel. Accordingly, the walker would get used to

holding the string at a certain height and a certain

tension, and when a gust began to lift his wing up, he

would feel the increasing tension in the string, and

naturally react by pulling down harder on the string.

Sometimes one wing walker would pull down

inadvertently, which pulled the opposite wing up

slightly. Feeling this tug, the other walker would assume

a gust was hitting his wing, and would begin to pull

“wing walkers” to mind

down harder on his wing to prevent the wing from

lifting more, and getting even more lift as the wing rose

higher against a side gust. The first walker would now

feel a strong pull on his wing and would resist even

harder. Since the wings weren’t designed to take large

point loads near the tips, a disaster seemed imminent.

The fix didn’t require a high-tech solution. After

discussing the problem, the flight team realized that by

simply having each wing walker alternatively call out an

estimate of how hard they were pulling on their string,

they wouldn’t fight one another.

When the flight team tested the

system, they discovered that it

didn’t even matter if the walkers’

estimates were accurate; they

just needed a rough idea of the

balance of their efforts.

In practice, as a pair of

walkers got used to working

together, they rapidly developed

a sixth sense that made their

estimates surprisingly close. But this job could quickly

get boring, which meant we often changed walkers

during a test day. Fortunately, we found that any new

team of walkers would quickly calibrate each other after

only a short orientation. The result: no broken wings.

The Gossamer Penguin solar-powered aircraft was

my first project management experience. Since that

time, I’ve found over and over that the most common

solution to problems in any group of people that must

work together has been better communication.

Sometimes it’s a system or process, sometimes it’s an

attitude adjustment, but improved communication

almost invariably helps a team be more productive and

effective. Just as importantly, it generally makes the work

a lot more fun. •

“I’ve found over and over again

that the most common solution 

to problems in any group of

people that must work together

has been better communication.”

RAY MORGAN is head of Morgan Aircraft &

Consulting and a senior technical advisor to

NASA. Morgan oversaw the development of

over 35 Unmanned Aerial Vehicles (UAVs),

including NASA’s Helios and Pathfinder

aircraft, during his tenure at AeroVironment, Inc. His first 

ASK feature, “Coming of Age,” appeared in Issue 16.
24 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

SPECIAL FEATURE: THE POWER OF STORY

ASK Magazine is not alone when it comes to using storytelling to capture lessons learned and share knowledge. Several other practitioners

have successfully introduced this approach to knowledge management within organizations. This article by Annette Simmons marks the first in

a series by authors whose work on storytelling has been widely recognized. We hope these features illuminate why ASK contributors use the

story form to share their knowledge, and how you can do the same. Annette Simmons spoke at the February 2002 APPL Masters Forum.

I WENT TO MY FIRST STORYTELLING FESTIVAL AS AN ADULT. MY DAD THOUGHT IT WOULD BE A GREAT PLACE FOR THE

family to get together, so he sent us all tickets. I can still recall sitting inside the festival tent and noticing the rapt

attention of the people around me as a story was told. Jaws slackened, whole bodies became receptive. We were

trained on every single word that came out of the storyteller. That’s when I understood the power of storytelling.

I first began to study storytelling so that my presentations wouldn’t be boring—but as I worked on storytelling, storytelling started to work on me. There’s something important going on here, I realized. But how do

I describe it? With a story, of course.

Truth, naked and cold, had been turned away from every door in the village. Her nakedness frightened the

people. When Parable found her she was huddled in a corner, shivering and hungry. Taking pity on her, Parable

gathered her up and took her home. There, she dressed Truth in story, warmed her and sent her out again.

Clothed in story, Truth knocked again at the doors and was readily welcomed into the villagers’ houses.

They invited her to eat at their tables and warm herself by their fires.

—Jewish Teaching Story
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 25

We need stories because cognitive learning doesn’t

always cut it. If it did, any of us who wanted to lose

weight would only need to read one diet book. People

don’t have flip-top heads that open up for you to shove

information down. We’ve tried that—at least I have. My

first ten years in management experience I worked that

way. It doesn’t work.

Story is one of the most respectful ways to share

knowledge, and thus, one of the most effective because

it allows people to come to their own conclusions.

Instead of telling someone, “You should be more

patient,” you invite your listener to come to that conclusion independently: “Hey, I know what the problem is.

My impatience is making things worse.”

And who amongst us doesn’t need more patience?

Yet, preach “Be more patient, be more patient,” to a

bunch of smart executives, and I’ll guarantee increased

patience will not be the first change you begin to notice

in their behavior.

So take them on a journey, instead. Here’s

another story:

A woman begged the shaman for a potion to

make her husband love her again. She explained that

before her husband fought in the war, he was warm,

loving, and he laughed easily. But since his return he

was angry, distant, and humorless. The more she tried

to hug her husband, tease him, and draw him back to

her, the worse it became. The shaman was her last

hope. He listened patiently to the woman’s story.

When she was finished, he said, “I think I can help

you. I will make you a love potion—but you must go

find one of the ingredients.” She said she would. Then

he told her to get a whisker from a live lion. She was

distraught, “How can I possibly get a whisker from a

beast as fierce and powerful as a lion?” The shaman

shrugged and left her to her tears.

The next day she went to a place where she had

once seen a lion. On that day she saw nothing more

than monkeys fighting in the trees and birds flying in

the air. On the second day, she stayed a little longer

and found a comfortable place to sit. But she did not

see the lion. Weeks passed. One morning she sensed

the lion’s presence before she saw him. She didn’t

move but the lion saw her anyway and ran away. It was

a week before she saw him again. Curious, the lion

stopped running away. Finally, after weeks of bringing

the lion good things to eat and ever so slowly reaching

out to pet him, he finally was so comfortable with the

woman that he fell asleep under her stroking hand.

Once he was asleep she took a very sharp knife and

gently cut one single whisker from the lion’s muzzle.

The next day she brought this whisker to the

shaman, and asked for the potion that would make her

husband love her again. The shaman said “You do not

need any potion. Throw away the whisker, keep the

knowledge you have gained, and your husband will

learn to love you once more.”

—Somali tale from Ethiopia

Now, that’s what I would call a teaching story. So if

you’re trying to teach someone how to be a good project

manager, handing out a list of dos-and-don’ts will never

encompass the subject the same way as one of your

personal stories about when you learned something

about project management. •

ANNETTE SIMMONS is the President

of Group Process Consulting and the

author of three books, The Story Factor

(2001), A Safe Place for Dangerous

Truth: Using Dialogue to Overcome Fear

& Distrust (1999) and Territorial Games:

Understanding and Ending Turf Wars at Work (1997). 

Her books have been translated into several languages,

and she travels regularly around the world to speak

about her work, much of it concerning the use of storytelling in organizations. 

“Whether you’re proposing a risky new venture, trying to

close a deal, or leading a charge against injustice, you

have a story to tell,” says Simmons. “Tell your story well

and you will create a shared experience with your

listeners that can have profound and lasting results.”

Simmons combines public speaking, writing, consulting

and constant research and development to serve organizations seeking to increase workgroup cooperation for

bottom-line results. Her latest book on women in organizations is scheduled to be released later this year. 

Annette Simmons can be reached at annettegpc@aol.com.

WE NEED STORIES

BECAUSE COGNITIVE

LEARNING DOESN’T

ALWAYS CUT IT.
26 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

PRACTICES
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 27

I FIRST CAME TO THE JET PROPULSION LABORATORY (JPL)

48 years ago, and was taught that what’s most

important for project success is bringing good people

on board, getting them to come together as a team,

making certain that they’re all on the same page, and

setting up the mechanisms to keep them communicating. That much is true to all successful projects—

but, naturally, it’s not as simple as it sounds.

What, for example, are the most effective

“mechanisms” for communication? Today, people

think about email when they think about day-to-day

communication and PowerPoint for presentations.

But many believe, including me, that the advent of

email and PowerPoint has, in some respects, eroded

our culture of engineering communication.

Of course, if you need a quick answer, if you’re

working with remotely located team members—

then email can be a tremendous communication

tool. So is PowerPoint for presenting an engineering

summary or presenting the results of a design

activity. But what’s important to note here is that

neither email nor PowerPoint is an adequate substitute for engineering documentation.

By that, I mean if you have people working in a

technical area, it doesn’t matter what it is, at

periodic times you need to have them capture the

engineering that has gone on. You need to do that

with an engineering memo, or a workbook, or a

technical report—whatever you want to call it. You

need to do that to provide an audit trail of decisions

that that can be reviewed and challenged by peers.

I believe that the

advent of email 

and PowerPoint have,

in some respects,

eroded our culture 

of engineering 

communication.
For the record

A technical memorandum is what we used to call it.

We used to have a form for the engineers; they

would put their summary at the top, list their

assumptions and the boundary conditions next, and

then go through the analysis—sometimes even

including a summary of some of the equations

involved, plus the pros and cons they had considered. All of that preceded their recommendations

and/or summary of actions taken.

That became a part of the engineering file.

Anybody could go back and review that or challenge

it. You could say, “Okay here is the analysis.” You

could give it to another person or to another group

and have them validate it or critique it. It also stood

as a good way of handing off information about work

that had been done to a newcomer on the project.

What I’ve seen over the last ten or fifteen years has

been a gradual erosion of the discipline of that kind of

engineering documentation. Again, I think it has a lot

to do with the introduction of email and PowerPoint—

which, once again, are tremendous tools for communicating but not for engineering documentation.

One way of putting it is that email and

PowerPoint are more like sound bites. You can’t

critique a PowerPoint presentation the way you can

an engineering memo. It simply doesn’t have the

structure and the completeness that you would find

in a report or a memo. In many ways communicating

has become easier, but it’s still necessary to keep

track of where you’re going and the decisions that

have been made.

But does it really matter?

Let me give you an example of a time when communication was at the root of a project’s demise. I was

on the Failure Review Board for the Mars ‘98

failures. The Mars Climate Orbiter failure was

ostensibly caused by a metrics conversion error that

led to a navigation failure. We were getting the

navigation data by tracking the spacecraft to

calculate the trajectory. The data that we got from

the spacecraft augmented the data from the

ground—but there had been some inconsistency

noticed during the mission well before the failure at

Mars orbit insertion.

When we observe an inconsistency during

operations, our practice is to use an engineering

reporting system, called an Incident Surprise

Anomaly (ISA) report, to record the discrepancy. It’s

only one page long, but it’s a formal report. Once it’s

28 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

PRACTICES CONTINUED

The Mobile Service Tower is being rolled away from the Titan

IVB/Centaur launch vehicle carrying the Cassini spacecraft.

Cassini Saturn Probe Undergoes Preflight Testing
Keeping the lines open

JOHN CASANI came out of

retirement in 2003 to return to

the project management ranks

at the Jet Propulsion Laboratory

in Pasadena, California. The

engineering memos Casani champions in this

article are far from being the only formal communication he sets up on his projects.

“As a project manager, I hold two regularly

scheduled meetings each week,” explains

Casani. “One is with just the core project staff,

and the other gathers a more extended set of

people working on the project—including people

matrixed to the project from each of the major

technical areas.”

In addition, the full project staff—including outof-town team members from other NASA

centers, government agencies, industry, and

academia—are invited to monthly meetings and

many of them make a point of attending the

meetings in person. “This is the way that we can

coordinate and keep track of how the project 

is going,” says Casani. “We keep everyone

informed about what everyone else is doing.” 

Informal communication is just as important.

Core team members are co-located in “our own

corner of the building,” says Casani. “We’re in

contact every day, almost every hour, in addition

to the meetings we hold.”

For more about John Casani’s remarkable

career at JPL, see his story, “A New Spin,” in this

issue (page 6).

You can’t critique a 

PowerPoint presentation

the way you can an 

engineering memo.

submitted, it gets tracked. During the course of a

mission there may be 100 or even hundreds of ISAs.

Once you write an ISA it becomes a permanent

record in the system. It gets reviewed. Its ongoing

status gets reviewed. Its closure gets reviewed. People

have to buy off and say, “Yes, this Incident Surprise

Anomaly, whatever it was, is understood now. We’ve

taken the following steps to prevent it from

happening again and we’ve corrected whatever it is.”

In the case of the Orbiter, the person who

noticed this problem didn’t use the ISA form. He

wrote an email message to the person that he

thought could solve the problem. That person got the

email message, and he looked at it and worked on it

for a while. Then his boss gave him something else to

do that this individual judged to be of higher priority

than working on the problem outlined in the email.

Here is a case where the guy who noticed the

problem thought he was doing the right thing. He

wanted to get the problem taken care of quickly. He

sent the email out. The email went to where the

spacecraft was being worked. The guy who received

the email probably could have solved the problem.

But he didn’t. It got forgotten.

If that message had been generated as an ISA, it

could not have been forgotten. It would have become

a permanent part of the engineering documentation.

In our failure review report, we described the

problem something like this, “Communication

channels among project engineering groups were

too informal.”

No one would argue that open communication

is key to project success. What I’m suggesting is that

we keep in mind that communication comes in many

shapes and sizes—it’s not a one-size-fits-all concept.

We need to reinforce the distinction between the

need for rapid communication and the need for

engineering documentation, which creates products

that can be peer reviewed and that leave an audit

trail for engineering follow-up and close-out. •
30 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 31

Following the release of the Columbia Accident

Investigation Board (CAIB) Report, Alphonso (Al) 

Diaz, Goddard Center Director, was asked by NASA

Administrator Sean O’Keefe to head up the Agency’s

response. The Diaz Team, as it came to be known, was

charged with making sure the CAIB Report did not

become another dusty volume on a shelf of old

Agency Reviews. 

AL DIAZ
AL DIAZ WAS APPOINTED GODDARD CENTER DIRECTOR IN

January of 1998. Before that, he served as Goddard’s

Deputy Director, beginning in 1996. Mr. Diaz began his

career at NASA’s Langley Research Center in 1964,

where he worked in a variety of technical management

positions, principally on the Viking Program as the lead

for GAS Chromatograph Mass Spectrometer. This

scientific instrument was the first to analyze the surface

material on Mars in 1976.

In 1979, Mr. Diaz began his work at NASA

Headquarters, where he served in a variety of leadership

positions, including program manager on the

International Solar-Polar Mission (now known as the

Ulysses Mission) and Galileo. Mr. Diaz has been awarded

three Presidential rank awards, two as Meritorious

Executive and one for Distinguished Service. He was also

awarded a NASA Outstanding Leadership Medal in 1994

for his work on the Hubble Space Telescope First

INTERVIEW CONTINUED

“Managing or leading entails the responsibility to have 

a justification for what you’re doing and to be able to

articulate that justification in a way that nine times out 

of ten is not going to be second-guessed.”
Servicing Mission and an Exceptional Scientific make needed changes. What was the charter of the “Diaz

Achievement Medal for his work on Viking. Mr. Diaz has Team” in addressing the CAIB report?

a Master of Science in management from the In looking at the Columbia accident, the CAIB report

Massachusetts Institute of Technology (MIT). focused on two different sets of causes: the physical

cause of the accident as well as the organizational

Since being tapped by NASA Administrator Sean causes. Physical causes tend, by nature, to be local to a

O’Keefe to head the team analyzing the findings of the particular project or program. But the assertion by the

Columbia Accident Investigation Board (CAIB), your CAIB was that organizational flaws had as much to do

name has been associated with the agency’s efforts to with the accident as did any of the physical causes.
The Agency wanted to know if behaviors like the ones Our charter ends with the identification of a set 

cited in the CAIB report existed on a broader scale than of recommendations we extracted from the CAIB 

simply the Space Flight Program. report that could be applied Agency-wide. Subsequent

implementation planning will have to determine how

How did you go about collecting information? best to execute those recommendations. It is my

The team recognized that we needed input from other expectation that there will be differences in the way

people, in terms of what they thought about the CAIB things are applied, but that there will be some standards

report and what they extracted from it. We engaged set across the Agency.

Headquarters. We engaged field center directors and their

staffs. We talked with individual managers. Then we held So then, a five-person project shouldn’t necessarily

a Safety and Mission Success Week, which got everyone expect to be addressing the same concerns as say a 500-

at NASA focused on safety and mission success, at the person program?

same time it provided us with an opportunity to hear their There is always this concern that we’re going to come

thoughts about the relevance of the CAIB report. out with an overly constraining set of recommendations

I think we’ve got to be clear about what the team that will squeeze out all of the creativity and flexibility on

was asked to do: Find out what, if any, of the CAIB a project. We have no intention of doing that.

recommendations had broader applicability. Then, to the

extent they did, what should we do about it as an Agency? 

INTERVIEW CONTINUED
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 35

Did identifying those “widely applicable” CAIB So, we observed that the recommendation has

recommendations come down to a judgment call based on broader applicability than the Human Space Flight

the collective experience of your team? Program—not because the RCC panels are used

It’s safe to say that we had a good deal of directly applicable everywhere, but because of the implications: People

experience among us. The example I like to use for that is shouldn’t be put in positions where they need to

the RCC [reinforced carbon carbon] panels. As one of the compromise on critical components. We relied on our

recommendations to address the physical cause of the own experiences to reach this conclusion.

accident, the CAIB report suggested that the Shuttle

program make certain in the future that there are sufficient Have your findings made you look at your own center,

RCC panels available that meet all of the specifications, so Goddard, in a new light?

that program people don’t have to make decisions about I have seen things at Goddard that I think bear some

using hardware that has lower integrity than required. consideration. The CAIB observed that in the case 

Well, we don’t have RCC panels anyplace other of Human Space Flight, there was not enough

than the Space Shuttle Program, but we do run into independent technical input. That somehow the

situations where the perception that a program is relationship between the engineers and the programs

resource constrained influences us to put ourselves in colored the input that engineering was making to the

the position where we have less hardware than we ought programs. I worry about that here at Goddard, and we’ve

to have when making decisions about selecting tried to structure our relationships so that engineering

detectors or other flight parts. retains an independent voice.

I don’t know how many times we’ve been through

this process of asking, “Well, can we use a non-flight How are you attempting to address that issue?

part in this application because it would take 26 months We went through a major reorganization five years ago.

to order a new part?” You put yourself in a position It was one of the first things I did here as the center

where you have to make those compromises sometimes. director. We established a central engineering

Technicians at the Johnson Space Center in Houston team up to assemble a test article to simulate the inboard

leading edge of a Space Shuttle wing as part of the Columbia Accident Investigation Board’s testing.
36 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW CONTINUED

organization so that we could matrix our engineering,

in order to establish quality control over the work that

is provided to the projects. We went through the pain

of pulling all of engineering out of other organizations

and bringing it to that organization. But a few of our

larger projects—Hubble, GOES [Geostationary

Operational Environmental Satellite], POES [Polar

Orbiting Environmental Satellite]—haven’t been

pulled into this setup yet. I think it’s time to revisit that

decision now.

You know, change has its risks—but not changing

has risks, too. We made the determination five years ago

that we were better served not to make the change on

these projects to the new model. But, as I said, it’s time

to take another look at this.

When engineering operates as an independent

organization, do you worry that project managers could

feel as though they’re being second-guessed?

I don’t think the good managers feel that way. I think the

good ones see our engineering organization as an

important element of getting the resources that they

need to get the job done successfully. It isn’t usually a

question of the project wanting to spend less on

engineering, and engineering wanting more and more

work performed. Our experience hasn’t been that at all.

Our experience has been just the opposite in that the

project manager wants more engineering support than

he or she might actually need.

What happens in this scenario when they don’t agree?

Does the project manager still get to say, “Look I respect

that you’ve said this, but my decision is that we go the

other way”?

Then the engineering organization can elect to take it to

the Program Management Council and say, “We’ve got a

problem. We think we’ve got to change something on

that project because we are worried that we’ve got the

wrong mix of people.” Or, “We’ve got too few engineers

there.” Or, “Our engineers have concerns that aren’t

being addressed.”

Aren’t there times when the project manager has to 

make a judgment call? Should project managers be

concerned that it is now going to be more difficult to

make decisions?

If it appears more difficult, then it is probably because we

haven’t been doing it right in the first place. I think this

whole idea that somehow it is going to be more difficult

because people have a legitimate right to question

leadership is really part of a dysfunctional mindset.

Leaders need to be accountable. If, as a leader, I

can’t tell people why I decided what I’m doing—with the

expectation that they will support my decision, given the

kind of record that I have—then I have a problem and

I’ve got to deal with that problem.

Managing to me is not simply making decisions and

moving on. Managing or leading, I do think, entails the

responsibility to have a justification for what you’re

doing and to be able to articulate that justification in a

way that nine times out of ten is not going to be secondguessed. If engineering decides that they are not satisfied

with something and they want to bring it to their

management, I don’t see that as second-guessing. I think

that’s just part of a healthy process.

What are the challenges that you see project managers

facing at NASA today?

Project managers work in the margins all the time. They

are always working on budgeting what is left. They have

a plan. The plan has reserves. The conduct of the project

is, in essence, the management of the depletion of those

reserves, so that every available resource is used to the

maximum extent possible.

The real challenge is how do you know when you

have enough? Everybody can’t have as much as they

could possibly imagine. So, how do you know when

you’ve got enough? Our tools are limited in terms of what

we have available to determine what the right cost is.

How can you tell when a project is being managed well?

I think it starts at the top, in terms of the competency

and character of the leader. It has a lot to do with

whether or not the resources that are being made

available are adequate to do the job.

“People shouldn’t be put

in positions where they

need to compromise on

critical components.”
How about communications and teaming?

I think that’s equally important.A team needs to act like a team.

I think there needs to be an environment for communication

that’s conducive to getting the job done.

That was another observation in the CAIB report.

In these complex projects we need to maintain an

environment where everyone feels invited to participate,

and where what are typically called “minority opinions”

are viewed as part of the diversity in the project that we

welcome, as opposed to people cringing when

somebody has a different idea. I really think the

communications piece of a project is critical.

While you were talking with people throughout the

Agency, interviewing them about the CAIB report, did

anything you heard surprise you?

One thing for certain: We can learn a lot more by talking

to other people than we sometimes believe. When we

went through Safety and Mission Success Week, for

instance, many of the issues that people raised were

predictable. We could anticipate the categories of things

that people would bring up. Where we did our learning

was in the feedback process, when we listened to people

address those issues.

Here at Goddard, I went to each of our major

organizations at the end of the week. I asked a cross

section of the population in each organization, “What did

you learn this week?” In the case of communications,

one of the issues we discussed was the way we wanted to

deal with minority opinions. I got an input from a young

guy in Human Resources, who said, “You know, even the

term ‘minority opinion’ is pejorative. As a consequence

you’re not really encouraging people to come up with

alternative viewpoints, which would really benefit you.”

And so I got to thinking about that—and I saw

that he is absolutely right. What we need to be doing is

not only saying that we are open to minority opinions;

we ought to be saying that we encourage the

development of alternative opinions so that we can test

the prevailing opinion the same way that we do in the

scientific method.

ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 37

CAIB board members Major General Kenneth W. Hess and Rear Admiral Turcotte examine debris at Kennedy Space Center.
Not only that, but we need to be prepared to apply about how we would go about doing that as part of the

resources to that, not force the people that have these establishment of what we will call our independent

different opinions to provide the resources themselves. If technical authority here.

we’re prepared to apply resources to develop those

alternative opinions, only then should we feel Let’s say you have five engineers working on a project,

comfortable that the prevailing opinion is in fact correct. and each one of them has a slightly different idea 

about the best way to do something. Can you run down

Is there something that can be done at the centers to make every idea?

resources available for that? For example, what will you No, you can’t run down every idea, but our engineering

do to change things at Goddard? people do their own peer reviews. They bring people 

I think that part of the independent technical in and test the prevailing opinion. I think there needs

authority ought to be an allocation of resources to to be a constant testing of the design and the

engineering that is non-specific to the task they’ve development of the design. If we ever get to the point

been asked to do, but is available on an unsolicited where everybody has a different idea, then we have a

proposal basis for people to develop alternative different problem.

options for projects. The challenge now is to recognize that the prevailing

Now, it may come out of the same pool that we use opinion may not always be correct. Why is it that we feel

for reviews or what have you, but we have to set aside so comfortable when there are no minority opinions, as

some resources for general engineering review functions, opposed to feeling good about being in a position where

development, and things like that. Typically, it’s not there has been a different opinion voiced? 

dollars. It’s workforce time. So, we’re trying to think

38 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW CONTINUED

The STS-114 crewmembers look at the reinforced carbon-carbon panels for one of the wings

of the Space Shuttle Atlantis in the Orbiter Processing Facility at Kennedy Space Center.
ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 39

Why do you think that is?

Perhaps it’s human nature. It’s just more comfortable to

feel that way. But in complex environments like ours, we

shouldn’t feel that comfortable.

Here’s an example: On the first Hubble Servicing

Mission, we all thought we were ready. We all thought

that everything was perfect. Then Joe Rothenberg, the

project manager, said, “I would feel more comfortable if I

could test this plan.” So, we brought in a group of people

from Lincoln Labs. We put together a team of around

twenty people and said, “We want you to sit down and go

through the reviews with the Hubble guys. If you see

anything that you think warrants further penetration, we

want you to develop that idea and we’re going to give you

the resources to support a team to do that.”

And you know what? They did find something that

they were worried about and they pursued it. In the end,

they concluded that they were wrong and the Hubble

guys were right. But it wasn’t a waste of time; we had

tested our prevailing opinion.

With the Hubble, there was a mandate that “we have to

fix this thing.” Some projects don’t have the kind of

resources to create those kinds of checks and balances.

Well, some of them don’t have to do that. For instance,

we have experts in a lot of very esoteric kinds of designs

and elements of design. I’m thinking about a guy in our

engineering organization who knows a certain kind of

device better than most people in the world, probably as

well as virtually anyone in the world.

In the past, he might have gotten the impression

that people cringed when he showed up at reviews

because he was always so penetrating and precise about

the use of this particular kind of device. But now we

make certain to let him know that we feel a lot more

comfortable when he walks away from a review than if

he hasn’t been at it.

In fact, we try very hard to make sure that if there is

a survey done of the use of this kind of device on any

particular project, we ask him to take a look at it. I mean

it doesn’t have to be a team of people that board a

project. It can be just one expert.

Are you worried that the CAIB report paints too broad a

picture of the problems in the agency?

Actually, I am less worried about what the CAIB Report

says than I am with what some might think it says. I do

worry about that. I was pleased to see that Admiral

Gehman has said that if he had been asked to do an

overall evaluation of NASA and the Human Space Flight

Program, there would be a lot more good that he would

have to say than there would be bad. The fact of the

matter is: That isn’t what he was asked to do. What he

was asked to do was focus on our problems.

We’re not talking about abandoning something

because it’s beyond hope. That isn’t the case. We’re

talking about improving something that’s worth

improving. The margins are too slim and the

consequences are too great for us to recognize that we

can do better and not do it. We need to improve. That’s

what we need to be doing all the time.

What would you like to see as the legacy of your work on

the “Diaz Report,” let’s say five to ten years from now?

What would you like to be able to point to and say, “This

is what came out of it”?

I don’t have any specific driving issue that I hope that this

report will help fix. On the other hand, I would be

satisfied five to ten years from now if I could look at what

is going on and say, “We made a difference.” •
40 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

THE “OLD SCHOOL” APPROACH WAS TO EMPHASIZE CONTROL

as adherence to plan—much like using a thermostat: a

point is set; then, by measuring the temperature, the heat

is turned on or off, maintaining the pre-determined

standard. It's simple and stable. But projects rarely are. In

today's fast-changing world, a more suitable metaphor

for project control would be coaching. A coach would

hardly be effective if he was isolated in the locker room,

receiving statistics via a monitor—he needs to see the

game in order to guide his team.

While it may not be possible to eliminate uncertainty, you can anticipate many of its surprises before

they occur, and hence lessen their impact. Project

managers must review formal reports—as well as “move

about” during the progress of a project. I call this

“systematic monitoring,” a two-step process of evaluating critical planning assumptions and providing timely

feedback for continuous planning.

The following 15 rules for systematic monitoring

are taken from “Ninety-Nine Rules for Managing ‘Faster,

Better, Cheaper’ Projects,” which can be accessed in its

entirety at http://67.92.16.242/nasa/laufer/99rules.htm.

1. Identifying a small problem is difficult; correcting it

is easy. Identifying a big problem is easy; correcting 

it is difficult.

2. Dynamic environments require monitoring the

validity and achievement of objectives (effectiveness),

and the utilization of the means (efficiency).

3. In unsuccessful projects, there is never enough time to

do things right, but there’s always time to do them over.

4. Management systems don’t control projects. People

do, helped by management systems.

5. Only team members directly responsible for project

implementation can control projects.

6. What is yet to come can be controlled. Last week’s

performance is relevant to the project team only

when it helps them decide how to do next week’s

work better.

7. More paperwork does not ensure more reliable or

accurate information—and it only seems that more

measurement and reporting means better control.

8. Excessive control often “encourages” employees to

distort data or develop aberrant practices to suppress

critical information in fear of management reprisal.

This, in turn, provokes even greater management

suspicion and scrutiny.

9. Successful teams know that effective project control

does not result from reviewing and analyzing

performance reports, but rather by carrying out

effective front-end planning.

10. Managers who stay in one place are forced to make

complex judgments with incomplete cues.

11. Master project managers control the project by

employing formal performance reports and by

moving about.

12. Moving about contributes not only to “understanding,” but also to “influencing” project control;

plus, it allows project leaders a natural, subtle, and

timely influence on project activities.

13. When uncertainty is low, control is best implemented by measuring performance and then by

taking corrective steps to adjust performance to the

plan. As project uncertainty increases, control is less

of a “governor” of execution, and more of a data

collection function for continuous planning.

14. In uncertain conditions, “control” should provide

feedback for planning, and thus its emphasis should

be on looking ahead with anticipation rather than

looking back with justification.

15. When uncertainty is high, the best way to control the

project is by selecting adaptable and responsive people. •

Looking Ahead With Anticipation

Today’s fast-changing projects call for managers to be highly responsive to 

the unexpected—those surprises that can alter the course of a well-laid plan

FROM THE EDITOR-IN-CHIEF Dr. Alexander Laufer

NP-2004-06-354-HQ