The NASA Academy of Program 

and Project Leadership

appl.nasa.gov

Inside

Making Reliable Promises

How to Conduct Effective Remote Meetings

Sharing Knowledge, the APPL Way

Streamlining Through Communication

A Conservative Approach to Risk Management

ASK Magazine • Issue Twenty-One

w i n t e r 2 0 0 5

I NTER V I EW

Bill Townsend

Academy Sharing Knowledge

The NASA source for project management

National Aeronautics and Space Administration 
It’s an important management role: 

evaluating people and assessing their needs and capabilities, 

and then placing them in a situation where they can 

get the necessary tools and experience. —Bill Townsend, from his ASK interview (p. 42)
	 STORIES

	 6	 Old Journey, New Heights

I learned some valuable lessons from this remarkably diverse group of talented and committed people who are 

largely responsible for making the project a success By John Del Frate 

	 10	 Establishing a Presence

Being there in person helped to develop a team persona in which we were really aware of each other’s 

strengths and weaknesses By Dr. Jeffrey McCandless

	 12	 The Knowledge Stealing Initiative?

I felt as though I was blindfolded at a fast-moving sporting event and the play-by-play was being described 

to me by many others around me BY Larry Goshorn

	 14	 Earned Value–Added

This feeling was expressed by managers reporting: “I’m getting all the data I need... why do I need 

earned value? BY Michael Jansen

	 18	 Putting EVM to the Test

In many instances there is no forewarning; schedules slip, costs soar, and the project manager is faced with the 

near impossible task of explaining why each impact occurred BY Jerald Kerby and Stacy Counts

	 22	 Earning Value Against Resistance

We figured out that we had to anticipate some level of resistance within the organization, especially if they’ve 

never done this before BY Glenn Rhodeside

	 24	 A Lengthy Career’s Lessons on Risk

Throughout the years, I developed the philosophy that you can be very successful if you spend the time to 

organize yourself, find qualified people, and understand the objectives BY Angelo “Gus” Guastaferro

	 FEATUREs

	 28	 A Leader, Not a Hero

Somebody told me that it takes patience to be a Program Manager. I thought, “Well, I’ll work on that” 

By Lynda Rutledge

	 33	 Keeping Promises

We all know what a promise is; we have plenty of experience making them and receiving them from others. 

So what’s the problem? By Greg Howell 

SPECIAL FEATURE

	 31	 The APPL “Learning Map”

The Academy of Program and Project Leadership teams up with Root Learning Inc. to combine two unique 

approaches to knowledge and learning 

	 PRACTICES

	 35	 Don’t Confuse Documentation with Communication

Like most other young engineers, I learned to use the RFI as a weapon in the ongoing battle between owners, 

or their designer, and the construction contractors by John Strickland

	 38	 Managing Meetings...Remotely

When I issued a meeting notice, with the location described in bold, somebody would inevitably remind me to 

“publish the call-in numbers” by hugh woodward

	 INTERVIEW

	 42	 ASK Talks with Bill Townsend

Former Goddard Deputy Center Director Bill Townsend discusses lessons learned from a 

40-year career at NASA

IN THIS ISSUE • 3

Knowledge, for the Taking

by jessica simmons

REVIEW BOARD • 4

FROM THE DIRECTOR’S DESK • 5

Knowledge and Meaning

through Visualization

by Dr. Edward Hoffman

LETTER FROM THE

EDITOR-IN-CHIEF • 47

Shared Voyage:

Encouraging Unlearning

by Dr. Alexander Laufer

On the Cover The Aura spacecraft launches 

from atop a Boeing Delta II rocket at

Vandenburg Air Force Base in July, 2004.

ASK 21 Winter 2005

appl.nasa.gov

Table of Contents
 appl the nasa academy of program and project leadership

Welcome to the Academy of Program and Project

Leadership (APPL) and ASK Magazine. APPL helps

NASA managers and project teams accomplish today’s

missions and meet tomorrow’s challenges by providing

performance enhancement services and tools, supporting

career development programs, sponsoring knowledge

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

other government agencies.

ASK Magazine grew out of APPL’s Knowledge

Sharing Initiative. The stories that appear in ASK are

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

primarily from NASA, but also from other government

agencies and industry. These stories contain knowledge

and wisdom that are transferable across projects. Who

better than a project manager to help another project

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

small projects—they’re all here in ASK.

Please direct all inquiries about ASK Magazine editorial

policy to Jessica Simmons, EduTech Ltd., 8455 Colesville

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

or email to jsimmons@edutechltd.com.

APPL Director and publisher 

Dr. Edward Hoffman

ehoffman@hq.nasa.gov

Editor-in-Chief

Dr. Alexander Laufer

allaufer@eng.umd.edu

associate Editors-in-Chief

Terry Little

Marty Davis

Content Development Editors

Donald Margolies

Larry Goshorn

editor

Jessica Simmons

jsimmons@edutechltd.com

Project manager: knowledge sharing

Denise Lee

dlee@edutechltd.com

Knowledge sharing manager

Therese Cooper

tcooper@edutechltd.com

Contributing Writers

Ray Morgan

Scott Tibbitts

Gregory Howell

Lynda Rutledge

Editorial Assistant

Michael Derocher

mderocher@edutechltd.com

Design

Hirshorn Zuckerman Design Group, Inc.

www.hzdg.com

senior printing specialist

Jeffrey McLean

jmclean@hq.nasa.gov

printing

Mosaic

Staff

ask online

http://appl.nasa.gov/ask
True, I’m a writer, but the Knowledge Sharing

Initiative has taught me that the same sentiment applies

for project managers: Take from the lessons and

accomplishments of the best. And we’re not talking

imitation—there is no flattery here—this is all-out

thievery. Make someone else’s story your own story,

make someone’s lessons learned your own. Gather all

the tidbits of best practices and leadership to become

integral parts of your own project management style,

not to be goals you strive to reach. Take knowledge, live

it, and claim it as your own.

The first time you do it, you might look over your

shoulder a little. There might be some guilt attached

to learning from the stories of the best of the best

and slipping the lessons quietly into your proverbial

pocket. In Larry Goshorn’s article, Knowledge Stealing 

Initiative, he describes this coming-to-terms with

Knowledge Sharing. The difference between that and

a misdemeanor? NASA’s Academy of Program and

Project Leadership (APPL) Master’s Forum presenters,

workshop participants, and storytellers—they want you

to use their stories and lessons and experiences! They

are holding them out to you, leaving them unattended

with your name on them, hoping you won’t have to

stumble down the same difficult roads if they could just

hand you their conclusions.

You’re already familiar with most of the ways that

APPL works with project managers like you to get

knowledge out there for the taking. In future issues

you’ll see how we’re continuously changing to make

sure you always get the valuable information that

you need. During the coming months we’ll introduce

you to experienced project managers who are joining

ASK’s editorial staff to add relevance and credibility

to its stories. In 2005, we’ll begin a quarterly publication schedule allowing us to add more stories, more

practices, and more knowledge in each issue for you

to pillage.

In this issue of ASK alone you’ll find out how

applying Earned Value Management to projects can

help turn them around. You’ll read the lessons one

retired NASA PM learned throughout his career and

see how far project management at NASA has come

over the years. You’ll absorb the knowledge that many

people on a project have to offer and how to balance

work and family during collocation. You’ll find an

illustration meant to stimulate discussion about APPL’s

Knowledge Sharing Initiative. And that’s just what

you’ll see in print...

Go to the APPL website and you’ll find much

more knowledge to steal. (Of course, we prefer to call

it collaboration.) Search the ASK archives for the many

lessons of issues past. Take a look at the Master’s

Forum stories and slides, and experience them without

stepping foot out of your office. Click on links to

other project management resources—most recently

we’ve established a content-sharing relationship with

GovSig’s online publication—and see what’s going on

in project management beyond the world of NASA.

It may seem a little counterintuitive at first—we’re

told plagiarism is punishable and identity fraud even

worse! But fight these urges to play it safe. Use the

many resources that APPL makes available. Grab what

you can, slap your name on ideas that were someone

else’s first, call up a story as if it were part of your own

project management past. Start here and now with

these very pages. And if you’re still feeling guilty, make

sure no one is looking. •

Knowledge, for the Taking

Immature poets imitate; mature poets steal

	 	 	 	 	 	 	 —T.S. Eliot

ask 21 for practitioners by practitioners 

IN THIS ISSUE Jessica Simmons
 appl the nasa academy of program and project leadership

review board

John Brunson of the Marshall Space Flight Center,

Systems Management Office, is a member of the

NASA Program Management Council Working

Group. He supports the Agency’s Chief Engineer

Office and MSFC in the review/development of

Agency and Center Program/Project Management

and Systems Engineering policy. He led the development of MSFC’s

Project Management and Systems Engineering Handbook as well

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

manager for three separate microgravity payloads that flew on various

Spacelab missions. Prior to his project management experiences he

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

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

member of the Space Shuttle Main Engine Engineering Team.

Dr. Michelle Collins works in the Spaceport

Engineering & Technology Research Group at

Kennedy Space Center. She has more than twenty

years experience in aerospace spanning engineering,

R&D and project management. She is on the

Florida Institute of Technology Department of ChE

Industrial Advisory Board, the National Fire Protection Association’s

Technical Committee for Halon Alternatives, and the United Nations

Environmental Programme Halon Technical Options Committee.

John Del Frate has 10 years of project management experience with the development and flight

testing of Uninhabited Aerial Vehicles (UAVs)

under the Environmental Research Aircraft and

Sensor Technology (ERAST) Project During that

time, he was associated with the development of

Perseus A, Perseus B, Altus, Pathfinder Plus, Theseus, Helios, and

the Solar Powered Formation Flight aircraft. Currently he serves as

Project Manager for the High Altitude Long Endurance Remotely

Operated Aircraft (HALE ROA), a NASA Vehicle Systems Program

sub-project which will continue the development of UAVs for use in

the stratosphere.

Hector Delgado is Division Chief of the

IndependentTechnicalAuthority inthe Independent

Technical Authority and Systems Management

Directorate at the Kennedy Space Center. Previously

Hector was the Division Chief of Process Tools and

Techniques in the Safety, Health and Independent

Assessment Directorate. In 1995, he served as Senior Technical Staff to

the NASA Chief Engineer at NASA Headquarters in Washington, D.C.

He has received many honors and awards including the Exceptional

Service Medal, Silver Snoopy Award, and various achievement awards.

Dr. Owen Gadeken is a Professor of Engineering

Management at the Defense Acquisition University

where he has taught Department of Defense

program and project managers for more than

twenty years. He retired from the Air Force Reserve

as a Colonel and senior reservist at the Air Force

Office of Scientific Research where he helped manage the basic

research program for the Air Force. He holds adjunct faculty appointments at the Federal Executive Institute and the Center for Creative

Leadership. Owen is a frequent speaker at project management conferences and symposia.

Dr. Michael Hecht has been with NASA since

1982 at the Jet Propulsion Laboratory (JPL). He is

instrument manager and lead investigator for the

MECA soil-analysis payload on the 2007 Phoenix

mission to Mars, reprising a role he played on the

cancelled 2001 Mars Surveyor Lander mission. In

the course of his JPL career, he has served in line, program, and project

management, and has participated in research ranging from fundamental semiconductor physics to martian geophysics.

Jody Zall Kusek coordinates results-based

management at the Africa Region of the World

Bank. She is currently involved in supporting the

efforts of several African governments to move to a

focus of 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.

Dr. Gerald Mulenburg is a member of the

Systems Management Office at the NASA Ames

Research Center in California specializing in project

management. He has project management experience in airborne, spaceflight, and ground research

projects with the Air Force, industry, and NASA. He

also served as Executive Director of the California Math Science Task

Force, and as Assistant Director of the Lawrence Hall of Science.

Joan Salute is the Associate Director for Projects

in the Information Science and Technology

Directorate at the Ames Research Center. Joan

currently is on detail to NASA Headquarters. Joan

previously was the Associate Director of Aerospace.

She has managed many NASA projects including

those involving flight testing of thermal protection materials, commercial technology, commercial applications of remote sensing, and

remote sensing science projects. Joan has been at Ames for 22 years,

and recently completed the Sloan Fellowship to attend the Stanford

Graduate School of Business.

Harvey Schabes is the Systems Management

Lead in the Systems Management Office at NASA’s

Glenn Research Center. He is responsible for

providing oversight for independent assessments

of programs and projects and for defining Center

strategic plans and policies. He is also leading the

Knowledge Sharing activities at GRC in collaboration with APPL. He

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

then has served in numerous organizations in support of the Space

Station Program.

Charlie Stegemoeller has served as the

Associate Director, Space and Life Sciences

Directorate, Office of Bioastronautics at the

Johnson Space Center since 2002. The Office for

Bioastronautics is responsible for coordinating and

implementing the NASA Bioastronautics Strategy—

the pursuit of tools, techniques, and policies to reduce risks, improve

efficiencies, and return benefits to earth through the conduct of human

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

served within the JSC Comptroller’s office, the former Space Station

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

One Program. He received the NASA Exceptional Service Medal in

1996, and became a member of the Senior Executive Service in 2002.

Hugh Woodward is the President of Macquarie

Business Concepts, a consulting firm specializing in

effective project portfolio management. Before this

position, he had a 25-year career with Procter &

Gamble. He served as the Chairman of the Project

Management Institute (PMI) for consecutive terms

in 2000 and 2001. He was elected to the Board of Directors in 1996,

and before being elected as the Chair, served as vice chair and in

several other key leadership roles.
This issue features a visual depiction of the Academy

of Program and Project Leadership (APPL). I imagine

a variety of initial reactions to the drawing. One

might be, “What is a cartoon doing in a magazine

about project management?” Or perhaps, “Wow, nice

colors—and fun.” Another may be to closely search the

image for signs, symbols and meaning. Still another,

to read a new level of innovation and creativity into

the picture. Undoubtedly, some readers will raise

questions about the cost.

Of course, any reaction is a sign of engagement.

The stronger, the more energized the emotional and

cognitive processing, the better. It is a sign of attention

and interaction. For I’ve heard it said, “You only need

to worry if they don’t care one way or the other.” So

what is the point of the picture?

To stimulate interest, raise questions, promote

discussion, and maybe raise a smile...That, at least, was

my initial reaction when I was introduced to the work

of Nancy Hegedus, who helps to create these drawings

for Root Learning Inc. At the NASA PM Conference,

I was first shown the work Nancy had been doing

with the help of Goddard’s Knowledge Management

Architect, Dr. Ed Rogers. I was immediately drawn into

the power of visualization as a tool for more effective

learning, communicating, and conveying complex

knowledge concepts.

We need new tools in today’s world, where

information and data overwhelms by sheer volume.

There are articles, pamphlets, communications, and

white papers—all aiming to convince and influence.

Reactions to these tend to be either avoidance or mindnumbing, heavy-eyed consent; the message never

registers or enters the soul. That’s one of the reasons

that APPL’s Knowledge Sharing Initiative (KSI) has

turned to storytelling as a memorable way of transferring knowledge, inspiring imitation of best practices,

and spurring reflection. ASK Magazine’s recent fourth

birthday marks an important milestone in APPL’s

continuing quest to provide ongoing support to project

managers and to promote mission success.

And similar to storytelling, the power of visualization is receiving increasing attention in recent years

as a way to stimulate engagement. Pictures and visual

graphs are viewed as one of the most effective ways for

displaying, describing, and generating discussion about

quantitative and technically complex information.1

Prototypes, models, and simulations are considered

essential for stimulating innovation through open and

engaging discussions.2 There has also been extensive

writing on the use of visual graphics, pictures, and

cartoons to facilitate memory, creativity, openness,

attention—and even well-being.

For many of these reasons, I am excited to have a

colorful visual depiction of the APPL world included in

ASK. Without the addition of text or slides, the intent is

to invite people into the world of the APPL mission—as

well as its products, services, customers, and partners—

in a fun and engaging manner. As project leaders strive

to find ways to encourage engagement, learning, and

transmission of knowledge, traditional technologies

are proving to be as valuable as modern technologies.

(But for those who want more information in the form

of texts and slide presentations, we certainly have an

abundance of those as well.) •

Knowledge and Meaning through Visualization

The soul never thinks without a picture

 —Aristotle

1

 Tufte, Edward R. 1997, Visual Explanations, Graphics Press.

2

 Schrage, Michael. 2000, Serious Play: How the World’s Best Companies Simulate to Innovate, Harvard Business School Press.

ask 21 for practitioners by practitioners 

from the Director’s Desk Dr. Edward Hoffman
 OLDJOURNEY,

NEWHEIGHTS

By John Del Frate

 appl the nasa academy of program and project leadership
If you could see the road ahead, you might just pass

up a fantastic opportunity because you’re blinded by

the potential pitfalls. In my case, I was testing the

project management waters at the NASA Dryden Flight

Research Center after ten years of being a research

engineer. I was an eager (but ignorant) rookie project

manager (PM) and I was willing to engage in just about

any project without knowing what it would entail. The

assignment I accepted was to help NASA’s Environment

Research Aircraft and Sensor Technology (ERAST)

Project, a partnership with a fledgling Uninhabited

Aerial Vehicle (UAV) industry, to tackle stratospheric

flight. I remember one of our industrial partners

querying me about whether or not I understood what

I was getting into. Like one of those bobble-head toys

that have become quite popular, I nodded. But in

reality, I didn’t have a clue. His response was, “Hang

on, it’s going to be a wild ride.” He was right.

In retrospect, if I had clearly understood the ten

years of pitfalls that were coming, I might not have

“hung on.” Now I can look back and say that I would

not trade the experience for anything.

The lows included the destruction of a number

of UAVs on my watch. Later someone told me that we

should not be surprised if we lost one UAV for every ten

flights. We wrote many chapters in the book on what

can go wrong with UAVs—and we are still writing. As

you can imagine, each mishap was accompanied by an

investigation. What an education!

But as bad as the lows were, the highs were stratospheric. We set a number of altitude records with the

UAVs, and we performed a number of “first-of-a-kind”

demonstrations with payloads. The highlight for me was

the world altitude record we set in 2001 with the Helios

aircraft on the Hawaiian Island of Kauai. We conducted

our flight operations there, flying to a record altitude

of 96,863 feet—10,000 feet higher than any non-rocket

propelled aircraft has ever gone. We did it on the power

of the sun, and it was an unforgettable experience.

The lowest low followed two years later, when

we crashed this magnificent aircraft. So, I shared in

both the glory and the humility that surrounded the

ERAST project.

For the ERAST effort, we had a small, close-knit

team—an alliance—that partnered with different small

companies and consultants. I viewed our collaboration

as a partnership with these entities, as they were

not contractors per se. We were working together

under something called a Joint Sponsored Research

Agreement (JSRA). It is a form of a NASA Space Act

Agreement which is rarely used by NASA but provides

a lot of flexibility. In this case, it allowed me to work

closely with some very special people. We structured

our agreement such that all work done by the various

partners was done on a non-profit basis with each of

the partners providing some cost-sharing.

Ilearned some valuable lessons from this remarkably

diverse group of talented and committed people who are

largely responsible for making the ERAST project—and

more specifically, the Helios project—a success. I would

like to share a few of the lessons I learned, lessons I will

take with me throughout my career.

LEARN FROM THOSE BEFORE YOU

Jenny Baer-Reidhart, the first ERAST Project Manager,

displayed an enormous amount of courage. Some of the

things she did to make the program a success required

her to be bold and innovative. Because we were doing

ask 21 for practitioners by practitioners 
things differently, she often took heat and had to fight

to stay the course. She always held her ground.

She also had the ability to see the big picture. She

created a work environment conducive to getting the job

done and secured the funding, the company associations, the places to fly, and the vehicles. Without her,

the project never would have enjoyed the successes we

did. There were lots of people involved, but Jenny really

provided the leadership we needed. I learned an immense

amount from her skills and strength as a leader.

YOU’VE GOT TO EMPOWER YOUR TEAM

Ray Morgan was (at that time) the Vice President of

AeroVironment, the company that was our partner on

Helios. He had been an ardent micromanager. A couple

of years before ERAST came around, he realized that his

management style was killing both him and his division.

In order to survive, he decided to change himself and his

division by managing a 180-degree turnaround. By the

time this recovering micromanager and his team joined

the ERAST alliance, Ray had empowered his team in

such a way that they confidently used the strength of the

entire team to make key decisions.

After his transformation, Ray would participate in

the decision-making process, but he no longer steamrolled the team by saying, “No, it has got to be done my

way.” He was always willing to let anyone on the team

have their say and to let the team processes dictate how

a decision would be made. It was really inspiring to see

the benefits of this type of management. Everyone had

the resources, the responsibility, and the authority to

do what they needed to do. As a result, we progressed

very quickly and very efficiently.

TRUST IS HUGE

Ilearned a lotfrom my relationship with AeroVironment,

specifically from two people, Bob Curtin and Kirk

Flittie. I wish everyone could have the opportunity to

work with contractors that they trust the way I trusted

these guys. Usually, with the government contracting

structure, we spend an inordinate amount of time and

money simply because we don’t trust the contractor.

There is probably a reason for every process or regulation used to govern them, but they seem ridiculous

and wasteful to me. I started out treating the industrial

partners like “contractors,” but they soon earned my

trust and respect. And it paid off for both the government and the industry partners, as we were able to do

more technology development at a set level of funding.

Not having to constantly monitor the contractors

meant a much leaner operation; we were able to work

smarter and faster. But we didn’t throw the necessary

checks and balances out the window. Instead, we used

them at a level that allowed us to pour far more concentration into getting the job done. And because of the

trust we’d established, I knew that our partners always

had the best interest of the project in mind. I didn’t have

to always look over their shoulders to make sure the job

was done right...ultimately we had the same goal.

DON’T TAKE “NO” FOR AN ANSWER

One of our independent consultants to ERAST was

Dale Tietz, a very tenacious fellow. He is the type of guy

that just does not take “no” for an answer. If the front

door is closed, he asserts, “Try the back door.” And if

the back door doesn’t work, “Try the windows.” That’s

how he is.

	 He’s also the kind of guy who has a very thick

Rolodex. He can walk into a meeting, and before long he

is friends with everybody and scheming ways of taking

advantage of the strengths of those in the room. Having

a guy like that on your team adds a very special dynamic.

He is constantly evaluating people and situations, and

is willing to do whatever it takes to get things done.

Watching him, I learned that project managers need to

be tenacious—even when you are doing the right thing,

doors will close—so you must never give up.

STATE “THE MESSAGE” QUICKLY AND CONCISELY

Somewhere along the way it occurred to us that we

needed help making the right kind of project information

available to the public. Now, I’ve never heard of another

NASA Project bringing in a “publicist” to help, but that

is exactly what we did. Pete Jacobs became our publicist.

He would pop in and out, but when he popped in, it

was because we were on the brink of some tremendous

flight accomplishment. He taught us the importance of

“the message.” He taught us to use words that could be

Everything we are doing today is a 

 appl the nasa academy of program and project leadership
remembered by children, the media, decision makers,

or the average Joe on the street. He wanted us to get that

message out but also to get it right. He pointed out what

should have been obvious: Stakeholders or the media

don’t have the time or capacity to absorb a longwinded

technical speech. Fifteen seconds to say what you mean

and say it right may be all you’re going to get—especially

if you’re on-camera.

I think that engineers, like myself, tend to really

over-complicate things. We see the nuances in everything. People are always telling us to keep it short and

make it consistent. Pete had us working on getting it

down to short, concise statements that packed a lot of

punch. He wanted everyone on the team to be able to

give the same message. We were skeptical that there

was any value to this exercise, but Pete was good and

achieved unprecedented results. So as an engineer,

whether I liked it or not, I learned that it’s vital to say it

right—and to say it concisely.

KEEP THE IMPORTANT THINGS IN PERSPECTIVE

This was the most personal lesson learned, but also

the most important. By the time we were in the 2001

deployment with Helios, my wife came to me and said,

“I think your work is more important to you than our

family.” I thought, “No way,” and I argued with her

quite a bit. I knew I had a pretty strong work ethic, but

I thought that my family rated a much higher priority.

I was convinced I was right, so as far as I was

concerned it was a dead issue. But a couple of weeks had

gone by when I made a decision that clearly favored work

over family, and my wife was quick to call me on it. The

bottom line was that even though I said that my family

was the most important, whenever there was a conflict

between my work and my family—work always won. If

there was a scheduling issue, work always won out over

my family. But I had become blind to this. I thank God

that I started to see the light sooner rather than later, as

it was hurting my marriage and my family.

Of course realizing you have a problem doesn’t fix

the problem, but it’s a start. I knew that I had to really

make an effort to show what my “top” priorities are. It’s

an ongoing struggle for me, especially when I, like most

PMs, don’t have the ability to turn work off when I leave

the office. It’s easy to let things get out of perspective. I

always understood that some things are more important

than work. But I learned that I need others—especially

my wife—to help me judge how well I am doing.

Part of keeping things in perspective is the ability

to see an individual project as a step in a larger, ongoing

journey. More than a hundred years ago, the Wright

Brothers took a huge step: They convinced the world

that we could actually achieve “heavier-than-air” flight.

Their work built a foundation, one that those of us

working in aerospace have been able to add to and

build on.

	 Our journey consists of taking steps based on

prior steps, learning lessons based on the accumulated

lessons of those who have gone before us. Everything

we are doing today is a small step along that larger

journey. These are the small lessons that have helped

me shape and characterize my part in the long journey.

They are the small road signs that I have posted for

those who follow me. •

Lesson

• Make it a regular habit to reflect on your experiences, to

develop “small” lessons, and to share them with your peers.

Question

Is embracing a philosophy of “ignorance is bliss”—that is, 

believing you are better off not knowing the detrimental factors 

beyond your control—the right attitude for only rare situations, 

or should it be applied systematically?

small step along that larger journey.

John Del Frate has ten years of project management experience with the development and flight 

testing of Uninhabited Aerial Vehicles (UAVs). 

This work was done under the Environmental 

Research Aircraft and Sensor Technology (ERAST) Project. 

Currently, he is Project Manager for the High Altitude Long 

Endurance Remotely Operated Aircraft (HALE ROA), a NASA

Vehicle Systems Program Sub-Project which will continue the 

development of UAVs for use in the stratosphere.

ask 21 for practitioners by practitioners 
The Space Shuttle Cockpit

The Space Shuttle was developed in the 1970s using

technology thatwasquite advanced forits time, including

fly-by-wire components and multiple computer screens

in the cockpit. Although the electro-mechanical gauges

and cathode ray tube (CRT) screens soon became dated,

no major upgrades were made to the cockpit for two

decades. Part of the reason was simply that the original

equipment was extremely reliable. However, it was also

bulky and expensive to maintain. A glass cockpit was

implemented in the shuttle to help remedy the obsolescence of many of the electromechanical gauges and

dials, but that upgrade did not resolve the human factors

and usability drawbacks of the cockpit displays. In

part to address these deficiencies, NASA is developing

a usability oriented modification called the Cockpit

Avionics Upgrade (CAU). A key goal of the CAU project

is to redesign the displays to improve the crew’s understanding of the on-board systems.

Which brings us to me

In the fall of 1999, one of my managers at NASA Ames

Research Center said, “There’s a great new project

going on at Johnson Space Center (JSC). They’re

upgrading the shuttle cockpit displays. How would

you like to spend two weeks at JSC learning about it,

then you could participate via telecons.” I said, “That

sounds great, but I have to talk to my wife. I already

do a number of trips each year. I’ve got to balance this

out and still keep this ring on my finger.” It turned out

that my wife was quite understanding. I already made

a number of conference trips each year, so a two-week

trip didn’t seem too excessive.

We need you here

When I talked with folks in person at JSC, they told

me candidly, “Two weeks down here is great, but we’d

really like you a bit more. Like every other week. For at

least one year. What do you think?”

By Jeffrey McCandless

The more time I spent

at Johnson, the more 

I realized how effective 

it was to actually 

collaborate in person.

Establishing a presence

10 appl the nasa academy of program and project leadership
Uh oh. I realized they were right. The project

seemed fascinating, but somewhat demanding. So

back I went back to my wife—flowers in hand—and

told her about this great opportunity. It was clear that

I married the right woman. She said, “Go for it. But

don’t be leaving home every single week!” I promised

that I’d be home every other week plus every weekend,

and I kept my promise. In actuality, the trips down to

JSC were typically from Monday to Thursday, every

other week. The project blossomed, and over the

last five years I’ve made dozens of trips to Johnson

to work with astronauts, trainers, engineers, mission

controllers at others at JSC.

Working side by side & face to face

This was very much a team effort, and it was

quite helpful that I was present as much as I was.

Typically, small groups of 5–10 people would work on a

new display for a several-month period, and the

co-location factor allowed for unscheduled, informal

communication. Being there in person helped to reduce

ambiguity surrounding decisions, speed up the project

in terms of information exchange, and develop a team

persona in which we were really aware of each other’s

strengths and weaknesses.

The more time I spent at Johnson, the more I

realized how effective it was to actually collaborate in

person. Every time I had a question or needed assistance,

there was someone who could help. They were happy

to give me one-on-one support and training. If I was

going to work in one of the space shuttle simulators and

needed to understand the crewmember’s roles during

a malfunction, it was easy to find an astronaut trainer

who would sit down with me. Without exception, the

folks there were helpful and enthusiastic.

And because of the many alliances I had from

splitting my time between the two centers, I was able

to keep Ames folks fully updated as well. A number of

us made trips down to JSC to help support this project;

one trip was made to address color characteristics of

the shuttle cockpit screens. We collaborated well and

were able to put together quite a few display formats. I

remember thinking that the “One NASA” theory really

held true on this project.

Different measures of success

For me, the basis for this successful collaboration was faceto-face communication. Though it was sometimes stressful

being on the road so much, I really learned the importance

of being present to work together and ask questions in

person. Another measure of success was that in the midst

of this project and traveling, my wife and I managed to start

a family. My oldest boy got a real kick out of visiting Space

Center Houston when he was two to learn all about the

“face futtle” which “goes way up in the sky.”	 •

Lessons

• When practical, collocation and face-to-face communication on a project eliminate misunderstandings,

establish relationships, make information more easily

accessible, and promote a team atmosphere.

• Compromise is key to balancing both family and career

goals. Knowing when to prioritize each is important to

success in both aspects.

Questions

Is compromise really the way, and is it even possible in 

today’s competitive environment? Or is alternation the key—

periods of putting work first, followed by periods of 

overcompensation at home?

For me, the basis for 

this successful collaboration 

was face-to-face communication. 

Dr. Jeffrey McCandless began 

work at NASA Ames Research Center in 1996 

developing image processing algorithms for 

advanced aircraft. Since 1999, he has been 

the Co-Lead of the Human Factors Team for 

the Space Shuttle Cockpit Council, which is 

responsible for designing and evaluating new 

shuttle cockpit displays. 

ask 21 for practitioners by practitioners 11
At least that’s how it felt to me initially. I have

the honor of being on the Academy of Program

and Project Leadership (APPL) Knowledge Sharing

Feedback and Assessment Team (FAA), and as such, I

am privileged to receive the feedback written by many

of you as attendees of the Project Management (PM)

Master’s Forums. It is the intent of the FAA Team

and APPL leadership to use this feedback as a tool for

continuous program improvement.

As a retired (sort of) PM in the payload contracting

industry, I’m a big supporter of NASA’s Knowledge

Sharing Initiative (KSI), especially the Master’s Forums.

I really enjoy participating in them. Unfortunately I had

to miss the 8th forum in Pasadena this past Spring,

but I did get the feedback package for the Assessment

Team work. So here I was, reviewing twelve pages of

comments, reflections, learning notes and critiques

from attendees of the 8th forum.

THE EYEWITNESS ACCOUNTS

The FAA’s mission is to find the positives and negatives

in the feedback and compile them for discussion. Shortly

into the process of reading the comments, however, my

mission changed. I found myself progressing through

the feedback, agenda item by agenda item, and actually

attending the forum vicariously through the feedback

writers! I became engrossed in the content. I felt as

though I was blindfolded at a fast-moving sporting

event and the play-by-play was being described to me

by many others around me.

The feedback was incredibly detailed and well

written, complete with application notes, doubts

and potential pitfalls. Not surprisingly, I found

myself learning rather than reviewing! I was actually

taking away knowledge, forming opinions of my own,

and developing questions, as though I had been

sitting right there! That’s why I initially felt like a thief.

Actually I was experiencing remote learning, not only

from the original forum presenters, but also from

the feedback writers.

CAUGHT RED-HANDED

I myself have “stolen” lessons from various storytellers and practitioners that have participated in APPL’s

programs over the years. I took the importance of storytelling as a means of conveying lessons learned—and also

ways to implement this tool with a program team—from

Annette Simmons’s ASK 18 Special Feature, “Dressing

up the Naked Truth.” From Dr. Gary Klein, a keynote

speaker at the 7th Master’s Forum, I discovered the use

 THE KNOWLEDGE 

STEALING INITIATIVE by Larry Goshorn

?

i had never thought of myself as a thief, but there i was, peering at

stuff that clearly wasn’t mine and quietly slipping it into my “toolbox” 

for my own personal use. it was broad daylight, and i was in plain view

of a least a dozen people. the audacity! 

12 appl the nasa academy of program and project leadership
of “pre-mortems” as risk identification tools to help a

team communicate effectively with a shared risk management philosophy. I learned ways to spot the predictors of

successful program management behavior during the

selection interviewing process from ASK feature writer

Scott Tibbitts’s article, “Tell Me About Your Lemonade

Stand,” which appeared in ASK 18. And these are just a

few of the things I’ve taken away with me.

As for the feedback accounts, it’s clear that the

8th forum was a huge success. As I reviewed the

agenda topics, then read the presentation slides and

the feedback, I found many of the common themes

that always surface when Program/Project Managers

get together to discuss successes and failures. A

few of these common success factors were: effective

communication both inside and outside your project

team;the fact that “people” management— rather than

“technical” management—is the most important factor

for overcoming adversity; and the argument that leadership is founded on the principles of interpersonal

relationships—including mutual respect, trust, open

communication, and the creation of an environment

that encourages new ideas and personal growth. And

even though these are repeating success factors, there

are always new stories, new thoughts, and new shared

experiences dealing with their successful application.

But my review of the forum material and feedback

also revealed some newertopics as well. This knowledge,

too, I snatched up like the proverbial starving squirrel

after the world’s last acorn; into my own PM toolbox

they went! This included thoughts and concepts such

as “the conductor does not make any noise, but

gets the best possible music out of the orchestra.”

I learned new ideas for motivating teams and individuals and reflected on a debate about intrinsic vs.

extrinsic motivation. I also read about the increasing

importance of coaching and mentoring with notes

for effective implementation of these concepts, the

use of Test Readiness Levels (TRL) for managing

Software project risk, considerations for establishing

pro-active “coyote teams” versus re-active “tiger teams”

and more.

LIKE TAKING CANDY FROM A BABY

This exercise in remote learning has been valuable

to me. It has provided many new ideas for me and

reinforced existing project management success

concepts. It has illustrated to me, and hopefully to you,

that we don’t have to be there to learn from it. The

available material alone is very useful. Coupled with the

excellent feedback from the gracious attendees, it was

almost as good as being there!

And the folks at APPL are great at keeping the

forum agendas and the presentation packages on their

website, which can be accessed according to the forum

number and date at http://appl.nasa.gov/businessunits/

knowledge/programs/master_forums.html.

You may have also noticed that many of the Forum

presentations also appear in narrative format in ASK 

Magazine, available online at www.appl.nasa.gov/ask.

That means that this same knowledge, without the

editorial comments found in feedback, is available on

the APPL website to everyone, whether you attended

the forum or not. Anyone can “steal” this knowledge

sharing opportunity.

I wasn’t able to attend the 8th forum this past year,

but I was able to take part in the knowledge sharing.

To those of you who wrote the excellent feedback,

I thank you. I’m looking forward to seeing you in

San Francisco! •

Lessons

• When you are open to it, Knowledge Sharing becomes

a tool for life, not a one-day workshop. Never underestimate the lessons you could learn from “communities of

practice” composed of your experienced peers.

• Reinventing the wheel isn’t admirable if it’s unnecessary. Don’t be afraid to steal, imitate, revise, and reuse the

lessons and best practices of others.

Question

For learning to occur, errors, mistakes, and occasional failures 

must be accepted. How does one create the conditions that 

overcome human nature: the fact the “everyone wants to learn, 

but nobody wants to be wrong?” 

“WE DON’T HAVE TO BE THERE TO LEARN FROM IT. 

 THE AVAILABLE MATERIAL ALONE IS VERY USEFUL.”

After over 28 years of program management 

experience, LARRY GOSHORN retired in 2003 

from ITT’s Aerospace/Communications Division 

as the Director of Space Programs. During 

his career, he successfully managed a variety 

of NASA payload projects, and he now works as a program 

management consultant in the Aerospace Industry. Goshorn 

previously published an article in ASK 18.

ask 21 for practitioners by practitioners 13
EXCEL FILE EDIT LAYOUT TYPE OBJECT TABL

®

Earned Value-A

by Michael Jansen

14 appl the nasa academy of program and project leadership
In 2002, I joined the Station program’s Assessments

and Cost Estimation Office (ACEO), an organization

established to perform the kind of early warning,

“Where’s-my-program-headed?” assessments that

few program managers have the time or staff to do

thoroughly.

By the time I joined the team, the ACEO had

already established several unique tools with which to

develop meaningful summaries and “What’s-the-datareally-telling-you?” assessments for the ISS Program

Manager. But one key program control tool remained

missing: earned vlue based performance measurement.

Leading the development and implementation of a

program-wide EVM system became one of my early

tasks, to no small extent because I volunteered that I

understood EVM and believed in its utility.

But you’ve got to use the data

Mid-program EVM implementations, I soon discovered,

are widely held by industry to be difficult endeavors at

best. Although the ISS program was receiving monthly

EVM data from its major contractors, nobody was tying

them together to form a consolidated performance

message. And even if someone had, only about half of

the program’s work would have been covered under this

type of performance measurement.

Few seemed to be using the contractor EVM data we

were getting. Most managers were collecting it because

it was required, not because they saw the value inherent

in EVM reporting. The common feeling was that EVM

was expensive, faddish, a royal pain in the posterior, and

definitely not worth the effort. This feeling was expressed

even more strongly by managers of work content not

already encompassed by EVM reporting: “I’m getting all

E

arned value management (EVM) ...either you 

swear by it, or swear at it. Either way, there’s 

no getting around the fact that EVM can be one 

of the most efficient and insightful methods of 

synthesizing cost, schedule, and technical status 

information into a single set of program health 

metrics. Is there a way of implementing EVM that 

allows a program to reap its early warning benefits 

while avoiding the pitfalls that make it infamous to 

its detractors? That’s the question recently faced 

by the International Space Station (ISS) program...

LE VIEW WINDOW HELP

dded

ask 21 for practitioners by practitioners 15
the data I need through planned vs. actual costs, plus the

technical updates I receive monthly from my leads...why

do I need earned value?”

That was only the beginning of the challenge.

ISS was already squarely in operations, even as the

last of the development effort was wrapping up. Some

astute managers started asking the very good question

of how meaningful EVM would be when applied to

what they considered to be essentially level-of-effort

work. Literature and Internet searches unearthed no

examples of implementation of EVM on programs

in the operations phase; nobody’s corporate memory

could recollect such an instance either. And it didn’t

help that what some veterans could remember was that

a prior implementation of across-the-program EVM

had been abandoned largely because the associated

overhead was perceived to outweigh the benefits.

Then there was the issue of timeframe. All knowledgeable sources indicated that EVM implementation

was often a multi-year endeavor. Once initiated, EVM

systems were said to take at least four to six months to

“settle out” and produce meaningful data. My team’s

marching orders were to have a tested EVM system in

place in time for the start of the next fiscal year (which

at that time was less than five months away) and to have

results capable of withstanding outside scrutiny after

the first month of baseline operation.

Drumming up support

A crucial first step was to develop an implementation plan and gain the Program Manager’s support.

We outlined an aggressive schedule that supported

conducting three dry runs of the new system. The

Program Manager agreed to our plan, as well as to our

request to present it to his control account managers

at his next senior staff meeting. Having the Program

Manager openly support our efforts in that forum was

worth far more than any amount of lobbying we might

have attempted to do. We had a sanctioned plan in front

of everyone. Now we had to make it happen.

Dealing with PMS

Our philosophy of implementing an EVM system which

maximized return on investment included minimizing

the impact on managers’ existing workloads. Our new

Performance Measurement System (PMS—yes, we’ve

heard all the jokes) was to be based on earned value

concepts rather than to be a formal, certified EVM

system. The idea was to use existing schedules, metrics,

etc., rather than to reinvent the wheel. Considering that

our program was largely in the operations phase, we

also didn’t expect to cover the high percentage of total

work content under discrete earned value performance

metrics that traditional EVM systems do.

We concentrated on measuring performance for

those tasks that, because of their risk, high cost,

or visibility, could cause potential problems for the

Program Manager. In this approach, we identified

and closely watched those items that could become

“gotchas.” Thus our PMS became closely aligned with

the program’s risk management system.

Another facet of making our PMS palatable to

managers involved relieving them from as much of

the implementation effort as possible. For example,

our team shouldered the up-front work of developing

a PMS process tool that would minimize the effort

required for control account managers to make monthly

EVM inputs and retrieve processed data for analysis.

Our team drafted top-level, resource-loaded schedules

for those control accounts that didn’t already use one

The overall program status was 

very close to the management 

team’s “gut feel.”

16 appl the nasa academy of program and project leadership
in routine status reporting. We reiterated our “lowimpact implementation” message as we presented our

pre-developed schedules and formats to managers and

their support folks, then worked with them to answer

questions and revise the schedules.

Within ten weeks of the inaugural senior staff

meeting, we had our process defined, and the first

version of the PMS tool developed and validated. We

also had top-level, resource-loaded schedules for all of

our new control accounts, covering the three-month dry

run period laid out in our PMS implementation plan.

Similar schedules, covering upcoming fiscal year 2003,

were in place. An innovative, more understandable

way of looking at the EVM data—adapted from a DoD

format—was incorporated into our tool and ready for

debut with the ISS senior management. We developed

methods of projecting end-of-fiscal year expenditures,

as well as the split between unencumbered under-run

and content-laden roll-through—taking into account

such unorthodox factors as being in the operations

phase. Convergence metrics were devised to track

the system’s “settling out” and to project when the

EVM data would be mature enough to be considered

meaningful for management decision making.

But will the process work?

Starting with the first dry run, we made monthly

briefings of PMS results to the Program Manager and

his senior staff. The initial results were interesting: Any

given control account’s data could be all over the map,

but in aggregate the PMS estimate of overall program

status was very close to the management team’s “gut

feel.” The second month’s dry run results showed more

of the same behavior, and underscored what EVM

experts had predicted: The data should be expected

to vary widely from one month to the next until the

system “settled out.” By the third dry-run, however, the

system already showed signs of stabilizing, particularly

the ISS-level aggregate data. The Program Manager

and his team were pleased with the initial results, as

well as with our tool’s data processing and presentation;

the go-ahead was given to proceed with a baseline PMS

for the new fiscal year.

Success...! 

The initial baseline run, completed within six months

of approval of our implementation plan, went as

smoothly as anyone could have hoped for. The new

resource-loaded schedules were completed just in

time; the last-minute process and tool tweaks came

together the same way. The financial and earned

value data—once loaded into our PMS tool—resulted

in a very believable ISS status that was in line with

the senior managers’ understanding of the program’s

technical, cost, and schedule situation.

Perhaps most importantly, the EVM data sparked

questions that forced managers to look a bit deeper

into what was going on in their respective areas of

responsibility. Those healthy discussions alone made

all the previous months’ efforts worthwhile.

All of this was accomplished with the part-time

efforts of a half-dozen people on our team, plus a

couple of people from each of the ten new control

accounts we created—and is being maintained with

far less overhead than is commonly attributed to EVM

systems. Our home-grown Excel®-based PMS tool,

besides being “no-cost” compared with commercially

available software, enabled us to tailor every thing at

will to meet our analysis needs. Our PMS, including

the unorthodox projection methods we developed, went

on to predict fiscal year closing statistics to within a

half percent a mere three months into baseline operations. EVM has become a valuable tool in our assessment suite indeed.

We swear by it. •

Lessons

• Rather than forcing a situation to conform to a

solution that doesn’t fit, flexibility and a willingness to

try new things are necessary to tailor known techniques

to the specific needs of a project.

• Overcoming the project team’s resistance to change

can be facilitated by minimizing the direct burden that

results from the implementation of that change.

Question

Why is a methodology developed more than a generation ago 

still unpopular in many well-developed organizations, and why 

does it still require a dedicated introduction effort?

Michael Jansen leads the Assessments

branch within the Program Planning

& Control Office of the International

Space Station (ISS) Program at the

Johnson Space Center (JSC). He is active

in NASA training, knowledge sharing, and community

outreach activities.

ask 21 for practitioners by practitioners 17
Putting EVM to the Test

Talk to any Project Manager in industry or government 

and you’ll find that two of the most common complaints 

are cost and schedule overruns. 

By Jerald Kerby and Stacy Counts

18 appl the nasa academy of program and project leadership
In many instances there is no forewarning; schedules

slip, costs soar, and the project manager is faced with

the near impossible task of explaining why each impact

occurred. With contractors performing the majority

of the work, the management job can become even

more obscure. The simple lack of proximity to the

contractor can limit effective communication. Add

to that a mixture of cultural differences and a desire

for the contractor to portray the most optimistic view

of their performance, and you create an even more

difficult task for the project manager.

This was the scenario when the Habitat Holding

Rack (HHR) manager at Marshall Space Flight Center

(MSFC), Stacy Counts, was introduced to the overall

concept of Earned Value Management (EVM). Faced

with increased costs (which eventually resulted in

decreased scope of the project), continued schedule

slides, and several technical anomalies, she was

looking for a way to gain a better handle on the

project performance.

As a component of the Space Station Biological

Research Program (SSBRP), the HHR project is an

integral piece of the Program content. The HHR is

the first rack hardware to be delivered for the Program

and has therefore been the first rack to move through

the trials of test and verification—documenting

anomalies and technical difficulties that will benefit

the other SSBRP rack projects. For these reasons,

the HHR maintained high visibility throughout the

manufacturing and assembly process, continuing

through test and verification activities. Needless to

say, the higher visibility emphasized the need for

improved performance on this project. And to improve

project performance, Stacy first had to figure out

how to measure the cost, schedule and technical

objectives effectively.

Enter the concepts of Earned Value Management 

As the principle center for EVM, MSFC was fortunate

to have a group of experts—Jerald Kerby among them—

whose knowledge of EVM was substantial, and who

were willing to work with Stacy to apply the principles

of EVM to her project. The overall goal was first to

understand performance and better deal with the

current overrun environment.

Second, EVM would be implemented to improve

the ways of managing cost and schedule concerns, and

to plan ahead for future impacts that might result from

the current situation. The process helps to measure

performance in cost, schedule, and technical areas,

and it would also help Stacy better identify her project

risks. By measuring performance effectively and

predicting a good percentage of issues/concerns upfront,

mitigation plans could be put into place to help reduce

or eliminate big impacts to the project.

The first step: determining the status of the project

Without an understanding of the current project status,

there is no baseline from which to measure future

evaluations. For a standard project that is in the early

What is Earned value Management (EVM)?

EVM is a process that has been used for years by government and industry projects, predominantly by the Department of 

Defense (DOD), to measure performance and health of the project. Government contractors use the process either as directed 

within the contract itself (currently NASA Policy Directive (NPD) 9501.3 but soon to be in NPR 7120.5C), or simply by choice. 

Unfortunately many projects never fully realize the potential of EVM and what it can do to help managers better understand 

the overall health of the project. EVM is not just a report! EVM is a tool that integrates the cost, schedule and technical 

requirements of a project. EVM also links these areas to the project’s risk management process. EVM requires discipline in all 

aspects of the project; it requires that the organization performing the tasks plan the work and then work to that plan. 

Obviously, some problems will occur that could not be predicted and therefore will not be a part of the initial plan; however, 

good initial planning followed by continual analysis and re-planning allows a manager to better mitigate issues and concerns 

that crop up. The use of EVM also helps the project manager in determining the current project status by answering questions 

such as: Are we on schedule? Are we on cost? Do the costs reflect the true accomplishments? What are our variances? 

EVM identifies trends that help a manager better predict where the project or a particular element is headed. EVM provides a 

method and data to establish a realistic Estimate At Completion (EAC) for the project. In essence, EVM gives personnel more 

reliable information to make better management decisions. 

ask 21 for practitioners by practitioners 19
stages of design development, an Integrated Baseline

Review (IBR) is held. Much like a Design Review,

the IBR is a review used to understand the project’s

performance measurement baseline (PMB) and project

objectives. The IBR also enables project personnel to

understand the PMB in three areas: cost, schedule

and technical performance. Based on this review, the

project identifies and documents the risks associated

with elements of the project so that mitigation plans

can be developed for each.

But since the HHR Project was only two years

from a completion date when Stacy came on board

and recognized the need to use EVM, Jerald helped

her to conduct a “mini-IBR,” or a benchmark review.

This helped them to assess the health of the project

and to establish a more realistic PMB. The review was

scheduled in such a way that it would not interfere with

the contractor’s regularly scheduled tasks.

The entire process went smoothly, and every effort

was made to alleviate intrusions that would cause cost

or schedule impacts in performing this review. Once

the review was completed, the entire team had a much

better vision of the remaining tasks, and individuals

came away with a clearer picture of their piece in the

overall project flow.

With contractors and government personnel

working from the same baseline, the last step in the

review was to come to documented agreement on

remaining project objectives. The review resulted in

a better-informed project team, and a group of people

that learned to work together rather than having a

“government versus contractor” mentality.

The second step: working with the schedule

In reviewing the PMB, schedule experts performed

a review of the HHR schedules to ensure that good

network logic was in place and that all task dependencies

in the schedule were linked accordingly. Personnel

from the Project Analysis Office at MSFC worked with

Stacy and her team to determine whether the time and

resources associated with each task were appropriate.

Once the schedules were reviewed, specific issues

dealing with missing network logic and unlinked tasks

were discussed, and actions were taken to update the

schedules as needed.

During the schedule revisions the HHR team

first realized the importance, and impact, of EVM.

Although contractor personnel had established critical

paths for every piece of the project schedule, an overall,

high-level schedule did not exist to tie them together.

Once a good schedule was developed for the overall

project—linking all the major pieces of the project

together—HHR personnel could better predict a date

for completion of the work, as well as to develop a

true critical path for the project. This schedule update

also allowed for schedule changes to be added. These

changes helped to identify clear critical paths for the

project, and also helped the team to pinpoint an enddate which was tied to the impacts of those changes.

The third step: applying the review concepts

Good schedules certainly help to better plan a project

in detail, but the implementation of that schedule is

key to any project success. Once the initial review

was complete—covering all functional areas of the

“Up until about three or four years 

ago, the people that had Earned Value 

Management on their contract would 

get a big, thick report and use it for 

a door stop. They just didn’t use the 

information.”

—Jerald Kerby

“When you start using EVM, I think it 

is very important to sit down with your 

team to help them understand that 

this is not an antagonistic activity. The 

contractors need to know that you’re 

not trying to beat them up, but to 

establish a true story of the project. 

They may have a more optimistic view 

of what the project looks like at the 

end of the year, and I’m bringing in a 

different, more realistic perspective.”

—Stacy Counts

20 appl the nasa academy of program and project leadership
project—the HHR team began to use EVM to regularly

manage the project.

The practice of EVM forced good planning by

measuring work progress and providing the cost and

schedule metrics to track project performance against

the baseline plan. Using initial data, as well as each

consecutive month’s data as it was delivered by the

contractor, the HHR manager could determine both

cost and schedule variances and identify developing

trends across the project’s tasks.

The fourth step: continuous review of data

The primary data was submitted by the contractor

via disk, loaded into a data analysis software tool

(wInsight), and a 5-page summary report was printed

for review with the contractor each month. This report

was reviewed alongside the standard Cost Performance

Report (CPR) that the contractor submits monthly.

With constant access to EVM data, both the contractor

and Stacy’s team were able to see a realistic picture of

where the project had been, where it was headed, and

how fast it was likely to get there.

It works if you work it

EVM is a management process that has been embraced

by project managers around the globe with good success.

It allowed Stacy to define a PMB for the project that

was more realistic than the previous baseline. It also

providedher withthenecessary data to track performance

and to ably discuss project impacts with higher-level

management. This was the data the project team needed

to back up that “gut” feeling that comes from years of

project experience—experience that says you will almost

always have schedule slips and cost overruns.

While EVM doesn’t make the problems go away,

when implemented properly it can help to identify

problems before they reach their full potential. Today,

project success is no longer an unattainable goal. By

using EVM data to guide a project on a monthly basis,

objectives can be more easily reached. With good tools,

solid upfront planning, and effective implementation of

these tools, project managers can be better informed to

make management decisions during the entire life cycle

of their project. •

Lessons

• When all members of the project team—whether

government or contractor—understand the objectives

and work together from the same baseline, you are more

likely to reach project success.

• The ability to track performance and cost and schedule

variances gives the Project Manager the information they

need for a preemptive strike to slips and overruns. That

is, they don’t have to operate on their “gut feeling” alone;

they have the data as soon as a problem begins.

Question

How can you change perceptions by introducing this tool to 

contractors as a benefit to the team, rather than a way of 

checking up on their performance? 

Jerald Kerby is the EVM Focal 

Point for Marshall Space Flight 

Center, where he supports the 

implementation of EVM for the 

Center’s projects.

Stacy Counts manages the 

International Space Station’s 

Biological Research Project (BRP) 

Habitat Holding Rack (HHR). She 

credits the EVM tools available 

through the MSFC Chief Financial Office with 

helping her to establish a realistic approach to 

project planning, and a solid method for assessing 

the quality of contractor financial data. 

“EVM gave me something to walk into 

a meeting with my contractors and 

speak to. I found that they would come 

in with their cost data and tend to put 

their best foot forward. I now have 

something substantial to back me up 

when I say, ‘Your past performance 

says you’re going to overrun—not only 

by what you’re telling me, but probably 

by more.’”

—Stacy Counts

ask 21 for practitioners by practitioners 21
In 2002 and early 2003, Kennedy Space Center conducted a pilot in which 

eight in-house projects implemented Earned Value Management (EVM). 

But let’s just say we weren’t welcomed with open arms.

By Glenn Rhodeside

Earning Value 

22 appl the nasa academy of program and project leadership
The project managers were given a half-day of EVM

training. Although a portion of the project managers had

some experience with EVM, the concept was completely

new for some of them. The rest of that training day

was spent helping them to start the base-lining process

and answering any questions that they might have had.

Slowly, we helped them to develop a baseline, and then

conducted pseudo-Integrated Baseline Reviews (IBR)

where they presented their Work Breakdown Structure

(WBS), their integrated resource-loaded schedules, their

risks, and their risk mitigation plans. The intent, as with

any IBR, was to get to an agreement with the project

management so that everyone understood the baseline,

what the project’s risks were, how they were going to

collect the data, and how they were going to use EVM

to manage their projects.

What we realized during the base-lining process and

as the project personnel collected data and performed

cost/schedule performance analysis was that half a day

of training just isn’t enough to learn how to use EVM.

We recognized the need for at least two or three days

to learn the basics. We also realized a few things about

the culture and environment of project management

in NASA, specifically in relation to implementing this

type of change. We figured out that we had to anticipate

some level of resistance within the organization,

especially if they’ve never done this before. We had to

be patient, work with them, and hold their hands a bit.

It also didn’t help that our financial systems did not

collect actual costs in a manner useful for EVM. Lack

of automated data collection meant manual manipulation of some data—an issue not present with most

contractor financial systems.

Lastly, it didn’t help the

cultural resistance when we

came in halfway through the

projects. EVM may benefit a

struggling project, but for our pilot, there was a price

to pay to come in after the start. There were already

systems in place on the projects and we came in and told

them that they had to change everything and start using

EVM. We realized that to be most effective, EVM has to

be introduced at the very beginning of the project. •

We’d say, “We’re EVM. We’re here to help.” And management would 

say, “We’ve got all the help we need, thank you very much!” It was

like that Tom Petty song, “Don’t Come Around Here No More.”

Glenn Rhodeside performs 

systems engineering, risk management, 

cost estimating, operations analysis, 

and related analysis for varied programs 

and projects. For the past three years, 

he has been a member of NASA’s EVM 

Focal Point Council to set and coordinate 

policy, as well as share best practices 

and lessons learned. 

Against Resistance

ask 21 for practitioners by practitioners 23
THE EARLY BIRD OPENS THE CHUTE

A Lenghty Caree

Lessons on Risk
I became a project manager at age twenty-two at

Eglin Air Force Base. I managed the droning of the B47

to fly unmanned, and I had zero experience to take on

that task. What I learned is the real way you acquire risk

aversion: I was scared to death that I’d fail.

This developed a characteristic that I carried with

me throughout my career. The strongest thing a project

leader can feel, in terms of risk, is the risk of failing.

So I took it upon myself to learn everything about the

airplane and the guidance control system by searching

out the best in the aerospace community. At that time,

Lockheed was doing a modification of the aircraft.

Boeing designed and built the aircraft, and Sperry was

doing the guidance control system. I made sure that I

spent hours and hours with each of them to understand

exactly what I was responsible for.

SETTING THE PATTERN

The pattern that I established for my career was one of

research and faith in the skills of other team members.

Through the years as I worked on other projects,

the philosophy I developed is that you can be very

successful if you spend the time to organize yourself,

find qualified people, and understand the objectives.

Once you decide what you need to do, you can organize

people around it. You can get the skills. That’s the

strongest way you can become risk averse—to be

I HAVE BEEN INVOLVED WITH PROJECT MANAGEMENT

FOR FIFTY YEARS. RATHER THAN FOCUSING ON ONE 

PARTICULAR STORY, I’D LIKE TO TELL YOU THE LARGER 

STORY OF MY CAREER. THOUGH MANY OF THE PROJECTS 

TOOK PLACE OVER THIRTY YEARS AGO, THEIR LESSONS 

ARE STILL RELEVANT TODAY. 

BY ANGELO GUASTAFERRO

er’s

ask 21 for practitioners by practitioners 25
dependent on the strengths of others and bring them

into the program as best you can.

When we worked on Viking, the first landing

mission to Mars, it was done at Langley Research

Center, which is really a technology center. Langley

was selected because of its strong technology base, and

the Jet Propulsion Laboratory (JPL) was busy with the

Mariner and Voyager projects.

We ended up using this to our advantage. Not only

did we concentrate on finding qualified people, but

we found that by doing the project at a technological

center, we were able to get people who were strong in

the technical skills it took to do the re-entry, to solve

aerodynamic problems, and to develop the parachute.

So Langley turned out to be a technological advantage.

THE EARLY BIRD OPENS THE CHUTE

But the parachute reminds me of the different ways

in which the first and second Mars Missions dealt

with risk. They were both successful, but the roads

getting there were different. In 1969 we did a fulllanded simulated test at White Sands. We simulated

the spacecraft in the necessary ways and developed the

parachute very early. The reason we did that was to

make sure that the parachute got sized properly, since

the whole integration of the spacecraft was going to be

built around the size of it. 

The recent Rover Missions on Mars waited too

long to do that test. They did it about nine months

before they were supposed to launch and the parachute

didn’t fully deploy. So they had to go back and do a

redesign of the parachute, but the whole spacecraft

was designed and fixed. At that point there were many

variables to look at and problems to solve, and the risks

went up tremendously because of the limitations they

had in changing the design.

So not only should you organize yourself and get

qualified people, but you have to do things early. You’ve

got to build enough reserve in your thinking so that you

can minimize problems. The other thing is: If you have

a threat of cancellation over your head, or your project

might be moved to another center, or parts of it are

being deleted—you allow for that, and you adjust. If you

stop working because you’re worried about changes to

your program, you start adding risks to it.

THE GROUP EFFORT

Also, you have to be disciplined in carrying out

very critical analysis. Don’t move on without it. On

Viking, we brought the science community in early

for the 1975 launch. They attended every design

review and participated very strongly. We wanted their

fingerprint on everything that was done from an

engineering viewpoint.

My mentor Jim Martin insisted that if this was

going to be their opportunity for a scientific achievement, then they needed to participate in the program

all along the way. Would you believe that 72 scientists

moved to JPL from their various universities for one

year during the Viking Mission just because he said

that was where the action was? He said, “If you want to

play on my program, that’s the way it’s going to be.” You

can’t avoid risk over the telephone.

PLANNING FOR

THE WORST-CASE SCENARIOS

During Viking, we also developed about 500 scenarios

of all the things that could possibly go wrong

during the development and flight. We adopted a

very pessimistic view and used these scenarios to

establish various plans for cost offsets, budget shifts,

and solutions to technical problems.

“PLAN THE WORK AND WORK THE PLAN”

26 appl the nasa academy of program and project leadership
We did have a problem that I’m not proud of, but it

also taught me something about risk. We had money

problems, and we were told that we weren’t getting any

more money. The cost was fixed, and the schedule was

also fixed since it was a planetary launch.

Well, we had a risk problem related to a test. One of

the problems with the fixed budget was that we weren’t

going to be able to perform the terminal-landing

test. This was a very sophisticated full-systems test

where we would drop the spacecraft through a Mars

landing simulation. We had pitched the cost problem

to headquarters, saying we needed $1.2 million dollars,

and we were denied the money. So we were going to

have to launch without the critical terminal-landing

test—a very high-risk decision.

Jim Martin accepted it at the time. He said, “Ok,

as long as you hold my hand, I’ll jump into the pool

with you.” So we made the decision to go ahead with

it. We ended up being successful, but there was a large

amount of risk attached. If we had failed we would

have lost $1 billion dollars (and this was in 1970)

because we couldn’t secure the $1.2 million for the

necessary preliminary test. That just doesn’t make

sense. It wasn’t a schedule problem; it was strictly a

cost problem.

GIVE IT TO THEM STRAIGHT

This is where I really learned a big lesson. As a

project leader, you’ve got to take the problem before

management and tell them the risks that they are taking

by withholding funds. You’ve got to be tough and hang

in there. At this point, we were seven years into the

project. Jim decided to swallow hard, pray a lot, and

cross his fingers that the test worked. We had a happy

ending, but under other circumstances, it could have

been a disaster.

This is an example where management made the

decision to take the risk against the security. I think

that’s the thing that has to change. We’re in a high-risk

business, and we have to approach it in a conservative

way. But the Agency needs to realize that sometimes the

failures make you learn and progress.

I’m not saying that you set out expecting to fail,

but there is such a thing as so much risk-aversion

that you don’t do anything. You’ve got to maintain a

healthy amount of it and move ahead. And these are

just some of the strategies I learned over my fifty years

that have helped me to do that. •

Lessons

• Sometimes pessimism can help to reduce risk.

Planning for possible problems—and developing a cost

and schedule-efficient way of dealing with them—can

provide an important project “safety net.”

• A small amount of funding is never worth the failure

of a large-scale project. Project managers have to fight to

get the resources they need to do things right—not cross

their fingers and hope for the best.

Question

In a situation where mistakes and misjudgments can cost 

millions of dollars, how do you strike the right balance between 

healthy risk-aversion and playing it too safe?

PEOPLE FIRST

There have been times when I’ve taken over 

a project in the middle, and also times when 

the project has been in the formative stages. 

In every case, I’ve gone off-site and started 

to look at—and fix—duplication. Everybody 

has to be in first grade again. I say, “Stand 

up and tell me what you think your job is.” 

They do that. Then you start listening.

Sometimes I’d find out that two or 

three people were doing the same thing. So 

I started to fix it. I’d find out where the holes 

were, where there is somebody who is not 

doing anything. So you work it out so that 

everyone is clear about exactly what they 

are doing and what the goals are.

Then you have to empower people to 

build a high-performance team. This team 

has to be willing to communicate and tell 

you exactly where you are. You do this by 

dealing with the complete human circle: the 

social aspects, the commitments, the truthfulness, the relationships, the passion—all 

the things that we measure in people. Then 

you can take their technical skills and apply 

them in a way that really drives the system 

to success.

A process doesn’t get the spacecraft 

built. A logo or a motto doesn’t make it 

happen. It’s people.

ANGELO “GUS” GUASTAFERRO has had a lengthy career 

in Program and Project Management, 

both at NASA and with private industry. 

His previous story, “Bringing Up Baby,” 

was printed in ASK 17.

ask 21 for practitioners by practitioners 27
28 appl the nasa academy of program and project leadership
I left the Joint Air-to-Surface Standoff Mission (JASSM) as a

systems engineer to start a new program called the

Small Diameter Bomb (SDB). I thought that this would be a good

opportunity to make the transition into program management. 

not a hero

By Lynda Rutledge

This little weapon, though, was not just representative

of a transition in my career. It was a paradigm shift for

the Air Force. Traditionally, we’ve held the American

outlook of “bigger is better.” Look at our cars, our

houses. So this program was symbolic of a culture shift.

It was important to make a switch to smaller weapons,

because the Cold War was over, and we were going into

smaller areas. Collateral damage became a big issue,

and we were limited in space on the aircrafts.

But can smaller get funded?

Being naïve, I thought, “We’re going to start up a

program. Somebody must want this. They’ll give me

money, we’ll lay out the strategies, and we’ll get started.”

I was frustrated when it didn’t go that way. Somebody

told me that it takes patience to be a Program Manager.

I thought, “Well, I’ll work on that.”

While I was working to obtain funding to develop

an acquisition strategy and to build coalitions, I was

also trying to make people understand what we were

doing. The weapons side of the house doesn’t get a lot

of money thrown down to us compared to our aircrafts.

So at first I had a very small team of only four people.

The four of us worked day in and day out coming

up with acquisition strategies and working with our

warfighter users to develop requirements. But every

year we’d find out that we were just under the cut and

that we wouldn’t get funded. And every year I would

think, “It’s time for me to leave.” But I kept going, kept

trying to build it. After three years of trying to start

this, I had laid out about 20 acquisition strategies in

any flavor you wanted. I had all kinds of choices for

anybody that came along.

Then it snowballed

It was Super Bowl weekend of 2000—not that I watch

the Super Bowl, but my husband was watching it—and

I was working on getting my numbers together. I had

gotten a call that Friday afternoon saying that General

Jumper, who at the time was the Commander of Air

Combat Command, wanted to pursue development of

this weapon. So they said, “We’re going to fund it.”

A LEADER

ask 21 for practitioners by practitioners 29
I was so excited. I went around briefing my strategy

and got things going. But what happened was that

when this program started, I was in my comfort zone.

Then my span of control went haywire overnight. Over

a period of two months, I went from managing four

people to 30 people.

At this point, I had made every decision about

the program along the way. It was my vision, my baby,

my masterpiece. I knew everything about this system.

And I liked it that way. I loved being able to make every

decision and to tell everyone what

they needed to do to make my

vision a reality. When I went

into the teams, everybody knew

how I operated: I tell you what

to do, and you go do it.

Then I was sitting around

the table one day in a meeting

trying to get our Request For

Proposal (RFP) together. What

I found is I had driven these

people to expect me to make

every decision. All of a sudden,

I got overwhelmed. I had about

25 people around the table, and

I’m saying, “We need to have these factors developed.

I need you to write your section L, you to write

your section M, you to write your instructions for

the offer, and then bring it all back to me.” They

all looked at me and said, “How do you want me to

do that?”

I thought, “I’m in over my head. There is no way

that I’m going to be able to do every one of these

people’s jobs, or tell them exactly what to do, or check

all of their work.” I just left the meeting.

Releasing the grip

There was a retired Colonel who worked for me as a

support contractor. I used him as a sounding board

a lot. I sat down at his desk and said, “Bill, I’m in

trouble. All of these people expect me to make every

single decision and tell them exactly how to do everything. I’m not going to have time to do it anymore.” He

said, “You’ve got to let go of this. You have no choice.

Otherwise, you are not going to make it.”

It was extremely hard for me, because I felt such

ownership of the program. I felt like I was giving up

my firstborn when I gave it to these people to try to

implement. But I called everybody back in the next day.

They were waiting for me to give them instructions on

exactly how to write up their RFP. I said, “Here’s the

deal. I’m not going to think for you anymore. We’ve

got to get on contract in six months.” I said, “If you’ve

never done it before, you’re going to learn now. I’m not

telling you how to do it. You had better figure it out. I’ll

be happy to help you, but I can’t do it all.”

I was very nervous though. Here I was not tracking

everything day to day. I wasn’t right on top of it writing it

myself.Butbytheendofthesourceselection, surprisingly

enough, things had changed. Some

of the people that wouldn’t go

to the bathroom without asking

permission were up at the

front of the room, coming up

with their own methodologies,

leading the pack, and making

decisions. All of a sudden, they

had emerged as leaders.

A new understanding

At that point, I was more proud

of having let go than of doing it

all myself. My focus had changed

from the details, the implementation

of developing every one of these criteria, and dealing

with the contractors, to leading the people.

When I realized that I had to do that, things got

easier. You would think that it was an obvious thing,

but sometimes you have to learn the hard way. Heroes

are people that can come in, take over, and do it all

themselves. But when you lead people, you don’t have to

do it yourself. You’re leading them to the vision.

I don’t know that I necessarily ever would have

gotten slapped in the face like I did had I just been on

a normal program. After having gone from four people

to 30 people in a two-month time frame—and having

them staring me in the face, wanting to know everything to do—the light came on. No matter how good

you are, this isn’t a one-man show. There are no heroes

in this. •

Lynda Rutledge was an Air Force systems 

engineer on the Joint Air-to-Surface Standoff 

Missile (JASSM) during the source selection 

phase. After leaving JASSM, she managed 

the concept exploration and planning of 

the program that is now the Small Diameter 

Bomb (SDB). She is currently Deputy Director in the Precision 

Strike System Program Office within the Armament Product 

Group at Eglin Air Force Base, Florida. 

Over a period of two months,

I went from managing

four people to

30 people.

30 appl the nasa academy of program and project leadership
Sarcasm,

metaphor and

graphics.
Root Learning Inc., is best known for creating “Learning Maps” like this one: humorous 

drawings based on the inner workings of an organization. Their purpose is to put complex 

topics on the table, to stimulate discussion, and to ultimately give team members a common 

vision of where the organization is going and what role they personally play in getting there.
1

2

3

4

Mapping

 success

Root Learning, a learning consulting organization

with a background in strategic planning, recognizes

the knowledge gap that frequently exists between a

leadership team and the rest of an organization. Team

members supposedly working toward the same goal

don’t always have the same vision of where the organization is headed—and they may not understand how the

piece they are accountable for fits into the big picture.

To address these complex problems within an organization, Root Learning utilizes the age-old tools of sarcasm,

metaphor and graphics (much in the same way that ASK

uses a traditional storytelling format.) The company is

best known for creating “Learning Maps” like this one:

humorous drawings based on the inner workings of an

organization. Their purpose is to put complex topics

on the table, to stimulate discussion, and to ultimately

give team members a common vision of where the

organization is going and what role they personally play

in getting there.

APPL knows how effective it is to incorporate

new and engaging techniques into its knowledge

sharing programs. By collaborating with Root

Learning, we were able to expand the knowledge of the

organization and add one more of these techniques to

our repertoire.

In a meeting facilitated by 

Goddard Space Flight Center’s 

Knowledge Management Architect, 

Dr. Ed Rogers, Root Learning Inc.

teamed up with members 

of the Academy of Program 

and Project Leadership’s (APPL) 

Knowledge Sharing team, Denise 

Lee and Therese Cooper. In a 

brainstorming session with Root 

Learning’s artists, together they 

worked to create an accurate 

illustration demonstrating the 

APPL vision. In its advanced 

stages, the drawing was sent to 

APPL Director Dr. Ed Hoffman 

and Deputy Director Tony Maturo 

for further suggestions. A few 

iterations later, APPL’s successful 

collaboration with Root Learning 

produced the final version of this 

customized “Learning Map.”

ask 21 for practitioners by practitioners 31
To learn more about Knowledge Sharing and other APPL services,

find contact information at www.appl.nasa.gov.

Academy of Program

and Project Leadership

Career Development 

Performance Enhancement

Knowledge sharing
Keeping 

Promises

Scheduling work seemed impossible; the design was

filled with conflicts, and it kept changing. Supervisors

were torn between finding work ready for today and

trying to solve problems for tomorrow. It wasn’t much

fun, and the client was very unhappy. There was so

much to do—and so little time—that it was hard to

know where to start.

Design issues dominated the weekly planning

meeting, so I went there to listen and learn. After new

issues were identified and discussed, the

meeting turned to review the status of

unanswered RFIs. These Requests For

Information typically originate in the

contractor organization and are used to

define, manage, and track solutions.

Going down the list, Carl,

the contractor’s project manager,

spoke to Dan the architect. “Dan, we need to

resolve RFI 173.” Dan shook his head in agreement,

and they moved on to RFI 204. I wasn’t at all

sure what had happened or how to interpret this

brief interchange.

After the meeting, I caught up with Carl and asked

if Dan had promised to solve the problem. Carl was

convinced that he had. I was not so sure, so we caught

up with Dan and I asked, “Did you promise Carl to

answer 173?” Dan was surprised and confused. “How

could I?” he said. “I agree we need to get it resolved, but

Carl owes me some vendor data before we can decide.”

Carl was taken aback; he had forgotten his promise

to Dan. But after a quick discussion, both were back

on track.

Walking away, I asked Carl why he had framed his

request, “Dan, we need to resolve RFI 173.” He said

this was a nicer, more team-friendly way of talking.

He claimed, “It puts us in the problem together.” Carl

and I are pretty good friends, so I took him straight on.

“Teamwork isn’t about being soft and unclear,” I told

him. “It requires making clear requests

and securing reliable promises. Don’t

be a wimp—ask for what you want.

And don’t be a flake—do what you say

you are going to do.”

Coordinating work in projects and

keeping projects under control is a

matter of people making and keeping

the commitments that release work to others in the

right sequence. A project can be understood as a

network of commitments that links the work of the

specialists to the promise of the project and coordinates

their action. Carl makes a request to Dan...Dan asks for 

vendor data...Carl asks his assistant...somewhere a request is 

mistaken for an opinion, or the nod of the head is interpreted as 

a promise. Planning systems can provide the structure

and circumstance for planning conversations, but

systems don’t make work happen. People make work

happen by making requests and keeping promises to

one another.

By Gregory Howell

The project, a complex healthcare facility, was in trouble. The 

money and time were gone, but there was plenty of distrust and 

mis-coordination. 

Commitments are 

between people, 

not schedules.

ask 21 for practitioners by practitioners 33
There are ways to tell when you are making a

reliable promise. Ask yourself if you can say one or

more of the following:

1. I am competent enough to perform, or I have

access to competence.

2. I estimated the amount of time (hands-on)

required for this work.

3. I have the capacity available to do the work and

have allocated it to the task.

4. I am not having a private unspoken conversation

in conflict with my promise.

5. I will be responsible; I’ll clean up the mess if I

can’t deliver.

Commitments are between people, not schedules.

Project management as practiced today creates a

“commitment-free zone,” because it assumes that people

will commit to centrally managed schedules without

providing a mechanism to ensure their work can be

done. So they give it their best, but something always

seems to come up...“I tried, but you know how it is.”

This form of project management does not provide

a mechanism to ensure that what should be done, can in

factbedoneattherequiredmoment.Toooften,promises

made in coordination meetings are conditional and

unreliable. It has been my experience that at times

trust can be low and hard to build in this environment. The absence of reliable promises explains why

on well-run projects, people are often only completing

30–50 percent of the deliverables they’d promised for

the week.

We all know what a promise is; we have plenty of

experiencemakingthemandreceivingthemfromothers.

So what’s the problem? The sad fact is that the project

environment—like many other work environments—

is often so filled with systemic dishonesty, that we don’t

expect promises that are reliable. Project managers

excel when they manage their projects as networks of

commitments and help their people learn to elicit and

make reliable promises. •

Don’t be a wimp—ask for what you want.

Gregory A. Howell is co-founder and

managing director of the Lean Construction Institute

(LCI),a non-profit organization devoted to production

management research in design and construction.

Howell brings 35 years of construction industry

project management, consulting, and university-level

teaching experience to LCI.

People make work happen by making requests 

and keeping promises to one another.

34 appl the nasa academy of program and project leadership
IN THE 25 YEARS THAT I’VE WORKED FOR GENERAL CONTRACTORS, 

OWNERS, AND ENGINEERING FIRMS, I’VE RECOGNIZED THE 

REQUEST FOR INFORMATION (RFI) PROCESS AS A HUGE SOURCE OF 

WASTED EFFORT AND NEEDLESS CONFRONTATION

DOCUMENTATION:

NO SUBSTITUTE FOR

COMMUNICATION

by JOHN STRICKLAND

ask 21 for practitioners by practitioners 35

PRACTICES
So what is an RFI? It was one of the first things

I learned about back when I started my project

management career with my first large construction

firm. I learned how to use these forms as a

convenient and effective means of documenting the

many legitimate clarifications needed on a major

project. However, like most other young engineers, I

also learned to use the RFI as a weapon in the ongoing

battle between owners, or their designer and the

construction contractors. Recently, our project team

has done a few simple things to greatly reduce the waste

and frustration that comes from this type of battle.

WHAT’S THE PROBLEM?

The RFI form can be a great tool if used properly, and

I certainly don’t recommend that they be eliminated

entirely. The RFI form was created to document the

many clarifications that are commonly required on

projects. Typically, the contractor uses the top half

of the form to clarify—or request permission to vary

from—the contract documents. The bottom half of the

form is used to record the answer. But this seemingly

simple process is plagued by a number of problems.

From the contractor’s perspective, RFIs are needed

to secure information that should have been in the

contract documents in the first place. The missing information keeps their crews from working effectively, and

it makes hitting already demanding cost and schedule

targets even more difficult. Owners, or their design

firms, often view the RFI as a means of harassment.

Both sides of the issue have legitimate complaints, and

both sides cause most of their own pain.

Considering that year after year these problems

appear on countless projects across the country, the

total wasted effort involved is beyond comprehension.

To make matters worse, many of the problems (and

many of the RFIs) are completely unnecessary and

represent waste in its purest form.

WHAT WENT WRONG?

It is easy to understand how the RFI was transformed

from a convenient means of documentation into a

weapon of project administration. Just start with the

owner/designer side of the contract: tough-minded

contract administrators or field inspectors would

require contractors to remove and replace work that

didn’t match the contract documents—even if there

was no functional reason to require the re-work.

Contractors quickly learned to document even the

slightest variation. But they also learned to write as

many RFIs as possible in order to substantiate future

claims. I recall a general contractor’s manager explicitly

instructing his staff to maximize the number of RFIs in

order to establish that the design was flawed. And I’m

sure experienced project managers can cite many other

examples of wasted effort.

LOOKING FOR ANSWERS

We have learned that life on the project does not need

to be as difficult as we make it. And there are some ways

that I’ve managed to avoid these difficulties by focusing

on communications skills and creating a culture

of collaboration.

I managed to do this on one of my recent projects,

a state-of-the-art facility constructed in the Pacific

Northwest for one of the world’s leading technology

companies. Our scope was to install and connect

hundreds of highly sophisticated machines in the

shortest feasible amount of time. Contractors worked on

very competitive fixed-price agreements and employed

up to 1,000 craft employees at the peak of construction. Although hundreds of RFIs were generated, there

were remarkably few complaints (if any at all) about RFI

turn-around time, which averaged about three days.

OPEN YOUR MOUTH

The key to our good experience was recognizing the

difference between documentation and communication.

RFI forms are great for documentation, but they are no

substitute for conversations. Our simple rule was that

nobody should receive an unexpected RFI. The first

step in our RFI process was to discuss the issue with

36 appl the nasa academy of program and project leadership

PRACTICES continued
the construction coordinator in charge of the work.

Many of the potential RFIs were answered before they

were ever written, and no effort was wasted getting them

through the system. The RFIs that were necessary could

be answered very quickly, because it simply documented

an agreement that had already been made.

REDUCING WASTE BY 

REDUCING NUMBERS

Several other techniques were used to reduce the need

for RFIs, including thorough pre-construction job walks

and design reviews to make sure that everybody understood the scope. We made sure that the construction

management and design teams had good access to

one another and provided many different forums for

communication. When RFIs were necessary, they were

electronically routed and tracked. We learned that

an electronic RFI system can be a good tool, but will

certainly not eliminate all of the friction in the RFI

system. It’s easy to imagine the computer-based RFI

tracking programs as simply more powerful weapons

in the battle.

AND EVERYBODY’S HAPPY

Contractors were happy, because they got their answers

quickly. The designers were happy, because they got far

fewer poorly worded RFIs that were unnecessary in the

first place. The owner was happy, because there were

essentially no change orders due to the RFI process to

cause delays, disruption, or field coordination issues.

The entire project benefited from the effort to develop

a collaborative culture, and we set new benchmarks for

safety and schedule performance as well.

The real lesson I took from this experience was

what an amazing effect good communication can have

on teamwork and project performance. Much of the

conflict and confrontation that burdens the project

team is largely unnecessary. There are countless other

opportunities on our projects—from contracts to

technical submittals—for improving project performance, as well as the quality of life for project team

members. These opportunities stem from establishing

a collaborative culture, even on projects with rigorous

contractual requirements. One way I’ve found to start

effecting change is to take a look at RFI processes,

as well as other processes where communication is

the key. •

THESE OPPORTUNITIES STEM FROM 

ESTABLISHING A COLLABORATIVE CULTURE, 

EVEN ON PROJECTS WITH RIGOROUS 

CONTRACTUAL REQUIREMENTS.

JOHN STRICKLAND has led numerous major design/

build and construction management projects within the 

microelectronics industry. He has developed a strong track 

record for completing projects ahead of schedule and under 

budget, and has helped pioneer numerous strategies that 

have dramatically improved “time to money” for clients. He has expertise 

in all phases of construction operations—including safety management, 

project controls, contract management and field operations—as well as 

the application of “Total Quality Management” and “Lean Manufacturing” 

techniques to complex construction projects.

ask 21 for practitioners by practitioners 37
1PM

2PM

3PM

4PM

5PM

6PM

38 appl the nasa academy of program and project leadership

PRACTICES
1PM

2PM

3PM

4PM

5PM

6PM

In 2000, I transferred from a department of predominantly manufacturing people to one in 

which most people had an IT background. For my manufacturing colleagues, “meetings” were 

always face-to-face activities.

ask 21 for practitioners by practitioners 39
But the IT people, many of whom worked from home,

made no such presupposition. And so even when I

issued a meeting notice, with the location described

in bold, somebody would inevitably remind me to

“publish the call-in numbers.” Faced with conducting

meetings of one, or learning to conduct effective remote

meetings, I chose the latter.

I experienced more than my fair share of failures

initially. But each failure prompted me to adjust my

approach. I soon realized that the practices that make

remote meetings successful are exactly those that make

face-to-face meetings successful. But habits that result

in poor face-to-face meetings are exacerbated in a

remote environment.

Any meeting announcement needs to clearly state

the location and starting time. Similarly, remote

participants need clear instructions on how to access

the meeting and when. Participants in face-to-face

meetings can generally ask for directions if the

announcement is unclear. Or the meeting leader can

send a search party for late arrivers frantically trying

to find a poorly marked conference room. No such

remedies are available for remote meetings. A simple

error in the telephone number or passcode can doom a

remote meeting before it begins.

There is obviously no need to select a meeting location

for remote meetings, but there are equivalent and

important considerations. For example, the dial-in

service and collaboration software, if any, must be

reliable and capable of handling the anticipated number

of participants. It must also be available for the required

duration, and restricted to the intended meeting. We

are all familiar with the confusion that results from

two groups trying to use the same conference room

at the same time. But it hardly compares to the havoc

resulting from two groups trying to use the same call-in

number at the same time.

This is due in part to the absence of the visual cues

that signal a face-to-face meeting is ready to start. For

example, it is obvious when the participants in a faceto-face meeting enter the room and sit down. Some are

early, some are late. Some immediately begin talking,

some enter quietly. Some sit down immediately, others

chat quietly with friends or pour a coffee. Some are

well-prepared with notes, others are consulting PDAs

desperately trying to recall the purpose of the meeting.

But the remote meeting leader must confirm

everybody is present and ready to begin audibly. I

typically do a roll call of expected participants, asking

each person to respond individually. Or I read the list of

people who have introduced themselves, and then ask,

“Is anybody else on the call?” I then confirm everybody

has access to the agenda and other documents. This

may be as simple as confirming everybody received

the documents emailed in advance. But if we are using

collaboration software, it is usually necessary to step

through the procedure for accessing the materials.

These cues would be obvious if the meeting were faceto-face. For example, it would be helpful to know if

somebody “leaves the room” or otherwise checks out of

the discussion. It would also be useful to know if people

are shaking their heads in disagreement, or if the shy

participant is frantically motioning to say something.

There is no effective way to do this, in my experience,

except to periodically stop and specifically ask each

participant to respond. Most collaboration software

has a feature enabling the participants to express their

40 appl the nasa academy of program and project leadership

PRACTICES continued
emotions, but most people use it only when prompted

by the facilitator.

Providing visual props during remote meetings is

essential. Even the most patient participant will lose

track of the conversation during a long telephone call.

The ideal visual aid is an outline, PowerPoint slides for

example, controlled by the facilitator using collaboration software. If the meeting is being conducted without

collaboration software, the visual aids must be sent to

each participant in advance. The facilitator should

constantly check that everybody is “on the right page.”

I generally say something like: “We are looking at slide

six. Is there anybody who does not have slide six?”

Remote meetings are best for updates and information

sharing, but it is possible to effectively facilitate decisions

with a little planning. Generally, the meeting leader needs

to clearly state the proposed decision and then separately

poll each participant for concurrence. Normally, there

will be a range of responses, requiring the facilitator to

restate the proposal and repeat the process. Several iterations may be required before a consensus is achieved. I

usually confirm decisions by restating the conclusion as

it will appear in the meeting notes and asking the participants to express any objections.

Gaining commitment to follow-up actions is never easy,

of course, but tends to be particularly tricky in remote

meetings. The ideal solution is to use collaboration

software with a whiteboard as a means of recording

the follow-up actions and responsibilities. (A Word or

Excel document viewed through NetMeeting works

equally well.)

But if the meeting is being conducted without

collaboration software, the leader must review each

follow-up action explicitly, even painstakingly. I

generally note follow-up actions throughout the meeting

and use the last few minutes to confirm and finalize. I

read each action and name the person I think owns the

responsibility. When the person accepts, I validate by

asking for a completion date. All the normal rules for

assigning follow-up actions apply, of course. One, and

only one, person must be responsible for each action,

and assigning an action to somebody not present is akin

to assigning it to nobody.

Documentation is good practice for any meeting, but

it is essential for remote meetings. It is far too easy to

misread the participants’ reactions without being able

to observe their body language. Did Mary drop out of the 

call because she lost interest, or because her cell phone died? 

Did Alfonso accidentally drop the phone, or throw it down in 

disgust? And who was that snoring anyway?

I make it a habit to issue meeting notes within 24

hours, preferably in the body of an email message (not

as an attachment) to maximize the chance of it being

read immediately. And I limit the meeting notes to the

critical items I want to be sure we’ve agreed to, generally

under just two headings: Conclusions and Follow-up

Actions. If there is a need to inform others of what

happened at a meeting, I do that separately. Confirming

the participants have a common understanding of the

outcome is absolutely essential to moving forward in a

trustful environment, and it should never be confused

with sharing the results with non-participants.

I frequently hear complaints that remote meetings

are ineffective. But in my experience, they can be just

as effective as face-to-face meetings for most purposes.

They just require more preparation. But with careful

planning, and a little practice, you too will find yourself

reminding people to “publish the call-in numbers.” •

Hugh Woodward

concluded a 25-year 

career with Procter 

& Gamble in January 

2004. He spent 13 

years as a program manager in both 

manufacturing and business services 

environments at P&G, leading teams 

focused on operational and process 

improvement. He is now working 

with Macquarie Business Concepts 

to advise clients on approaches to 

achieve their strategic goals through 

the application of effective project 

portfolio management processes.

ask 21 for practitioners by practitioners 41
42 appl the nasa academy of program and project leadership

interview

42 appl the nasa academy of program and project leadership
Recently retiring from his position as Deputy Director of NASA’s 

Goddard Space Flight Center in Greenbelt, Maryland, Bill Townsend is 

now the Vice President and General Manager of Civil Space Systems of 

Ball Aerospace and Technologies Corporation. Prior to his assignment 

to Goddard in 1998, Mr. Townsend had served as the Deputy Associate 

Administrator (Programs) for the Office of Earth Science since 1993. 

For a 20-month period beginning June 1996, he was also the acting 

Associate Administrator for the Enterprise.

Mr. Townsend also held other key positions within NASA, including the 

title of Deputy Director of the Earth Science Applications Division and 

the Chief of the Flight Programs Branch. He began his tenure at Wallops 

in 1963, and in addition to being recognized with various prestigious 

service awards, has been involved with close to sixty launches during 

the course of his NASA career. His story about the Aura launch was 

recently published in ASK 20.

Bill Townsend 

ask 21 for practitioners by practitioners 43
You recently had a story about your experiences with 

the Aura launch published in ASK. One of the most 

valuables lessons that came from it was the importance 

of listening to minority opinion.

People need to recognize how important it is to listen

to minority opinions. It doesn’t mean you have to

agree with them, but they should be heard. And this

needs to happen at all levels of the organization. In this

particular case, I had to seek out the minority opinion.

When I heard that it might have some legitimacy, I

wanted to hear more and take the time to discuss what

was being said.

I was asking, “Why are we seeing these things so

late in the game?” Allegedly, we’d never seen them

before, so why were they coming up in the launch

sequence? It turned out that they had been there all

along, but we hadn’t seen it in the data. It was the

dissenting opinion that caused us to go back and look

at the test data again.

If you are lower down in the organization,

sometimes it’s hard to raise your hand and say, “We’ve

got a problem here.” It is the same kind of thing that

was discussed in the CAIB report. You’ve got people

who are afraid that they are wrong, and they don’t want

to be embarrassed in front of their peers. That’s why at

Goddard we always insist that there are senior people

onsite, involved, and ready to act for all our launches to

make sure that no viewpoint gets overlooked.

This story, especially in reference to the CAIB report, 

reinforces the importance of establishing a culture that 

respects minority opinion.

Sure, because sometimes it’s tempting to ignore the

small voice. People get caught up in what I call “launch

fever.” Regardless of what’s going on, people just want

to launch. They get caught up in the quick tempo of

things during the countdown.

This discussion where I was able to elicit the

dissenting opinion took place only an hour before

launch—which is the height of “launch fever.” It was a

case where senior management had to step in and make

a decision. So I decided to stop the launch.

You’ve been involved with almost sixty launches, over 

half of which were at Goddard. Were there any other 

times when you had to make the tough decision of 

postponing a launch?

Another situation was a NOAA launch some years

ago. It was an entirely different situation, but as we

prepared for launch, there were issues that needed to

be resolved.

During launch countdowns, I typically keep five

or six channels open so I can hear what is going on

across the board. Those almost sixty launches you

mentioned have taught me that when everything is

going well, the net is really quiet. When things aren’t

going well, people are talking constantly. In this

particular case, there was chatter all over the place.

As the countdown continued, it only got worse. It

got down to about ten minutes, and I just had a gut

instinct that we needed to stop the launch and assess

where we were. So I did.

We fixed our problems and launched the next

night without any issues. It’s tough, but as a manager

you have to hold out against “launch fever.” I have

a motto I follow, which I’ve adopted from the wine

industry: “No launch before its time.”

What can you conclude from these cases regarding risk 

and decision making during a launch?

It is a real fallacy that it is possible to drive risk to zero.

Anybody who thinks thatthere is no risk in this business,

has never worked in this business. Everything we do has

residual risk associated with it. Senior Management has

“ I will take real, live 

experience any day 

of the week over 

a textbook, or 

classroom-type 

training.”

44 appl the nasa academy of program and project leadership

interview CONTINUED
to make judgment calls. They have to ask, “Is the risk

low enough that we can go forward with this? Do we

have a reasonable chance at being successful?”

For example, in a perfect world, people would say

that you don’t launch until you find the flashlight. But

we held a full investigation: tracked people down as far

as Holland, looked at photographic evidence—even

checked the trash dump to see if we’d accidentally

thrown it away. The spacecraft was the size of a small

school bus, and the flashlight was a little penlight.

When it came down to it, I thought the evidence was

overwhelming that the flashlight was not on the spacecraft, so I decided to launch.

Your decision turned out to be the right one, since the 

launch was ultimately a success. Have you ever made 

decisions on a project that you later wished you’d done 

differently?

Yes. There was a program called the Advanced Airborne

Flight Experiment Program (AAFE). I proposed an

aircraft instrument development effort, it was selected,

and it came out very well. Then I proposed to augment

the system. It is, in my opinion, one of my more notable

career failures that I could never get this augmentation

to work.

Probably what happened is that I was so deep in the

forest that I couldn’t see my way out for the trees. I really

needed somebody to have said, “Give it up. This is good

money after bad. You’re not going to get anywhere.”

Then again, I don’t think you can become a topnotch project manager who is recognized as somebody

to emulate without having made some mistakes. A

classroom definitely doesn’t provide everything you

need to know to be a good project manager.

What kind of role, then, do you think that training and 

certification of project managers plays?

I will take real, live experience any day of the week over

a textbook, classroom-type training experience. Don’t

get me wrong: Training has its place. It’s important,

there is no doubt about that. But you can’t become a

project manager by going to a class. There has to be

a balance.

Is there an Apprentice Program at Goddard so people 

can get that important hands-on experience?

We are part of NASA’s Summer High School

Apprenticeship Research Program (SHARP) which allows

students the opportunity to become apprentices to scientists and engineers at various centers across the country.

Goddard Space Flight Center’s launch phase simulator.

ask 21 for practitioners by practitioners 45
For our in-house employees, the kinds of experiences that build good project managers are different for

each person. Sometimes we let people learn on smaller

projects as a training ground. Or we might let them

work on a larger project, but under a more experienced

Project Manager.

They’ve got to have the opportunity to learn the

whole experience. I think we grow people at Goddard

very well, partly because we have so many opportunities

for our people. At any given time we have about three

dozen missions in formulation, two dozen in active

development, and another couple of dozen in operations. There is a wide breadth of activity here. The

main thing we’ve tried to continually work on is to

grow people into being able to successfully assume

positions associated with all stages of a project.

Do you think that it is important to have an open-door 

management style so that people can get the support they 

need beyond training an experience?

Absolutely. And then it’s the management’s job to

provide the support needed along those lines. I never

turn down requests for that kind of consultation, and

people know I’m willing to do that. When people give

me feedback about how my advice helped them, it

reinforces my motivations for giving it.

Not too long ago there was a person who came to

me that was interested in becoming a project manager.

I told him that I didn’t think he was ready. I said, “I

just don’t think you’ve had the right experiences yet to

be put into that position.” So I told him I’d like him

to be a Deputy Project Manager on a larger project

than the one he wanted to manage himself. I said, “Do

that for a year or two, and we’ll talk about a project

management assignment.”

That’s an important management role: evaluating

people and assessing their needs and capabilities, and

then placing them in a situation where they can get the

necessary tools and experience.

When you think back on your career at NASA, can you 

think of anyone who mentored you?

Well, I came to NASA right out of high school. I had

no interest at the time in going to college, so I went

into an Electronic Technician Apprentice Program.

I did well in the program, and I got noticed by the

Wallops Flight Center Director at the time, Bob Krieger.

He encouraged me to go to college and helped

me understand the importance of an education. I

completed the Apprentice Program and got an electrical

engineering degree from Virginia Tech.

When I got back to Wallops, Bob Krieger was still

the Center Director. Around 1970, he set up a small

group to do space-borne radar development. Back then

Wallops didn’t do a lot of development work, but he

saw some opportunities there and knew he had people

whose talents could be directed towards it.

I was only six months out of college, and I got

in at the ground floor of this group. We build three

successful space-borne radar systems before I left

Wallops to go to NASA Headquarters. For me, Bob

Krieger was the most instrumental person in my career.

I’ve had other folks who have played a significant role

in advancing my career, but without Bob Krieger, it

wouldn’t have mattered. He took an interest in me and

spent the time to help me understand my potential.

Is there a specific moment that you remember about your 

first job in a project management capacity?

When I was at Wallops, I was Experiment Manager

for the SeaSat Radar Altimeter, which launched in

1978. I was sitting here at Goddard in “Building 14” at

a console in the Control Center on the second floor.

I gave the command personally to turn this particular

instrument on, and then all the various parameters

came up on the screen. It worked, and I was elated.

It was an experience I’ll never forget. •

The Aura Launch at Vandenburg Air Force Base.

46 appl the nasa academy of program and project leadership

interview CONTINUED

46 appl the nasa academy of program and project leadership
Shared Voyage: Encouraging Unlearning

In recent years, more and more leaders

of private and public organizations alike

have realized that knowledge is the chief

asset of organizations and the key to

maintaining a sustainable and competitive advantage. Organizational learning

means the continuous acquisition and testing of experience and the transformation of that experience into

knowledge that is made accessible to everyone within

the organization.

However, creating a “learning organization” is only

half the solution. In addition to the familiar “learning

curve,” companies should establish a “forgetting curve,”

which is the rate at which a company can unlearn those

habits that hinder future success. Pursuing unlearning,

however, is not easy. First, very often people are simply

unaware of the need to unlearn (e.g., they are unaware that

the old assumptions regarding the world have changed),

and, second, it is always difficult to undergo a change.

The following examples, taken from Shared Voyage,

show just how difficult it can be. Shared Voyage: Learning 

and Unlearning from Remarkable Projects focuses on

four projects: the Advanced Composition Explorer 

(NASA), the Joint Air-to-Surface Standoff Missile 

(U.S. Air Force), the Pathfinder Solar-Powered 

Airplane (NASA), and the Advanced Medium Range 

Air-to-Air Missile (U.S. Air Force). Each project is

presented as a case study comprises stories collected

from key members of the project teams. The book

which was co-authored by A. Laufer, T. Post and

E. Hoffman, was recently published by the NASA

History Office. One of the main objectives of the book

is to encourage unlearning of outdated concepts.

Sometimes it takes another person to help you

change your mind-set. During the integration and test

phase of the Advanced Composition Explorer (ACE)

project,the Applied PhysicsLaboratory (APL) fell behind.

NASA Project Manager Don Margolies thought that the

way to deal with it was to order their team to work either

weekends or double shifts. But Mary Chiu, APL Project

Manager, was steadfastly opposed to telling her people to

work overtime. Her people were salaried, and she wasn’t

going to order them to put in more hours.

They argued about it for a while, finally asking the

Chief Engineer at APL to join them for a meeting of

minds. Don hoped that meeting would not turn into

a very divisive discussion. What happened instead was

that Mary pointed out something to Don that he realized

should have been a no-brainer. In fact, it was then so

obvious to him that he was embarrassed that he hadn’t

realized it himself. “All we have to do is make it known

that we are behind schedule,” Mary said. “Professionals

don’t have to be reminded that they have a job to do...

they will rise to the challenge on their own.”

Realizing she was right, Don went back and told

NASA management what Mary had said. She couldn’t

put the extra hours on the schedule, but she’d assured

him that the work would get done. Ultimately, they

recovered the lost time. Don knew that Mary had taught

him a lesson in basic psychology: it’s always better to let

people come up with a good idea and implement it, than

for you to force it down their throat.

At times, the role of leaders is to help their team

change their mind-set. During source selections for

the Joint Air-to-Surface Standoff Missile (JASSM)

project, Air Force Program Director Terry Little told

the team that he wanted this phase to be completed

in six months. Truth be told, he would’ve been happy

with seven, or even eight—but he wanted to set almost

unrealistic goals. Why? “I didn’t want a schedule

that the team felt they could achieve just by working

weekends or figuring out a handful of inventive ways

to do things,” he said. “I wanted something so outrageous that it would cause them to at first, give up—and

then, to step back and examine their assumptions, their

beliefs, everything they’d learned from past experiences

and ask themselves with a clean slate: what do I really

need to do to achieve this goal?”

And that’s exactly what they did. The team actually

completed the source selection in five months. “When

we talked about it afterwards,” Terry said, “the team

discovered that they hadn’t known how capable they

ask 21 for practitioners by practitioners 47

from the editor-in-chief Dr. Alexander Laufer
could be if they just quit thinking about things in the

way they had always thought of them.”

Of course, sometimes teams are not ready to think

of things in new ways. The Advanced Medium Range

Air-to-Air Missile program had been around for 20

years, and Program Director Judy Stokley knew it was

time for a major reform.

It wasn’t easy because of the type of partnership her

team had with the contractor. If the contractor needed

to change something, he had to submit an Engineering

Change Proposal, and the government had to approve

it. The contractor documented every change in parts,

down to the lowest-level nut, bolt, or screw, and sent

change proposals all day long. The government paid

him to make those changes, or they didn’t get done.

Judy used to say, “If I want my contractor to flush the

toilet in Tucson, I have to write him a contract letter

and pay him to do it.”

She wanted very much to change that mindset,

and get the contractors to have a “heart and soul”

relationship with their products. If they could write a

good, simple set of performance specifications that the

contractor would control, and the government would

pay a fair price for the product, Judy believed it could be

a win-win situation for both sides.

But she also didn’t want any claims against her.

The program had been under litigation for one thing

or another since it started. When Judy took over as the

Program Director, there were twelve standing requests

for equitable adjustment filed by the contractors. She

told the contractors straight out that she couldn’t team

with people who filed claims against her. She told them,

“I’m going to help you pay for everything, I’m going to

help you make a decent profit, and you are going to

make sure that we have a good product out there.”

At a meeting, she laid out all her plans for reform

to the contractor, and at first she was met with a lot of

nodding heads. Then, the contractor’s Chief Engineer

stood up and addressed his Vice President, “Boss, I’ve

got to make sure that before you agree to this, you

understand what she’s saying. Because if you do, I don’t

think there’s any way you’ll agree to it.”

That’s when the room became extremely tense.

“Right now,” the same contractor continued, “if we

change something, the government pays. She’s telling

you that from now on if we change something, we pay.”

From that moment on, it was clear that the contractors

would not embrace any type of change. Judy felt the urge

to laugh out loud; the attitude of those in the room was

indicative of the same problems plaguing the industry.

Then, as a result of a merger with another company,

the Vice President was replaced. The new leader was

able to see the opportunities of Judy’s reform plans, and

together they transformed the mind-set and behavior of

their teams.

Even though it may be difficult to convince others

to “unlearn” old habits, the hardest thing can be

to “unlearn” your own. In this issue of ASK, John

DelFrate’s article mentioned former AeroVironment

Project Manager Ray Morgan and his struggle to

overcome his tendency to micromanage. After managing

a solar-powered flight project on which the young test

pilot was nearly killed, Ray says he became “exactly the

kind of boss that I said I would never be.”

Staying on at AeroVironment, he was working

what should have been “the ultimate job.” And yet some

days he felt so much stress on the drive to work that he

almost threw up. He tried to control every aspect of his

projects, working up to 100 hours a week himself, and

killing the morale of everyone he worked with. He had

to control everything; nothing happened without his

approval. People who had been so grateful to come to

work for him were burned out in two or three years. He

knew he’d have to either quit or find a solution.

Around this time, Ray’s wife saw a PBS special on

Edward Deming, who had a revolutionary approach

to management. He talked about incorporating “The

Golden Rule” and the Scientific Method into your

style. It was the first philosophy that really spoke to

Ray, so he decided to take a night class at UCLA on

the same topic.

He saw his professor’s teaching style that utilized

the brains of the classroom, and he began to reflect

on how he could do this within his own projects. He

began the difficult task of “letting go” and admits that

at first it was terrifying. But by the time he joined the

ERAST team to develop Pathfinder, he says, “I was not

only a different man, but a better manager. I had finally

begun to be a leader, and was leading my division in a

transformation that enabled me to draw full value from

all of the brains of my workforce.”

Whether the concepts conveyed through these

examples call for learning (that is, adding on new

concepts), or for unlearning (that is, letting go of some

old concepts), depends to a great extent on the set of

beliefs that the particular project participant (or reader)

has developed throughout his/her experience. One

thing, however, is clear. Today, in our competitive and

dynamic environment, everyone is expected to unlearn,

and quite often. New ideas are breaking traditional

molds and updating old axioms: “Live and unlearn.”

“Gone and forgotten.” •

48 appl the nasa academy of program and project leadership

from the editor-in-chief continued

www.nasa.gov

Explore. Discover. Understand.

NP-2005-05-404-HQ