appl.nasa.gov

ASK Magazine • Issue Twelve

MAY 2003

INTERVIEW

Michael Hecht

Academy Sharing Knowledge

The NASA source for project management
You must engage yourself in understanding 

the environment in which your program or project 

operates. To put it simply: You can run,

but you cannot hide from politics.

—Joe Shaw, from his “Getting Politically Active” (p 9)
appl.nasa.gov

Table of Contents

ASK 12 June 2003

STORIES

5 Earthly Considerations on Mars

Much had already been written about the Mars missions. Why did I think 

I had something new to say? BY TIM FLORES 

9 Getting Politically Active

I spent a lot of time explaining my vision for the new program—and listening 

to their complaints BY DR. ROBERT J. SHAW

12 Stumping for the Project

Where I work, we joke about how we all went to engineering school but what 

we really needed were classes in political science and marketing BY CAROL GINTY 

24 Grins & Giggles: The Launch Pad to High Performance

“Bring your lunch,” he said, “we’re gonna have some fun.” We were a little 

apprehensive—was this allowed? BY MAJ. NORMAN H. PATNODE

SPECIAL FEATURE: KNOWLEDGE SHARING 

15 Transfer Wisdom Workshops:

Coming to a NASA Center Near You

I didn’t have anything to back me up other than my confidence in the philosophies 

we were teaching and my belief in the value of the TWWs BY DENISE LEE

FEATURES

20 Project Management: The Television Show

While watching the latest episode, I recognized parallels to what goes on 

in successful project management BY TERRY LITTLE

22 Lessons Learned Again and Again and Again

I want to scream, “I learned these lessons 30 years ago. Why do we continue

to learn these same lessons over and over again?” BY W. SCOTT CAMERON

PRACTICES

28 Implementation Reviews

We took the approach of asking each team,“What do you need in order 

to get your job done, and how can we make that happen?” BY GERALD MURPHY

INTERVIEW

32 ASK Talks with Dr. Michael Hecht

Project manager or scientist? Dr. Michael Hecht of the Jet Propulsion Laboratory

shows while it may be difficult, you can be both

IN THIS ISSUE • 3

What Is This 

Fourth Dimension?

BY TODD POST

FROM THE DIRECTOR’S DESK • 4

Remembering Frank Hoban

BY DR. EDWARD HOFFMAN

LOOP • 38

Tributes to Frank Hoban

REVIEW BOARD • 39

LETTER FROM THE 

EDITOR-IN-CHIEF • 40

Perfection Is in the 

Details—or Is It?

BY DR. ALEXANDER LAUFER

ON THE COVER Hubble telescope captures 

a view of the Red Planet
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 genuine

nuggets of 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 Todd Post, EduTech Ltd., 8455 Colesville Rd.,

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

email to tpost@edutechltd.com.

APPL DIRECTOR AND MANAGING EDITOR 

Dr. Edward Hoffman 

ehoffman@hq.nasa.gov 

EDITOR-IN-CHIEF

Dr. Alexander Laufer 

allaufer@askmagazine.org

www.edutechltd.com/NASA/Laufer/index.htm 

EDITOR

Todd Post

tpost@edutechltd.com

ASSOCIATE EDITOR

Jody Lannen Brady

jbrady@edutechltd.com

CONTRIBUTING WRITERS

W. Scott Cameron 

Terry Little 

KNOWLEDGE SHARING MANAGERS 

Denise Lee

dlee@edutechltd.com 

Therese Salmon

tsalmon@edutechltd.com

EDITORIAL ASSISTANT

Michael Derocher

mderocher@edutechltd.com 

DESIGN

Hirshorn Zuckerman Design Group, Inc.

www.hzdg.com 

SENIOR PRINTING SPECIALIST

Dave Dixon

ddixon@hq.nasa.gov 

STAFF
THE RESEARCH COMMUNITY AT NASA, I WAS TOLD, IS TOO

often overshadowed by the folks who build hardware.

Four of NASA’s nine centers, after all, are research centers.

I hope stories in several of our recent issues have

satisfied some of those early critics. But to any project

manager of a research project who may still feel slighted,

well, here is an issue for you.

In working on this issue, what I’ve learned is that

managing research projects demands an understanding

of what Dr. Robert J. (Joe) Shaw calls the fourth

dimension: politics. His story, “Getting Politically

Active,” explains how he has evolved from being an

observer of organizational politics to actively politicking

for his projects. Carol Ginty, who like Joe Shaw is located

at NASA’s John Glenn Research Center, knows that the

technical report doesn’t always sell the research. That’s

why she’s always looking for things that will—and finds

them wherever they turn up.

Tim Flores returns to ASK this issue. I interviewed

Tim for Issue 2. At the time, he was on leave from

NASA’s Ames Research Center, working on a Masters

degree at MIT. Finished now, he has a story, “Earthly

Considerations on Mars,” about the research he did for

his thesis. Tim looked at two Mars projects, the

successful Pathfinder and the ill-fated Surveyor,

attempting to understand the difference between a

successful mission and a failed one in terms of the

organizational structures of the project teams. Research

projects often give us many surprises, and this one is no

exception.

Our interview this issue is with Dr. Michael Hecht,

a project manager at the Jet Propulsion Laboratory.

Among other things, Mike shares what it was like

working as the project manager and co-investigator on

an instrument scheduled to fly on an upcoming Mars

mission. Did his dual role on the project pose a conflict

of interest? Read the interview and see.

In the Special Feature, APPL Knowledge Sharing

Manager Denise Lee has a story about how the APPL

Transfer Wisdom Workshops have evolved. Denise and

her APPL teammates conduct one-day workshops at the

NASA Centers, using stories from ASK to promote a

knowledge sharing culture at each Center. Along with

the story by Denise, we’ve included stories by participants from some of the workshops.

Lastly, we celebrate the life of Frank Hoban, who

passed away unexpectedly in December. Frank was the

editor of Issues in Program and Project Management,

published by NASA and dedicated to research done by

NASA managers. Issues appeared throughout the late

1980s and early 90s. “From The Director’s Desk,” Dr.

Edward Hoffman’s column, is a remembrance of Frank,

and in the “Loop” we pass along some tributes written

by Frank’s friends and colleagues.

Hope you enjoy this issue of ASK. Remember, this

and all issues are for you. • 

What Is This Fourth Dimension?

Soon after we started publishing ASK, I heard from some

of our NASA readers that we needed to feature more stories

about managing research projects 

IN THIS ISSUE Todd Post

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

THE JOB WAS BEING SECOND-IN-CHARGE OF NASA’S

Program Project Management Initiative (precursor to

the Academy of Program and Project Leadership), and

my interviewer was Frank Hoban.

Shortly after we exchanged typical pleasantries, Frank

jumped right into discussing ideas, beliefs and goals. After

twenty minutes he asked,“So, when can

you start?” I made the second best

decision of my life and accepted the job

on the spot.

I remember a typical Frank

remark when embarking on a new

assignment, “Let’s get started soon

because we can do some really

important things, and let’s remember

to have fun.” Few days were as

enjoyable as meeting with Frank over

lunch and hearing stories of escorting Wernher von

Braun to the Dick Cavett show, or working for George

Low on the Low Cost Systems Office, or the early days of

Space Station.

Frank came from a project world. He much

preferred addressing real issues by working with the best

people and staying focused on the customer requirements. When I first started with Frank, he informed me

that the more time I spent in my Headquarters office the

less effective I would be. The customers, experts and

practitioners, were in the field—spend time with them.

He made that point personally by the way he used

his last few weeks before leaving NASA. He escorted me

on a tour of each of the centers. We met with all of the

working groups and individuals who were so vital to the

project management community. I still remember him

telling everyone what a wonderful leader I would make,

and his strong insistence that I receive their support.

Frank had accepted a university teaching position.

He felt it was time for a new adventure and assured me

he would always be nearby to help—and he was. Over

the years we stayed close. One time,

several years ago, Frank invited my

family to his New Year’s Day party. We

went for a walk on the grounds of his

beautiful home, the two of us, and he

asked me how things were going. This

was during a period of excessive travel

and long hours. I knew he could sense

I was burning out. He shared some of

his experiences and then talked from

the heart about the most important

thing being family. He warned me that it was easy getting

caught up in the excitement of work and travel.

The last time I saw Frank was at the Goddard Space

Flight Center. We had a few minutes to talk. We

discussed possibilities, exchanged ideas, caught up on

people and agreed to get together for lunch soon.

Leaving, I noted how his eyes sparkled with energy,

excitement and adventure. I knew he was planning the

next big thing.

Frank was a big part of what makes NASA special.

He was part of a hero generation that faced challenges,

dreamt big and remembered to have fun. He embodied

a love for family, country and NASA. I have always

considered myself an extremely lucky person for having

known him. • 

Remembering Frank Hoban

Years ago, I interviewed for a job I wasn’t sure I wanted

with a man who wasn’t confident he wanted me

FROM THE DIRECTOR’S DESK Dr. Edward Hoffman

Leaving, I noted how 

his eyes sparkled 

with energy, excitement 

and adventure.

I knew he was planning 

the next big thing.
ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 5

Earthly Considerations

on Mars

Martian nightfall: Nine enhanced images capture the twilight of sunset over the Ares Vallis river channel.

LIKE THE REST OF THE COUNTRY, I READ THE NEWSPAPER ACCOUNTS

of NASA’s Mars missions in the late ’90s. Headlines touted the

success of the 1996 Mars Pathfinder and, later, highlighted two

of the 1999 Mars Surveyor program missions as failures. Unlike

much of the country, my work at NASA gave me more than a

passing interest in the headlines. by Tim Flores
6 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

When I left my job at Ames Research Center in

1999 to go back to school, both of these projects were

fresh in my memory. So, when it came time to choose a

research project for my Master’s thesis, the Mars

missions came to mind. I wanted to work on something

of real value to NASA and, by looking at these projects

from a new perspective, I hoped I would have something

to offer the Agency.

Much had already been written about the Mars

missions. At least two books had detailed the success of

Pathfinder from start to finish. Committees had studied

closely the Mars Climate Orbiter and Polar Lander, two

not-so-successful Surveyor projects. Why did I think I

had something new to say?

Asking questions

The Pathfinder, Climate Orbiter and Polar Lander

projects all came out of the Jet Propulsion Laboratory

(JPL). They were conducted under the same “faster,

better, cheaper” mandate, were all of comparable scope

and shared many similar elements and even some of the

same team members. But they had very different end

results; what accounted for the difference? Aside from

the reported technical issues, what could have been the

deciding factors between success

and failure? Could the organizational design, politics or culture

have been a factor?

With the help of my advisor at

MIT, I developed my research

project as an organizational study of

the Mars projects, and I developed a

lengthy set of questions to use when

interviewing team members from

the three projects. I anticipated that

some of the people I spoke with

might, quite understandably, be

sensitive about discussing their work on a so-called

“failed” mission, and I gave this a lot of thought.

When it came time to contact my research subjects

on the Orbiter and Lander projects, I made it clear that

I wasn’t interested in finger pointing and I wasn’t

looking to blame anyone for failures. I explained that I

was studying the strategic design of each project, i.e.,

the grouping, linking and alignment of the project. I

wanted to look at the political environment to see how

the goals and interests of stakeholders affected the

outcomes, and I wanted to understand the working

culture of each project.

One fundamental 

element distinguished the

successful mission from 

the failed missions: 

teamwork.

➤

A southwest view from Pathfinder’s

landing spot reveals the rocky

Martian landscape.
ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 7

In the end, I was impressed by the

generous response of the participants;

every one of them expressed a desire to

share their knowledge and to help with 

my research.

Getting answers

I interviewed, in great depth, eight key

figures from the missions (one subject

worked on both Pathfinder and Surveyor,

and I interviewed him separately about

each). I expected to find that the

Pathfinder differed from the other

projects on a number of levels: resources,

constraints, philosophy, and personnel.

And this was, to some extent, true. But I

was extremely surprised to find one

fundamental element that distinguished

the successful mission from the failed

missions: teamwork.

You can’t underestimate the value of

effective teamwork. The Pathfinder team developed

trusting relations within a culture of openness. They felt

free to make the best decisions they could with the

resources available to them, and they knew that they

weren’t going to be crucified for mistakes. That trust

never developed in the other programs.

Why did the individuals of one team work so well

with another, while the other teams suffered from

numerous conflicts and communication gaps? Tied into

this are a number of factors. One of the things that

Pathfinder did was to develop a flat

organization, which allowed team

members to make decisions across

the board. They were not forced to

follow the standard hierarchical

protocol that usually exists in

government programs. Team

members were encouraged to

speak to one another directly,

rather than through managers,

and they felt fewer bureaucratic

limitations on their work.

Another factor: collocation.

The Pathfinder team built their

own spacecraft, and they were able

to co-locate almost all the team on

one floor in one building. Team

members had frequent, informal

face-to-face interactions on a daily

basis. Consequently, they could

respond to emerging issues quickly.

Contrast to that the distance between the Orbiter/Lander

prime contractor, Lockheed Martin Astronautics, in

Colorado and the mission team at JPL in California.

Working with dispersed teams made communication

failures more likely, and communication failures, in

turn, prohibited developing trust.

Never underestimate the power of positive

thinking. Even though the budget for Pathfinder was an

order of magnitude smaller than previous Mars

missions, team members turned that into a “can-do”

Because dust extends high into the

atmosphere, the Martian sky stays

bright for up to two hours after sunset.
8 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

motivational factor. Management took the first step in

creating a trusting environment that set the tone for

positive results. The atmosphere brought out a strong

performance ethic and the relentless

desire to accomplish the mission. In

contrast, the challenges for the

Surveyor program were presented

with a negative connotation of “two

for the price of one” and “it couldn’t

be done.”

Not surprisingly, my research

uncovered many of the same factors

identified by earlier studies as critical

elements to the relative success or

failure of the Pathfinder, Orbiter and

Lander missions. The striking difference between the projects, however, became clear during

my research: the cooperative relationships between team

members across the boundaries on the Pathfinder

mission did not exist on the other missions.

Without a doubt, sound science and technical

proficiency are crucial to a project. But an examination

of the Mars missions tells us that we can’t afford to

overlook the relationships between the people doing

the work.

In many ways, my research continues. I’m trying to

apply the lessons I learned to my current work situation.

I’ve pushed for more face-to-face communication and

I’m trying to help build a relationship of trust between

members of the various teams working on my project.

If there’s one thing my research taught me, it’s that every

project, no matter what its technical specifics, comes

down to being a human capital effort. •

LESSONS

• You can enable success but cannot create it. Project

managers must find the right balance between giving

people the right independence (trust) to accomplish great

things and providing the guidance to help them do it.

• Project management is a people industry. Gaining the

trust of your followers will grant you more influence

than any formal authority.

QUESTION

In research, we expect to be surprised because that’s how we

learn. On a project, we often greet surprises with some trepidation, understandably. How might you rethink “surprises” on a

project as learning opportunities?

We can’t afford to 

overlook the relationships

between the people 

who work on a project.

In 2001, TIM FLORES earned his Masters of

Science and Engineering Management from the

Massachusetts Institute of Technology (MIT).

Flores attended MIT as part of NASA’s

Accelerating Leadership Option (ALO), which

allows some of NASA’s most promising midcareer project managers to develop skills needed to lead the

Agency in the 21st century. The program combines business

management and systems engineering studies at MIT with a

one-year developmental assignment.

Managers from all nine NASA Centers have participated in the

three-year-old program. In their developmental assignments,

graduates have worked at IBM, Raytheon Corporation,

MC Corporation, National Reconnaissance Office, NASA

Headquarters offices and other industry and Agency settings.

Tim Flores’s post-grad assignment with L3 Communications has

been extended and he continues to work on the Stratospheric

Observatory for Infrared Astronomy (SOFIA), a joint project

between NASA and the German space program.

You can find Tim Flores’s thesis about the Mars projects,

“Organizational Team Characteristics That Enable Successful

Projects at NASA: A Framework for the Future,” on the NASA

APPL Web site at http://appl.nasa.gov/resources/flores.htm
GETTING 

POLITI CALLY

BY

A C

DR. ROBERT J

TI

.S

V

HAW

E

ASK 120 FOR PRACTITIONERS BY PRACTITIONERS 9

EARLY IN MY CAREER, I DID A

lot of work in icing research.

My research group had

been trying to get money to

upgrade our icing research

tunnel, and it wasn’t going

well. We weren’t considered

mainstream enough, I suppose.

We were given a certain budget

every year and we were told to do

BILL RICHARDSON

the best we could with that money.
Out of nowhere came a front-page news story

about a horrible plane crash that was due to icing. It

wasn’t the icing that we were studying but, nevertheless,

icing research had new currency (yes, pun intended).

Suddenly, the money we were asking for—and more—

was made available to us.

I wasn’t directly involved in bringing that money to

the program. I stood by on the sidelines and said, “Well,

I don’t understand how the politics of this works exactly,

but it seems to be benefiting me and so that’s nice.”

Detachment served me fine in that case. Many years

later, however, I was involved in another political football

match and, this time, the ball didn’t bounce my way.

On My Own

In 1999, the program I was working on, High Speed

Research (HSR), was terminated. I could spend pages

talking about why it was terminated, but at the risk of

sounding like sour grapes, let me just say this: Over a few

weeks (literally, a few), we lost our national agenda and

priority. We went from the top program to the one that

you didn’t want to talk about anymore.

It was a very upsetting experience. Many of the

people who worked for us wanted to know what they did

wrong. The answer was, “You didn’t do a damn thing

wrong.” There were forces at work beyond our

immediate control.

The program was terminated around Thanksgiving.

While I was at home for the Christmas holidays that

year, I put up shelves in our basement. I worked out

some of my frustration with work on my home project.

I still have a lot of drill holes in the wall, and there are

names associated with each one of those holes.

Shortly after the HSR program was cancelled, Dan

Goldin, the NASA Administrator at the time, told my

boss that he wanted to start a new program—somewhat

similar to the program that had been terminated but

different enough to be considered revolutionary. My

boss told me that he wanted me to do this job.

I wasn’t terribly excited about jumping right back

into the political fray. I told him point blank, “I don’t

want it.” He said, “Oh, yes, you do.” So, that was the end

of that discussion.

Politics, Redux

The Ultra Efficient Engine Technology Program

(UEET) is a collection of technologies aimed at

impacting future gas turbine engine designs. Some of

10 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP QUENTIN SCHWINN
the people assigned to UEET worked

in the HSR program and the

Advanced Subsonic Technology

(AST) program, which was cancelled

at the same time. Though these NASA

employees and industrial partners

suffered collateral damage when the

old programs were terminated, I

needed to get them to buy in to the

new program.

I spent a lot of time explaining my

vision for the new program—and listening to their

complaints. That was okay; people need to vent, and

you’ve got to understand that. I believe that by communicating with all the people associated with this program

and by developing a relationship with them, we

developed a high degree of support for the program—to

the point that some of our contractors have taken the

initiative to spread the message that the UEET Program

deserves continued funding.

I want to make very clear, though, that I have never

encouraged any industrial partner to go out and lobby

Congress; that’s not an appropriate activity for NASA

personnel. I think we have a strong, clear vision in

UEET and we deliver timely, high-quality technical

products. This vision and our success in realizing the

vision inspire people to take appropriate action.

I have also spent a good deal of my time with our

stakeholders at NASA Headquarters. Over the years, the

leadership in the Office of Space Technology has

included people of very different backgrounds, experiences, and approaches to program planning. Each and

every one of these individuals has been a good person,

but they come from different perspectives. My advice to

anyone heading up a research program at NASA:

Understand your stakeholders’ perspectives, or run the

risk of seeing your program being killed off in an instant.

And that is also my advice to all program and

project managers. You must engage yourself in understanding the environment in which your program or

project operates. To put it simply: You can run, but you

cannot hide from politics. Either you will influence the

politics that surround your program, or politics alone

could determine the fate of your program. I learned the

hard way that a manager can’t afford to be detached. •

LESSONS

• Projects can, and do, succeed because of politics. And

they can fail due to politics, as well. Politics does not have

to be a dirty word, if it means working closely and openly

with customers and stakeholders; it is an essential

approach that requires continuous dedication of time

and attention.

• Project management is a people industry. Gaining the

trust of your followers will grant you more influence

than any formal authority.

QUESTION

How do you get buy-in from the stakeholders on your projects?

ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 11

“I suppose we all come to project management through

unconventional paths,” says DR. ROBERT J. (JOE) SHAW.

While working on his PhD at Ohio State University, Shaw

didn’t expect to become a project manager, or to spend

his career at NASA. Explains Shaw: “My advisor at Ohio

State told me that NASA is a great place to go for five

years, learn, gain experience, then get out and get on to

the real thing. For me, the real thing was to become a

university professor. But as that great philosopher of our

time, Yogi Berra, said, ‘When you come to a fork in the

road, you take it.’” After starting out as a Division Manager

in the Icing Program at Lewis, now the John Glenn

Research Center, Shaw gravitated to a formal project

management role leading the High Speed Research

Project. Most recently, he has managed the Ultra Efficient

Engine Technology Program Office and started up the

Vehicle Systems Program.

Understand your stakeholders’

perspectives, or run the risk 

of seeing your program being 

killed off in an instant.
1212 APPL APPL THE NASA A THE NASA ACCADEMY OF PR ADEMY OF PROGRAM AND PR OGRAM AND PROJECT LEADERSHIP OJECT LEADERSHIP
ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 13

WHERE I WORK AT NASA’S JOHN GLENN RESEARCH

Center, we joke about how we all went to engineering

school, but what we really needed were classes in

political science and marketing. These days, it seems

that technical decisions aren’t made strictly based on the

merits of the technology. At their root, decisions about

research projects are largely political.

It all comes down to this: How do you convince

people that low-visibility projects have the potential to

change the way they live, and that they share a vested

interest in the outcome of this work? And it’s not just

the American public or Congress that I need to

convince. I’ve found that I have to do a lot of “stumping”

within the Agency about why this technology is so

important.

As a project manager, I have to be aware of what’s

going on at my research institution relative to other

ADVOCATING RESEARCH IS A LITTLE TRICKIER

THAN SELLING OTHER PROJECTS AT NASA.

YOU CAN POINT TO A SATELLITE. YOU CAN

POINT TO A ROCKET. YOU CAN SEE THE

SHUTTLE AND THE INTERNATIONAL SPACE

STATION. BUT IT’S DIFFERENT ON THE

RESEARCH SIDE. HOW DO YOU DISPLAY

COMPUTATIONAL FLUID DYNAMICS? HOW 

DO YOU GET SOMEONE TO UNDERSTAND 

THE VALUE OF COMPOSITE MATERIALS OR

NANO-TUBES THAT THEY CAN'T EVEN SEE

WITHOUT A MICROSCOPE?

Turn up the heat: Material processing facilities

at the John Glenn Research Center host hightemperature research. DONALD HUEBLER

STUMP

FOR TH

IN

E PROJE

G

CT

by Carol Ginty
programs and projects—and I have to be on the lookout

for any threats that might be coming my project’s way.

When my program manager, Gary Seng, gets mandated

budget cuts, he has to take the money out somewhere.

An important part of my job is convincing him that my

project shouldn’t be the one that gets cut.

It helps that I’m genuinely passionate about what

we’re doing. So, whenever I have the opportunity to

present our technology to upper management, I don’t

simply report the status of our milestones. I try to make

every presentation exciting. I show the potential of what

we’re working on and I talk about benefits down the

road. I spin the project however and to whomever I

think it needs to be spun.

Currently, I’m managing advanced high temperature materials research. Almost every system study has

identified materials as the key to future technological

developments. So, I’m always out there looking for any

nugget of information that I can pull

from one of the studies. I’m looking for

that sound bite capable of influencing

someone in about 30 seconds—

something that will leave him or her

thinking, “Oh, we really do need this

materials research.”

The technology being developed in my project will

enable a commercial subsonic engine to perform at

higher temperatures. When you raise the temperature in

an engine, the engine runs more efficiently. You reduce

emissions and save money because the engine burns less

fuel. Most current materials have reached their inherent

thermal capabilities. So, we are developing both new

material systems and coatings for existing materials to

achieve this goal.

If I simply told you that millions of dollars have

gone into this research and that the operating temperature of an engine has been increased by 100 degrees

Fahrenheit, you might jump to the conclusion that we

haven’t accomplished much, and that we’ve been

wasting money. Instead, I point out that a think tank at

Stanford University recently did a study and concluded

that raising the engine temperature 50 degrees

Fahrenheit across the entire fleet of commercial airlines

would save $1 billion annually in fuel consumption.

That gets people’s attention.

And that’s what I mean by

selling the project.

I have learned that the

technical paper doesn’t sell

a project. Frequently at

reviews, you watch people

nod off in the middle of all

the technical data. While it’s

exciting to the researcher,

it’s often boring to the decision makers. If you want their

vote, you need to get their attention and you need to

show them value. •

LESSONS

• There are times when the role of the project leader is

simply to sell the project. On a research project it is often

more crucial and more difficult, and requires focus,

effort, and creativity.

QUESTION

Is there a point at which “selling” a project can become “selling

out” a project? 

14 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

How do you get someone to

understand the value of composite

materials or nano-tubes that they 

can’t even see without a microscope?

I have learned that the technical

paper doesn’t sell a project.

CAROL GINTY has held several positions at the John

Glenn Research Center over the last 20 years, all

involved with the research and development of

advanced propulsion materials for aeronautics applications. In 1989, she became a subproject manager

for Analytical Methods in the High Temperature

Materials (HITEMP) Program where first-life prediction

methods were formulated for high temperature

composites. In 1991, she became the Deputy

Program Manager for HITEMP and assumed the role

of Manager in 1998. She was responsible for the

successful completion of the program, which had an

unprecedented, 12-year uninterrupted life cycle. 

In 2000, she formulated a follow-on project, Higher

Operating Temperature Propulsion Components

(HOTPC), and is currently managing that effort.
ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 15

YOU KNOW THE FEELING: YOU THROW A PARTY, INVITE A LOT your throat so many times and say, “Maybe we should

of people and you pray they show up. When we planned wait another ten minutes and see if a few more people

one of our first Transfer Wisdom Workshops (TWWs) at get here.” Eventually, we got things underway.

Goddard Space Flight Center, we expected to run a TWWs focus on practitioners’ stories about their

workshop with 25–30 people. Instead, only five people work experiences. We craft the stories we discuss and the

from Goddard had entered the room by the time we questions we ask to bring out concrete examples of best

were supposed to start. practices and lessons learned. Our aim is to help the men

It’s hard to “share” knowledge when you don’t have and women who work on NASA projects step away from

people there to do the sharing, but you can only clear their work for a moment in order to better understand it,

TRANSFER WISDOM

WORKSHOPS

COMING TO A NASA CENTER NEAR YOU

By Denise Lee

SPECIAL FEATURE: KNOWLEDGE SHARING

IN NOVEMBER 2001, THE APPL

KNOWLEDGE SHARING INITIATIVE 

INTRODUCED A NEW PRODUCT,

THE TRANSFER WISDOM WORKSHOP.

THE IDEA WAS TO GIVE PRACTITIONERS

AT EACH OF THE NASA CENTERS

THE OPPORTUNITY TO ENGAGE IN A

KNOWLEDGE SHARING ACTIVITY.
16 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

SPECIAL FEATURE: KNOWLEDGE SHARING CONTINUED

learn from it and then share what they have learned with

others. By the end of a workshop, we have participants

familiar enough with the concept of sharing knowledge

through narratives that they write their own stories. (You

can see a few of these stories on pages 18–19.)

Though we had only a handful of participants at

that first Goddard workshop, we engaged them in lively

discussions and, by all accounts, they left feeling that

they had spent their time productively and had learned

a great deal from one another. We had done a solid job

running the workshop—but it was apparent that we had

done a poor job recruiting participants.

At a coffee shop not far from Goddard, the

Knowledge Sharing (KS) team gathered for a debriefing.

I got into a discussion with Dr. Alexander Laufer

(Editor-in-Chief of ASK and creator of the TWW

concept) about our planning strategy. Alex’s idea had

been to go to each of the Centers and spend face-to-face

time recruiting KS affiliates who would, in turn, sell the

workshop for us. I pointed out that the plan sounded

great in theory, but our affiliates were all busy people,

top-notch project managers themselves, and they had

precious little time to tout our initiative and make sure

chairs were filled at our workshops.

I suggested that rather than relying on affiliates, I

should “work” each Center to guarantee we had an

adequate turnout. Alex argued that I wouldn’t know

how to identify the right people. I countered that if we

found ourselves on the morning of a workshop not

knowing how many people were going to walk through

the door, then we weren't doing a good job marketing

our program.

I believed that if I had more influence over signing

up workshop participants, then I could make the

process work. In fact, I promised that I would. I didn't

have anything to back me up other than my confidence

in the philosophies we were teaching and my belief in

the value of the TWWs. We simply had to do a better job

of getting our message out there.

To my surprise, Alex came to me the next day and

told me that he thought my approach to the problem—

recognizing the need for hands-on marketing—was

creative and might just work. He had to be willing to

accept a risk, but project managers have to do that all

the time. He gave me the go ahead.

NEXT STOP, FLORIDA

Our next workshop was at Kennedy Space Center in

Florida. Two months before the workshop, I went with

Michelle Collins (then NASA’s KS project manager

and someone who had spent most of her NASA career

at Kennedy), and we walked the halls of the Center,

talking with experienced project managers we knew

from previous KS activities as well as managers who

had been recommended to us. We met with 30 people

in 2 days.

We introduced ourselves, gave an overview of the

initiative and asked the managers for the names of

people we should invite to the workshop. Then we

asked them to encourage people on their projects to

attend. We only requested 15-minute meetings, because

we knew that the only way to get on a busy manager's

calendar was to ask for a brief meeting and to honor

that timeframe.

This idea of asking experienced project managers to

recommend younger project managers for the Workshop

goes along with our vision of knowledge sharing as a

grassroots initiative. If young project managers get a form

letter from NASA Headquarters suggesting they

consider attending a new program, how likely are they to

take time away from a heavy workload? If a project

manager they know and respect tells them that it’s a good

thing to do, they’re a lot more likely to go.

The people we’re trying to get to come to the

workshop aren’t necessarily project managers or even

people on a project management career track. We’re

targeting the team of people who work on a project,

trying to get them to embrace the philosophy of

knowledge sharing and put to use some of its practices

and lessons. The idea is that projects have many

components—for instance, procurement, systems

WE SIMPLY HAD TO DO A

BETTER JOB OF GETTING 

OUR MESSAGE OUT THERE.
ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 17

engineering and human resources. All the different

disciplines contribute to a project.

On the same visit that we spoke with project

managers, we identified a champion in Training and

Development at Kennedy, Tim Gormley. The idea was to

cultivate a local champion because we were only going

to be on site for two days. We sold Tim on the concept

and he stayed with us every step of the way.

RSVPs for the workshop started coming in almost

immediately. I didn’t just let an RSVP drop into my

email box. I called each person back and said, “I

received your RSVP. Thank you so much. We are

looking forward to meeting you and introducing you to

the Knowledge Sharing Initiative.”

How many workshops do you sign up for where

someone calls you? Where you talk to the person who’s

actually going to run the workshop and they say, “I’m

really looking forward to meeting you”? I tried to

establish a relationship from the moment someone first

heard from me. And from that moment on, I understood

that my credibility was on the line.

SHOW TIME

The day of the Kennedy workshop, I had a knot in my

stomach before people arrived. But as they trickled in,

first alone and then in groups of two and three, I knew

it was going to be a good day. And it was. By the time we

got underway, we had 26 participants in the room.

TWWs use the stories in ASK Magazine as a starting

point. At the Kennedy workshop, people began reading

the story we had given them and silence fell over the

room. Slowly, as people finished reading, we heard the

murmuring of conversations starting up in the small

groups we had set up.

People read at different speeds, and the sound of

their voices grew as time passed, until the entire room

was discussing the stories and leveraging the knowledge

in the stories to talk about their own work. Lessons

were continuously being generated and shared,

generated and shared.

As I watched people talking at that first Kennedy

TWW, I realized that the workshops themselves are the

fun part of my job. The material we present speaks for

itself once we get participants through the door. Our

challenge is speaking for the material in advance, so that

people have the opportunity to experience it. •

THE MATERIAL WE PRESENT

SPEAKS FOR ITSELF 

ONCE WE GET PARTICIPANTS

THROUGH THE DOOR.

“What we’re trying to do in this initiative is promote learning,” says DENISE LEE, who manages

Transfer Wisdom Workshops and Masters Forums for the APPL Knowledge Sharing Initiative.

Lee didn’t just come off the street to start doing this; her Masters degree in Organizational

Learning focused on Knowledge Management. Says Lee of her current work, “My role is to

create the space where people can come together to learn from one other.”

In a project like the Transfer of Wisdom Workshops, Lee works to change workplace mindsets and behaviors,

and to help instill a culture of knowledge sharing at NASA. Her strategy? “Perseverance,” says Lee, “is

necessary in any change project. But even more important is a willingness to learn and adapt as you go.”
18 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

O ur division was under a hiring freeze and our

workload was increasing. We had one person on

staff who was rarely assigned work on highprofile projects because he was thought to be nonproductive. I decided that it was time to bring this

person out of mediocrity and into productive mode.

I believe that all people want to do well and want to

succeed. I approached my manager with my thoughts

about this. He laughed and said, “He doesn’t have what

it takes and won’t change.” I pointed out that if we did

nothing, the workload would continue to rest on a few

people and our best workers were likely to experience

some form of burnout. I proposed that I become a

mentor to this person.

I began by explaining that I wanted him to succeed.

I spent a lot of time listening. Soon his work output and

confidence began to improve. He came by and asked

frequent questions and proposed possible solutions.

This “problem employee” often solved his own

problems as he spoke. By giving him the encouragement

to extend himself and trust his judgment he seemed to

blossom. He even went to my supervisor and asked for

more challenging work! 

My supervisor came by, excited, and said he had

noticed changes and wanted to thank me for doing such

a fine job being a mentor. I told him, “All I did was put

him in touch with his own potential. He did all the rest.”

I learned much from this experience: Do not judge.

Take time to know people and their dreams and goals.

Listening is often more important than talking. •

T

he opportunity to manage a flight project came up

and I was eager to see what that world was like—

to actually see hardware fly. The only catch was

that the opening occurred because the current project

manager wanted out. It was too much work on top of his

other workload, and the project scientist was driving

him crazy.

Sure enough, as soon as I took the job, the project

scientist started complaining all the way up to his

management chain. We would

be in a meeting and have to

step outside to argue over some

disagreement. Finally I decided,

“If you can’t beat ‘em, join

‘em.” I started to listen closely

to his concerns and realized

that some were valid. I also

started to recognize his strengths, and I capitalized on

them. He was quite articulate and he was willing to share

his ideas with an audience. I asked him to present a few

charts at our monthly presentation to management. I

also included him on the telecoms with our payload

support managers at Marshall Space Flight Center and

Johnson Space Center. These simple things gave him

more insight into what was going on with the project,

and they cost me nothing.

The project moved along and before too long our

hardware was tested and ready to fly. It was time to

present our work to management during a two-day

review. The project scientist faded into the background

because he trusted me to do my job. The first part went

fine. I went home Friday evening, thinking about what I

would say on Monday. But things didn’t work out the

way I planned. I was eight months pregnant, and I went

into premature labor. I called work to say that I wouldn't

be in on Monday.

When Monday came, the project scientist did a

wonderful job presenting my charts—but not before

praising me for the job I had done. This from a person,

who looked more like an enemy than a friend when I

first met him. You can go far when you reach out to

“enemies” and listen. •

LISTEN UP

Carlos Torrez, Ames Research Center

Transfer Wisdom Workshop November 7, 2001

TRUSTING THE ENEMY

Terri Rodgers, John Glenn Research Center

Transfer Wisdom Workshop May 2, 2002

I TOLD HIM, “ALL I DID WAS

PUT HIM IN TOUCH WITH 

HIS OWN POTENTIAL. HE DID

ALL THE REST.”

SPECIAL FEATURE: KNOWLEDGE SHARING CONTINUED
ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 19

D uring a long and checkered professional career,

I was taught to “never get in bed with the

customer.” While working for the government

(NASA and US Air Force), “getting in bed” with the

customer/supplier would, at worst, compromise your

objectivity and result in a conflict of interest, and, at

best, give the appearance of impropriety.

While working in private industry, we were told that

“getting in bed” with the customer/supplier would reveal

minor flaws in your product or process that the

customer didn’t really need to know about. We were told

that the customer would nitpick you to death with

questions and concerns that weren’t important, and that

decision-making would be delayed by bringing someone

else into the decision making process. We were told that

proprietary products or design processes would be

revealed to someone without a “need-to-know.”

One project changed my feelings about all that.

Project KAFFU (Kiwi Air Force Fighter Upgrade) was 

a fighter retrofit program for the Royal New Zealand

Air Force; we were trying to give F-16 capabilities to

old A-4 fighter aircraft. When the contractor I was

working for won the competition, the contract

included sharing office space with the Royal New

Zealand Air Force engineers, pilots, and maintainers

throughout the entire development, prototype, and flight

test effort—cradle-to-grave, as far as the engineering

effort was concerned.

We sat side-by-side with these guys. They participated in every facet of the engineering development

program. They helped write requirements, software,

drawings, specifications, test plans, test procedures and

test reports. They worked in the lab integrating and

testing hardware and software. They knew how things

worked, and they saw things fail. They saw smart and

dumb engineers and managers. They worked and played

with all of us. Aside from a few classified areas, they had

full access to our entire facility—our engineering labs,

work areas and our cafeteria.

They were truly, fully, integrated into our

engineering team. And the results? 

We had product advocates (the Royal New Zealand

Air Force engineers) who were trusted by both the

customer (the Royal New Zealand Air Force) and the

supplier (us). With less engineering work for us, we

produced a product that more fully addressed our

customer’s needs and requirements. It was a better

product—more capable and user-oriented—than we

would have produced without the active participation 

of the customer’s engineers, operators, and maintainers.

And, in the end, we had a well-informed, well-educated

customer expert in our system’s uses and capabilities.

Overall, the results from “getting in bed” with the

customer were nothing like I had been taught they

would be. Nothing but good came from the effort, and

both customer and supplier benefited—the ultimate

win/win situation. •

GET IN BED

Jon Bauschlicher, Kennedy Space Center

Transfer Wisdom Workshop January 23, 2003

THEY WERE TRULY, FULLY

INTEGRATED INTO OUR

ENGINEERING TEAM.
20 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

WHILE WATCHING THE LAST EPISODE, I RECOGNIZED Once the victim appeared, there was no wasted

parallels between what was going on in the emergency motion. With time as the chief resource, no one did

room, with its host of accident and gunshot wound victims, anything that didn't directly address the ultimate

and what goes on in successful project management. objective—saving the victim. The medical team shared

a clear set of priorities: deal with life threatening issues

Inside a Metaphor first, possible long-term consequences second and

First, there was a sense of urgency, but not haste. ignore everything else.

As an ambulance or helicopter brought in patients, the Each person in the room had an active role. No one

physicians, nurses and technicians did some quick was in the emergency room as an observer or overseer.

planning, anticipating the likely condition and needs of Someone was clearly in charge, but typically no one

the patient. They moved to get the necessary tools and waited to be told what to do. Interestingly enough, no

equipment in place before the patient arrived. one ever seemed paralyzed by fear of doing the wrong

Contrary to what my wife would say, I don’t watch

much television. I do, however, regularly watch one

show on the Learning Channel—the reality series

called Trauma: Life in the E.R.

The

Television elevision

SHOW byTerry Little SHOW

PROJECT MANAGEMENT PROJECT MANAGEMENT:
thing. Through training and experience, the entire

team operated in harmony. When there wasn’t enough

information to make a decision about a course of

treatment, the staff moved quickly to get more information using x-rays, magnetic

resonance imaging and similar

diagnostics. People spent little

time debating or pondering

what to do next.They decided on

what to do and got on with it.

Sometimes the unexpected

happened and a situation that

seemed to be in control

suddenly went out-of-control.

In those cases, there was

no hand wringing or fault

finding—just a measured,

adapted response to the new

situation. Sometimes there

were mistakes; mostly they were

acts of omission rather than commission. There was

concern and open discussion about the mistakes, but

learning was the chief consequence.

I also noted that there was a general acceptance that

not everything affecting the patient was totally within the

control of those in the emergency room. The staff

spent their time dealing with what was in their control

and not complaining about what wasn’t.

Rerun

I know some of you are thinking that I have carried

this metaphor too far. Perhaps so—perhaps not.

Consider planning and preparing for the project.

It’s important to do it, but a team shouldn’t spend too

much time trying to achieve perfection. The plan will

never perfectly reflect reality. And what about priorities?

Certainly a project’s priorities are likely to be less

clear-cut than those in an emergency room, but having

them and working to them is no less important.

Think about economy of resources. It’s important to

have the right number of people working the project, but

each must have an active role. Like the emergency room,

a project has no place for bystanders.

Expending effort on the niceties when the

fundamental objective is in question doesn’t work. From

what I know of project management, the expression

“Nero is fiddling while Rome burns” is alive and well.

Recall from your own experience what happens when

a project begins to go awry. Lots of meetings, lots of

analyses and lots of discussion—all aimed at deciding

on the “right” thing to do. We accept that as a matter of

course, but should we? 

What’s wrong with making a rapid decision based

upon the data at hand,

intuition and experience; and

then, having made the

decision, focusing our energy

on execution? Let’s face it, a

perfect answer for any project

emergency doesn’t exit. Yes,

there are some fundamentals

to consider, but never a backof-the-book answer that

prescribes the solution.

And finally, how do we

deal with mistakes in project

man-agement? They are

inevitable, you know. Any

project manager who claims

to have never made a mistake is either a neophyte or a

liar. Sometimes our mistakes result from things we do

or don’t do when we should have known better. Other

times our mistakes are only retrospective mistakes—

mistakes because of factors we could not have known or

anticipated.

In either event, we should deal with our mistakes

and those the folks working for us make in the same way

as the emergency room does. Admit the mistake. Distill all

the learning from it we can. Move on. Like the emergency

room staff, the alternative of avoiding mistakes by doing

nothing simply isn’t in our playbook. •

ASK 12 FOR PRACTITIONERS BY PRACTITIONERS 21

Let’s face it, 

for any project

emergency there 

is no perfect

answer.

“In order to provoke unconventional

thinking, you need to create a situation

where the status quo won’t get you

there,” says TERRY LITTLE of his management style. “Until you’re able to turn that light on in

people’s heads that just doing things the same old way

isn’t going to get you to where you need to be, you’re not

going to stimulate innovative, creative thinking.”

Little is currently the Director of the Kinetic Energy

Boost Office of the Missile Defense Agency. Before 

that, he was the head of the Air Force’s Center for

Acquisition Excellence. He is one of the Air Force’s

most seasoned program managers, and was promoted 

to Senior Executive Service in 1997.
I WANT TO SCREAM, “I LEARNED THESE LESSONS 30 YEARS

ago. Why do we continue to learn these same lessons

over and over again?” I don’t scream, though; I remind

myself the individuals are probably experiencing these

lessons for the first time. I’ve come to realize, too, just

about all the repeated lessons reduce down to just 

one primary lesson: Project scope drives project cost

and schedule.

Said another away, if you properly define and gain

alignment to your project scope early in the life of your

project, the cost and schedule will follow.

I love the scope but hate the cost!!!

I was the project manager on a project and was called

into a Friday afternoon meeting to review the project’s

cost, scope, and schedule. I used my traditional agenda

of scope review, cost review and schedule review. During

the scope review, I discussed the base scope (i.e. scope

required to meet the business requirement) and the

value-added scope (i.e. savings-justified scope, which is

discretionary but improves the economics of the overall

project). The scope review went extremely well.

Next we talked the cost of this scope. The reaction

was, “I love the scope but hate the cost.” My response

was if you like the scope, then this is the cost. We went

back and forth on this point for the next twenty

minutes and at the conclusion of a robust discussion,

we agreed to the proposed scope but disagreed on the

cost to be presented to top management the following

Monday. We did agree to mull over the scope and cost

data and reconvene on Monday morning to review our

positions again. We met at 7 AM on Monday and

agreed to use my cost figure in the subsequent

meetings with hierarchy. The figure was used, the

scope was installed, and the job came in slightly below

the stated costs.

This experience reaffirmed my belief that if you get

the scope correct, the costs will be correct. As I sit

through other project critiques or learn a project’s

costs are trending high or low, the root cause I ask the

team to address is how their original scope basis has

changed. Without exception, changes in scope by the

team and/or their hierarchy directly relate to changes in

cost and schedule.

22 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

LESSONS LEARNED

AGAIN AND AGAIN AND AGAIN

RECENTLY I HAVE SAT THROUGH A VARIETY OF PROJECT CRITIQUES

AND HAVE ASKED THE TEAMS INVOLVED TO ARTICULATE THEIR

LESSONS LEARNED ON THEIR PROJECTS. DURING THESE REVIEWS,

MY ANXIETY LEVEL AND BLOOD PRESSURE INVARIABLY INCREASE

BECAUSE I HEAR THE SAME LESSONS LEARNED, REPEATED AGAIN

AND AGAIN FROM EACH TEAM.

by W. Scott Cameron
ASK 12 FOR PRACTITIONERS BY PRACTITIONERS 23

I want this cost but need that scope 

We started to design and construct a “grass-roots”

manufacturing facility and planned to complete the

multi-million dollar project several years later.

Unfortunately, just how many millions of dollars the

plant was going to cost became extremely troublesome.

Early in the life of this project, management believed

the project should cost $X, a figure based on their collective experience and not on the project’s scope. Agreement

to proceed with the project and its staffing was based on

their $X cost figure. A subsequent conceptual study,

however, indicated that the project’s cost could be as high

as $X + 40% based on the defined scope.

Management declared this estimate unacceptable. They questioned the cost engineer’s credibility,

even though he was quite experienced and had used

proven methods to develop the estimate. Accusations

flew that the scope and estimate were “gold-plated.”

After agreeing to reduce the project scope to appease

management (for example, reducing the building

size), a compromise estimate of $X + 20% was

reached by agreeing to eliminate or change specific

scope items.

After receiving project funding, however, the eliminated/modified scope was restored because the

reduction decisions had been based on cost criteria

alone, with no real consideration of the actual needs 

of the project. For example, by reducing the building

size, a key piece of process machinery could no longer

fit, so the building had to be returned to its original

dimensions. Despite valid scope additions, management

refused to approve project change authorizations. They

said, “You already have 20% more funding than you

need. We’re not going to give you more fat!”

Once management ignored valid cost estimating

and trending data, the project team didn’t bother

much with cost control. The situation soon got out

of hand. The project team knew they were exceeding

their funding commitment, but since management

refused to listen to the team’s concerns and data,

cost control was ineffective.

So the required scope grew while the cost predictions stayed the same. When the project team

completed definition and design, a second estimate was

published at $X + 25%. During construction, the

estimated cost of the plant increased to $X + 40% (note

the amount the conceptual study estimated at the

outset of the project).

At project close, the project team had done an

excellent job of designing and building the plant. The

start-up was on time and one of the best in company

history. Cost was the only criterion the project failed to

meet. Once again, the same lesson learned: Project

scope drives project cost and schedule.

We continue to learn this lesson over and over

again. One day I may just scream! •

SCOTT CAMERON is the Global Capital Systems Manager for the Food & Beverage Global Business Unit of Procter

and Gamble Company in Cincinnati, Ohio. For the past 20 years, he has managed capital projects and

developed other capital management practitioners for Procter & Gamble within its Beauty Care,

Health Care, Food & Beverage and Fabric & Home Care Businesses.

In an interview last year (ASK 7), Cameron reflected on his tenure as a project manager:

“When I think about how I have grown throughout my career, I can talk about the projects that I’ve worked on. But

when I get down to the root cause of my growth and development, the most important factor has been the people who

managed, coached and challenged me. Individual managers have had a profound impact on me. As I look back, I can

see how this boss taught me how to write proposals. This mentor taught me financial aspects and cash flow of the

company. This peer focused me on schedules. This one focused me on team dynamics. This one taught me how to

listen and not immediately react. A collection of people helped me become the manager I am today, and now I feel

that it’s part of my job to share my experience with younger managers the same way that others invested in me.”

WITHOUT EXCEPTION, CHANGES IN SCOPE BY

THE TEAM AND/OR THEIR HIERARCHY DIRECTLY

RELATE TO CHANGES IN COST AND SCHEDULE.

SINCE MANAGEMENT REFUSED TO LISTEN TO

THE TEAM’S CONCERNS AND DATA, COST

CONTROL WAS INEFFECTIVE.
24 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 25

Long ago I observed that people get more things done when

they’re having fun. At the time, I had no idea why. Now I think I

have an answer. When children play, look at the energy that’s

put into it, that’s shared with everyone else. This sort of energy

brings people together, unleashes their creativity and indeed

inspires them to do amazing things. To steal a phrase from Dr.

Owen Gadeken’s article in ASK 7, it’s their “activation energy.”

Amazing stuff! Dr. Gadeken highlighted the need for activation

energy to propel a team to high performance. I’d like to focus

your thoughts on creating this energy.

By Maj. Norman H. Patnode

Grins & Giggles

The Launch Pad to High Performance
26 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

AFTER YEARS OF EXPERIENCE WITH TEAMS, I’VE COME TO

recognize the absolute necessity of grins and giggles—of

having fun. This is hands-down the best way to create

the activation energy needed to move a team forward. I’m

so convinced of this that when I join a team, if it’s not safe

to have fun, I work to change that. In whatever way

possible, no matter how stilted or silly, it’s essential to

inject humor into a team’s work, and the earlier the better.

Once when I joined a small team of engineers who

were responsible for managing tests of reentry vehicles,

I found myself surrounded by people who were not

having fun. They would frequently, after getting off the

phone with a customer, begin to rant and rave about

how stupid the customer was and how much trouble the

customer was causing them because of some new

funding or schedule change.

My solution? I brought a toy plastic dart gun to

work. Whenever one of my teammates began to rant and

rave, I grabbed my gun and shot him, over and over until

he shut up. At that point the whole team was gathered

around, and after we all quit laughing at the ridiculousness of the spectacle, we began to talk about the

problem and what we could do about it. In a matter of

weeks, the attitude of the team had shifted. We began to

work together and to focus on how we could make our

jobs easier by making our customers’ jobs easier.

And the dart gun? Believe it or not, within a couple of

weeks everyone had one, and we continued to use them as

a fun way to blast the negative energy out of our team.

Fun doesn’t have to be this dramatic. The key is to

bring people together—so that they can share, explore

and have fun. This can be done with something as

simple as a lunchtime card game.

I still remember one of my earliest team experiences.

Fourteen of us were doing stability and control work for

high-speed military aircraft programs. Most of us were

young, right out of college, which meant we were

strapped for cash. We ate our sack lunches each day as

we sat at our desks and reviewed reports or read technical

journals. All that changed the day that Paul, a

senior engineer in our group, brought in a

couple decks of cards and herded us into the

new central conference space. “Bring your

lunch,” he said, “we’re gonna have some

fun.” We were a little apprehensive—was

this allowed?

After assuring us that we weren’t

breaking any rules, he said we were going to

play Hearts, and he started explaining the

rules. We ate, played and kept score. More

importantly, we started talking to each other.

Just in that first day I learned that Bill raced his

car on Saturdays at the local drag strip, José had a

girlfriend in Toledo and Joe was taking classes at

night in hopes of getting into medical school. It was fun,

and we agreed to play again the next day.

Pretty soon we were competing for bragging rights.

Then one day, after Bob had won several days in a row,

it happened—we ganged up on him. While it’s true we

“ganged up” on him, what really happened was we

started working as a team. Looking back on it, I realize

that as we got to know each other, it became much

easier to ask those “dumb questions,” and to ask the

team for help when we needed it. We also got a lot better

at working together, solving problems, and getting

things done—all because of a silly card game.

If it hadn’t been for those card games, I’m sure none

of us would have made that three-hour drive to Toledo

seven months later to see José and Lori get married.

Fun comes in many shapes and sizes, but one of the

best ways to bring on those grins and giggles is to tell a

good story. We all recognize how much learning can be

found in a good story, but we shouldn’t neglect the fun

that can be squeezed out of one, as well. On one of my

more recent teams, we made a point to share our stories

in a fun and humorous way.

Every Friday afternoon we’d meet in the courtyard

for refreshments, a much-deserved break, and the

As a team moves

towards higher performance, its

members begin to see the differences between themselves not as

obstacles, but as opportunities.

In whatever way 

possible, no matter how 

stilted or silly, it’s essential to

inject humor into a team’s work,

and the earlier the better.
ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 27

presentation of what we called the “Clue Bird” award. trusting relationships. And trust is the foundation

(A “Clue Bird,” an expression used by pilots in the required to build a high performance team. With a high

military, is a good luck sign because it lands on one’s performance team, you can accomplish anything.

shoulder when one needs it most.) The rules were As a team moves towards higher performance, its

simple. Anyone could get up and tell a story about members begin to see the differences between

someone on the team. Usually the story involved some themselves not as obstacles, but as opportunities.

“noteworthy” activity from the previous week, such as Exploiting these opportunities leads to more innovative

how Dan had become a hero by screwing something up ideas and increased performance. Team members learn

in a way that caused the rest of the team to take note of to move past superficial differences in how they look

an impending disaster, and avert it. and speak, and begin to recognize the differences in how

This was a big team, responsible for the Herculean they think, explore and even dream. They find new and

task of manufacturing and delivering the Air Force’s creative ways to put those differences to work for the

newest large cargo aircraft, so there was never a shortage team. As a result, performance soars.

of stories each week. The stories were always clean and As for the team members, they’ll tell you they’re

in good taste, but since it was widely accepted that only having the time of their life. They’ll tell you what they’re

10% truth was required for a good story, they always doing is fun, not work. Then they’ll make you swear not

brought plenty of comic relief. to tell anyone. So don’t. Just keep on grinning. •

After everyone had told their stories, we’d all vote by

applause and the “Clue Bird” would be passed on to the LESSONS

winner to display proudly at their desk for the week. As • Work can and should be fun. Think about a child at

we all headed back to our desks, laughing and reflecting play—curious, open-minded, learning and discovering.

on the stories we’d just heard, and what we’d learned Play can stimulate a cycle of solving problems and unfrom them, you could actually feel the increased energy covering new ones by bringing out the best in each of us.

in the team. • Regardless of your position on the team, you can

The thread that weaves these three examples of create the fun and energy needed to launch your team

teams sharing grins and giggles is the very fact that they on a path to high performance.

were “sharing.” Shared experiences create space where

team members can get to know one another, and QUESTION

discover how much they have in common with each If not by play, what ways do you tap the “activation energy” of

other. These commonalities are the building blocks of a project team?

Owen Gadeken and Maj. Norman H. particularly dry or even complex 

Patnode met in January 2000 when subject to discuss with the class, I

Gadeken was the faculty advisor to could always rely on Norman to come

Patnode’s section in the Defense up with some interesting insight on the

Acquisition University’s (DAU) topic.” Gadeken soon discovered that

Advanced Program Management Patnode also had a well-developed

Course. “Although Norman sat in the sense of humor, probably honed from

back corner of the room, he was not the experiences he relates in his

shy about commenting on virtually article. Eventually, with Gadeken’s

anything that caught his interest encouragement, Patnode joined the

during the course,” remembers DAU faculty. “I continue to be

Gadeken, whose article in ASK 7, amazed,” says Gadeken, “at the

“Activation Energy,” brought out insights Norman can draw from both

the “Grins and Giggles” in Patnode. his and others’ seemingly routine

Says Gadeken: “Whenever I had a project management experiences.”

MAJ. NORMAN H. PATNODE

is a Professor of Program

Management & Leadership 

at the Defense Acquisition

University, where he provides

training in strategic leadership, critical

thinking, teamwork and teambuilding, the

application of Myers-Briggs (MBTI), program

risk management, coaching and conflict

management. He also teaches a number of 

the basic program management tools. He can

be reached at norman.patnode@dau.mil 
28 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

PRACTICES PRACTICES by Gerald Murphy

> > > IMPLEMENTATION

REVIEWS

>>> T HE BIGGEST CHALLENGE IN MANAGING SCIENCE

INSTRUMENT DEVELOPMENT OR ANY NEW TECHNOLOGY

D EV E LOPM E NT FOR THAT MAT TE R I S T RY I N G TO G E T TH E

PROJECT COMPLETED ON SCHEDULE FOR THE MONEY YOU

H A VE. FEW PROJECT MANAGERS ACCOMPLI SH THAT,

D E SPITE WHAT THEY MIGHT TELL YOU.
AN INSTRUMENT ON THE ADVANCED

COMPOSITION EXPLORER CAPTURES

AN AURORA’S BRILLIANT ARRAY.

ASK 12 FOR PRACTITIONERS BY PRACTITIONERS 29
30 APPL THE NASA A THE NASA ACADEMY OF PR ADEMY OF PROGRAM AND PR OGRAM AND PROJECT LEADERSHIP OJECT LEADERSHIP

IT JUST DOESN’T HAPPEN, AND IT’S EASY TO UNDERSTAND

why: technology development doesn’t have a predictable

path. You haven’t built this thing before so how the heck

do you know how much it’s going to cost, and, besides,

you can’t foresee all the problems you’ll run up against.

You know the result you want and you declare success

when you are “close enough.” In short, the job must be

“dynamically” managed.

When I worked on the Advanced Composition

Explorer (ACE) project, we needed to produce five

instruments that were either entirely new or were

considerably modified from earlier models. These were

each $8–10 million instruments. All of them were what I

would call technically risky in one way or another—

some in several ways.

Some of our problems early in the project derived

from not understanding exactly what the instruments

were intended to do (what was going to be good

enough), and not knowing what we could do to help the

university-based teams in building them. We in the

payload management office took the approach of asking

each team, “What do you need in order to get your job

done, and how can we make that happen?”

As a cure for this problem, one of the things that we

decided to do was to have Implementation Reviews. I

had never been on a project before where this was done,

but it turned out to be the single most valuable review

we had from the point of project success.

Typically, reviews are design-focused. In point of

fact, many of a project’s problems are not due to design

flaws. They are due to implementation flaws—if the

implementation doesn’t have a good “design,” it will not

be executed smoothly.

When I use the word “implementation,” I mean it in

the broadest sense: implementation of the

design and manufacture of the

instrument. And I don’t just mean taking

a look at schedules and money; I mean

looking to see, as well, if you have the

right team, if the team is assembled in

such a way that the lines of responsibility

make sense, if the interfaces are clear and easily defined.

Do you have margin for error? Where are the

technical risk items and what is your plan to deal with

them? Who is responsible for what? How many

engineers do you have on this job and do they have the

right experience? Oh, you have five engineers? Well, I

only see three engineers in the room; where are the

other two? “Well, they actually work for Joe Blow, a

scientist down the hall. Joe has promised me that a year

from now, when I need the engineers, I can have them.”

Yeah, right, but what happens if Joe decides he needs

them in a year? They actually work for him, right?

Here’s another example: On one project, an

instrument team partners with a team from the

European Space Agency (ESA). A foreign scientist there

tells his American counterpart, “I can give you an

electronics board or part of your detector system and it

will do all these wonderful things, and you won’t have to

pay for it out of NASA’s budget because ESA will pay for

it.” The American scientist says: “That’s great; that

makes my instrument cost a half million dollars less.”

I HAD NEVER BEEN ON A PROJECT BEFORE WHERE

T H IS WAS DONE, BUT IT TURNED OUT TO BE THE

SINGLE MOST VALUABLE REVIEW WE HAD FROM

T H E POINT OF PROJECT SUCCESS

PRACTICES CONTINUED

>>>
ASK 102 FOR PRACTITIONERS BY PRACTITIONERS 31

But what happens, a little way down the line, when

ESA is a little slow to fund its part of the project, or

erratic currency exchange rates cause a financing

problem or a new tariff regulation prevents the transfer

of technology from one side of the Atlantic Ocean to the

other? These are examples of implementation

questions. It may still turn out that having ESA

supplement the program is the right thing to do, but you

have to ask the questions.

The point of the implementation review is to

prevent problems from occurring later by trying to get

our arms around the planning from the start. Our

discussion might go like this: “Well, look, instead of

having that scientist across the ocean be solely

responsible for delivering this critical element, maybe we

can find some other way to get it.” Or we might decide

to fly there and observe first-hand how well our

counterparts are doing, and if there is something we can

do to help assure success.

For the ACE project, we traveled around to each

partnering institution. The process took several months

because we would camp out onsite for three days. We sat

around the table together, listened to presentations and

figured out how we were going to get the instrument

built and delivered. We found the holes and looked for

ways (together) to plug them. We tried not to be

optimistic and fool ourselves.

The size and composition of review teams were

tailored to the places we went. It was always tricky

putting together just the right team, but Al Frandsen,

our payload manager, was good at that and we managed

to find the expertise that we needed.

The review teams turned out to be between five to

eight people, a balance across the different disciplines,

and they included the payload group (i.e. Al Frandsen,

Howard Eyerly, our Reliability and Quality Assurance

Manager and me). Say we knew that a team was having

a problem making their detector meet

launch load requirements. We would grab

somebody from JPL who could solve that in

a week instead of letting the instrument

team spin their wheels for six months. In

addition, we would typically bring someone from

Goddard who was good at understanding resources and

estimating actual costs.

The implementation review happened only once at

each site, but it was a big deal. I would say it was the

most important thing we did to enable ACE to deliver on

schedule and within budget, because we recognized and

dealt with potential problems before they became

unmanageable and costly.

Since then I have seen several projects that would

have benefited from this review. It is important that it

take place at the right time. You have to understand

your requirements, your schedule, and your other

resource constraints. You also have to understand

where you have flexibility. If the review is too early, it is

not beneficial; if it is too late, you are buried in trying

to solve the problems of the day instead of being ahead

of the wave.

Implementation reviews do one other thing. They set

the tone for management of the project. They establish a

teaming relationship (if they are run properly), and they

level the playing field instead of setting up turf wars. •

GERALD (GERRY) MURPHY founded Design Net engineering in

1996 as a network of senior consulting engineers

serving as “problem solvers” for NASA missions. The

network evolved into an aerospace hardware/software

development company providing design and fabrication service to businesses, universities, and government agencies. About his world since leaving NASA, he says,

“Managing with flexibility is still my paradigm. In fact, it works in small

business environments even better than when you are managing the

standard NASA project. In either case, the ground under your feet is

always in motion, and fog in the road up ahead never quite “clears.”

> >> T HE SIZE AND COMPOSITION OF REVIEW TEAMS

WERE TAILORED TO THE PLACE WE WENT

FROM LEFT TO RIGHT, A TRIO OF ADVANCED COMPOSITION EXPLORER INSTRUMENTS: 

SOLAR WIND IONS MASS, SOLAR ISOTOPE AND SOLAR WIND ION COMPOSITION SPECTROMETERS
32 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

DEVELOPED FOR THE 2001 MARS SURVEYOR LANDER,

MECA is a miniature chemistry, microscopy, and

electrostatics laboratory. MECA was chosen by NASA

from a field of 39 proposals and was developed to

perform studies on the potential hazards that the soil

and dust on Mars might pose to human explorers. (The

MECA project was featured in an earlier article by Dr.

Hecht in ASK 7.)

In his previous assignment with NASA’s New

Millennium Program, Dr. Hecht was instrumental in

defining the “microlander” that was adopted as NASA’s

New Millennium Program Deep Space 2. Beginning in

1991, he led a microtechnology program at JPL’s

MicroDevices Laboratory.

Dr. Hecht was the first recipient of JPL’s Lew Allen

Award for Excellence, which was established in 1990 to

recognize and encourage significant individual accomplishments or leadership in scientific research or technological innovation by JPL employees during the early

years of their professional career. He has published

extensively in both the surface science and the planetary

science literature. He received his Ph.D. from Stanford

University in 1982. He has also been a member of the

ASK Review Board since ASK 1.

A couple of years ago, you gave a conference presentation

about a science instrument, MECA, that was going to fly

on a Mars mission. You described yourself as both the

project manager of the instrument team and the coinvestigator. It’s unique for a project manager to be

involved so directly in the science of a project. Why are

these normally kept as separate functions? 

Generally, there is the concern—and it is a legitimate

one—that someone who has an investment in the scientific return isn’t going to be able to control the

resources. At my institution, JPL—and I think at NASA

in general—you’ll find there’s a creative tension between

the science team on a mission and the project team. The

model is that the science team pushes the capability,

while the project manager holds the line and protects the

resources. The science team will come and say, “We want

more memory so we can do more analysis on the ground

and return better data,” while the project manager will

say, “that will push the budget or schedule.” Allowing a

scientist to also have a project management role is

generally viewed as the equivalent of letting the fox

guard the chicken coop.

INTERVIEW 

Dr. Michael Hecht

Dr. Michael Hecht has been a member of NASA’s Jet Propulsion Laboratory (JPL)

staff since 1982. He is currently Project Manager and co-investigator for the Mars

Environmental Compatibility Assessment (MECA)
ASK 12 FOR PRACTITIONERS BY PRACTITIONERS 33

But MECA was different. How so?

MECA was a very unusual project. We were below the

radar, if you will, so we could be a little more relaxed.

What kind of relationship did you have with the

Principal Investigator (PI), someone you were working

with closely as a scientist and at the same time managing?

On MECA, the principal investigator was expert in the

general scientific issues we were studying, hazards

associated with particles. He was a senior guy, very

skilled and very knowledgeable, from whom I have

learned a tremendous amount. But he knew almost

nothing about Mars science, so that was really my role. I

was the one defining the Mars science agenda.

When we have a discussion about who should be the

principal investigator for an instrument or a mission, we

recognize that there are two different jobs of the PI, and

you seldom find an individual good at both of them. One

job is to be the statesman, the spokesman, the senior

individual with unimpeachable scientific credentials, who

stands up in front of the cameras and speaks for the

mission. The other job, frankly, is a day-to-day science

management job. Most people in this community

recognize that once you get past winning the proposal,

it’s more important to have a science manager than it

is to have a statesman.

How does your background as a scientist, or researcher,

help you as a project manager?

To me, the science is part of the whole system. When

you optimize the system, the science is one of the factors

that you can weigh. I’ll give you a very simple example.

This happened with MECA when we had an opportunity

to add a component, a stirring device that would accelerate chemical reactions. Now, the reaction of the project

manager of the overall mission was, “You’re adding

capability to the instrument.” My reply was, “By doing

this we can finish the experiment in one day instead of

two days. We won’t have to deal with an overnight freeze

and thaw cycle, which not only imposes risks, but adds

a great number of requirements on testing, specifically

environmental testing.”
34 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

While I’m considering the science and engineering and

project management as part of the overall risk picture,

I have a different perspective than someone who is only

treating the issue as a requirements driver.

Does this sensibility, being a scientist/project manager,

affect how you select your team?

We all have a model of the kind of person we want

working for us, and it often mirrors our own abilities

and interests. That “sensibility,” as you want to call it,

defined my choice of all of our staff. On MECA I put

the kind of team together that I could work with. I

drew on a group that JPL likes to call “technologists,”

a group it doesn’t normally look to for mission work.

By technologists, they mean scientists in disciplines

other than space science. That’s not pejorative; it’s just

terminology, nothing more. You could have a Nobel

Prize-winning biochemist and JPL wouldn’t put him in a

science category.

These were people that I had worked with for

years, and years, and years. Many of them were physicists or chemists. I tend to be fond of physicists

because I am trained in physics. The organization I

came out of is called the MicroDevices Lab. We had

people who are electron microscopists or spectroscopists, people who study the arrangements of

atoms on surfaces. In fact, that’s what I did most of my

career. I studied surfaces and interfaces, semiconductor materials.

My model for project management was the one 

I learned from hanging around small businesses. If

someone is too busy to finish this job, the person at the

next desk will finish it. Laboratory scientists are good at

working this way, and have an instinctive grasp of the

trades involved in defining the instruments. I thought it

was easier to take those very bright, PhD scientists and

train them how to do mission work than it was to take

the people who typically worked on flight projects to

train them in my management style. So, I had a team

of generalists, and I think that’s why it worked. I think

that everyone felt like they could do any job on that

team. They had an assigned job and they accepted that,

but only because that was what had been negotiated.

If tomorrow we changed the agreement, they could have

stepped into a different role.

Was it difficult to convince people without flight

experience to join the project?

It varied with each person. Of the hundred or so PhDs

in the MicroDevices Laboratory, I have probably

approached thirty of them with such an opportunity at

one time or another. Of the thirty, perhaps five or six

jumped at the opportunity. That’s why they came to JPL,

they told me. They’d always wanted to do space work,

they’d always wanted to build things to fly; they never

knew how to go about it, and they were completely

isolated from the flight culture at JPL.

Did anybody think you were managing the project in an

unorthodox way by building a team of “generalists”?

I don’t know. But one of the most interesting conversations I had when MECA started was with the fellow who

was the section manager of the MicroDevices

Laboratory at the time. He was concerned about what I

was doing because he worried that once those people

went to work on a mission, they would never want to

come back into research. “Why is that so terrible?” I

asked. I think it’s a good thing for a research organization to have turnover—and for us to have alumni in the

larger JPL community.

In the end, it turned out every one of them went

back to research afterwards, but I think they all felt that

they came back to their research with a broadened

perspective. The flight world gives you street smarts

about how to get things done on schedule and to cost

that you never learn in the research lab.

INTERVIEW CONTINUED
ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 35
36 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW CONTINUED VIEW CONTINUED
ASK 10 FOR PRACTITIONERS BY PRACTITIONERS 37

Back to the conference we mentioned at the start of the

interview. I remember you walked into the lobby one night

and said that you had gone outside to look at Mars. Is that

frontier aspect of it something that means a lot to you?

Yes, absolutely. I have to admit that is something that’s

fairly recent. That is something that has developed within

the last decade, at most, that kind of passion for Mars.

And what is the source of it?

Several things, one of which I suppose is that I’m turning

50 this year. I also think it is far more common at JPL

than almost any place at NASA to find that kind of

passion. You find people who come to do jobs all over

JPL—in contracts, in the machine shop, as scientists, as

engineers—and they tell you, “I know I could have made

more money in private industry, but I just fell in love

with the idea of going out and exploring the solar

system.” That’s very common.

You began your career as a researcher, and then moved

into project management. Was that a way for you to get

to Mars?

Not entirely. I enjoy wearing a lot of different hats.

I’ve slowly come to realize that this is something that

drives me. I want to have some experience in every part

of this process, basic instrument concepts through

instrument development, through the actual building 

of flight instruments where I have done my project

management, and through the study, the science of 

what I learn, both the data from the instrument 

and the modeling and theory. I’ve been driven to be 

that broad generalist. The only place in that whole 

chain where there is a conflict, an artificial conflict

imposed by the institution, is in the role of science and

project management.

Could you imagine being the project manager of a project

that didn't allow you the freedom you had on MECA?

I don’t know. I imagine that if I was on a project where I

wasn’t able to select the kind of people I wanted to work

with, the experience would be much less satisfying to me.

Is it fair to ask which of these two, science or project

management, matters the most to you? 

If I have to choose whether my career is going to be in

project management or in science, for me that’s a very,

very difficult choice.

Let me ask you one other question. You’re on the ASK

Review Board, and you participate in the Masters

Forums. What’s the value of the Knowledge Sharing

Initiative for you?

One of the most important messages you learn here is

that as you delve into project management more deeply,

you realize the idea that anyone is doing it to a blueprint

is ludicrous. Nobody uses a blueprint.

Certainly every time I come to the Masters Forum,

or read ASK, I come away with having learned

something. I should say not just new tools, but new

perspectives. I think learning, and not just learning other

ways of doing things, but learning to have realistic expectations is very important. It is just like raising children.

My first one was six years old before we had the second

one. You somehow expect the second one will be like the

first. Of course, they never are. They couldn’t be more

different human beings. I’m sure if we had a third the

same thing would happen.

I’m at that stage in project management where I

need desperately to learn that lesson. If I go in expecting

the next project to be like the previous one, I will not

only be severely disappointed, but I could very well fall

flat on my face. •
38 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

LOOP 

I FIRST MET FRANK THE DAY AFTER I WAS ASSIGNED TO FORM FRANK WAS QUITE AMAZING IN A NUMBER OF SPECIAL WAYS.

a Space Station task force. Frank stopped by my office to I remember his smile that encouraged all to sit and talk,

say that he knew we would need someone to look after his genuine respect for people’s ideas and comments,

management, and he was interested in the job. I liked his and his creative imagination never at rest. He was

style, and I gave him the job on the spot—probably the dedicated to developing training programs and tools to

best program decision I ever made. enhance the effectiveness of project managers at NASA.

We discussed the organization we needed for the Although his formal resources were limited in this

task force, and realized that we couldn’t afford to go endeavor, somehow he attracted talented individuals to

through the usual advertising and selection. So, Frank join him. Textbooks define this as leadership. Frank was

personally persuaded the best and the brightest to join an extraordinary leader and a great friend.

the program. It was a great outfit, and we had a lot of Dale Crossman

fun—thanks in large part to Frank’s efforts. (Everyone

remembers the summer parties that we had at his farm I FIRST MET FRANK OVER 20 YEARS AGO WHEN I JOINED THE

in Northern Maryland.) Space Station Task Force. He liked to point out that he

To the end, Frank excelled at making people want to was the fourth person hired on the program, while I was

take part in whatever he was working on. We will miss somewhat later on the list. My response to him was that

you, friend. at least I was the second Irishman. I dubbed him “Father

John Hodge Mulcahy” after the priest in the television series M.A.S.H

because so many people in the office brought their

IT WAS OFTEN SAID OF FRANK THAT HE HAD AN “IDEA A problems to him.

minute,” and many of them were exceptional. But the After we both left Space Station, we went to

most important example Frank set for us was his different offices at NASA Headquarters, but stayed in

marriage to his beloved Mary Louise. Although married frequent contact. After retiring from NASA, Frank put

for decades, they remained as giddily in love with each together a program to tap the talents of other retired

other as a pair of high school sweethearts. I remember NASA managers. The last time I saw him was at a

when Frank was still working at NASA headquarters, meeting on December 3rd, and he was as upbeat as ever.

they would talk often during the day. I never heard Frank As distinguished as his career was, Frank’s real

end one of their conversations with anything other than, strength was his character. He was one of my best

“Love you,” or “I love you, too.” You only had to be friends, and I miss him every day.

around them for a few minutes before you were not only John Sheahan • 

in awe of their devotion to one another, but also a bit

envious as well.

Tony Schoenfelder

On December 5, 2002, NASA lost one of its stars, Frank Hoban. Recipient of the NASA

Exceptional Achievement Medal and the Apollo Achievement Award, Hoban ended his

NASA career as director of the Project Management Initiative. In 1997, he published a

book about his NASA career, Where Do You Go After You’ve Been to the Moon?

Tributes to Frank Hoban
ASK 12 FOR PRACTITIONERS BY PRACTITIONERS 39

JOHN BRUNSON of the Marshall Space Flight Center is a

member of the NASA Program Management

Council Working Group. He served as project

manager for three separate microgravity

payloads that flew on various Spacelab

missions. His career in the space industry began

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

DR. MICHELLE COLLINS works in the Spaceport Engineering

& Technology Research Group at Kennedy

Space Center. She has over 20 years experience

in aerospace spanning engineering, R&D and

project management. She is on the Florida

Tech Engineering Accreditation Board, the

National Fire Protection Association’s Technical Committee for

Halon Alternatives and the United Nations Environmental

Programme Halon Technical Options Committee.

HECTOR DELGADO is Division Chief of Process Tools and

Techniques in the Safety, Health and

Independent Assessment Directorate at the

Kennedy Space Center. In 1995, he served as

Senior Technical Staff to the NASA Chief

Engineer at NASA Headquarters in Washington,

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

Exceptional Service Medal, Silver Snoopy Award and various

achievement awards.

DR. OWEN GADEKEN is a Professor of Engineering

Management at the Defense Acquisition

University where he has taught Department of

Defense program and project managers for

over 20 years. He retired last year from the Air

Force Reserve as a Colonel and Senior

Reservist at the Air Force Office of Scientific Research. He is

also a member of the Advisory Board of the NASA Academy of

Program and Project Leadership and 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 project

manager and a co-investigator for the Mars

Environmental Compatibility Assessment

(MECA). In his previous assignment with

NASA’s New Millennium Program, he was

instrumental in defining the “microlander” that was adopted as

NASA’s New Millennium Program Deep Space 2.

JODY ZALL KUSEK is a Senior Evaluation Officer at the World

Bank. She is currently involved in supporting

the efforts of seven governments to move to a

focus of performance-based management. She

has spent many years in the area of public

sector reform, serving the Vice President of the

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

Secretary of Energy in the areas of Strategic Planning and

Performance Management.

DONALD MARGOLIES of the Goddard Space Flight Center was

Project Manager for the Advanced Composition Explorer (ACE) mission, launched in

1997 and still operating successfully. He

received the NASA Medal for Outstanding

Leadership for his work on ACE and a NASA

Exceptional Service Medal for the Active Magnetospheric

Particle Tracer Explorers (AMPTE) mission.

DR. GERALD MULENBURG is the Manager of the Aeronautics

and Spaceflight Hardware Development

Division at the NASA Ames Research Center.

He has project management experience in

airborne, spaceflight and ground research

projects with the Air Force, industry and NASA.

He also served as Executive Director of the California Math

Science Task Force and as Assistant Director of the Lawrence

Hall of Science.

JOAN SALUTE is the Associate Director of Aerospace at Ames

Research Center. She has managed many

NASA projects including those involving flight

testing of thermal protection materials,

commercial technology, commercial applications of remote sensing and remote sensing

science projects. She has been at Ames for 20 years, and was

awarded the Sloan Fellowship to attend Stanford Graduate

School of Business in the fall of 2002.

HARVEY SCHABES is currently assigned to the Systems

Management Office at the Glenn Research

Center. He started his career with NASA in

icing research, and since then has served in

numerous organizations in support of the

Space Station Program.

CHARLIE STEGEMOELLER is Manager of the Johnson Space

Center (JSC) Human Space Life Sciences

Programs Office. He is responsible for the

programmatic and tactical implementation of

the lead center assignments for Space Medicine,

Biomedical Research and Countermeasures,

and Advanced Human Support Technology. He began his

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

technical program analyst.

HUGH WOODWARD is a Program Manager for Global Business

Services with the Procter & Gamble Company.

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 terms as vice chair and in several

other key leadership roles.

REVIEW BOARD
LETTER FROM THE EDITOR-IN-CHIEF Dr. Alexander Laufer

40 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

I MOVED BACK TO ISRAEL AND GOT A JOB MANAGING A

large building project where I was in charge of both the

design and construction. The complex I was working on

was being built in Jerusalem—but the design took place

in Tel Aviv. I spent my days shuttling back and forth

between the two sites.

It soon became clear that things weren’t going

according to the textbook. I had learned to prepare

implementation plans as early as possible and as detailed

as possible.

My construction superintendent, an experienced

engineer twenty years my senior, kept

postponing the planning I asked him to do.

He insisted we weren’t ready to create a

complete plan because details of the project

kept changing.

Eventually, I came to realize that he was

right to delay the detailed planning, because

quite often I would explain something I wanted done in

the morning; then I would go to Tel Aviv in the

afternoon and find out that the design had been altered

and the information that I had passed along in the

morning was no longer accurate. Still, I didn’t know how

to explain what I was observing–even to myself.

I left that construction project to teach a summer

graduate school class on construction productivity at

Texas A&M. As part of the course, I sent five teams of

students to construction sites to see how productivity

could be improved. The students set out armed with

high-tech tools and prepared to conduct sophisticated

measurement and analysis. I expected them to come

back with recommendations to improve productivity at

their sites by changes in project staffing, equipment use

and the like.

After weeks of study, they produced, instead,

detailed short-term plans for the projects they had

observed. As project managers, we were all taught to

prepare comprehensive plans, with full details at the

beginning of a project. But that wasn’t what my students

observed in the field, and it wasn’t what I had experienced as a project manager. I began to question the

accepted theory of project planning. Something so basic

that it was alarming.

Why, I wondered, didn’t experienced project managers

have these detailed plans in place before construction

began? Why did they have to wait for my students?

After the course ended, I spent some time giving

presentations at construction companies across the U.S.

I shared my questions about planning with top

managers at the best companies. No one threw

me out of the room, and that was enough to

keep me going. I continued to struggle to

understand what I had observed.

Then, a piece of writing came along to

reinforce my thinking. In Jay R. Galbraith’s 1977

book, Organization Design, I found the missing piece of my

puzzle: uncertainty as information gap. I came to understand that planning equals uncertainty reduction. In

subsequent research, I was able to confirm this. I observed

that uncertainty is not an exceptional state in an otherwise

predictable process of project work.

With this new insight, it was easy to see why my

superintendent kept postponing his planning and why

my graduate students didn’t find detailed plans at the

sites they visited: they needed to collect data onsite, after

construction started. Detailed plans aren’t possible in

the absence of information. I learned that perfection is,

indeed, in the details—but not prematurely. A project

manager must adjust the degree of details in a project

plan to the completeness of available information.

It is so clear to me now, but it took me years to reach

these conclusions. Before I could, I had to let go of

assumptions that I had been taught. So much of learning,

I have come to realize, begins with unlearning. • 

Perfection Is in the Details—or Is It? 

After I earned my engineering doctorate at the University of Texas,

I accepted a teaching position at Texas A&M University. By 1982,

I was ready to return to the field and put principles to practice

I began to 

question the 

accepted theory of

project planning

XX-XXXX-XX-XXX-XX