Inside

BOOSTING TEAM MORALE

WHEN THE UNEXPECTED HAPPENS

COLLABORATION IN PRACTICE

A CULTURE OF STORYTELLING

ASK Magazine • Issue Twenty

N O V E M B E R 2 0 0 4

I N T E R V I E W

Dr. Gary Klein

appl.nasa.gov

Academy Sharing Knowledge

The NASA source for project management
That’s the power of stories—changing the dynamic of situations 

with knowledge and understanding. —Dr. Gary Klein, from his ASK interview (p. 39)
 STORIES

 6 A Glass Can Be Half Full—Even in Microgravity

The project team’s response to this challenge taught me how resilient people and projects 

can be when you give them the chance TOM SUTLIFF

 10 Managing the Unexpected

You can go through your whole career and never have someone drop one of your spacecraft. 

I think that would have been nice BY MARTY DAVIS

 14 Warning: Projects May Be Closer Than They Appear 

 It was a crazy time. I lost 20 pounds. My team kept asking, “What happened to our 

development manager?” BY COLBY AFRICA

 18 Cleaning Out the Closet

Like the closet that accumulates all the stuff we buy and never get rid of, 

we felt our list could stand a little spring cleaning BY W. SCOTT CAMERON

 FEATURES

 22 The Morning Meeting 

The idea was simple: a short, all-hands meeting once a day to maintain the 

week’s action item list BY SCOTT TIBBITTS

 26 Putting Patience to the Test

I had made some serious errors in judgment, and I was kicking myself mentally 

while steeling myself for dealing with the repercussions BY RAY MORGAN 

 SPECIAL FEATURE 

 29 No Launch Before Its Time 

I remember a member of the crew asking me, “Is this normal?” 

And in my experience, it wasn’t BY BILL TOWNSEND

 PRACTICES

 34 A Collaboration on Collaboration

We learned quickly that we were a group with diverse backgrounds, 

in every sense of the word BY BRENT COBLEIGH

 INTERVIEW

 39 ASK Talks with Gary Klein 

Dr. Gary Klein, Chief Scientist of Klein Associates Inc., discusses how stories 

help to strengthen intuition

IN THIS ISSUE • 3

The Bare Bones of 

Leadership

BY JESSICA SIMMONS

REVIEW BOARD • 4

FROM THE DIRECTOR’S DESK • 5

A Partnership with 

Universities

BY DR. EDWARD HOFFMAN

LETTER FROM THE 

EDITOR-IN-CHIEF • 39

A Tale of Two Houses: 

Building on a Foundation 

of Trust or Mistrust

BY DR. ALEXANDER LAUFER

ON THE COVER The Quetzalcoatlus Northropi, 

a model pterodactyl created for the Smithsonian 

IMAX movie, On The Wing, is mounted atop a 

van to record simulated flying.

ASK 20 November 2004

appl.nasa.gov

Table of Contents
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 Jessica Simmons, EduTech Ltd., 8455 Colesville 

Road, Suite 930, Silver Spring, MD 20910, (301) 585-1030; 

or email to jsimmons@edutechltd.com.

APPL DIRECTOR AND PUBLISHER 

Dr. Edward Hoffman 

ehoffman@hq.nasa.gov 

EDITOR-IN-CHIEF

Dr. Alexander Laufer 

allaufer@eng.umd.edu

EDITOR

Jessica Simmons 

jsimmons@edutechltd.com 

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

Mosaic

STAFF

ASK ONLINE

http://appl.nasa.gov/ask
THE AMOUNT OF FLEXIBILITY, DEDICATION, FOCUS, STAMINA—

and pure bravery—was fascinating to me. I guess it’s the 

idea of putting oneself in harm’s way for a shot at hardearned perfection, the ultimate goal being a medal not 

only for yourself, but for your team. I had previously 

wondered how this issue’s article would begin, but then 

I watched one of the gymnasts on the balance beam 

dismount with conviction, smile, wave at the crowd, 

laugh and hug her teammate who was up next, and then 

shake her head at her coach as if to say, “I could have 

done better.” I watched her focus, perform, and then 

respond appropriately to each of the people around her. 

It occurred to me that this is the type of balance that it 

takes to be a project leader: knowing how hard to push, 

knowing when to laugh, knowing how to motivate, and 

knowing what to do better next time.

In this issue, ASK writers explore ways to maintain 

that balance in their field of Project Management, and 

even what happens when they don’t. From his own 

experiences, Colby Africa learned that pushing too hard 

can take a personal toll, even though his project was a 

success in the end. He looked back and asked himself, 

“At what personal cost?”

Sometimes one of the most simple—and the most 

human way—of keeping oneself grounded is not to 

lose your sense of humor. Ray Morgan’s story about a 

test flight gone bad tells how the sound of their model 

crashing to the ground was followed by the test team’s 

hysterical laughter. The story, you will see, is much 

deeper. But the message in the example? Sometimes 

for no fault of our own, things just don’t go as planned. 

One way of dealing with it is to be able to laugh at 

ourselves. Of course, a setback itself is not to be taken 

lightly, but a leader capable of lightening the moment is 

more likely to set a positive tone for the try, try again.

Staying optimistic is important for team morale, 

specifically when a project is dealt a huge downsizing 

blow. After his project was cut significantly, Tom Sutliff 

was able to show his team that all was not lost and to 

help them focus on the fact that they still had a job to 

do. He had to balance the new project requirements 

with the fact that his team had been committed to 

the original project and would be personally affected. 

He stood back, got a new perspective, and upheld the 

positivity needed to lead them effectively. 

Even when you keep your chin up and work to the 

best of your ability, things still go wrong. It’s human 

nature. People train for years to make it to the Olympics 

and blow their shot during one crucial second in the 

spotlight. For Marty Davis, his crucial second was 

when the contractor dropped his 3,000 pound spacecraft. Rather than point the finger at those around him, 

Marty stood up like a true leader and acknowledged 

what he could do better if ever in this situation again.

The other day I read a quote that said something 

about a real leader needing a “backbone, a funny bone, 

and a wishbone.” The “bones” are representative of 

the human factors of leadership: courage, conviction, 

and perseverance, a sense of humor and the ability to 

not take oneself too seriously, and hope, optimism, 

and a positive drive. In this issue, the writers tell 

their stories about balancing these factors—along with 

the necessary Project Management skills, training 

and experience—a leadership fundamental absolutely 

worthy of our attention. • 

The Bare Bones of Leadership

Most of my late-August evenings were spent watching American gymnasts 

compete in the Summer Olympics

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 3

IN THIS ISSUE Jessica Simmons
4 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

REVIEW BOARD

JOHN BRUNSON of the Marshall Space Flight Center, Systems 

Management Office, is a member of the NASA 

Program Management Council Working Group. He 

supports the Agency’s Chief Engineer Office and 

MSFC in the review/development of Agency and 

Center Program/Project Management and Systems 

Engineering policy. He led the development of 

MSFC’s Project Management and Systems Engineering Handbook as 

well as in-house training modules in these areas. He served as project 

manager for three separate microgravity payloads that flew on various 

Spacelab missions. Prior to his project management experiences he 

served as the Integration and Test Team Lead for the Tethered Satellite 

System Mission. His career with NASA began in the late 1980s as a 

member of the Space Shuttle Main Engine Engineering Team.

DR. MICHELLE COLLINS works in the Spaceport Engineering & 

Technology Research Group at Kennedy Space 

Center. She has more than twenty years experience 

in aerospace spanning engineering, R&D and project 

management. She is on the Florida Institute of 

Technology Department 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 the Independent Technical 

Authority in the Independent Technical Authority 

and Systems Management Directorate at the 

Kennedy Space Center. Previously Hector was the 

Division Chief of Process Tools and Techniques 

in the Safety, Health and Independent Assessment 

Directorate. 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 more than twenty years. He retired 

from the Air Force Reserve as a Colonel and senior 

reservist at the Air Force Office of Scientific Research 

where he helped manage the basic research program 

for the Air Force. He holds adjunct faculty appointments at the Federal 

Executive Institute and the Center for Creative Leadership. Owen 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 soilanalysis 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, he has served in line, program, and 

project management, and has participated in research ranging from 

fundamental semiconductor physics to martian geophysics.

JODY ZALL KUSEK coordinates results-based management at the 

Africa Region of the World Bank. She is currently 

involved in supporting the efforts of several African 

governments to move to a focus of performancebased 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) mi ssion.

DR. GERALD MULENBURG is a member of the Systems Management 

Office at the NASA Ames Research Center in 

California specializing in project management. 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 

Science and Technology Directorate at the Ames 

Research Center. Joan currently is on detail to NASA 

Headquarters. Joan previously was the Associate 

Director of Aerospace. 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. Joan has been at Ames for 22 years, and 

recently completed the Sloan Fellowship to attend the Stanford 

Graduate School of Business.

HARVEY SCHABES is the Systems Management Lead in the Systems 

Management Office at NASA’s Glenn Research 

Center. He is responsible for providing oversight 

for independent assessments of programs and 

projects and for defining Center strategic plans and 

policies. He is also leading the Knowledge Sharing 

activities at GRC in collaboration with APPL. He 

started his career with NASA in 1983 in Icing Research, and since 

then has served in numerous organizations in support of the Space 

Station Program.

CHARLIE STEGEMOELLER has served as the Associate Director, 

Space and Life Sciences Directorate, Office of 

Bioastronautics at the Johnson Space Center since 

2002. The Office for Bioastronautics is responsible 

for coordinating and implementing the NASA 

Bioastronautics Strategy—the pursuit of tools, 

techniques, and policies to reduce risks, improve 

efficiencies, and return benefits to earth through the conduct of 

human space flight operations and research. He joined JSC in 1985 

and has served within the JSC Comptroller’s office, the former Space 

Station Freedom Project Office, and as a key member of the NASA/

Mir Phase One Program. He received the NASA Exceptional Service 

Medal in 1996, and became a member of the Senior Executive 

Service in 2002. 

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.
THE CENTER FOR PROGRAM/PROJECT MANAGEMENT

Research (CPMR) recently selected a first round of 

awards for research in the field of program/project 

management. CPMR is a newly established alliance 

between the NASA Academy of Program and Project 

Leadership (APPL) and Universities Space Research 

Association (USRA). The fundamental intent of this 

partnering is to initiate a formal forum for universities 

to better assist NASA in enhancing program/project 

management capability. Specific objectives start with 

establishing a relationship between NASA and the 

university community to engage in world-class research 

in the discipline of program and project management.

This initial objective is in no small part vital to 

better understanding and overcoming the challenges 

facing NASA and Aerospace missions. In the President’s 

Commission on Implementation of United States Space 

Exploration Policy Report, NASA is encouraged to 

pursue broadened relationships with universities (as 

well as other organizations) to promote more effective 

and efficient pursuit of our programmatic goals. This 

is a common-sense strategy since the US economy has 

long been fueled by the brainpower and wealth of talent 

located at the nation’s universities. 

In the 21st century, the role of strong partnerships among government, industry and universities, 

will continue to become more visible and essential for 

a successful space program. Government has the role 

of pursuing ambitious projects that are too visionary, 

costly or risky for the private sector to pursue. Industry 

is the engine through which work is completed (approximately 90 percent of NASA funding goes directly to 

industry partners.) The university sector has been a 

less-frequently tapped source of capability; leading 

minds are able to research, explore and study topics over 

a longer timeframe with scientific scrutiny and debate.

In recent years I have listened to NASA leaders ask 

fundamental questions about the nature of programs 

and projects. Many of these questions can be approached 

either from a quick-answer solution, or from the perspective of engaging and listening to what universities have 

discovered scientifically. From the latter we can then 

determine strategically, and with reflection, what best 

fits the unique demands of NASA projects.

Partnering with universities is certainly nothing 

new to NASA. USRA itself has its genesis in a request 

by the NASA Administrator in the 1960s to engage 

university minds in lunar research. However, all of 

these efforts have been in areas of natural sciences—

astrophysics, astronomy, life, space and earth science. 

Such collaboration with universities in the field of 

program and project management has been nonexistent. This is partly due to a bias I have witnessed 

that “we can’t learn anything from universities about 

program or project management.” This has no basis in 

reality as universities are increasingly managing NASA 

and DoD missions: University of Colorado, Boulder, 

Johns Hopkins, and Penn. State, for example. At the 

same time, universities have established world-class 

programs that develop program and project management expertise: Steven’s Institute, George Washington 

University, University of Maryland, and others.

It is consistent with the call of the President’s 

Commission to seek out and form sensible partnerships 

with academia and other organizations. The intent is for 

CPMR to promote cutting-edge research, foster greater 

collaboration, disseminate information, encourage and 

develop student councils, and generally serve as a 

resource for program/project management knowledge. 

The Center will also facilitate training, workshops, and 

developmental opportunities, providing an environment to openly pursue innovative concepts.

For more information on CPMR, contact Deputy 

Director David Holdridge at dhold@seabrook.usra.edu,

(301) 805-8396, or visit the CPMR website at 

http://cpmr.usra.edu/. •

A Partnership with Universities

The Center for Program/Project Management Research is intended to be a catalyst 

for engaging universities to collaborate with NASA in the important domain of 

program and project management

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 5

FROM THE DIRECTOR’S DESK Dr. Edward Hoffman
A GLASS CAN 

BE HALF FULL

—EVEN IN MICROGRAVITY

by Tom Sutliff

6 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
THEN THE INTERNATIONAL SPACE STATION CAME ALONG.

Our researchers needed a second-generation system, 

the SAMS-II, which would measure acceleration and 

vibrations for multiple payloads conducting experiments throughout the life of the station. Measurement 

requirements were all over the map with a variety 

of frequencies that needed measuring over a broad 

dynamic range, so it was essential to develop a robust 

system that would be flexible enough to accommodate 

all the particular users. 

We came up with a concept using the Space 

Station’s Ethernet as the means to talk between 

multiple remote triaxial sensor systems and a remote 

controller box. Ultimately, our job was to acquire data 

within the existing constraints of the station and to 

quickly and effectively get that information to the 

scientists. In 1994 we had a $2.1-million budget and 

a four-year development schedule aimed at achieving 

these goals. Technical risks were few and primarily 

resulted from uncertainty of ISS capabilities. At that 

point, we didn’t worry about a thing programmatically; 

our cup runneth over.

THE GLASS IS NOW...

Our fate, however, was tied to the fate of the Space 

Station. We were working on a system that would 

conduct experiments inside a structure that was being 

designed and built at the same time as our system. The 

Space Station began to go over budget, and they passed 

along the cost challenges to all the projects connected 

to them. By the end of a budget slashing in 1996, we 

had taken about $1.5 million in cuts. That left us with 

about $600,000 to do our job. No amount of magic 

was going to let us develop our full system—or at least 

a system that would meet the needs of all our various 

customers—for the budget we had left. 

As project manager, I had to deliver the bad news 

to the project team, but I didn’t want them to see this 

as the end. I said to them, “You know what our project 

looked like yesterday. Here is what it looks like today.” 

I held up our project logo and tore it in half to hammer 

the message home. True, what we had left was smaller; 

it couldn’t meet all the original mission requirements—

but we still had a project that was very much alive. And 

the good news: our customers still needed our sensors. 

We still had a job to do, and we needed to focus on 

what was still viable. We needed to stay excited about 

our project, even though its scope had significantly 

changed. It was going to take creativity and enthusiasm 

to work with what we had, and I planned to make the 

most of it. “The glass is not half empty,” I told them. “It 

is absolutely half full.”

Our most immediate problem was that we already 

had a signed agreement to deliver the first sensor 

subsystem to one of our customers. For now, we knew 

we couldn’t serve all of our intended users, but we 

could at least figure out a way to meet the needs of our 

initial customer. The rest would have to wait. 

WHEN CONDUCTING PHYSICAL SCIENCE RESEARCH IN 

SPACE, THE SMALLEST VIBRATION OR DISTURBANCE 

CAN DISRUPT SENSITIVE EXPERIMENTS. Back in the 

1990s we developed an instrument, the Space Acceleration 

Measurement System (SAMS) that flew on the shuttle to 

monitor the vibration environment—but it wasn’t very flexible. 

It could only measure vibrations for three users and only at 

fixed frequency ranges, and it had to be disassembled after 

each two-week mission to be refurbished, reconfigured, and 

readied for reuse.

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 7
IT’S ALL ABOUT PERSPECTIVE

The project team’s response to this challenge taught 

me how resilient people and projects can be when you 

give them the chance. We took a look at our entire 

system. We said, “Okay, together we’ve got to come up 

with a new strategy.” We already had a system design 

for the control unit and distributed sensors at multiple 

locations, but our original $2.1-million budget was 

needed to create the control unit for the sensors. Now 

we had no money for that, and we already had the 

first sensor delivery agreement. We asked ourselves, 

“How are we going to provide the researchers with 

the acceleration data they need without our onboard 

control system?”

As a team, we came up with a bright idea. The 

vehicle design already had laptops in the Space Station 

that they were using as vehicle systems controllers. 

If we used an extra one of these existing laptops as 

our onboard control unit, we could cut the cost of 

developing hardware. And since it was designed for 

flight aboard the Space Station, we didn’t have to worry 

about the cost of design, development, or testing to 

meet their requirements with a new system; it would 

already be flight-qualified by the International Space 

Station program.

There was still the issue of where to put the laptop. 

We weren’t the Space Station’s priority, and they weren’t 

going to let us just put it anywhere. So, once again, 

the team came up with the idea of adapting one of 

the Station’s existing International Sub-rack Interface 

Standard (ISIS) drawers to house the computer. The 

ISIS drawer is a standard configuration with power and 

data connections in the back. If we used a standard 

drawer, our control unit laptop would be tucked inside 

and out of the way. And since the drawer had been 

designed to the Space Station’s requirements as well, 

we again wouldn’t have to do any additional structural 

or thermal modeling, or worry about any other new 

payload constraints. 

Ultimately, we made an agreement with the 

program that they would authorize the project in two 

phases. The laptop control unit wouldn’t give us as 

much performance as we would’ve had on our original 

system, but it would give us enough to support our 

initial users. We knew we had to be satisfied with a 

temporary solution or none at all, so we planned an 

eventual upgrade to the control unit with a second 

iteration of the project. In the end, this temporary 

solution allowed us to serve our initial researchers as 

well as other Space Station projects.

AND SOME TO SPARE

In April 2001, we successfully launched the modified 

SAMS-II aboard STS-100. After the Station crew 

unpacked their bags, configured hardware brought 

aboard, and got things going, we acquired our first 

data and down-linked it successfully. Since then, we’ve 

accumulated over 16,000 hours of operation. We had 

the system up and running three years ahead of when 

we would have if we’d waited for the rest of our budget 

to be reinstated. 

As it turned out, there was a point when the control 

unit laptop failed—not our custom software and not 

our unique power system. As a result of the ‘built-in’ 

spares on the Space Station, we were able to get another 

AN EXPERIMENT’S LEGACY 

As with many small-scale projects within NASA, there is invariably a driving force behind the scenes focused on achieving the 

project’s technical and operational objectives. The Microgravity 

Acceleration Measurement System or MAMS is no exception to 

this rule; our friend Bill Wagar was that driving force behind the 

MAMS experiment. In accomplishing its important objectives of 

characterizing the sources of microgravity disturbances on the 

International Space Station, MAMS has currently accumulated 

over 1,100 days and over 25,000 hours of operation on the ISS 

since its launch on STS-100 in April 2001. 

Unfortunately, Bill passed away during the processing of the 

MAMS experiment and was unable to witness its activation and 

continued success. As a tribute to Bill and his dedication to 

MAMS, a commemorative sticker was designed and installed on 

the MAMS front panel following MAMS final processing at the 

Kennedy Space Center. Each time we are fortunate enough to 

view a video clip of the Destiny Module and catch a glimpse of the 

commemorative logo, we are reminded of Bill and how fragile life 

here on Earth can be. Increment 2 crew member Susan Helms 

summarized our feelings during a dedication offered on board the 

ISS in saying, “I myself would like to add my wishes to his family, 

my regrets that Bill has moved on to a better place, but also my 

congratulations to the work he did leave behind, because he was 

obviously extremely successful.”

8 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
laptop allocated to us, put our hard drive into the 

new laptop, and get the system back up and running. 

The paperwork required to do this—and the approval 

process for it—was much harder than getting the crew 

and hardware together to make it happen. The loop 

was closed. We had provided a versatile, maintainable 

measurement system. It was supporting multiple users, 

some of whom weren’t involved in the initial requirements development phase. And we did it in spite of 

technical and programmatic obstacles. 

I think that this comes back to the general attitude 

that we had about the project. As a project manager, 

you’ve got to remember to give a little bit of positive 

reinforcement along the way. Sometimes you have to 

keep reminding your team that the glass is half full, or 

at least there is enough in the glass to keep going.

There are always going to be cracks forming—but 

if you hold it tightly, you may find you can slow those 

leaks enough to make it to the finish line before the 

glass empties. Many times, what you need to do is 

believe in the positive—and then go make it happen. 

This time we were able to find a smaller glass. That’s 

what project management is all about. •

LESSONS

• Leadership requires realism coupled with optimism.

• Constrained resources are often the best way to 

provoke innovative solutions.

QUESTION

How can you artificially create a situation in which resources 

are frequently constrained for the purpose of triggering 

such innovation? 

The SAMS-II Interim Control Unit.

THOMAS SUTLIFF

is certified as a Project Management Professional by the Project Management 

Institute. He has been employed by the NASA Glenn Research Center in Cleveland, 

Ohio since 1983. In 1999, he began managing the Microgravity Combustion Science 

Program, which is chartered within the Office of Biological and Physical Research 

(OBPR), leading the formulation and implementation of physical science research 

projects aboard the Shuttle and International Space Station.

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 9
Unexpected Managing the

by Marty Davis

About a year and a half ago, I sent all of my 

people—the support contractors and the civil 

servants alike—to risk management training. 

It was part of an ongoing commitment to manage 

risk effectively on my weather satellite program 

at the Goddard Space Flight Center.

Unexpected*

*

*

*

*

*

*

*

10 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
THEY BROKE INTO GROUPS FOR A FULL DAY OF TRAINING,

and then they all got together for a workshop to 

create a list of the risks we faced. When I came into the 

workshop, I told them that they were free to suggest any 

risk they wanted, but they needed to understand that 

our senior management team was going to review all 

the submissions to decide what was relevant.

“Your imaginations could go wild,” I explained to 

them, “and you could generate hundreds of risks—that 

you get run over by a car, or other things like that. 

We can’t plan for situations like that. So don’t submit 

ridiculous things to us like, ‘We’re going to crush an 

instrument,’ or ‘We’re going to drop the spacecraft.’ 

Those just aren’t credible.”

At the end of the day, we collected all the risks they 

came up with, and we entered the credible ones into our 

system for tracking. We reviewed some of these risks 

every other week and revisited the entire list periodically. We were doing what we could to manage risk on 

the program—or so we thought.

You’re not going to believe what happened

On September 5, 2003, my wife and I left to go on 

vacation. We planned to spend two weeks wandering 

around New York State seeing all the sights. When we 

left the house, I turned off my cell phone, but kept my 

pager on—in case anyone needed to get hold of me.

We had a wonderful weekend. Then, bright and 

early on Monday morning, my pager went off. It was 

the Project Manager for one of our spacecraft. She 

had been trying to reach me on my cell phone since 

Saturday to tell me that the day after I left, LockheedMartin had dropped one of my spacecraft.

You can go through your whole career and never 

have someone drop one of your spacecraft. I think that 

would have been nice. So, one of the first things I did 

when I got back, was to inquire whether I could retire 

retroactively to Friday, so it wouldn’t have been on my 

watch. They just laughed that off.

Then we got to work. Almost immediately, four 

investigation teams were formed—two by LockheedMartin and two by NASA. Each was tasked to investigate a different aspect of the accident. These aspects 

included not only finding out what happened, but also 

looking for systemic problems in the program, determining next steps, and assessing liability.

What went wrong?

The “what happened” investigation didn’t take long 

to report its findings. To begin with, the procedure 

called for eleven people to be present for this operation. 

There were only six there. The Lockheed-Martin 

people had decided some time earlier that three of them 

weren’t really needed—but they had never redlined the 

procedure and notified us. The other three hadn’t been 

scheduled. The safety guy wasn’t even notified, even 

though he was listed in the procedure.

The operation was scheduled to begin at 6:00 a.m. 

They also should have had a NASA QA guy there, 

but when they called him, he said he’d be in later and 

to proceed without him. When the contractor’s QA 

person arrived at about 6:30 a.m., they were on step six 

of the procedure, and he said, “Oh, you’re on the sixth 

step. Let me sign off on the first five.” And he stamped 

them, without bothering to look at anything.

One of the procedure steps involved inspecting the 

cart to make sure it was ready to take the spacecraft. 

The test conductor said he used the cart a week ago; 

so what could have happened since then? He didn’t 

inspect it.

“

A 3,000 pound spacecraft dropping three feet 

onto a concrete floor gets damaged.

”

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 11
Then one of the technicians went over to the cart as 

they were lowering down the spacecraft. He told them 

something looked different, but the test conductor 

didn’t go over to look. He just said to go ahead. Turns 

out, there was a ring of bolts missing. That’s what 

looked different.

There were many steps 

bypassed that day, any one of 

which would have caught and 

avoided the problem. They 

ignored them all. They went 

on. They mounted the spacecraft. Then they went to turn it 

over on their dolly, and it hit the 

ground. A 3,000-pound spacecraft dropping three feet onto 

a concrete floor gets damaged. 

How damaged was a bit more 

complicated, but estimates ran 

up to $200 million.

Pointing fingers

After the Mishap Investigation 

Board (MIB) draft report came 

out, the test conductor and two 

other people got fired. It was 

Lockheed-Martin’s response to 

show that they wouldn’t tolerate 

this kind of activity. The way I 

saw it, the people who got fired weren’t necessarily the 

people who should have been blamed, because they 

weren’t the root cause of the accident. I felt the blame 

really should have gone higher in the organization. The 

Project Manager was replaced six months later.

There were several MIB conclusions with which 

I took issue. For instance, they put some of the blame 

on the government, because we didn’t have our own 

QA person there at the time of the occurrence. I believe 

that I should have reviewed all of the procedures and 

to have made certain that things were in place for the 

contractor to do the work properly and safely—safely 

for the people, and safely for 

our equipment.

They suggested that we 

needed to have a civil servant 

in residence at a plant for every 

project like this. But I don’t 

think it matters what badge 

someone wears. He or she 

just needs to have the right 

dedication, the right training, 

the right experience, the right 

everything. Being civil service 

doesn’t mean a damn thing. I 

have actually used civil servant 

leads and contractor leads at 

one time or another in the past. 

Either will work as long as you 

have the right person in the 

right situation.

But I was told by my management, “You will implement 

everything that is in the report.” 

No discussion, no exceptions.

Around that same time, I 

got my copy of the Columbia Accident Investigation 

Board (CAIB) report. After reading it, I called my 

deputy center director. I said that the CAIB Report tells 

me not to blindly do things that I think are stupid. So, I 

said we needed to talk about the MIB report. He started 

to laugh. Then he said that he would have to think 

about that one.

“

We thought we were doing what we could to 

manage risk on the program.”

Most spacecraft are safe on their dolly: workers separate 

upper equipment module from its dolly.

**

*

12 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
So, we had a little standoff. Since that time, I have 

spoken with the chairman of our investigation board. I 

found out that the MIB team didn’t unanimously agree 

to the things that I had problems with. The next time 

they meet in Washington, as a complete team, I’m going 

to get to talk to them.

An incredible risk repeated

A risk (dropping a spacecraft) that I had summarily 

dismissed as “not credible” at our risk management 

workshop actually has real-world precedence—both 

before and after our own event.

In mid-2000, another contractor, let’s call them 

Contractor-B, dropped a spacecraft. You didn’t hear 

too much about that, because it wasn’t a government 

contract; it was a commercial contract. They dropped it 

because of bolts that were missing in the dolly. (Sound 

familiar?) We knew they dropped it, but the details 

never came out.

The same Contractor-B dropped another spacecraft in 

the middle of December 2003. That made it into the Space 

News without much detail. They had just run a thermal 

vacuum test on the spacecraft in Seattle, Washington, and 

then dropped it while putting it back into the shipping 

container. Someone was hurt in that accident.

None of these are simple cases where a team 

missed one step and so the accident happened. It’s 

always a combination of skipped steps or miscommunications or dangerous assumptions. So, how do we 

mitigate this sort of risk?

First, we need to properly identify the risk. In our 

case and the two I sited above, the real risk wasn’t 

necessarily “dropping the spacecraft,” even though that 

was the end result. The risk in our case would more 

accurately be called “complacency.”

We had a long-term project with our contractor. 

Their attitude was that a spacecraft lift was not a risky 

thing. After years of doing this work, they saw it as 

very low-risk. But, in truth, it’s always a hazardous 

operation. It should never be considered low-risk. It 

always requires the full attention they gave it the first 

time they did it.

I’ve come to realize that, no matter how long 

you work in this business, new experiences will keep 

coming along. Each one broadens your horizon and 

helps you do better. •

LESSONS

• Safety requires strict adherence to procedures. Period!

• However, adherence to procedures in repeated operations 

also requires the careful attitude typical of “first-timers.”

QUESTION

To what extent is adherence to procedures—coupled with the 

right attitude, but unsupported by the proper experienced-based 

judgment—sufficient to prevent known risks, but insufficient in 

preventing the unknowns?

MARTY DAVIS is the Program Manager 

of the Geostationary Operational 

Environmental Satellite (GOES) at the 

NASA Goddard Space Flight Center 

(GSFC) in Greenbelt, Maryland. He 

is responsible for the design, assembly, integration, and test of the GOES flight and ground 

support hardware and for the launch activity and 

on-orbit checkout of the spacecraft.

Another safe transition: 

the Apollo Spacecraft 017 

Command Module is 

lowered onto a dolly.

**

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 13
WARNING

PROJECTS MAY BE CL

THAN THEY APPEA

BY COLBY AFRICA

14 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
THEY TOLD ME WHAT THEY WANTED TO DO TO THE

software, and they even showed me some prototypes. 

Their idea was to take the basic software tool that the 

large company was producing and make it more accessible to the customer. They would do this by building 

in flexibility based on user skill level and organizational 

maturity. I thought that was a fascinating approach, and 

I bought into it in a big way. I decided to leave my job 

and join up with the smaller company as their director 

of software engineering.

YOU’D BETTER KNOW THE SHOT

My former employer was a massive organization with 

tons of money. They can afford to try, try, and try 

again—but even they hate to do that. At a startup, you 

typically have one shot. Screw up, and you’re dead. 

I HAD BEEN WORKING FOR TWO YEARS AS THE TECHNICAL 

PRODUCT MANAGER FOR A LARGE SOFTWARE COMPANY,

WHEN THEIR PARTNER COMPANY GAVE ME CALL. THEY NEEDED 

GOOD SOFTWARE ENGINEERS TO CUSTOMIZE A NEW VERSION

OF SOFTWARE, AND THEY THOUGHT I WAS THEIR GUY. 

LOSER 

AR!

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 15
We were taking a product designed for everyone and 

trying to make it work for a smaller set of users. Here 

is something I learned quickly: When you’re modifying 

a commercial-off-the-shelf (COTS) product, it makes a 

huge difference if you have inside information. Why? 

Because there are undocumented features, a.k.a. bugs, 

which only people with an intimate knowledge of the 

product will know how to work around. It’s something 

to think about when you’re going to tailor a COTS 

product: How extensible is it from the get-go? 

We were okay because the person I had 

recommended to the company, a hotshot at my former 

company, had gone to work with them. He knew 

things about the old software that the current team 

didn’t even know. But even with him on our side, we 

were bootstrapped with limited resources. We needed 

money, so we had to find a client. 

WHAT THE IDEA LOOKS LIKE

At that point we had our working prototype. (I’m 

a firm believer that prototypes are the best way to 

communicate a vision.) We showed it to people and 

heard things like, “Oh yes, this is interesting.” We had 

a few customers in mind, and we visited all of them. 

It helps to get feedback from your customers as early 

as possible (again, the prototype was invaluable). Plus, 

there’s the other side of the equation, which is making 

certain that your customer has a sense (not a lot of 

detail necessarily, but a good sense) of the engineering 

constraints of your development effort.

We found a few small clients willing to pay for 

some of the research and development we needed to 

keep going. After a while, we got enough traction to 

go after the real capital—we needed VC money. That 

was a scary proposition. We couldn’t just go in and 

say, “Give me some money because I have a great idea.” 

These people were very technical and very sharp. But 

we apparently said the right things, because in the end 

we got the money we needed. That took some of the 

pressure off. We now had enough money to survive on, 

but a very short period of time (about a year and a half) 

to develop a product.

CLOSING IN ON THE DEADLINE

This was early 1999. At that point, I was trying to hire 

the development team that would take our product 

to the next level. Because we had to get things done 

quickly, we couldn’t afford to sit around thinking 

about the design for eight months before we wrote any 

code. We decided to take a milestone approach, where 

you basically pick a number of features or a quality 

bar—something—put a date on it, and run towards 

that date. 

We chose a rapid development programming 

language as the first technology to implement this 

software. We did this because the software was more 

readily modified as customer feedback came in. When 

we would show the software to the customers, they 

would say, “I think you should have this,” or “Based on 

my experience it should do this...” Then we could turn 

around, go to engineering for a couple of weeks and 

send a version of the software back to the customer that 

did what they were describing.

NO TIME TO PLAY

That was helpful early on because we could get the 

customer’s viewpoint almost immediately. It’s also a 

wonderful way to force your developers to buddy up 

with the Quality Assurance guys and get things done. 

That’s important because the natural instinct for 

software developers is to treat the project like a box of 

Legos. They want to take it home to see what they can 

create. You have to ask, “Okay now, is the customer 

really going to have a better experience if you put one 

more layer of lacquer on that sucker?” 

Their answer is usually, “What’s a customer?” 

As a project manager, you have to be able to take 

these people who think they are just playing with 

Legos and get them to do things on schedule and on 

budget. You have to make certain they understand the 

business purpose for what they’re developing. The role 

of the project manager has to be to articulate business 

requirements to the developers in a way that gets 

them jazzed—like reminding them that they’re doing 

something good for the company, or whoever the target 

MANAGING SOFTWARE HAS A LOT MORE TO DO 

16 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
customer is in the end. When it comes to managing 

software, I’ve found that it has a lot more to do with the 

people than it does with the processes.

GETTING TOO CLOSE 

Our ultimate constraint was a window of opportunity, 

which was rapidly closing. Our one competitor was 

getting ready to release. We had some money, but we 

still had to do what’s referred to in the industry as a 

“death march” towards our deadline.

I was the development manager, or what is effectively 

the project manager—and I made the absolute worst 

mistake a manager can make. As development manager, 

your job is to delegate, but I couldn’t keep my hands out 

of the coding. 

Originally, I didn’t think that we had the 

manpower to separate the functions of management 

and development. In hindsight, we should have. I was 

working on a number of low-level subsystems, and 

other developers couldn’t get started on their work 

until mine was flushed out. I was supposed to be 

managing these people, and here I had put myself on 

the critical path.

It was just a crazy time. I lost 20 pounds. My team 

kept asking, “What happened to our development 

manager?” I would go into my office before it was light, 

and I would leave after it was dark. Instead of meeting 

with them to talk, I was “instant messaging” my leads 

to get status reports, because I was busy cranking out 

all of this code. 

A HIGH PRICE FOR SUCCESS

We launched in October 2001, and it was a big success. 

But I had to take a hard look at myself and ask, “At what 

personal cost?” 

I had previously thought of the developers as 

the guys who got wrapped up in creating rather than 

efficiently tailoring a product to the needs of the 

customer. Now I was faced with the truth: I had become 

one of the Lego people, obliviously adding layer after 

layer of blocks. Don’t get me wrong—we software 

people do it because we love it, we have a passion for 

it. But I had let myself become overtaken by just one 

aspect of the project rather than the whole. I was losing 

weight, never seeing daylight, having virtually no 

person-to-person contact with my team...

It was a great experience, but I wouldn’t do it again. 

I had to figure out the hard way that software itself is 

not the answer; project management is the answer. It’s 

all the people, processes, and technologies working 

together. Rather than being one of the Lego people, I 

knew I needed to figure out exactly how to motivate 

them so that together we could create products that 

make good business sense. •

LESSONS

• When tailoring a COTS software product, you should 

recruit developers who have an in-depth understanding 

of the intricacies of the product.

• Establishing open communication with your customer 

is not only intended to understand customer requirements 

but also to convey challenges you face on the project.

QUESTION

How does an active project manager effectively delegate and 

manage without “sticking his hands in” the actual project?

 WITH PEOPLE THAN IT DOES WITH PROCESSES.

“I wrote my first piece of software when I 

was 11,” says COLBY AFRICA. “When 

I was 15, I wrote my first production 

software, which was promptly rewritten 

by a 13-year-old, who went on to work 

at the media lab at MIT. The lesson 

there is that someone is always smarter and younger 

than you are.”

In spite of his prodigious gifts, Africa never intended to 

become a software developer. At Microsoft from 1994 

through 1999, he rose through the ranks to become a 

product manager—making time to write a little software 

on the side. Today, he works for Robbins-Gioia, a project 

management consulting firm in Washington, D.C., and is 

too busy assisting project teams around the country to 

write any software code even if he wanted to. 

“I have a bunch of developers who work for me now,” he 

says. “Whenever I want to get my fix of software, I have 

them show me something cool they’re working on.”

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 17
1. Cos t Es t ima t i ng

2. Pr ojec t Execu t i on 

 Plann i ng

3. Eng i nee r i ng, 

Pr ocureme n t, and

4. Lega l and Corp ora te 

Req u i reme n t s

Cons t ruc t i on Plann i ng

Cleaning Out 

18 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
t The Closet

I HAVE NOTED DURING MY CAREER THAT THERE IS A NEVER-ENDING

AMOUNT OF RULES AND RESTRICTIONS FORCED UPON PROJECT 

MANAGERS UNDER THE GUISE OF HELPING THEM “BE SUCCESSFUL” 

IN MANAGING THEIR PROJECTS. IT APPEARS TO BE A ONE-WAY STREET; 

MANY REGULATIONS ARE ADDED, BUT FEW (IF ANY) ARE REMOVED. 

By W. Scott Cameron

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 19
WE NEVER SEEM TO BE ABLE TO TAKE THE 

time to clean out our project management closets and 

remove the rules and regulations we have outgrown, 

the ones that have gone out of style, and the ones we’re 

not sure why we put in place to begin with. 

I had the opportunity to assist in cleaning 

out such a closet as part of a project management 

leadership team I was part of. Prior to beginning the 

process, each member of the leadership team had 

reviewed the quantity and quality of our existing 

technical standards (TSs) and standard operating 

procedures (SOPs) with the capital management 

practitioners in his or her area. The feedback we 

received from these reviews was a resounding, “We 

have too many, at times they contradict each other, and 

we need a simpler system.” Those were just the positive 

points of our system.

Since we were in the process of “streamlining” the 

capital management TSs and SOPs used to define and 

execute our capital projects, we had an opportunity to 

completely rethink each one. At first we felt that we 

had done a pretty good job: We’d reduced the number 

of TSs from 18 to 11, and SOPs from 32 to 24. But 

as we reviewed our new TSs and SOPs, we noted our 

“closet” was still full. We had simply rearranged all 

the clothes by reformatting or renaming the standards 

versus actually taking something off the plate. In some 

cases, we actually changed the font size so it only 

appeared that there were less!

Like the closet that accumulates all the stuff we 

buy and never get rid of (and just end up moving 

around) we felt our list of TSs and SOPs needed a 

major cleaning. We went back to the drawing board, 

took an initial cut, and reduced the TSs from 11 to 7 

and SOPs from 24 to 7. People were feeling fairly good 

about this reduction effort, but many of us questioned 

why we couldn’t reduce more. As project managers 

described their role in simplistic terms, we always 

came down to the fact that they were accountable for 

managing cost, schedule, and technical correctness. 

And it worked; now we had just three main topics!!! 

We told the team reviewing the standards to be 

merciless with their reduction efforts, leaving only the 

core requirements and keeping in mind these three 

areas. The team came back with a proposal reducing 

the number of TSs and SOPs to just four each:

1) Cost Estimating

2) Project Execution Planning

3) Engineering, Procurement, and Construction 

Planning

4) Legal and Corporate Requirements

As our leadership team reviewed this proposed 

change, they realized how much “stuff” had been 

added to the TSs and SOPs over the years. These 

additional TSs and SOPs didn’t add any actual value 

and went a long way toward explaining why the project 

management community was feeling so overburdened. 

In the beginning we expected our original 11-standard 

proposal would leave the practitioners feeling that 

we’d really helped them and streamlined the process. 

However, all we’d actually done was rearrange the 

existing data in their closet, making things harder to 

find. With our four TSs and SOPs, we felt we had left 

just the right amount of clothes in the closet.

We decided to deploy the four TSs and SOPs, 

figuring if our project managers experienced problems, 

IT IS MANAGEMENT’S RESPONSIBILITY TO UNDERSTAND, REVIEW, AND 

PERIODICALLY EDIT THE REQUIREMENTS IT PLACES ON ITS PROJECT 

MANAGERS AS CRITERIA AND TIMES CHANGE. THIS IS ESPECIALLY 

TRUE SINCE IN THE PAST WE TENDED TO ADD REQUIREMENTS THAT 

MAY OR MAY NOT HAVE ADDED VALUE. 

20 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
we could recreate what we had removed. In our 

opinion, the risk of negatively impacting our projects 

was small. We were excited to find out the project 

management community was delighted with these 

reductions and felt empowered by them. It gave them 

more flexibility to manage their projects and develop 

their own personal management style.

Still basking in the glow of this successful 

reduction, our leadership team decided to tackle our 

capability assessment tools—another closet to clean 

out! We asked for two volunteers to review and propose 

reductions. Each one of these tools had 16 sections and 

anywhere from eight to 16 components in each section. 

Within two months the individuals returned with their 

proposal and beamed that they had combined the 

tools (GREAT), reduced the total number of sections 

from 32 to 16 (not great, but OK), and each section 

now had 15–30 subcomponents (UGH). Thus, the 

closet was still full but had been rearranged. We forgot 

how to clean out the closet again. The team rejected 

their proposal! I volunteered to try and streamline 

these tools by reapplying the process we’d used with 

the TSs and SOPs. In the end we agreed on one tool, 

four sections, and 6–10 sub-points in each section. 

The closet was cleaned out!

After six years, the four standards and SOPs and 

the capability tool have stood the test of time, and our 

project management success measures have improved. 

The streamlining process enabled us to:

1) Reduce the effort, costs and time required to 

maintain these standards and SOPs.

2) Focus the project managers on what is truly 

important, and allow them the creativity to 

develop their own style.

It is management’s responsibility to understand, 

review, and periodically edit the requirements it places 

on its project managers as criteria and times change. 

This is especially true since in the past we tended to 

add requirements that may or may not have added 

value. Thus, we were just building an extra closet to 

house our new stuff, versus cleaning out the original 

one to solve the problem.

Management needs to listen to its practitioners 

to determine how they can help the system. 

Statements like “do more with less” are interesting, 

but management needs to be accountable to determine 

what rules and regulations are truly necessary 

for project managers to be successful and deliver 

successful projects. •

LESSONS

• The natural tendency in organizations is to add new 

standard project procedures and guidelines throughout 

the years, without deleting old ones.

• It is management’s responsibility to periodically 

review and edit standard project procedures and guidelines, leaving only the minimum core requirements. 

QUESTION

How can you encourage, in today’s dynamic environment, 

appropriate flexibility necessary for implementing standard 

operating procedures?

W. SCOTT CAMERON IS THE GLOBAL PROCESS 

OWNER OF PROJECT MANAGEMENT FOR THE 

PROCTER AND GAMBLE COMPANY IN CINCINNATI, 

OHIO. HE HAS BOTH MANAGED CAPITAL 

PROJECTS AND PROGRAMS, AND DEVELOPED 

OTHER CAPITAL MANAGEMENT PRACTITIONERS 

WITHIN THE COMPANY’S VARIOUS BUSINESSES 

FOR MORE THAN TWENTY YEARS.

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 21
22 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
It was fourteen years ago, and I remember 

it well. It seemed that the right hand didn’t 

know what the left was doing. It was crazy. 

Starsys was only eight people, and deadlines 

were being missed because someone didn’t 

know what someone else needed. How could 

a handful of people be this disconnected? 

Maybe a daily meeting would help.

The Morning

Meeting

By Scott Tibbitts

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 23
LITTLE DID I KNOW THAT WE WERE INITIATING A PROCESS

that would last for two decades. The idea was simple: 

a short, all-hands meeting once a day to maintain the 

week’s actions item list. Not too tough a challenge with 

eight folks, but quite a challenge as we grew to a 140- 

person company.

NOTE TO SELF: 1992

Things that DO NOT work for getting a meeting 

to start crisply at 8:00 a.m.:

1. A heartfelt plea that timeliness is next

to godliness

2. $1-per-minute penalties for latecomers

3. Playing the theme from 2001: A Space Odyssey

with the expectation that everyone is in the 

meeting room by the end of the music

Things that DO work:

1. A company-wide bell that rings prior to 

the meeting and lasts exactly 60 seconds

2. A “quarter-to-the-party-fund” penalty 

for those who aren’t in the room by the 

time the bell ends

CHAIRMAN OF THE “BOARD”

The meeting developed its horsepower during the 

first year when we started using it to publicly declare 

program actions for upcoming days. A whiteboard was 

placed in the front of the room, and each program had 

its own area on it. Actions were written, along with the 

responsible party and the committed date of delivery. 

Anything could go up on the board—major 

or minor—as long as it had a date. Humor 

was encouraged. Peer pressure provided the 

impetus for folks to get their actions on 

the board; not doing so was to imply 

that work was not being done. 

We cycled through everyone in 

the company, each having the opportunity to run the board for a week. The 

clear message was that the board was by and for 

the team. Each day a tally was made of what tasks 

were completed and which were moved out. The pulse 

of the company was there to see. As everyone became 

aware of each other’s activities, the cross-strapping 

necessary for a high performance team just happened. 

It wasn’t uncommon to hear something like, “Tom... 

I’ve worked with that potting material before and had 

some problems. Let’s talk.” 

READING THE MINUTES

But we found out that starting on time was only half the 

battle. How could we limit the meeting to only fifteen 

minutes? A second bell was added that rang at the end 

of the meeting for 60 seconds. Suddenly the meeting 

leader was managing the meeting to finish before the 

bell. Group pressure for the meeting leader to perform 

in the time given was a powerful motivator: the board 

managers, driven by the bell, became masters of 

efficiency. We found that we could tag in on more than 

50 actions in less than 10 minutes. 

BUT CAN WE KEEP OUR PROMISES?

The board provided a way to measure the day-to-day 

agreements made between coworkers, “Anne, I’ll get 

that to you by Friday.” These were now tracked giving 

us a window into the “agreement integrity” of the 

company. We started tracking these agreements and 

posting the track record for all to see; what percent of 

the informal day-to-day agreements that were made 

between people were kept? 

“ A cultural shift had

happened—and a new

habit was created—

that lasted for years.”
Year after year the number hovered around 50 percent, 

and that just seemed low. We knew that if the number was 

too high, the company would be losing its nimbleness. But 

only 50 percent? We knew we could do better than that.

NOTE TO SELF: 1995

Things that DO NOT work for raising the 

“agreement integrity” of the company:

1. Heartfelt pleas that keeping agreements 

is next to godliness

2. Everyone in the room making a loud buzzer 

sound every time an agreement is missed

3. Daily tracking of agreements and results with 

a clear goal posted on the graph, and a daily 

focus on how we are “missing the mark”

We tried everything we could think of to bring this 

number up. Nothing worked. Was this a physical law 

of organizational behavior, akin to the speed of light, 

which would never be bettered? We were not yet ready 

to throw in the towel. We had to get out of the box. 

Way out.

MASSAGING THE PROBLEM

I stood up in front of the meeting one morning. “Ok...

here’s the deal. If this company can exceed 75 percent 

on the board and hold it for two weeks, we will bring 

in two masseuses on Friday. We will set them up in a 

conference room, and everyone in the company will get 

a massage. Thereafter, every two weeks that we are above 

75 percent, we will do the same thing.” Much discussion 

followed—mostly the “are-you-serious?” kind.

It took 24 hours. The next day the company went 

from 50 to 77 percent. Folks were on the edge of their 

chairs as we worked the board each day, and at the 

end of the two weeks the metric was solidly above 

75 percent. We looked for sandbagging, but it wasn’t 

there. The quality of the actions had not changed. The 

company was keeping its agreements. 

Good to our word, we set up the two masseuses, 

and everyone had a 10-minute slot. 

Was it disruptive to our schedule? To some extent.

Was it expensive? Yes...both the cost of the masseuses, 

and the lost time added up. Was it worth it? Absolutely. 

The value in increased efficiency more than paid 

the bill. It also provided a morale boost by providing

an honoring benefit: “You are working hard, here’s

your reward.”

The massages continued with the company making 

the mark about three of four times. After the first 

year the newness wore off, and the motivational effect 

lessened. After a year and a half it was time for a change, 

and the massages ended. But the 75 percent agreement 

result was there to stay. A cultural shift had happened—

and a new habit was created—that lasted for years.

THE PRACTICE EVOLVES

Over the years the morning meeting has become a 

primary generator of company culture. Through it new 

traditions have been born, legendary discussions have 

been held and critical values debated. As with many 

worthy things, over the years it too has changed. In its 

current form in a 140-person Starsys, it is a twice-a-week

meeting. We no longer track the actions; that became 

impractical at about 75 people. In its place, once a 

week, each company department makes a 10-minute 

presentation on any topic they choose. To keep these 

worthwhile, a show-of-hands vote is taken immediately 

afterwards; was that a great use of time, a good use 

of time, or a poor use of time? The highest scoring 

department every quarter gets to take their department 

out to dinner. 

The one thing that has not changed through the 

years is the practice of “help sessions.” These were 

suggested by an employee almost 12 years ago. At 

the end of the morning meeting, team members can 

request the help of anyone else there and can meet with 

them for a couple of minutes. With everyone in one 

place at one time, it is a great way to make unscheduled 

links that help keep a team communicating. For those 

five minutes, the room is filled with small standing adhoc meetings that kick off the day. 

The question that is constantly raised, both from 

within the company and from outside, is: “Is it worth 

it?” You can do some simple math and scare yourself 

with the cost of those meetings. But at the end of the 

day, it’s like the ad says, “The value of getting everybody 

together in one room at one time, twice a week,

to collaborate on how to better accomplish our

goals—priceless!” •

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. His other ASK

features appeared in Issue 16 and 18.

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 25
“There is no music in the rest, but there is music in the making.” 

— Johnny Albea, Director, Turrentine Junior High School Band, ca. 1960

PUTTING 

PATIENCE

TO THE TEST

“THERE IS NO MUSIC IN THE REST, BUT THERE IS MUSIC IN THE MAKING.” 

—Johnny Albea, Director, Turrentine Junior High School Band, ca. 1960

BY RAY MORGAN

26 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
IT WAS LATE IN THE DAY, IN THE SUMMER OF 1985. TWILIGHT

had come, the sun was down and the sky was getting 

darker, making colors hard to distinguish. Lights 

were coming on around us—beyond the two-lane 

highways that formed the boundaries of the milesquare abandoned farming field. 

Following a series of delays and last-minute fixes 

and changes, I felt compelled to make the first tail-less 

flight of our “yaw model” for the pterodactyl today. 

Over and over, we had managed to keep its nose into 

the wind by strapping it to a swivel chair base on the 

roof of my van. We had repeatedly launched the bird 

with a “launch trolley” fitted with a standard tail and 

wheels. All that was left for this phase of the project 

was to prove that we could launch the full-sized bird, 

release the trolley cleanly, and have it automatically 

stabilize itself in flight with no tail. 

Conditions were not very good—it was getting 

difficult to see details of the faked-out, radio-controlled 

bird even from just 50 feet away, and we were all tired 

from working late the previous night and through the 

day. We urgently needed to prove that the autopilot 

could wiggle the head, fingers, and wing ailerons fast 

enough to stabilize the bird. Otherwise, we would not 

be able to build the complete version in time to make 

the filming dates for the Smithsonian’s IMAX movie, 

On the Wing.

“What could go wrong?” I asked myself, but 

thinking on my feet at this point was too difficult. 

Feeling too much pressure, too tired, and too hopeful 

it would work, I stepped on the foot switch that started 

the towline winch. The crude, half-scale replica of 

the 36-foot flying reptile rapidly accelerated toward a 

return pulley staked down a quarter of a mile away. 

I kept my left index finger touching the emergency 

parachute release, which was designed to allow the 45-

pound robotic dinosaur to float down with (hopefully) 

minor damage. “The big guy would have gone for it, 

too,” I told myself.1

My doubts began to grow as the model’s form began 

to blend into the darkening landscape, and bounce down 

the dirt road toward the setting sun. I pulled back on the 

stick (by faith more than vision) and the bird rotated and 

began its rapid ascent upward, finally appearing in profile 

as it shot above the horizon in the distance. The backlit 

darkness distorted my judgment of its distance and 

altitude, so I listened as the electric winch seemed to slow 

down. I commanded a hard left bank to turn the model 

away from the towline, effecting its automatic release. 

Half way through the turn, I switched on the autopilot. 

The large head turned side to side and simulated “fingers” 

wiggled on the outer wings.

Seeing that the bird began to roll to wings level with 

the autopilot on, I knew it should be safe to release the 

stabilizing trolley and tail. I aimed the model back past 

our vantage point as it glided down from its release point, 

 1 My boss, and the founder of our company, had sold the idea of a flying replica of the largest 

flying animal ever that ever lived to the Smithsonian and to its primary sponsor, Johnson Wax. 

He had made the task sound easy, with the famous words “If nature did it 65 million years ago, 

it should be easy to replicate today.”

The largest of all flying pterodactyls, the Quetzalcoatlus 

Northropi, had no tail. Its large beak and head at the 

end of a long neck, made flying it equivalent to shooting 

an arrow backwards with its feathers in front. A major 

problem requiring solution before designing and building 

the final version, was to determine if we could overcome 

this instability with an automatic system. The system used 

natural features of the real animal, but with electronic 

sensors and electrical servos.

The grounded yaw model.

MARTYN COWLEY, AERO VIRONMENT

The Quetzalcoatlus Northropi in flight. The yaw model just before launching.

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 27
600 feet above the ground. We commanded the release 

of the stabilizing trolley, hoping to see the bird model fly 

straight on its own. But it didn’t quite work as planned.

Instead of simply falling away from the bottom of 

the pterodactyl’s belly, the tailboom dropped down and 

to one side slightly, but remained attached (loosely) to 

the yaw model. 

I had a quick choice to make. I could immediately deploy the recovery chute, or I could try to shake 

the trolley loose by commanding control hard-overs. 

Deploying the chute could stop forward flight and 

reduce the fall rate, or it could tangle in the trolley and 

cause the whole mess to crash down together. I decided 

to try to shake it loose.2

I had to be careful because the bird, at best, was 

expected to be conditionally stable without the tail. This 

meant that small perturbations from straight and level 

flight could be handled by the autopilot, but very large 

ones would cause the bird to “swap ends” in a real hurry. 

Gradually I applied more and more violent control 

inputs, trying to shake off the reluctant trolley.

At last, the trolley and tail assembly fell free. 

Unfortunately, the bird was also approaching the edge 

of the field. I had been so focused on the trolley, and the 

motions of the model, I hadn’t kept an awareness of how 

far it had flown away in the dark sky. Worse yet, the yaw 

model was tumbling out of control, and it appeared to 

be falling towards the two-lane road between the field 

and the horse stables. I quickly scanned for car lights, 

but didn’t see any ... small relief. 

Suddenly, the bird rebounded back up from about 

40 feet above the ground. It had hit some hightension wires running along the roadway. At this point, 

everything seemed to take place in slow motion. It 

cartwheeled back away from the roadway, and toward 

the field ... a big relief. 

I was waiting for some type of electrical event, but it 

seemed at first we had been very lucky. Then I noticed 

a wave moving through the wires toward me, and then 

reflecting back from a pole and propagating toward 

where the bird struck. 

KABOOM!! There was the brightest flash that I 

have ever seen in real life. An arc between the wires 

made a large ball of an intense white—almost a 

miniature sun. It reminded me of movies I had seen 

of the first atomic test at Alamogordo. Then I heard 

a sharp, short, electrical buzzing noise behind me. 

Immediately, the entire neighborhood ... houses, streetlights, and the horse arena beyond the road ... went 

dark, as wires fell from a transformer to the ground.

There was a sizable crowd out to see this first flight 

attempt—families and friends of my employees, mainly. 

When the bird first fell out of control, there were 

screams. When the bright flash went off with a large 

boom, there was a collective, “Uh-Oh!” After the bird 

had settled to the field and everyone recognized there 

were no serious consequences other than blacking out 

a large fraction of the small town of Moorpark, CA, 

hysterical laughter set in. I, however, was not laughing. 

One of the flight team members (a natural comedian), 

yelled, “Well ... I’ll see you guys later.”

WHY YAW?

When an airplane turns left or right, it is said 

to “yaw.” The yaw axis can be envisioned as 

a vertical string suspending the aircraft about 

its center of mass. For the pterodactyl, the 

shape of its large head made it develop strong 

aerodynamic forces about this axis. With the 

head being so far in front of the center of 

mass, and with no vertical tail to counteract 

the forces it could develop, it made the replica 

want to turn and face backwards. To solve this 

problem, we had to make the head part of the 

active control system. In fact, we found we 

also had to use the “fingers” out on the wings 

(as spoilers), and use warping of the wings 

to assist the head. The latter two devices 

increased drag near the wing tips to help the 

head keep pointing into the wind.

2 The bird’s chute was designed to be deployed when free of the trolley; the trolley itself had its 

own chute that automatically would open once it left the bird.

28 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
RAY MORGAN IS HEAD OF MORGAN AIRCRAFT 

AND CONSULTING AND A SENIOR TECHNICAL 

ADVISOR TO NASA. MORGAN OVERSAW THE 

DEVELOPMENT OF MORE THAN 35 UNMANNED 

AERIAL VEHICLES (UAVS), INCLUDING NASA’S 

HELIOS AND PATHFINDER AIRCRAFT, DURING HIS TENURE AT 

AEROVIRONMENT, INC. HIS OTHER ASK FEATURES APPEARED IN 

ISSUE 16 AND ISSUE 18.

Epilogue: The Quetzalcoatlus Northropi full-flying replica, with wing 

flapping, automatic stabilization—and nearly life-like appearance matching 

the paleontologists precise specification—made its first successful flight on 

January 7, 1986, one week before filming was begun in Death Valley, 

CA. Twenty-two successful flights were made for the movie, for which it 

became the main star. The movie, On the Wing, produced by Francis 

Thompson and directed by Bailey Silleck, was shown at IMAX theaters at 

the Smithsonian Air and Space Museum and around the country.

The yaw model was towed to a height of 600 feet 

before beginning its glide down.

I had made some serious errors in judgment, 

and I was kicking myself mentally, while at the same 

time steeling myself for dealing with the repercussions. The first thing I needed to do was to call 

the power company and get someone out to repair 

the downed line. The second thing, which I was 

dreading the most, was to speak to the owner of the 

horse arena, who was obviously going to lose some 

income for the evening. I was just finishing a call 

to the power company on a mobile phone, when I 

saw the stable owner crossing the road, looking for 

someone to blame. 

Surprisingly, when I explained what had happened, 

apologized, and offered restitution, everyone was quite 

reasonable. The power company guys thought it was 

funny (total repair bill only about $600) and when the 

stable owner found out what it was we were testing, he 

even refused compensation.

We had taken pride in the fact that, as a company, 

we were quick to put prototypes in the air when developing innovative aircraft, and could rapidly learn what 

the real problems were to make changes faster than 

most aerospace companies could develop analytical 

models. And, to a large degree, there is much merit 

in testing unique designs in flight as soon as possible, 

particularly with sub-scale models. I still support that. 

However, like in all of life, there is a balance. Here, 

we found that we had gone too far to the side of “hurry 

up and get something in the air,” and it actually cost 

time and money, rather than saving it. What’s more, we 

had been extremely lucky that no one was injured, or 

even killed. The model was not that big at 45 pounds, 

but it certainly could have done serious damage when 

falling hundreds of feet. We were very lucky not to have 

hit a car driving down the road, or someone walking on 

the ground. The power lines could have hit and even 

electrocuted someone when they fell.

In hindsight (there was a lot of discussion among 

the team) we recognized that we (me, mainly) were 

just too impatient to get into the air, particularly with 

a potentially lethal flight vehicle. Because of this and 

other similar experiences, we ended up with what I 

consider a very good rule: no work on the aircraft the 

day before a planned flight test. By bringing patience 

into the flight test program, it gave us a chance to rethink what we were doing, and look for stupid plans or 

actions before we went to the field.

To sum it up, it is good to rapidly put prototypes 

into the air and learn the real problems. Irv Culver, 

famed engineer of the old Lockheed Skunk Works, 

was a champion of this approach. That said, there is a 

time for patience in the test world to allow one to think 

everything through, to create a plan for predictable 

events, and to make sure nothing obvious has been 

overlooked. Finding that balance is critical to being a 

good project manager. •

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 29
SPECIAL FEATURE

U

U

NO LAUNCH

B E F O R E I T S T I M E

2 0 0 4

C A L I F O R N I A

C E

B Y B I L L T O W N S E N D

E

30 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
UU

E

AURA IS AN EARTH-

observing satellite 

developed to help us study 

the quality of the air we breathe. It will look at the 

state of the ozone and the atmospheric composition in 

regards to the Earth’s changing climate.

I headed to California on July 5, 2004. The plan 

was that the satellite would launch on the tenth, but 

we had a few problems getting it off. This was the 

fifty-ninth launch of my career, and it was also a little 

different than most of my previous launches. Most of 

the time it’s weather that postpones a launch; there 

aren’t usually that many technical issues this late in the 

game. This time, however, we had several problems, 

equally split between the launch vehicle and the space-

craft. I remember a member of the crew asking me, “Is 

this normal?” And in my experience, it wasn’t.

A WRENCH IN THE WORKS

We had three significant spacecraft issues during 

the launch campaign. These problems, together with 

the launch vehicle problems, ended up postponing 

the launch five days. During that time, the mission 

management team met 11 times at all hours of the day 

and night to try to sort things out. I myself held four 

special reviews.

V

As Deputy Director at NASA’s Goddard Space Flight Center, I was responsible for overseeing the launch of the Aura spacecraft from atop a Boeing Delta II rocket out of Vandenburg Air Force Base in July 2004. 

V

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 31
The first problem was that some tools had been 

misplaced during final spacecraft closeout, which could 

present a problem if they were left on the spacecraft 

during launch. A wrench was lost and then found. 

Then we realized that we had also lost a flashlight. 

The first step to solving this problem was interviewing everyone who had been involved with getting the 

spacecraft ready for launch. This was a massive effort, 

even extending to people overseas. Then we were able 

to make a timeline of activity based on photographic 

evidence, which were time-tagged and fairly easy to 

review. Through these measures, we were able to limit 

the possibility of the flashlight’s whereabouts to an area 

that made up about 10 percent of the spacecraft.

THE LIKELY STORY

We were able to determine that the flashlight had last 

been seen on a processing table. Something called 

“scrim,” which is a plastic covering that is taken off the 

fairing during its installation on the launch vehicle, had 

been put on the table. The flashlight was also on the 

table, and it was probably swept off with the trash. We 

even checked the dump, but the search was futile.

Based on all the evidence and interviews, we were 

able to put together a story that convinced us that the 

flashlight was not on the spacecraft. What was really 

frustrating, however, is that all of this investigation 

could have been avoided. I found out that there was 

someone along the way who had noticed immediately 

that the flashlight had been misplaced. It was a week 

before they finally came forward, and by that time, the 

trail was cold. The person didn’t speak up, because 

he was initially afraid to report it. I realized that 

there needs to be a clear message sent on this type of 

thing: No one is going to get in trouble for calling our 

attention to potential problems. It’s the kind of behavior 

that we need to encourage.

SHAKE, BUT NO RATTLE

The second problem had to do with a transistor failure 

in another program. A nickel-plated transistor can had 

been improperly cleaned, and this created the possibility of particles being generated inside the can. As 

long as they were smaller than about two thousandths 

of an inch, we wouldn’t have a problem. But particles 

were reported to be larger than that. 

The screening technique for this type of problem is 

to vibrate the transistor and listen for particles rattling 

around. This process is able to detect particles down to 

one thousandth of an inch. But the parts reported as 

having particles larger than two thousandths of an inch 

had passed this test. One of the team members said that 

the noise should sound like “an acorn in a coffee cup” if 

it were that large, but there was no noise.

I asked to push back the launch date in order to 

figure out the problem. It wasn’t a popular decision, 

but I felt it was a necessary one. I was able to facilitate 

a discussion between our parts and materials engineers 

and those from the program that had the problem. It 

turns out that there had been a miscommunication. 

The “particles” were actually very quiet flakes. That’s 

why all the parts passed testing based on an acoustic 

response—the flakes didn’t make much noise. 

We then did a thorough risk assessment for every 

application of this part in both the spacecraft and the 

instruments. Thanks to redundancy, we convinced 

ourselves we were OK. Had we just gone ahead with the 

launch, it would have been successful. But we wouldn’t 

have known why it was successful. I felt we needed to 

take the extra time to figure it out.

THE MINORITY REPORT

The last problem occurred during the countdown when 

there was a bit flip in the solid state recorder. We had seen 

Aura satellite—artist’s concept.

32 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
this occur occasionally on Aura’s sister spacecraft, Aqua, 

and it wasn’t mission-threatening. But then it happened 

again one hour from launch. I asked for a summary of 

the situation, and I was basically told that the spacecraft 

was ready to fly “as is.” I asked if there was anyone that 

disagreed with that, and I was told reluctantly that there 

was one person. His name was Michael.

I got Michael on the net and asked him to explain 

his opinion about the problem and his reservations. 

It turned out that he had seen the problem in the test 

program, but no one was worried because it hadn’t set 

off any alarms. While he was explaining, there were 

other people on the net that kept saying we needed to go 

ahead with the launch. As the conversation progressed, 

I could feel him getting pressure from the rest of the 

team and begin to change his mind. I again made the 

unpopular decision to delay the launch until the issue 

could be ironed out.

So after speaking to Michael, I went to find out 

more about the problem, and to talk to my team about 

possible solutions. Since the problem was on both the 

A and B sides of the recorder, and in the same word and 

memory section on each side, we determined that if this 

became a frequently recurring problem, we would be 

able to bypass that section of memory and work around 

it. It sounded like a viable option.

But since Michael was the only one who had been 

concerned about the problem, I wanted to consult 

with him before moving forward. He was working 

the second shift and was asleep. I got him out of bed 

to hear the solution and to see what he thought of it. 

He believed that it was airtight. I really felt like this 

situation was very similar to what had been outlined in 

the CAIB report: When minority opinion isn’t valued, 

people are afraid to speak up, and they end up giving 

in to conformance pressure even though they know 

there’s a problem. So I wanted to make sure that I took 

the time to hear the dissenting opinion.

AND PATIENCE IS REWARDED

In the end, we launched on July 15, 2004. We managed 

to work around each of these issues, mainly because we 

cracked them wide open each time. There’s a personal 

motto I’ve adopted from the wine industry, and I take 

it with me to each launch. That motto is “No launch 

before its time.” It’s the job of the management not to 

get caught up in the “launch fever” that accompanies 

the last few hours before liftoff. If there is an issue, no 

matter how small, it needs to be brought to the table 

and dealt with. The problem needs to be investigated, 

the risk needs to be evaluated, and sometimes the best 

decision is to postpone. Better to hold off five days—or if 

necessary, even longer—and be sure of success, than be 

on schedule with failure looming in the background. •

LESSONS

• In dealing with potential problems, it is essential to get 

to the bottom of technical questions and understand 

why things work, not just why they don’t work.

• It is important to hear, evaluate, and respect minority 

opinion, as well as to protect that minority from the 

conformance pressure of the majority.

QUESTIONS

How can you foster a project environment in which people are 

not afraid to speak up immediately when they notice that there 

is a problem?

Recently retiring from his position as Deputy Center 

Director of NASA’s Goddard Space Flight Center 

in Greenbelt, Maryland, BILL TOWNSEND is 

now the Vice President and General Manager 

of Civil Space Systems of Ball Aerospace and 

Technologies Corporation. 

Former Goddard Center Director Al Diaz, speaking of his time 

working alongside Bill Townsend, says, “I wish everyone who is 

a cynic about what it takes to be successful in this business could 

read this story. Six and a half years ago when I first became Center 

Director, we had the only total failure of a mission in all my time 

at Goddard. Since then we delivered 40 spacecraft to orbit or

systems to another user. The difference between then and now is 

the wisdom that I had to bring Bill Townsend on board. Bill has 

been the difference between my having a balanced life and having 

none. He has brought a lot of credit to the Goddard Space Program.”

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 33
• 

Headline

Deck

NASA’S 2003–2004 LEADERSHIP DEVELOPMENT PROGRAM CLASS RECOGNIZED 

THAT EFFECTIVE COLLABORATIONS ARE OFTEN THE KEY TO ACHIEVING MISSION 

SUCCESS. PERSONAL CONNECTIONS AND COMMON GOALS WERE KEY ELEMENTS 

OF THEIR WORK TOGETHER AND KEY FINDINGS OF THEIR COLLABORATION 

BENCHMARKING WITHIN THE AGENCY. 

N

O

L O

by B

A

re

T

n

I

C

t C

A

oblei

N

g

h

OI

N

T

C

AR

L O

OBAL

LABOR

O

34 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

PRACTICES
FINDING OUR WAY

NASA’S FIRST LEADERSHIP DEVELOPMENT PROGRAM (LDP)

class was asked to define and complete a project that 

would have a significant impact on the agency. However, 

agreeing on a project took much more time than any of 

us expected. Starting in the midst of the Integrated 

Financial Management rollout, One-NASA implementation, and the Columbia Accident Investigation Board 

(CAIB) report release, provided a lot of potential topics 

to choose from. Brainstorming sessions led by our 

leadership coaches yielded additional ideas. 

Projects were proposed to address workforce 

mobility, aging infrastructure, volunteerism, congressional communications, internal NASA communications, new engineering management models, new 

NASA TV programming, virtual teaming, and cultural 

issues between the centers. We had one year to complete 

the assignment (while also completing two leadership 

development rotational work assignments, participating 

in six leadership trainings off site, attending briefings by 

most of the agency leadership, and maintaining connections with our home centers) and we were encouraged 

to tackle a Big Hairy Audacious Goal (BHAG). 

So how did a group of strangers come to a decision 

on our project, and what were the results? It’s helpful 

to take a step back and look at how the first question 

was answered, as it is illustrative of several key findings 

from our project.

THE MELTING POT 

At our first leadership training off site, which served 

as a get-acquainted meeting, the class of 20 revealed 

our backgrounds and passion for NASA to one 

another. We learned quickly that we were a group with 

diverse backgrounds, in every sense of the word. We 

represented nine of NASA’s 10 centers, and our work 

experience included scientists, research and facilities 

engineers, project managers, procurement specialists, 

lawyers, and senior managers. Our origins included 

small farms and big cities, numerous military and 

second-generation NASA families, and several who 

spent part or all of their childhood outside the U.S. 

A subsequent training session had the class 

complete the Myers-Briggs (MB) personality model. 

Of the 16 possible MB personality types, the class 

had members that fell into 12 categories. This further 

illustrated our diversity, but provoked a concern in 

some that the class may have difficulty working as a 

cohesive team.

Several multi-hour discussions and much debate 

further revealed these personality differences. Team 

members that registered in the “traditionalist” category 

were poised and ready to hit the ground running 

on a project proposed by a NASA Senior Manager. 

Others that fell into the “visionary” category were 

deeply troubled about working on a project that did not 

personally resonate with them. Decision-making conflict 

also existed between those who preferred a “planned 

and organized” approach and those who preferred a 

“flexible and spontaneous” approach. Proposals were 

made to break the class into two teams, each with a 

different project, but these ideas were rejected in favor of 

focusing the energy of the entire team on one BHAG. 

CONSENSUS

Gradually, one element, common to several of the 

proposed projects, became a unifying factor for 

the class. That element was collaboration, and more 

specifically, cross-center collaboration. The appeal 

for studying collaboration was based on its increasing 

criticality in support of the NASA mission, and its 

connection to increasing cooperation and breaking 

down cultural barriers between the centers. 

While the collaboration topic was related to other 

NASA studies (e.g. One-NASA, Diaz report) we discovered 

that no one had directly benchmarked collaborations 

within the agency by trying to uncover the elements of 

success and failure. Several adjustments to the emerging 

plan were made to satisfy everyone’s concerns, but we 

finally had consensus, the elusive win-win scenario that 

allowed everyone in the group to “buy-in.” 

Using the positive energy of the group as fuel, the 

project moved quickly into high gear. The class established a vision—achieving extraordinary mission success 

in the twenty-first century through powerful collaborations—and three top-level goals for the project: 

1) Catalog collaboration principles and best practices. 

2) Infuse collaboration best practices into new and 

existing tools and programs.

3) Align incentives and structures to support effective 

collaboration. 

This vision was documented in a five-page plan 

that was used as our marching orders throughout this 

process. The team then established rotational leadership assignments for the overall project and each of 

the three goals, and established a set of operating 

principles that addressed teamwork, communication, 

and accountability. 

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 35
OFF TO THE RACES

The first order of business was to establish those collaboration best practices that were inherent in successful 

NASA programs and projects, and to identify those 

traits that led to inter-center conflict or otherwise 

inhibited progress. We decided to survey a number 

of NASA collaborations to assess their opinions and 

experiences on a number of characteristics that could 

influence their effectiveness. 

At the suggestion of Chris Williams, the 

LDP Program Director, we hired an independent 

Social Psychologist trained in the development, 

administration, and data analysis of unbiased surveys 

to help in the process. What a good idea that was! (I 

have to admit that I was hoping to dig through and 

analyze the survey data as I had done in years past as a 

flight test engineer at Dryden.) The consultant helped 

us adapt a list of potential collaboration drivers, brainstormed by the class, into a two-part survey: a questionnaire requiring a 1-to-7 scale answer indicating the level 

of agreement to a particular statement, and an interview 

to be given by members of the class. The questionnaire 

allowed us to perform statistical analysis, and the interviews provided opportunities for new ideas and unforeseen 

collaboration impediments to be raised. 

Following interview training by our consultant, 

the class was off to the races, canvassing the agency 

for the secrets behind good collaboration by interacting 

with projects with a budget of a few million dollars to 

massive billion-dollar programs. In each collaboration we targeted survey data collection from a project 

manager, a lead engineer/scientist, and a support worker 

on opposite sides of the collaboration. To ensure that 

we were getting candid responses, we established a 

process to assure people that their interviews would 

remain confidential. In less than two months, we interviewed Center Directors, Associate Administrators, and 

nearly 100 people from 16 different projects/programs 

across the agency, generating a mountain of data in 

the process. Additionally, a series of collaboration 

topics were evaluated by one of the Advanced Program 

Management classes. 

Although we spent several months selecting our 

project, the class was making significant progress 

toward our goals. Sub-teams were formed to concentrate 

on data analysis, training modules, integration of best 

practices into existing program management processes, 

systems mapping, and the latter used to identify the 

best leverage points for improving collaborations. The 

group had clearly developed a sense of trust and appreciation for each other’s abilities over the time we spent 

together as a group. 

Over several weeks, the survey findings were boiled 

down to the most important elements. These findings 

were used as the basis for generating the collaboration best practices and a set of recommendations for 

improving the environment for collaborations within 

the agency. 

THE RESULTS

The collaboration best practices (see sidebar, pg. 38) 

can be categorized into three areas: human element, 

project framework, and management involvement. The 

first area, human element, requires an investment 

in people, relationships, and communications. The 

importance of interpersonal communication cannot be 

overstated. The investment in travel to facilitate face-toface communication is an investment in the success of 

the project. When asked what technology could improve 

collaborations, many respondents answered, “Star 

Trek transporters” or “faster aircraft” in order to get 

people face-to-face more often. The pivotal point was 

that it is not about the technology, but rather that 

establishing personal relationships is critical to establish 

trust and a willingness to share knowledge—which 

in turn overcomes rivalries and differences in cultures 

and processes.

The second area, project framework, calls for 

an up-front investment in establishing common and 

agreed-upon goals, processes, roles and responsibilities, 

funding mechanisms, and establishing buy-in from all 

parties—before the project begins. Whether or not 

roles and responsibilities are clearly defined was found 

to have a strong impact on the success of collaboration. 

THE TEAM ESTABLISHED A SET OF OPERATING PRINCIPLES THAT 

 ADDRESSED TEAMWORK, COMMUNICATION, AND ACCOUNTABILITY.

36 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
A lack of clarity in roles and responsibilities most often 

resulted in an inefficient use of resources, wasted time 

and energy, frustration, distrust, and lowered morale. 

In our own collaborative effort, we found our five-page 

mission statement to be our bible. Without it, progress 

could not be tracked.

Cultural differences between centers, when not 

presented as center rivalry, most often showed up 

as differences in processes. These differences led to 

frustration and confusion, and in some cases, mistrust 

and an unwillingness to communicate. There is also a 

need for up-front planning to blend processes, rather 

than allowing one group’s processes to dominate. All of 

these problems can be overcome by increased personal 

interaction. In this way, people can learn how other 

centers or organizations operate, and they learn to 

understand each other’s cultures.

The final area, management involvement, employs 

project leadership to set and model the policies and 

standards, and it employs center senior management 

to support, encourage, and occasionally intervene on 

behalf of the collaboration. Project management must 

encourage respect for the other partner’s knowledge 

and capabilities. Allowing the development of an “us” 

vs. “them” attitude is detrimental to collaboration. 

Getting the teams face to face is once again an effective 

tool in this effort. 

SEEING EYE TO EYE

One manager from the survey relayed a story about a 

long-running technical disagreement between centers 

that persisted for months. Finally the teams were 

brought together, closed into a conference room, 

and told to solve the problem. They did, less than a 

half-hour later. We also found that true in our own 

working group; we would banter thoughts through 

emails for several weeks, but resolve issues in hours 

during our face-to-face meetings throughout the year. 

The survey also indicated that difficult personalities can 

be highly disruptive to collaborations, especially when egorelated. Project managers must ensure that these people 

are not in positions that will lead to frequent conflict with 

the collaboration partners. Establishing points of contact 

between the partners to facilitate communication and 

serve as problem solvers was mentioned as an effective 

means for maintaining healthy collaborations.

Senior managers’ active involvement was found to 

be key and many were commended in the survey for 

providing periodic reviews, helping solve funding issues, 

and avoiding micromanagement. Survey respondents 

desired a more active role of senior managers in the 

development of collaboration agreements, setting of 

project expectations, and management of inter-center 

conflicts. Additionally, there was a strong desire for 

senior managers to make personal visits to the collaboration staff and facilities—a clear show of support.

There does not seem to be a widespread use of 

metrics for management to measure the progress or 

success of collaborative efforts. The most common 

measures of project success, often reviewed monthly 

by center management councils, are schedule, budget, 

and technical progress. Managers rarely focus on the 

working relationships and processes, even though it’s 

the team that drives success or failure. We recommend 

that metrics be developed to assess the health of 

collaborations. These metrics should be reported as part 

of periodic project reviews so that issues get addressed 

in a timely fashion and not be allowed to fester. 

INSTITUTIONALIZING

From the very beginning, the class recognized that 

reports-on-a-shelf accomplish nothing. In order to 

make a real impact on the agency, the collaboration best 

practices had to be integrated into NASA systems. With 

that in mind, a multi-prong approach was initiated. 

Connections were established with the NASA Academy 

of Program and Project Leadership (APPL) and, at 

their suggestion, training materials were generated 

to support existing leadership training courses. The 

Chief Engineer’s Office supported an effort to integrate 

collaboration elements into the updated NASA Program 

Management Requirements and Handbooks. 

The groundwork is also being set for a process 

to assess ongoing collaborations and make the 

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 37
recommendations necessary for them to achieve the 

highest standards. A class member also participated in 

the addition of “teamwork” as a new performance plan 

element for leadership positions. In order to illustrate 

the value of collaborations to the agency’s mission, 

a new NASA Peer Award is also being established. 

A forum on collaboration also ran on NASA TV. Lastly, 

the LDP class is fanning out to brief all NASA centers 

at senior leadership meetings and town hall meetings 

on the best practices for successful collaborations. 

FOLLOWING OUR OWN ADVICE 

Without knowing it a-priori, our LDP class followed 

many of the important collaboration practices in 

the conduct of our study. First we spent time 

getting to know each other, our backgrounds and 

personalities. Second we worked, with some conflict, 

until we achieved buy-in on a common vision and 

goals. Next we defined roles and responsibilities and 

a set of operating principles that, in retrospect, the 

team closely followed. Throughout the process, our 

commitment to achieving the project goals for the 

betterment of the agency took priority over any parochial 

concerns or personal agendas. 

It is our hope and our vision that greater attention 

will be given to the nurturing of our collaborations 

across the agency. Highly effective collaborations are 

a key building block to fully achieving the vision 

of One-NASA and ultimately succeeding in our 

important mission. •

BRENT COBLEIGH recently returned 

to Project Management at the 

Dryden Flight Research Center after 

year working on the Vehicle Systems 

s at NASA 

Development 

e working on 

cluding X-29, 

X-33, SR-71 

nd X-37. Prior 

ers Degree in 

e Washington 

enter’s Joint 

cience. 

spending one 

and Centennial Challenges Program

Headquarters as part of the Leadership 

Program. Brent has 15 years experienc

atmospheric flight research projects in

X-31, F-16XL Supersonic Laminar Flow, 

LASRE, Autonomous Formation Flight, a

to coming to Dryden, he received his Mast

Aeronautical Engineering from the Georg

University/NASA Langley Research C

Institute for the Advancement of Flight S

COLLABORATION BEST PRACTICES

How does your project rate?

>> Managers should recognize that efficient and effective 

 collaborations are the product of relationships.

>> Face-to-face interactions, especially as the collaboration 

 forms, improve the formation of relationships, establishment 

 of trust, and issue resolution.

>> Interpersonal interaction substantially improves the ability 

 to overcome inter-center conflicts.

Partnership agreements must have clearly defined 

>> Roles and responsibilities.

>> Shared vision, goals, and objectives.

>> Flexibility to deal with changes over time.

>> Means for decision-making and conflict resolution 

 between the parties. 

>> Funding processes.

>> Buy-in!

>> Processes and procedures should be agreed upon, 

 understood, and documented.

>> Points of contact should be established to manage 

 and resolve issues.

>> Successful collaborations require sufficient travel.

>> Health of collaborations should be measured, continually 

 assessed, and discussed at management reviews.

Managers & Leaders should

>> Encourage and model respect and appreciation for each 

 other’s capabilities and knowledge.

>> Recognize and reward team members timely and peer 

 driven most effective.

>> Consider personality compatibility.

>> Ensure that difficult personalities are not in position to 

 disrupt collaboration.

>> Have collaboration as a performance plan element.

Senior Managers should

>> Review projects, support funding, and avoid micromanagement. 

>> Personally visit project staff and facilities.

>> Play an active role in the development of 

collaboration agreements.

>> Set project expectations.

>> Manage inter-center difficulties.

38 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
GARY KLEIN, PH.D., IS CHIEF 

SCIENTIST OF KLEIN ASSOCIATES INC.,

A COMPANY HE FOUNDED IN 1978 

TO BETTER UNDERSTAND HOW TO 

IMPROVE DECISION MAKING IN 

INDIVIDUALS AND TEAMS. THE 

COMPANY HAS 30 EMPLOYEES 

WORKING ON PROJECTS FOR BOTH 

GOVERNMENT AND COMMERCIAL 

CLIENTS. DR. KLEIN IS ONE OF 

THE FOUNDERS OF THE FIELD OF 

NATURALISTIC DECISION MAKING. 

HIS WORK ON RECOGNITIONAL 

DECISION MAKING HAS BEEN 

INFLUENTIAL FOR THE DESIGN OF 

NEW SYSTEMS AND INTERFACES, 

AND FOR THE DEVELOPMENT OF 

DECISION TRAINING PROGRAMS. 

HE HAS EXTENDED HIS WORK 

ON DECISION MAKING TO 

DESCRIBE PROBLEM DETECTION, 

OPTION GENERATION, SENSE 

MAKING, AND PLANNING.

DR . GARY K LE IN

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 39
In order to perform research on decision making 

in field settings, Dr. Klein and his colleagues have 

developed new methods of Cognitive Task Analysis. 

Klein Associates has used Cognitive Task Analysis 

methods to study decision making in more than 60 

domains, including firefighting, command and control, 

software troubleshooting, healthcare, and consumer 

purchasing. Dr. Klein has presented workshops on 

Cognitive Task Analysis to more than 300 professionals 

in the U.S. and abroad, and has presented seminars on 

naturalistic decision making to a wide variety of groups 

such as the Smithsonian Associates program.

As a researcher and storyteller, you preach about the 

power of stories as learning tools. How can project 

managers harness this power in their work every day?

To start, we need to stress the importance of intuition—

following your hunch, trusting your years of experience to lead you in the right direction. Intuition, 

in and of itself, is extremely undervalued. Why? 

Because it’s fallible. It’s only a first step; it needs to be 

checked by analysis. But we have lots of tools and 

mechanisms for strengthening our analytical capacities, and we don’t have a similar repertoire for strengthening our intuitions.

How then, do we use stories to strengthen and apply our 

intuitions? 

We use stories when we make recognitional decisions. 

Most of our decisions are based on recognition. We 

use stories to map situations and say, “I’ve seen that 

before.” In this way, I can call up incidents that I’ve seen 

myself, or that other people have told me they’ve seen. 

Then I can use the stories to evaluate my intuition. We 

also use stories to make sense of events. We start with 

basic scripts, we build onto them with the knowledge 

we’ve collected, and we turn them into stories. 

Can you give an example? 

Sure, I have an example in the form of a story:

A friend of mine was a highly experienced Colonel 

in the Marines. He was part of an exercise at Camp 

Pendleton called “Hunter-Warrior.” Marines—noncommissioned officers—would go out in the field as forward 

observers to look for enemy tanks and equipment. They 

would radio back what they saw so that those tanks and 

other targets could be attacked.

My friend wasn’t part of the exercise, but he got 

permission to go along. At one point, the unit spotted 

a tank. The non-commissioned officer in charge of the 

unit saw the tank once it was in plain view and sent 

back to headquarters the message, “I see a tank,” along 

with the grid coordinates. 

My friend was thinking, “Anybody could see the 

tank by now, because it was out in the open.” So he 

watched it closely as it came down the valley, and then 

took a defensive position. He said to himself, “There 

is never just one tank. Nobody ever goes out all by 

himself. There has got to be at least one more tank.”

He kept watching, but he didn’t seeing another tank 

come down the valley. So he realized that the second 

tank must already be in position. He started looking 

in the shadows to see where the other tank would be 

positioned to support the first one, and he found it. 

He said to himself, “Tanks usually travel in platoons of 

four. If there are two tanks, maybe there is another one 

or two.” He looked deeper into the shadows and found 

the other two. 

Then he thought, “These guys are just sitting 

there, and the position they’ve taken up is a defensive 

position. So, what are they defending?” He decided that 

there might be a command post, and he looked in the 

likely places for a command post. Then it got a little 

windy, and he noticed the glint of an antenna. Instantly, 

he found the command post. 

It was interesting to compare what my friend could 

see versus the non-commissioned officer, because the 

NCO was only reporting the tanks when they came 

into plain view. My friend wasn’t just reporting what 

he was seeing. He was going beyond. He was looking 

for things.

He was building a story based on his prior experiences. 

Exactly. He was looking for things, because he had a 

storytelling technique that told him what to look for. 

That’s how this story-building activity helped him 

to make sense and to build a better account of this 

situation. Stories can help sharpen our intuitions by 

helping us with sense making, with anticipating a 

result, and with decision making.

Are there key questions that we ask ourselves when we 

create these stories?

Sure, for example, “What’s the logic of this story?” Or, 

“How does this story work?” This is an important question, 

because a story works in a couple of different ways. 

One, it works sort of like an efficient experiment. 

When we conduct a standard experiment, we typically 

40 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW CONTINUED
manipulate one variable. That’s the independent 

variable, and we measure changes in the dependent 

variable. Our research tends to only look at one or two 

variables at a time, which is unfortunate, because it is 

like looking at the world through a soda straw. We can’t 

see all of the variables and how they are interacting.

When we build a story, we take into account 

several independent variables at a time. A story shows 

all of those variables as they interact. What we lose is 

the ability to control the independent variables, because 

we can’t set up the values. But what we gain is the sense 

of how these are interacting and working together. 

That’s a source of hypotheses.

So a story is a basis for discovery?

It’s a natural experiment that we use to our advantage; 

then we compile these experiments, accumulate them, 

and try to learn from them. That’s just one of three 

aspects of the logic of stories. 

And the second aspect?

The second aspect has to do with mental simulations. 

During a mental simulation, you are constructing a 

story in your head. You say to yourself, “I know how 

this starts. Let me work out the continuation.” Or you 

also might say, “I know how this ends. Let me work 

out the beginning.” Or there also might be a situation 

where you say, “I know both how it starts and how it 

ends. Let me work out the middle.” 

Can you give an example of a mental simulation?

Sure, and I can use one based on a story from ASK. 

You remember there was a story in ASK 13 by Tom 

Rivellini? He talked about the airbags on Pathfinder. 

We got to see that great picture of the Mars landscape, 

the equipment looking great, a picture of him looking at 

the airbags, and we heard how everyone did their jobs. 

We all know that it worked. But he said, “It 

wasn’t that simple. It wasn’t trivial to get those airbags 

configured so that they would do their job. Here is what 

really happened...”

We’re suckers for stories like that because, we want 

to know the inside part of what happened. He led us 

through it, including the emotional ups and downs. 

We heard how he became discouraged as attempt after 

attempt failed. The story got us to the point where we 

asked, “How did he ever get it to work?” He started with 

a story that we all knew the ending to, but he said the 

interesting part is how we got there.

Then what is the third aspect to the logic of stories?

This aspect deals with how you make sense of a situation 

by combining its components. You’re compiling the 

data, the events, and what you observed into some sort 

of frame that holds it all together. 

For example, the frame can be a map made up of the 

details of various places that shows how they connect. 

Or it could be something like a script that shows all the 

people involved in something and the part they play. Or 

it could be an outline of a routine of some sort. 

Which comes first, the data or the frame? 

That’s an interesting question, because the fact is 

that neither of them comes first. You need the data 

to tell you which frame is appropriate, but you need 

the frame to tell you what counts as data and which 

data to use. You create the framework and compile the 

data simultaneously. 

The story becomes a blend of the data and the 

frame. As you work through the story, the frame 

gets richer and richer, because you’re deepening the 

account. A story allows you to do both simultaneously: 

Make the frame richer and identify new types of data. 

It sounds like an extremely effective way of evaluating 

and acquiring new information.

It is. The problem is that while stories are often 

important, they’re not sufficient. When I fly in an 

airplane, I don’t want my pilots’ training to have been 

only hearing stories about how to take off and land. 

I want them to have checklists. I want them to 

follow procedures, because I know that people forget 

things. But I don’t want them to just know procedures, 

which are designed for situations that continuously 

repeat themselves, because sometimes the procedures 

don’t work for unique situations. 

So, you need the procedures, but a story might help you 

know how to handle a situation that they don’t cover? 

And presumably as the world becomes more dynamic, 

these situations become more prevalent?

Right. However, some organizations don’t want to 

buy into that. They think that they can come up with 

procedures so exhaustive that there is never a need to 

go beyond them.

Researchers who have looked at this have never 

found that procedures alone are very successful. Yet, it 

is often an organizational quest to write them so they 

are. I can give you an example of an incident where 

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 41
the organization refused to believe in the power of 

stories. I got this from Kim Vicente, a researcher at the 

University of Toronto.

There was a crack nuclear power plant in Canada 

where the controllers were really, really good. All 

nuclear power plants are regularly inspected and tested. 

A day came for one of the periodic tests for this control 

room team. 

These guys had always scored really high in the 

past, but they had one flaw: They didn’t always follow 

the procedures. For this, they were always reprimanded. 

They knew what they were doing, and they knew when 

they could do shortcuts, but they were tired of getting 

dinged for not following all of the procedures. Before 

the next test, they all banded together and made a pact. 

They said, “Whatever comes, hell or high water, we are 

going to follow the procedures.” 

So the test comes, and they’re given a tough 

situation. They’re working on it, and they get into a 

loop. They take action-A, which produces situation-B. 

They respond to situation-B, which gets them to C. 

They follow the procedures, and the procedures get 

them right back where they started at situation-A. They 

just look at each other like, “This is amazing!” They 

follow the procedural loop around again and again, 

and each time they end up right back at the beginning. 

They are just loving the heck out of this—having a 

great time.

The controllers finally stop them. In the end, the 

inspectors were so irritated that they wrote them up 

anyway, this time for “malicious procedural compliance.” 

It’s a funny story, but it shows that there are times 

to follow procedures and times not to, times to codify 

information and times when you need the context that 

goes beyond codification.

So stories help with the practical knowledge that goes 

beyond the checklists. What is another storytelling tool 

that can be used in a dynamic workplace?

Another tool is having people swap their stories in 

Lessons Learned sessions. The idea is that your peers can 

teach you valuable information, and you can teach them. 

Let me tell you another story that shows what I mean:

 We put on a workshop for fire fighters in 

Los Angeles. We were talking to battalion commanders 

and captains about how they could improve decisionmaking through the use of stories.

I started by saying, “The purpose of this workshop 

is to improve decision-making skills.” One of the fire 

fighters, a captain, asked, “But will it help with things 

like morale?” I answered that, “No, I don’t see it 

helping with morale.”

I came back a couple of weeks later when we had 

our next session. The same fire fighter said, “Hey, you 

were wrong about stories not helping morale.” He told 

us the story of how he came to this conclusion.

Apparently, there was somebody in his company 

who was a real loser. This guy was always messing up, 

and they were constantly at each other’s throats. After 

we finished the last workshop, the captain went back to 

his company. A few days later, the company responded 

to a fire call. This same guy in the company, again, does 

something really stupid. (The routine at this point was 

that the guy did something stupid, the captain goes 

over to him after the incident and yells at him. He asks 

him, “How many times have I told you not to do that?” 

And then he writes him up.)

But this time, the captain had just come out of the 

workshop. Instead of yelling at the guy, he said “When 

you handled things that way, I was kind of surprised. 

Can you explain your reasoning to me so that I can 

understand what you were you trying to do? What 

was in your mind? Give me your story.” The firefighter 

explained what he was trying to do and why, and the 

captain was amazed because it made sense. Then they 

were able to have a dialogue about how he’d handle 

other situations, and it was the first time they’d ever had 

a real discussion.

The captain came back to our workshop and said, 

“I used to think this guy had an attitude problem. Now 

I realize that I was the attitude problem. When I let him 

tell his story before chewing him out, it changed the 

whole dynamic.” 

That’s part of the power of stories—changing the 

dynamic of situations with knowledge and understanding.

That is what ASK Magazine is attempting to do for the 

field of project management.

There are some great stories in the magazine. Somehow 

you’ve been able to create a culture that not only 

collects stories, but you’re also sensitizing people to 

those stories so that they are even experiencing their 

world slightly differently. That’s what you want when 

people come out of a storytelling workshop, or when 

they finish reading the magazine. You are sensitizing 

people to the value of stories, because they are an 

effective vehicle for knowledge. You are helping to build 

the culture of storytelling that we are both a part of. • 

42 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW CONTINUED
Reflecting on this, I remembered a story about my 

friend, T. Rust Worthy, who was in the market to buy a 

townhouse. His father was an experienced contractor, 

so after receiving a list of references from him, T. Rust 

pinpointed one on the list. He selected a developer and 

quickly struck a deal on a house that was in the process 

of being built.

T. Rust then met with the architect, who was a 

consultant, to request design changes. He found out 

that changes went through a lengthy process: his 

requests were drawn up by the architect, an estimate 

of the cost was drawn up, approval was obtained by 

the chief engineer, and then the approved changes 

were sent to the site superintendent. This process 

took forever and was compounded by the fact that the 

architect hadn’t been informed about the developer’s 

changes to the original design.

He asked the developer if he could work directly 

with the chief engineer and site superintendent since his 

changes were small and didn’t require major redesign. 

The developer told him that he used to do things that 

way when his business was smaller, but he had adopted 

a more formal process to eliminate misunderstandings 

and disagreements with his customers. Since he knew 

T. Rust’s father, however, he said he would work with 

him that way. During the completion of the house, two 

major episodes helped to establish a relationship of 

trust between the developer and T. Rust.

First, the storage room that he had been promised—

which was located in a separate storage building—was 

mistakenly sold to another customer by the sales agent. 

T. Rust simply accepted another room without making 

a fuss. Then the site superintendent made a mistake 

while securing the water pipes during a routine leakage 

test, resulting in water damage to the interior walls. 

Once T. Rust had been assured by his father that there 

would be no permanent damage, he didn’t make a big 

deal out that problem either. 

A Tale of Two Houses: 

Building on a Foundation of Trust or Mistrust

Trust has been a main theme in over 20 articles that have 

been printed in ASK so far

THESE STORIES MAKE IT VERY CLEAR: TRUST AMONG PROJECT PARTIES IS NOT JUST AN

attitude that is nice to have. It is a must, since lack of trust costs money—often 

a lot of money. Trust helps resolve conflicts before they arise; trusting relationships are conducive to full and open exchange of information within the team; 

elaborate surveillance and control systems must be implemented to compensate 

for lack of trust, often with only partial effectiveness. In past issues, we’ve taken 

a look at projects that succeed because of these factors, but we haven’t directly 

focused on how trust and mistrust are built. In this article we will see how 

prejudice shapes what we see and how we act. 

ASK 20 FOR PRACTITIONERS BY PRACTITIONERS 43

FROM THE EDITOR-IN-CHIEF Dr. Alexander Laufer
The site superintendent was very grateful to T. Rust.

Therefore, when it was his turn to make mistakes 

or change his mind, T. Rust was able to deal directly 

with the superintendent in an informal, friendly way. 

However, he made sure that the formal paperwork 

was always completed by the developer’s main office. 

As time went on, he developed a trusting relationship 

with the chief engineer as well. This made the formal 

approval process faster and smoother.

In contrast, my friend’s future neighbor, one Miss 

Trust, was going through the same process to buy her 

townhouse. She, however, was having a less satisfying 

experience. Miss Trust and the developer initially got 

off to a bad start, because she had always thought badly 

of developers. She wouldn’t do anything without the 

presence of her lawyer. The lengthy process for design 

changes only made her more positive that the developers were underhanded.

Since Miss Trust didn’t trust the contractor, 

she went to the site every day to scour for mistakes. 

(In contrast, T. Rust stopped by only once a week 

and communicated mostly by phone.) When Miss 

Trust found discrepancies between the construction 

and design, she got angry and assumed that she was 

being cheated. 

She found out that T. Rust had been charged 

slightly less for a similar design change and refused to 

believe it was a result of the waived architect fee. On 

another occasion, T. Rust paid less than Miss Trust had 

for a similar scope of work. This was because T. Rust 

elected to have the work charged “cost-plus,” allowing 

it to be finished as quickly as possible. Miss Trust on 

the other hand, didn’t trust the contractor at all, and 

would never have approved a change without knowing 

the final cost. She signed a lump sum agreement which 

eventually turned out to be more expensive.

In the end, T. Rust was satisfied and recommended 

the developer to others. Miss Trust served the same 

developer with a lawsuit.

This story clearly shows that once we accept 

stereotypes, prejudice shapes what we see and how 

we act. Since initial opinions of team members are 

crucial, if possible, you should avoid recruiting team 

members who start the project distrusting you. You 

should build trust incrementally by making statements of intent that express the desire to trust the 

other party, followed by actions that support and 

comply with these statements. •

STORIES ON TRUST

FROM THE ASK ARCHIVES

ASK 1

From Apprenticeship to Management, by Tony O’Neil 

ASK 2

Reforming a Mindset, by Roy Malone

Cross-training Within the Project Team, by Owen Gadeken

ASK 3

Pin the Deputy’s Badge on Me, by James Barrowman

The Big Briefing, by Terry Little

ASK Talks with Joan Salute

ASK 4

Trading on Trust, by Terry Little

ASK 5

Our Man in Kauai, by Ray Morgan 

ASK 6

The One Thing You Need to Know, by Dougal Maclise

ASK 7

Hot Meetings, by Mary Chiu

The Join-up Meeting, by W. Scott Cameron

A “Sweet 16” of Rules about Teamwork, by 

Dr. Alexander Laufer

The Idyllic Workplace, by Tony Shoenfelder

ASK 9

Customer Responsiveness, by Mary Chiu

How Do We Work Together?, by Terry Little

ASK 11

Give It to Chuck, by Frank Snow

Speed Merchants: A Conversation with W. Scott 

Cameron and Terry Little

ASK 12

Grins and Giggles: The Launch Pad to High Performance, 

by Maj. Norman H. Patnode

Earthly Considerations on Mars, by Tim Flores

Trusting the Enemy, by Terri Rogers

Get into Bed, by Jon Bauschlicher

ASK 16

The Eye Cannot See Itself, by Dr. Alexander Laufer

ASK 17

Passing the Baton: Lessons in Regret, by Terry Little

Right on Time, Radically, by Ken Lehtonen

44 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

FROM THE EDITOR-IN-CHIEF CONTINUED

NP-2004-11-384-HQ