appl.nasa.go appl.nasa.gov

Academy Sharing Knowledge

The NASA source for project management

INTERVIEW

Tom Gavin

Inside

HANDING OFF A PROJECT

DELIVERING ON TIME

MANAGING CULTURE

A PM DEVELOPMENT PLAN

ASK Magazine • Issue Seventeen

APRIL 2004
I walked around and talked to the people working on the project,

so that I could find out what they needed. Budget, schedule,

and technical issues were all-important, but what often gets 

overlooked is how you get a team to work together.

— Ken Lehtonen, from his “Right On Time, Radically” (p. 6)
appl.nasa.gov

Table of Contents

ASK 17 April 2004

STORIES

6 Right On Time, Radically

I could literally hear the team’s cohesiveness. It was something of a mystical moment 

BY KEN LEHTONEN 

10 Radical Is Temporary

We achieved a remarkable level of productivity and quality during the time we developed 

the new code BY LARRY BARRETT 

14 Walking a Fine Line 

When things got behind schedule the instrument manager didn’t have the experience 

to know what was needed to catch up BY MARY BOTHWELL 

18 Sounds Clear Enough

There’s a reason that project management is a full-time job BY ALAN ZAK 

22 Bringing Up Baby

It was going to require a delicate touch for me to step in and help him understand 

that this was what was best for the project BY ANGELO (GUS) GUASTAFERRO 

FEATURES

26 Transition Time: Zero

The project manager of one of our biggest projects had requested to be removed 

from the job immediately BY W. SCOTT CAMERON 

28 Passing the Baton—Lessons in Regret

I had failed miserably in preparing the way for my inevitable successor BY TERRY LITTLE 

SPECIAL FEATURE: 

APPL’S PROJECT MANAGEMENT DEVELOPMENT PROCESS 

29 The PMDP Roadmap

In addition to what I’ve gained through the curriculum and hands-on experience,

I’ve benefited from all of the people that I’ve met through the process

PRACTICES

32 Managing History: A Practicum

Roger was very good about offering to help after he left. Sometimes I turned to him 

to ask his advice on situations BY STEPHEN J. GARBER

INTERVIEW

35 ASK Talks with Tom Gavin 

More than 40 years after he began work as an engineer at the Jet Propulsion Laboratory,

Tom Gavin shares some of his project management lessons learned

IN THIS ISSUE • 3

What Makes a 

Good Manager?

BY TODD POST

REVIEW BOARD • 4

FROM THE DIRECTOR’S DESK • 5

Well on Our Way

BY DR. EDWARD HOFFMAN

LETTER FROM THE 

EDITOR-IN-CHIEF • 40

Checkmate to Uncertainty

BY DR. ALEXANDER LAUFER

ON THE COVER The first-generation Rotor

Systems Research Aircraft
2 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

WELCOME TO THE ACADEMY OF PROGRAM AND PROJECT

Leadership (APPL) and ASK Magazine. APPL helps

NASA managers and project teams accomplish today’s

missions and meet tomorrow’s challenges by providing

performance enhancement services and tools, supporting

career development programs, sponsoring knowledge

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

other government agencies.

ASK Magazine grew out of APPL’s Knowledge

Sharing Initiative. The stories that appear in ASK are

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

primarily from NASA, but also from other government

agencies and industry. These stories contain knowledge

and wisdom that are transferable across projects. Who

better than a project manager to help another project

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

small projects—they’re all here in ASK.

Please direct all inquiries about ASK Magazine editorial

policy to Todd Post, EduTech Ltd., 8455 Colesville Rd.,

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

email to tpost@edutechltd.com.

APPL DIRECTOR AND PUBLISHER 

Dr. Edward Hoffman 

ehoffman@hq.nasa.gov 

EDITOR-IN-CHIEF

Dr. Alexander Laufer 

allaufer@eng.umd.edu

EDITOR

Todd Post

tpost@edutechltd.com

ASSOCIATE EDITOR

Jody Lannen Brady

jbrady@edutechltd.com

ONLINE EDITOR

Sally McKee

smckee@edutechltd.com

CONTRIBUTING WRITERS

W. Scott Cameron 

Terry Little 

Ray Morgan

Scott Tibbitts

EDITORIAL ASSISTANT

Michael Derocher

mderocher@edutechltd.com 

DESIGN

Hirshorn Zuckerman Design Group, Inc.

www.hzdg.com 

SENIOR PRINTING SPECIALIST

Jeffrey McLean

jmclean@hq.nasa.gov 

PRINTING

Fontana Lithograph, Inc.

STAFF

ASK ONLINE

http://appl.nasa.gov/ask
NOBODY WILL BE BLINDED BY THE BRILLIANCE OF THIS

insight: Projects often get into trouble because of how

they are managed. Sometimes they recover; sometimes

they don’t. When the reason they recover stems directly

from changes in management, that begs the question:

What happened?

We return to this theme over and over again in ASK.

You may recall these remarks by Dr. Charles Pellerin in

Issue 13, commenting on his tenure as NASA’s Director

of Astrophysics: “I was frustrated that I couldn’t anticipate and recognize the difference between project

managers who were going to succeed and project

managers who were doomed to fail. We could predict

things like sensor performance. We could understand

the detectors. We could understand the power systems.

But we couldn’t understand this one critical, invisible

piece: What makes a good manager?”

One approach to answering that question is by

looking at cases where project fortunes reversed

following a change in managers. In “Bringing Up Baby,”

Gus Guastaferro remembers being asked to take over a

research project in which the project manager he

replaced was also the lead researcher. To achieve the

promise of the prototype aircraft they were building,

Guastaferro not only had to overcome management

problems created by his predecessor, but to do it in such

a way that did not compromise research goals.

In another story, Alan Zak, a Vice President at

Line6, tells of selecting a project manager to produce a

new line of guitars. The project manager seemed to have

what it takes—the technical smarts, an interest in project

management, and, because he was a guitarist himself, an

intimate understanding of the product—but he quickly

found himself in over his head. Zak’s story, “Sounds

Clear Enough,” may well teach those a level or two above

the project manager about how to recognize a problem

situation before it unfolds.

Mary Bothwell’s story, “Walking the Fine Line,”

picks up this theme from Alan Zak, but depicts a

different approach to solve the problem. A division

manager at the Jet Propulsion Laboratory (JPL),

Bothwell was concerned that a change in management at

a critical point in a project could prove more destructive

than constructive. Bothwell’s story offers an interesting

look at the paradox of how to positively impact what’s

happening within the project from outside it. How

closely can upper management get involved before

“micro-management” sets in?

Managers change for reasons other than because

projects get in trouble. People move on to other jobs, or

they get promoted. In some of those cases, a project

manager’s job is simply to keep things on track. Such is the

type of situation described by Steve Garber in his practice,

“History: A Practicum.” Garber offers some practical

insights on how to be a more effective communicator.

In addition to all this, we have an interview with

JPL’s Director of Flight Projects, Tom Gavin; a before

and after story about a reengineering effort at the

Hubble Control Center; and feature writers Terry Little

and Scott Cameron return after getting a rest in Issue 16.

The APPL spotlight this time is on the Project

Management Development Process (PMDP). You may

be surprised to find who’s talking up PMDP at NASA.

While we may not have the definitive answer to “What

makes a good manager?”—we believe this issue of ASK

will contribute to your conversations about that subject. •

What Makes a Good Manager?

This issue of ASK we look at several projects that recovered from serious

problems after a critical change was made in how they were managed 

IN THIS ISSUE Todd Post

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

REVIEW BOARD

JOHN BRUNSON of the Marshall Space Flight Center is a

member of the NASA Program Management

Council Working Group. He served as project

manager for three separate microgravity

payloads that flew on various Spacelab

missions. His career in the space industry began

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

DR. MICHELLE COLLINS works in the Spaceport Engineering

& Technology Research Group at Kennedy

Space Center. She has over twenty years

experience in aerospace spanning engineering,

R&D and project management. She is on the

Florida Tech Engineering Accreditation Board,

the National Fire Protection Association’s Technical Committee

for Halon Alternatives, and the United Nations Environmental

Programme Halon Technical Options Committee.

HECTOR DELGADO is Division Chief of Process Tools and

Techniques in the Safety, Health and

Independent Assessment Directorate at the

Kennedy Space Center. In 1995, he served as

Senior Technical Staff to the NASA Chief

Engineer at NASA Headquarters in Washington,

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

Exceptional Service Medal, Silver Snoopy Award, and various

achievement awards.

DR. OWEN GADEKEN is a Professor of Engineering Management

at the Defense Acquisition University where he

has taught Department of Defense program

and project managers for over twenty years. He

retired last year from the Air Force Reserve as a

Colonel and Senior Reservist at the Air Force

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

management conferences and symposia.

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

Jet Propulsion Laboratory (JPL). He is project

manager and a co-investigator for the Mars

Environmental Compatibility Assessment

(MECA). In his previous assignment with

NASA’s New Millennium Program, he was

instrumental in defining the “microlander” that was adopted as

NASA’s New Millennium Program Deep Space 2.

JODY ZALL KUSEK is a Senior Evaluation Officer at the World

Bank. She is currently involved in supporting

the efforts of seven governments to move to a

focus of performance-based management. She

has spent many years in the area of public

sector reform, serving the Vice President of the

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

Secretary of Energy in the areas of Strategic Planning and

Performance Management.

DONALD MARGOLIES retired from the Goddard Space Flight

Center in January 2004. He was Project

Manager for the Advanced Composition

Explorer (ACE) mission, launched in 1997 and

still operating successfully. He received the

NASA Medal for Outstanding Leadership for

his work on ACE and a NASA Exceptional Service Medal for

the Active Magnetospheric Particle Tracer Explorers (AMPTE)

mission.

DR. GERALD MULENBURG is the Manager of the Aeronautics

and Spaceflight Hardware Development

Division at the NASA Ames Research Center.

He has project management experience in

airborne, spaceflight, and ground research

projects with the Air Force, industry, and NASA.

He also served as Executive Director of the California Math

Science Task Force and as Assistant Director of the Lawrence

Hall of Science.

JOAN SALUTE is the Associate Director for projects in the

Information Sciences and Technology Directorate

at Ames Research Center. She has managed many

NASA projects including those involving flight

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

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

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

attend Stanford Graduate School of Business.

HARVEY SCHABES is currently assigned to the Systems

Management Office at the Glenn Research

Center. He started his career with NASA in

icing research, and since then has served in

numerous organizations in support of the

Space Station Program.

CHARLIE STEGEMOELLER is Manager of the Johnson Space

Center (JSC) Human Space Life Sciences

Programs Office. He is responsible for the

programmatic and tactical implementation of

the lead center assignments for Space Medicine,

Biomedical Research and Countermeasures,

and Advanced Human Support Technology. He began his

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

technical program analyst.

HUGH WOODWARD is a Program Manager for Global Business

Services with the Procter & Gamble Company.

He served as the Chairman of the Project

Management Institute (PMI) for consecutive

terms in 2000 and 2001. He was elected to the

Board of Directors in 1996, and before being

elected as the chair, served terms as vice chair and in several

other key leadership roles.
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 5

I INDICATED THAT IF THE ACADEMY OF PROGRAM AND PROJECT

Leadership (APPL) was going to significantly improve

program and project management at NASA, we needed to

expand our portfolio of services, including resources that

go directly to the project. “We need to be sending experts

to the projects, experienced project practitioners, who can

respond to the needs of the project manager,” I said.

Tony smiled and said, “Okay, I know where you’re

going with this. But if we do what you want, we need to

do it right. I don’t want us to offer willy-nilly, do-whatyou-want, feel-good stuff that costs a lot and makes

absolutely no difference to a project.”

I laughed because I knew exactly what he meant. I

related a story of mine from nearly twenty years earlier:

In the mid-80s, I was responsible for providing

organizational development support to NASA project

teams. I was preparing to work with a new team and was

conducting general interviews of the “what is working,

what is not” variety. A young woman seemed nervous

about an upcoming retreat, and I asked about her

concern. She blushed and asked me, “When we’re at the

retreat, will we have to talk to a banana?” I had been

prepared for many things in my doctoral program at

Columbia University, but they never told me how to

respond to the banana question.

She was serious. At a previous retreat, the facilitator

had her team talking to bananas: “Speak to the banana

as you would a new person joining the team...”

Tony laughed at the story and said, “Exactly; if we’re

going to support project teams, let’s do it in a way that

makes a clear difference.”

While a training director in the Navy, Tony had been

responsible for establishing rapid response support

capability. His successful experience then provided us with

many lessons that we could use in our current situation.

We outlined how we wanted to do this: First, we

would gather a team of expert practitioners with top-gun

status. I’m talking about experts with the ability to

address all aspects of a project during any phase in its

lifecycle. Second, we would work only to improve project

capability and competence—we were not going to

supplement project staffing. Third, we would show we

were serious by responding within 48 hours to any

request for our support and by following through on

requests only when the project manager and team were

committed to change.

Moreover, we didn’t want to impose another layer of

bureaucracy on projects, so we needed to establish simple

procedures for obtaining our support. We also felt we had

to measure project improvement in real terms, with data

that could stand up to scientific scrutiny.

That was the foundation for APPL’s Performance

Enhancement business line, which presently accounts for

just over half of all APPL business. Entering 2004, we

were supporting 29 program and project teams in such

areas as program control, project planning and scheduling, systems management, risk management, project

leadership, and culture/team improvement. Each project

has been tracked with specific measures to indicate the

value of our support. I have seen the initial measures and

we will soon be unveiling findings indicating statistically

significant improvements that should lead to wider

discussions of how to develop and improve project teams

and individuals.

It is exciting and gratifying to see and hear the

reaction of the NASA project community who has used

these services. Based on customer reaction, increasing

demand, and measurement of results, I think we’re well

on our way to improving project management at NASA.

And no one has to talk to a banana. •

Well on Our Way

A couple of years ago, I was sitting in my office talking with my 

Deputy Director Tony Maturo. We were in a contemplative mood,

discussing NASA’s then-recent run of prominent project failures

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

BY KEN LEHTONEN
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 7

NASA GODDARD SPACE FLIGHT CENTER WAS NO

exception to that rule. Some folks in upper management

wanted to take advantage of this new paradigm and they

turned their attention to the Hubble Space Telescope

ground system. The objective was to reduce the

operating cost of the system by at least 50 percent. This

was a noble objective, as Hubble would likely be around

for another ten to fifteen years at least.

When I first was approached by my branch head

with the opportunity to lead this reengineering team, I

said, “Well, that sounds good. I’ve done one of these

before, and it sounds like a good challenge.” So, she put

me on the project. What she didn’t tell me was that I was

the third person to lead the reengineering effort. The

people before me hadn’t seen much success.

When I came on the project, I spent some time

getting a feel for the place and what the major issues

were. I didn’t try to reach conclusions about the hard

decisions facing me right off the bat. Though people

introduced me as the new project lead, I tried to stay in

the background at first. This gave me the opportunity to

observe what was going on and think about how I might

need to change things.

The first thing I noticed was there seemed to be a

lack of cohesion, or “culture.” We didn’t have any

government on-site management; we had a consultant

running the day-to-day activities. This person knew

what he wanted to do, but he didn’t seem to know how

to go about it. We had a number of prototyping activities

underway, but they seemed unfocused. In fact, it seemed

more like a technical playpen than a project. The only

schedule we had was a February 1997 deadline for

completing the system update before the next Hubble

servicing mission. Overall, the project simply needed

better structure, methods, and processes.

Though we were tasked with reengineering an old

system, the project team largely consisted of people left

over from the original system development. At that time,

Hubble senior management felt that the reengineering

effort could be completed with the legacy staff alone.

This assumption later proved to be erroneous.

This is what I inherited in March of 1996 when I

came on board.

PROJECTS ARE PEOPLE

Yes, we had technical issues to address, but I concluded

that I needed to concentrate first on the team itself if we

were going to succeed. That was a strength that I think I

brought to my role as project manager. In my work on

past projects, I felt that was where I had contributed the

most, and I knew that I had good technical people on this

project who would handle that side of the house for me.

The project team had an alarming rate of attrition. I

realized quickly that people were leaving out of frustration because they sensed a lack of direction. They felt

that the management style of the consultant who had

been in charge was obstructing, rather than enabling,

work. One of the first things I did was to fire him.

I was able to convince our primary stakeholder that

the project wasn’t going to succeed with just the legacy

people we had in place. She said, “Fine—go off and hire

some new people; do whatever it takes.” I managed to

bring in about fifteen people who had worked for me in

the past, which allowed me some flexibility to start to

fold and mold the project the way I felt it needed to be

BACK IN THE EARLY 1990s, REENGINEERING WAS ALL THE RAGE. ALL OF THE CORPORATIONS AND

THEIR CEOs GOT EXCITED ABOUT THE PROSPECT OF HAVING TO STREAMLINE AND REORGANIZE,

REENGINEERING THEIR ORGANIZATIONS IN AN EFFORT TO IMPROVE THE BOTTOM LINE.

BUDGET, SCHEDULE, AND TECHNICAL

ISSUES ARE ALL-IMPORTANT, BUT WHAT

OFTEN GETS OVERLOOKED IS HOW YOU

GET A TEAM TO WORK TOGETHER.

The Hubble Space Telescope offers scientists a glimpse of star

formation within the Omega Nebula.
8 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

in order to get our work completed. The remainder of

the revamped staff was provided by existing Hubble

contractors, cold interviews, and “word of mouth.” At

the peak of the project, we had over 150 people from

fifteen different companies, plus NASA civil servants. It

was a diverse group of people—from old to young and

everything in between—and we were co-located, which

was a good idea.

I wanted to create a “badgeless” team. I

know the word gets thrown around frequently,

but we took it to extremes. Since we were colocated away from the main NASA Center,

Goddard, it was easier to do. We were able to

have people working together who hadn’t

worked together before because they were

from different contractors. In a couple of cases

we even had government people reporting to

contractors. In the past, their management had

said, “You can’t work together.” Well, we let

them work together. That was a start.

However, it wasn’t achieved overnight and

took a lot of energy and convincing by my

management team and me before it stuck.

We also flattened the organization. We got

away from the hierarchical approach. We

developed a series of product development

teams, who were tied into the architecture that

we developed. We then developed a work

breakdown structure to start putting some

process, structure, and schedules in place. The

rewards quickly came; we started to look and

feel like a cohesive project.

As we did this, I walked around and talked

to the people working on the project, so that I could find

out what they needed. Budget, schedule, and technical

issues were all-important, but what often gets

overlooked is how you get a team to work together. How

do you create order out of chaos? I hoped we could

create, over time, a tight-knit community much like the

old Cheers slogan, “A place where everybody knows your

name.” One of my earliest initiatives to accomplish this

was to have biweekly barbecues, which allowed folks to

have a place to unwind a bit and to talk about things that

had nothing to do with work. The idea was that in six

months, when they would be delivering key components

in a stressful integration environment, there would be an

esprit de corps to carry us through those difficult times.

Another of my initiatives I called the “kudos”

program. After each major release produced by the team,

I made a trip to my local grocery store to stock up on

about twenty boxes of Kudos® bars. Then, I went to each

individual personally and congratulated him or her on his

contribution to our work. I would do that for all 150

people. This became something of an “end job,” if you

will, or an in-process, as far as the relationship that I had

with my team. In fact, people started bringing me coupons

for the next round of Kudos that I would be buying.

WE SEE RESULTS

Did it all work? I find it interesting that near the end of

the summer, a little less than six months since I’d arrived,

I was sitting quietly in my office, which was centrally

located and always open, when I became aware of the

hum and the vibration of energy out in the hallways. I

could literally hear the team’s cohesiveness. It was

something of a mystical moment, I suppose, because I

knew then, without a doubt, that the project was going

to succeed. I was convinced of it based on the energy

flow, the pulse, and the conversations that were

occurring in the hallways on this particular day.

In retrospect, when I look back on what was

happening there, I can see that we had become the

badgeless team I was aspiring for. We had gone from a

hierarchical, structured environment, to teams who

THE MISTAKE OR CERTAINLY THE LESSON I LEARNED

HERE IS THAT ONE NEEDS TO CONTINUE TO MANAGE

EXPECTATIONS TO NEXT-GENERATION STAKEHOLDERS,

AND TO DO IT RIGHT AWAY.

Mission accomplished: the Hubble Space Telescope as seen by

the Space Shuttle Discovery after servicing in February 1997.
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 9

had the trust, confidence, and openness to stop in the

hallways to discuss problems and make decisions

without having to worry about any repercussions if

they didn’t pass everything through their management

team each time.

An interesting side note to all of this was that over

time the vocabulary of the project changed. Initially,

there was a lot of “I” and “you.” Over time, we noticed a

subtle shift in the vocabulary to “us” and “we.”

Not only did we meet our original milestone, but we

had five major releases completed on time and on

schedule. During that period, we delivered over one

million lines of code. We were producing something on

the order of fifteen lines of code an hour, where the

accepted norm is closer to five. Our defect metrics were

a third of the normal industry rate. This seemed great to

me, but I wanted to be certain these metrics were real.

I went to a group at Goddard who study software

development. I asked them to take a look at the code we

had produced. They spent a couple weeks analyzing our

work, and came back and said that our team’s work was

some of the best they’d ever seen. So, technically, we

were in good shape, which was what I figured.

What about programmatically? Maybe there is a

direct correlation between high technical productivity

and the type of organization and team that you put

together. That would be nice to know. I got hold of

another group who was putting together a project team

development survey. I said, “Why don’t you take a look

at our team? Come on over and give the survey to our

team.” We did that for a couple of days. They came back

and said, “We have ten major criteria for very high

successful teams. The average that we’ve seen so far is

about three. Well, you guys have seven.” Even programmatically, we were off the charts.

MANAGING EXPECTATIONS

Despite all of the success that I’ve talked about, in

August of 1998 I was replaced. We had a release due in

June of that year, which we delivered on time and on

schedule. Two months later, an organizational chart

appeared, and I was gone.

What happened is that the original stakeholder—

the key supporter of the “radical management”

philosophy—retired. New stakeholders came in,

including a new program manager who had a

background in management rather than systems. I

didn’t think much about the change in stakeholders

until the day my new boss came in and said, “We’re

going to review why you have failed to deliver; the

project is now in stand-down mode.” Evidently, there

was a disconnect between what we had been asked to

deliver by our former stakeholder, and what our new

stakeholder expected to find. The mistake or certainly

the lesson I learned here is that one needs to continue

to manage expectations to next-generation stakeholders, and to do it right away. Don’t assume that they

know what you know.

Perhaps I could have done a better job in presenting

the case for our project team to the new stakeholders. If

I had done a better job bringing my key people in to

meet the stakeholders—presenting what we had done

to-date, what the challenges ahead were, how we had

accomplished what we had, and how effectively we

worked—perhaps they might have had second thoughts

and would have allowed us to continue.

I’m not convinced that would have helped, though.

It was clear that their expectations were very different

than my expectations. They wanted to go back to the old

way of doing business, one they felt comfortable with,

specifically with the prime contractor managing a more

traditionally structured project team. If the change had

occurred a few months earlier, it would likely have had a

devastating effect on productivity levels—but the change

came when our initial development phase was almost

completed.

In retrospect, I can see that the project had reached

a point where exceptional productivity wasn’t the

highest priority anymore. We’ve all heard, again and

again, that you have to know when things are good

enough. It’s true in engineering—we don’t put twentynine bolts in where we need twelve—and it’s true in

project management. •

LESSONS

• Nurturing a collaborative culture on a project can 

go a long way towards achieving tangible costs and

schedule results.

• Manage expectations, not only from the people

working for you, but for the key people, i.e. stakeholders,

that are above you.

QUESTION

When would you prefer the collaborative leadership style

depicted here, and when not?
10 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

BY LARRY BARRETT
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 11

THE ANALOGY I USE TO DESCRIBE HUBBLE IS A DATA

factory, and we provide the factory controller. The

telescope takes in light and produces pictures, and we’re

the ones sending all of the control signals and

monitoring the temperature, power, and voltages in the

factory to make sure the production line is doing its job

and that it’s not reaching some sort of a stress point.

That’s basically it. We maintain the Hubble command

and control system.

I think we’re still putting out a good quality

product. We still meet our schedule and cost milestones.

Every time we make a change to the ground system, we

run a suite of tests to make sure that the system still runs

as expected, and that it correctly controls the spacecraft.

Other than that, provided the interfaces are controlled,

everything is okay.

BUT BEFORE THIS

As Ken was saying, we achieved a remarkable level of

productivity and quality during the time we developed

the new code. In my experience, it was exceptional—and

it was something I hope to see repeated.

What made it work so well? For one thing, we had

a stakeholder who decided that Hubble needed a new

ground system, and she was willing to do whatever it

took to get it done quickly. To achieve this goal, she was

willing to allow Ken to run things the way he wanted to,

including demolishing a hierarchical decision structure.

From my perspective, any project demands a bounty of

decisions to be made in a proximate order. What we

were trying to do on this project was to get those

decisions made not only well, but also quickly.

All swords have two edges. In the flat organization

you can get decisions made quickly. Sometimes you are

missing information and have to go back and unmake

them, but in the long run I think you still save time. This

is definitely the way to go when speed is paramount. In

a hierarchical organization, decisions have to go through

two or three levels of management to get approval. You

tend to defer decisions as long as possible so you get the

best answer with the most information. It takes longer,

but by the time the decision is made there is usually no

doubt that everyone has had a chance to comment.

Under Ken, instead of taking days or weeks to walk

up the chain-of-command with a here-is-our-recommendation presentation and to walk back down with a

here-is-our-answer document, everyone who had an

interest in the selection of this capability, or this

software product, sat down at one meeting and said,

“Okay here is everything that we know. Here is how we

want this thing to work. Here is how it fits in the

system.” In a two-hour meeting, an Integrated Product

Team of ten to fifteen people could come together to

make key project decisions.

Before Ken, I recall people quitting the project

because of the lack of progress. There were several

conscientious and technically competent people who

couldn’t deal with the lack of progress—feeling stalemated or blocked in our attempts to move forward. The

consultant who was leading the effort had assumed

absolute control, to the point that individual initiative

was actively discouraged.

Another reason for our change in productivity, I

believe, was that the culture of the organization was

completely revitalized when Ken took over. Meetings

I SUSPECT THAT EVEN IF KEN HAD STAYED ON, WE WOULD HAVE EVOLVED TO THE STATE WE’RE

IN RIGHT NOW. IN TERMS OF THE NATURE OF THE WORK THAT WE’RE DOING, WE’VE GONE FROM

DEVELOPMENT TO MAINTENANCE, AND SO THE PROJECT TEAM NEEDED TO EVOLVE TO REFLECT

THAT CHANGE.

WE JUST HAD TO BEAR DOWN AND DO IT,

AND THE ONLY WAY WE WERE GOING TO

GET THERE WAS BY WORKING TOGETHER.

The planetary nebula NGC 6751 puts on a show captured

by the Hubble Space Telescope on April 6, 2000.
12 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

were non-confrontational. Ken worked to make sure

they weren’t. Questions came up, but there were fewer

hostile challenges, like “Why the hell did you do that?”

The questions were more along the line of, “Well, what

else did you look at? Did you consider this?” This

cultural change wasn’t an easy thing to do, since it is

always easier to be a critic than a contributor.

We had one guy, in particular, who was an excellent

engineer, but who loved to play devil’s advocate. People

like that can play a useful role on a project, but he

simply came across as arrogant. People didn’t want to

talk when he was at a meeting. He impeded decisionmaking unintentionally, I believe, by intimidating

people into not expressing their views. If you have

someone who is constantly challenging a decision, you

slow the process down. As a result, Ken had him

removed from the project, which was probably the right

thing from a productivity standpoint. The skill was

there, but unfortunately his personality was damaging

to the group effort.

Ken didn’t allow any one individual to stand in the

way of getting the job done. We were in a phase where

we knew what we had to do: reengineer an existing

system. We just had to bear down and do it, and the only

way we were going to get there was by working together.

ONE PHASE ENDS

It is the nature of project work that teams evolve and

move on. As new development slowed, our budget and

staffing were reduced, and we went from 150 people to

around 40. A lot of the top performers gradually left the

project. With the technical challenges on the project

diminished, the need for creativity was no longer

paramount. You can’t keep highly enthusiastic people

around if there’s not enough for them to get excited

about. Many wouldn’t have been happy in a maintenance mode anyway.

In the transition from development to maintenance,

we also ended up losing many of those exceptional

characteristics of the project that enabled our high

decision rate and productivity. Had Ken stayed around,

we might have retained, who knows, more functionality

in the system. As it stands, we’re still doing some

technical upgrades because changes in the ground

system are needed to support servicing missions and

technology keeps changing, too. We try to fold in some

new products and new capabilities, as well as implement

some elements that were deferred earlier in the project

because they were too costly. (Today, products exist that

have made some of our former wish-list items feasible.)

In a few cases, products we originally used in the system

are no longer supported and must be replaced with

current technologies.

As Ken said, when our major stakeholder retired,

the new stakeholders didn’t have the same goals as the

old stakeholder. They weren’t willing to accept the risk

of keeping a radical project management approach in

place. We all have our comfort zones, and it takes a

great deal of courage to work outside of them. In all

fairness, “radical” was understandably less acceptable

in their career paths than it was in the career path of

our former stakeholder, who knew that her next career

move was retirement. We were lucky to have such a

stakeholder in place at such a critical phase of the

project’s life cycle. Could we have accomplished what

we did without the radical changes to our management

structure? I don’t think so.

We were on an aggressive schedule in development

and, in response, we took aggressive steps to achieve our

goals. A radical management approach may be

something you can only sustain temporarily. But I think

the results that came out of our experience on this

project demonstrate the potential impact of adjusting

management style to suit the real-time demands of a

project. Our real challenge is making that possible. •

LESSONS

• During a project life cycle, you must examine and

question what management approaches are appropriate

in the current phase.

• To get maximum value out of meetings, make sure

that the tenor of the group is cooperative enough so that

everyone feels like they can express their views.

QUESTION

For what type of decisions would you prefer a flat organization

with quick informal processes?
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 13

YE SHALL NOT BREAK HUBBLE

“On occasion, we would remind folks, ‘By the way, this is a $2-billion national asset, and if something fails, you’re going to get

more visibility and more attention than you ever wanted,’” says KEN LEHTONEN of the Goddard Space Flight Center. Making

certain that no one “broke” the Hubble Space Telescope may have been his primary responsibility—but Lehtonen was intent on

accomplishing far more than that. And as these stories attest, he indeed proved to be a talented “fixer” during his tenure as

project manager on the reengineering effort of the telescope’s control center.

In addition to managing the reengineering of the Hubble control center, Lehtonen has served as the project

lead on the development of the International Solar-Terrestrial Physics ground and science data processing

systems and, most recently, as the mission readiness manager on the Aqua, ICEsat, and Aura missions.

Lehtonen has more than 35 years of experience in software engineering, including 20 years of “hands-on”

experience developing software applications in the fields of orbit determination, image processing, real-time

data capture, and data communications.

LARRY BARRETT works for Orbital Sciences Corporation. He has more than 25 years of experience in all

aspects of the system and software engineering life cycle. For the past six years, he has been the chief

systems engineer for the Hubble control center system.

Lehtonen and Barrett’s stories in this issue of ASK are not the first time the two have publicly shared their

BARRETT experiences working together on the Hubble Space Telescope ground system. In 1999, they delivered a

paper, “Culture Management on the Hubble Space Telescope Control Center Reengineering Project,” at the

30th Annual Project Management Institute Seminars and Symposium, and earlier in 2004 they published an article, “Managing

a Product Development Team,” in Program Manager. Their stories in ASK were based on an August 2003 presentation at the

APPL Masters Forum.

Lehtonen can be reached by email at ken.lehtonen@nasa.gov, and Barrett at lbarrett@hst.nasa.gov.

LEHTONEN

OUR RESULTS DEMONSTRATE THE POTENTIAL IMPACT OF ADJUSTING

MANAGEMENT STYLE TO SUIT THE REAL-TIME DEMANDS OF A PROJECT.

Some 5,000 light-years away from Earth, funnels and twisted-rope structures form

the heart of the Lagoon Nebula, as seen by the Hubble Space Telescope.
14 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

My division was charged with building a suite 

of cameras for the Mars Exploration Rover

(MER) project. We were building the science

cameras on the mass assembly, the microscope camera, and the hazard and navigation

cameras for the rovers. Not surprisingly, a lot

of folks were paying attention to our work—because there’s really 

no point in landing on Mars if you can’t take pictures. 

IN SPRING 2002 THINGS WERE NOT LOOKING GOOD.

The electronics weren’t coming in, and we had to go back

to the vendors. The vendors would change the design,

send the boards back, and they wouldn’t work. On our

side, we had an instrument manager in charge who I

believe has the potential to become a great manager, but

when things got behind schedule he didn’t have the

experience to know what was needed to catch up.

As division manager, I was ultimately responsible for

seeing that all my project and instrument managers

delivered their work. I had to make the decision whether

or not to replace him.

Insight from oversight

After talking with the instrument manager’s immediate

supervisor, I could see that he was doing an excellent job

of keeping people motivated and working despite the

challenges. For the morale of the team, I decided not to

replace him—but I knew that he needed a little more

horsepower behind him.

I began working with the instrument manager 

and got the deputy section manager involved as his 

day-to-day mentor. The deputy section manager actually

took over running the schedule and realigned it to meet

the MER project’s needs.

I met with the instrument manager and the deputy

section manager every day for a while. We would go

around the table and discuss the schedule. We had it on

an 11x17 piece of paper that the deputy section manager

had put together. We went over every item. We would

say, “Okay camera number three—are you really going

into thermal vacuum today? Are you really ready to do

the calibration on camera number four today?”

With 650 people in my division, and a half-dozen to

a dozen projects to track at any given time, I don’t

usually get involved at this level on a project. I have

neither the time nor inclination for this sort of heavyhanded management, but because the cameras were so

important, I had to get involved.

The instrument manager probably felt bad for a

month, but he knew that changes needed to be made.

Let me make something clear here: We didn’t say,

“You’re doing a terrible job.” We never used words

like, “If you don’t get these things done, you’re fired.”

Walking a Fine Line

BY MARY BOTHWELL
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 15

MER project staff drive a rover over staggered

ramps in the laboratory to test the suspension’s

range of motion.

A landscape taken by the Spirit rover’s panoramic

camera stretches west towards hills named after the

Apollo 1 astronauts, who perished during a launch

pad test of their spacecraft at Kennedy Space Center

on January 27, 1967.
16 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

What we said at our meetings was more along the

lines of “We have a problem here, and we need to find

a way to succeed.”

Not only did I meet with the project team and

management, but every day I would walk around to

where members of the team were working and ask,

“How’s it going now? Did you get that answer yet?”

Because of that level of involvement, I knew what

the challenges were so that I could forecast where the

project might run into trouble. I am sure that I made a

few lives miserable during this time. There was a little bit

of, “Well, we really don’t have a problem. We’re going to

be able to fix this ourselves.”

But once they figured out they couldn’t get rid of me,

they became forthcoming about the problems. If I saw

someone in the hall and asked, “Hey how’s it going? Are

you there?” I began hearing,“Oh yeah, we’re there,” or “Oh

no, we didn’t quite make it and this is what we’re doing.”

After several months, I was able to ease up, but I

kept holding weekly meetings so that the team, down to

the floor-level technician, knew that I remained engaged

in the project. As a matter of fact, I remember that at one

of these meetings, one of the technicians looked at me

and asked, “Why are you pushing us so hard?”

I explained our position clearly to everyone at the

meeting: We were the “eyes” for the entire mission; it

would not and could not fly without our cameras. If we

fell too far behind on our schedule, we would drag the

entire project down with us. That technician didn’t

complain again.

Some people might think it courageous that he

questioned me that way, but one of the things that I’ve

always tried to do in my division is have an open door

policy. Everyone knows they can come and talk to me

about anything. They call me on the phone, and they

know I answer my own phone. If they send an email,

they know I’ll respond. They know that if they have to

see me and I’m not around, that my assistant will work

to find them time on my schedule.

We are tested

One of the things that I pushed the instrument

manager on was asking if the team had enough people

to complete the testing. We needed to do 24-hour

qualification soaks on the cameras in a vacuum prior to

science calibration. When we worked the schedule out

and worked out the staffing that was required and

looked at the two other projects that we had in thermal

vacuum at the time, we realized that there weren’t

enough people. Fortunately, we figured this out two

weeks ahead, and not when there was no one to take a

4 p.m. second shift.

For the morale of the team,

I decided not to replace 

him—but I knew that he

needed a little more 

horsepower behind him.

A rover sits at rest in the lab.

The MER mission’s “eyes,”

panoramic (Pancam) and

navigational (Navcam) cameras,

sit atop the rover’s white mast.

Spirit’s panoramic camera captures an image of

the rover’s landing site, the Columbia Memorial

Station at Gusev Crater.
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 17

We could have had the project team work 12-hour

shifts in order to cover the testing schedule. But I noticed

that we were starting to see them dragging, and they

were already under so much pressure that I was

concerned about them making mistakes. I decided to

take some of the shifts myself and I enlisted other

managers who were capable of doing this work—so that

we could give the team some relief during a time when

the testing was not critical. Everyone I recruited had

some past integration test experience.

My time slot was 4 p.m. to midnight on Saturday

and Sunday nights a couple of weekends in a row. You

have to rearrange your life to do this, but it’s absolutely

the right thing to do. We didn’t need to use the subject

matter experts.

It wasn’t technically challenging work, and much of

it was boring. You just sit there and take a measurement

once an hour. We simply needed someone who could

look at the scope and say, “It’s in-spec,” or “It’s out-ofspec.” If it was out-of-spec, you made a phone call and

found out what to do next. I made a couple of phone

calls on my shift when the temperature got a bit too high

or too low, and was talked through the process so that I

could adjust the temperature.

By offering relief to the troops at this point, they

were fresh for the part of the testing program where

their expertise was absolutely critical. That’s something

a project manager learns to do over time, and

something that a project sponsor should always watch

for. To ask, “Are we pushing our people too hard? Can

we come up with an alternative solution that will keep

us on schedule? Can we add outside people during

non-critical times? Can we tell people who need a

break to go home for the weekend?”

And in the end...

As we closed in on delivery, there came a point that my

interactions with the instrument manager were more

along the lines of, “Hi. How’s it going? We’re doing

such-and-such test? Oh, okay. How do the scientists like

it? Great.” Everything was just going fine.

While we never caught up to the original schedule,

the cameras were completed in time to be integrated

onto the spacecraft and rovers. The instrument team

delivered superb cameras that satisfied their customers,

the scientists.

After delivery, we had a party. We rented a bowling

alley, all of the lanes. Some of us threw strikes and some

of us gutter balls, but we bowled together all afternoon

and had a wonderful time. We had much to celebrate,

after all; the instrument manager and his team could feel

proud of what they’d accomplished.

We had the opportunity to celebrate those accomplishments, once again, after the successful Mars

landings—with all the world looking at pictures our

cameras had delivered.

LESSONS

• Project sponsors must be prepared to move from

monitoring to intervening when a project runs into

trouble. Timing is everything; a project sponsor must

recognize both when intervention is necessary and when

it is no longer needed.

• Effective managers demonstrate leadership by supporting

their teams—including managing-by-walking-around and

serving as a “soldier” when needed. •

QUESTION

How do you draw the line between destructive micro-management

and constructive, intensive help?

LOOKING BACK

Though she has years of experience

behind her, MARY BOTHWELL of the

Jet Propulsion Laboratory (JPL) hasn’t

forgotten what it was like to be a

young manager on a troubled project. “I got an

assignment to fly an instrument on the second flight of

the Columbia,” she remembers. “Right when everyone

thought that we were ready to go, we failed the preship review. It was probably one of the most miserable

periods of my life.”

The “misery” didn’t last, thankfully. When Bothwell’s

instrument went back in the thermal vacuum for

testing, the team was able to “prove the problem wasn’t

a problem.” The instrument was shipped, and it flew—

ultimately proving the validity of a new infrared

measurement technique. “It started a whole new way of

investigating mineralogy on the surfaces of planets,”

Bothwell explains.

Today, Bothwell serves as manager of the

Observational Systems Division at JPL, where she

oversees the work of more than 600 managers,

engineers, and technicians working on as many as a

dozen projects at any one time.

PHOTO: GRAHAM BOTHWELL
18 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

I’m a vice president at Line6, where

we produce electronics for musical

instruments. My company recently

developed a guitar that can be

programmed to sound like twentyfive different classic guitars—

everything from a 1928 National

“Tricone” to a 1970 Martin. It is quite

an amazing piece of technology. 

Sounds Clear

By Alan Zak
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 19

THE GUITAR STARTED AS A RESEARCH PROJECT BECAUSE WE

needed to know if the technology was going to be viable

and if the guitar design was going to be practical. I’ve

been in this business for about twenty years now, and I

still enjoy starting up projects whenever the opportunity

presents itself. During the research phase, I headed up

the project myself.

Once we completed our preliminary research and

made the decision to move into development, that’s

when I handed the project off—and that’s where this

story really begins.

Orchestrating a hand-off

We had an engineer, Dave, who had project management experience on comparatively smaller derivative

projects, some of our more- or less-matured signalprocessing gear. In that role he was performing well, and

he had been brought in to help the researcher developing the concept for the new guitar. When we made the

decision to develop the guitar, Dave asked me if he could

take over the project.

When I kick off new initiatives like this one, I never

take them to the finish line. I hand them off to a project

manager already in the ranks, or I try to mentor

someone who’s just starting out in project management.

The guitar project was going to run nine to twelve

months, which is a relatively short span for our projects,

and would only require a small team. It didn’t seem too

big a project to consider a new manager.

I have to admit, though, that I had my concerns

about handing off the project to Dave. He wanted to

keep his hands in the firmware development, and

become the project manager on top of that. There were

many, many challenges in the project. Could we give the

instruments an authentic sound? We had never done

this. That was the first challenge. The second was that

we weren’t simply dealing with electronics. As an instrument, the guitar required attention to aesthetics as well

as its tactile qualities. It needed to be desirable for the

customer from a “playability” standpoint. We might get

our arms around it from an engineering vantage point,

but we also needed to work with an outside manufacturer for the body.

Dave is certainly a competent engineer—but one of

the problems we sometimes have with engineers is that

their people skills aren’t strong enough to be effective

project managers. Now, I knew that Dave had a hard-core

engineering background, but I also knew that he had

worked well with his team when managing derivative

programs. Plus, he was a guitarist himself. So, he had the

enthusiasm I look for. The other thing that I suppose sold

me is that he told me that he had been doing some soulsearching and looking at his career track and so forth, and

he really wanted to develop his skills as a project manager.

We talked about all of this a lot before I agreed to let

him lead the project. I said, “You know, this can be

difficult. If you want to do it, more power to you. We will

try to help in any way we can, but if the situation does

get to be more than you can handle, we need to know.”

I gave Dave the project because he had a good track

record. But I knew that I was introducing an element of

risk to the project, because the scope was larger than

what he had handled before. This was something we

would need to watch carefully.

Project discord

Fast forward a few months: Dave did get himself into

trouble. The main problem was that he wouldn’t relinquish his technical responsibilities. In essence, he was

saying, “While I’m doing the engineering myself, I’m

also going to be managing the project.”

And he did deal well with the engineers and technicians on the program. But we also needed for him to be

dealing with the manufacturing interests, supporting

the subcontractors, looking ahead to the marketing

aspects, keeping control of the financial planning, and

Enough
staying on schedule. There’s a reason that project

management is a full-time job.

Dealing with the body manufacturers in Korea and

China, and integrating that with our own electronics

manufacturing here in Los Angeles, came close to being

a full-time job in itself. The electronics work was also

experiencing some minor setbacks. As a result, the

project was falling farther and farther behind schedule. I

had to have some very frank discussions with Dave. “In

my view,” I told him, “you’re spreading yourself too thin.”

Invariably, a young project manager will respond,

“I’m not spreading myself too thin. I can keep this thing

going, and it’s going to get better. Just because I was here

until midnight, you know, it doesn’t really matter. Give me

a week, you know, we’re going to turn this thing around.”

In this case that went on for more than a month.

From my perspective, it got worse and worse as we went.

At last, I said, “Dave, if we get to this next milestone and

it’s still apparent that you can’t function at the higher

level of visibility that we need, we’re going to have to

bring in some help.”

I think the nail was put in the coffin when the

production units arrived, and they were badly flawed.

They were 50 to 60 percent unusable. At that point, I

knew I had to bring in a new manager.

Dealing with the dissonance

It never is pleasant to replace a project manager,

especially a young one, because you always, to a certain

degree, hurt their feelings, their pride. I brought in a

manager, Kevin, with a proven track record who was

winding down work on a couple of other programs. He

was the best project manager we had on staff.

Earlier, when I had handed off the project to Dave, it

was a natural progression. Kevin and I both understood

that this second hand-off was very different; it was a

sensitive matter. Kevin didn’t want to come in and usurp

the good things that had been going on, including the

camaraderie that had developed among the team

members at that point.

By telling their leader to step down, we might

inadvertently be letting the team down, and the project

could have unraveled quickly. Once things do start to

unravel, I know from experience that sometimes you

can’t put these things back together. My prime concern

during the transition was to keep the team enthusiastic

and highly motivated.

The way I dealt with that was by staying involved

after Kevin took over. I had as much open dialogue

with the team as possible—with the schedule as a

backdrop. In other words, when Kevin

and I put together a new schedule, we

the didn’t foist it upon the team saying,

“Look, you’ve got nine months. You had

better make it happen.” No, it was a

n collaborative process. The team not only

signed up for the new schedule, they

authored it. Once we all had agreed on a

re schedule, I held regular weekly meetings

with the team and the new project

manager where we looked at the

milestones against our schedule.

And what of Dave? Yes, I replaced

him as project manager, but I wasn’t

saying, “You know, we’re just going to cast you aside and

move on.” I believed that he still had much to offer the

project, and that he was committed to see it through to

the end. Dave remained on the project, but strictly in a

firmware capacity.

His first reaction was typical of what I usually see in

cases like this. The project manger that’s being replaced

says, “Well, okay, I understand. We’ve got to do what’s best

for the program.” He understands that was a logically

sound decision to make; but then the emotions kick in. In

general, the people who work for us put their heart and

soul into these projects. When they’ve been disappointed

like Dave was, often they’ll start acting out. Sometimes it’s

as benign as being a little less responsive. In extreme cases,

they find ways to demoralize the rest of the team.

This was not an extreme case. Dave’s bitterness, or

resentment, simply had to be managed. I would say that his

cooperation ebbed and flowed. In order to let the new

project manager focus on more important issues, I took on

the job of monitoring Dave’s attitude. I made an effort to

20 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

I think the nail was put in 

coffin when the productio

units arrived, and they we

badly flawed.
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 21

work alongside him on occasion, so that I knew when I

needed to take him out to lunch and have a talk with him,

or when I needed to let things go to give him some space.

The next movement

In hindsight I can see that I made a mistake in picking

Dave to be the original project manager. He had a good

track record with smaller scope projects, but I misjudged

the level of risk that I introduced to the project by

selecting a manager whose experience had not prepared

him for the magnitude of this particular project with its

many interfaces—including manufacturing teams, offshore contracting, and FCC oversight interfaces.

I also had to relearn another lesson: Project management is a full-time job. If a project manager also wants to

take on a technical role on the project, it must be a small,

limited role—and not something in the critical path. If

you have anyone trying to take on a managerial role, but

they’re also implicated in the critical path, really in all

cases that’s a recipe for difficulty if not disaster.

Dave is still with our company, and still working

productively. For now, I have made the decision that his

future lies on the architecture side of our work. He

might have thought that he wanted to be a project

manager, but it became clear that his heart was still in the

engineering. More than anything else, he wants to be

working with the latest, greatest digital signal processing.

So, he’s very happy in that role. For now, anyway.

And what of the guitar? Even after the new manager

came on board, we couldn’t get the project back on

schedule. Early missteps are difficult to make up, and it

was clear that in several respects we did not meet our

objectives. One example: We didn’t deliver in time to

make our original marketing window.

Still, I didn’t let the project slip too far before interceding. Ultimately, the project was saved. The guitar was

delivered three months later than we had hoped, but it’s

doing extremely well on the market. In fact, it was our

most popular product in the industry last year. •

LESSONS

• Project management requires skills and experience,

but first of all it requires dedicating sufficient quality

time to the project. A novice project manager must

understand that his or her new role will demand significant energy and time.

• When a project manager is replaced, even if the transition is handled in a timely fashion and with sufficient

sensitivity, the project may still require a great deal of

oversight on the part of project sponsors. Substituting

one project manager for another should not be seen as a

“quick-fix.”

QUESTION

Under what circumstances should a project sponsor remain

closely involved in a project after a hand-off?

JAMMING WITH ZAK

“By using digital processing modeling techniques, we can make guitar amplifiers sound like any kind

of vintage amplifier you could want,” explains ALAN ZAK, Vice President at Line6. Zak heads up

electronics projects for musical instruments that “give musicians a larger sound palate to work with.”

The guitar project he describes in his story, “Sounds Clear Enough,” is the VariaxTM: “Vari” as in various

stringed instruments it can sound like; “ax” as in the term that guitarists use for their instrument. 

Guitar projects are a harmonious fit for Alan Zak. A musician himself, he has played and performed as a guitarist

for much of his life. “When I was in high school, I played in several bands. I wasn’t a world-class player, but eventually I managed to get gigs opening for people like Ricky Nelson and George Jones.”

In his early 20s, Zak decided it was time to go back to school. After two years of engineering courses, he went

to work for a startup music company and was involved in the invention of digital recording technologies and sound

processing gear, obtaining three patents. “I was also doing a lot of project management. That’s when I decided to go

back to school to get a Bachelors degree in business.” (For the record, he also has two Masters—one in comparative

philosophy, the other a MBA degree.)

These days, Zak plays classical guitar—ironically eschewing the technologies he’s helped develop. “Technology

is wonderful,” explains Zak. “I think it’s great for recording and for sound reinforcement, but I’m still captivated by the

simple musicality of playing.”
22 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

I REMEMBER QUITE VIVIDLY WHEN I GOT THE PHONE CALL FROM ED CORTRIGHT,

who was the Langley Center Director at the time, with news about my next

assignment. He asked me to come to the aid of a project that was in trouble, the

Rotor Systems Research Aircraft (RSRA).

“Are you sure you got the right guy?” I asked. “You’ve got so many

aeronautical researchers at this center and you pick on me. I don’t know

anything about this technology.”

“This is not a mistake,” he assured me. “You’re the person I want to do this.”

Cortright recognized that bringing this project to its end point would

require someone with my skills—not necessarily me, but somebody like me

who could drive the objectives of the program towards the plan already laid

out. On Viking, we said we were going to land a spacecraft on Mars and do

science there. Every decision we made was focused on that, so we learned to

pay attention to our objectives.

Cortright’s concern was that unless someone with a real project

background came in to deal with the contractor who was building the

aircraft, it could become a continuous sandbox research program. They were

trying to make the technology the best they could get it, and this was costing

a lot of money and a lot of time. It’s like you’re trying to get to 99-percent

pure. Well, you have to learn sometimes that 95-percent will work, and that

requires you to force people to make decisions to get it done.

The project manager was also the researcher who had designed this

aircraft. The whole project was his idea. He had worked in helicopter

research for 28 years. I would say he probably had spent seven or eight years

getting the project approved. Then he spent another three years working on

it. Altogether a decade of his life was invested in this project. It was going to

require a delicate touch for me to step in and help him understand that this

was what was best for the project. I realized that this was his baby, there was

no doubt about that, and I had to promise him that I was going to take care

of his baby.

IN 1977, I had just finished eight years on the 

VIKING program, which was just a marvelously rich,

fascinating experience, usingthe most up-to-date,

sophisticated management techniques, under an

outstanding leader named JIM MARTIN. After that,

you could say the opportunities available to me

within NASA in some ways werelimitless.

BRINGING UP
BABY BY ANGELO (GUS) GUASTAFERRO

Members of the first-generation Rotor Systems Research Aircraft strike a pose. Dressed to

the nines in the front row, fourth from the right, is project manager Gus Guastaferro.

ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 23
One of the things that made this project exciting to

me, and why I was keen to accept the challenge, was that

in spite of decades of leadership in aeronautics, my

center, Langley, had never designed its own fully

integrated airplane, except for this one.

I said to Cortright, “Well, before I say yes, let me go

talk to the individual.” I told him that I wouldn’t make a

decision until I understood the problems, and I wanted to

understand them from the project manager—not from a

third party, but from the person running the project.

A MEETING OF MINDS

I went to see him. Nothing had been announced yet, and

I didn’t tell him I was considering taking over the project,

but he knew something was up. He was not dumb. I was

not there because I had nothing to do for lunch. I just

said I was asked by the director to get a rundown of what

he was doing. To his credit, the manager was forthcoming with details.

So, I went back to Cortright and said, “I’ll take the

job, if you still want to offer it to me because I understand what the challenges are and what the problems

are. I believe I can help, but I want to keep the current

manager as the chief engineer.”

When Cortright made the call to the project

manager to tell him he was going to be replaced,

I wanted him to explain it in no uncertain terms,

“Hey, you’re going to be replaced, but Gus would like to

have you on his team. He needs you.”

And it’s true, I did. It would have been very hard for

me to take over this project without his smarts. I had a

pretty good sense of my own weaknesses. I didn’t come

there as a helicopter research specialist. I was expected to

step out of the space world, because remember Viking was

an outer space mission, and enter this new world of

aeronautics. I could have said I don’t need this person and

gone out and hired a different chief engineer. My management would have supported it.

But how you handle a transition like this is

important. There was no guarantee my method was

going to work, but I had previous experience in two

situations like this where the manager was forced to

leave and I had to take over, and I did not want to

repeat what happened to me in either of those cases.

FLASHBACK

Once, I had to take over management of a critical

resource without the help of the previous project

manager because he was fired. It was then I learned how

difficult it is to pick up where someone else has left off—

without that person’s knowledge to rely on.

Another time, on Viking, I faced a situation similar to

what I was facing on RSRA. In 1973, a little more than

two years before launch we ran into problems with one

of the instruments. Jim Martin said, “You’re no longer

the management operations director. I’m putting you on

this instrument, and you’ve got to go make it happen.”

Again, I offered to make the instrument manager

my chief engineer. I could have easily let him go, but I

decided that he should still be on the team. I wanted to

make him a part of the solution rather than a part of the

problem. The worst thing is to say, “Hey, thanks for

being around. Good luck. Have a good life,” and then

walk away. That’s a big mistake. You have to be sensitive

to that transition. Nobody likes to be replaced.

Hence, I did the same thing that I did on the RSRA,

but the difference was that the instrument manager on

Viking wasn’t a researcher, he was a project type, and he

never accepted the transition. He never did anything to

hurt the project, or me, but he wasn’t interested in

helping either. I had to decide whether I would bring him

along or let him go. Eventually, I found another position

for him that allowed him to leave the project with dignity.

24 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

They were trying to make the technology

the best they could get it, and this was

costing a lot of money and a lot of time.

A next-generation X-Wing

Helicopter awaits takeoff.
I learned an important lesson from this experience.

When you see that there is a lack of interest, then you

work hard at finding them a new place, another niche.

You’ve got to get that person off your project and get

them somewhere else.

THE COOPERATION FACTOR

There is no question in my mind that my job on RSRA

would have been tougher without the cooperation of the

project manager I replaced. It was certainly a lot easier

with him. He stayed with me for about two months as

my chief engineer, and he was just wonderful in terms of

the transition. He understood my skills and what needed

to be done, and was able to put his own ego on hold

while he adapted to this new life.

When you get in an environment where somebody

has lost their baby like the RSRA researcher, and you do

a good job in convincing them that they can still be a part

of the solution, then you’ve done the right thing. The

researcher on the RSRA believed in his baby so much

that he accepted the fact that this transition was

necessary to be successful. He spent a lot of time giving

me the technical aspects to do my job as best I could.

What I gave him was an understanding of why this

decision had to be made.

Now I also had to show the team that I valued this

individual. He was obviously well liked and respected as

a technologist. I can’t speak for the rest of the team, but

I think they respected me for the fact that I didn’t hurt

their former leader.

Right after I joined the project, I held a party. The

manager that I replaced came with his wife. You know,

I sensed more hurt and sensitivity in his wife than I

ever did in him, and so I made sure to take her aside

and let her know how important her husband was to

the project and that he would certainly be sharing in

its success.

Thirteen months later, I’m proud to say that I lived

up to my word. The day we had the first flight, he was

standing right there with me. It was still his baby, and he

had raised it well. He just needed a little help in getting

it to college. •

LESSONS

• You don’t want to lose key project knowledge. When

a person being replaced has key project knowledge,

seek ways to make sure that knowledge remains

available to you.

• Be sensitive during transitions. You don’t know how

emotional fallout will affect the project. Allow people to

step out of their roles with dignity.

• Don’t overlook the teammates of a leader who is

replaced. It is not your job to convince them that this is

the right decision, but you should respect their feelings

toward their colleague.

QUESTION

How can you detect early on whether attempting to leave the

replaced manager on board is going to be successful or not? 

ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 25

STAYING IN TOUCH

Following his work on the research

project described in this story,

ANGELO (GUS) GUASTAFERRO

went on to serve as NASA Director

for Planetary Programs, Deputy Director of the

NASA Ames Research Center, and Vice President

of Civil Space at Lockheed Martin. Now retired,

Guastaferro’s decades of aerospace experience

don’t go untapped: He continues to consult for

NASA on future space systems and serves as

Chairman Emeritus of the Hampton Roads

Technology Council and Director of the Virginia

Technology Alliances.

In addition, Guastaferro’s work for APPL includes

serving on the Advisory Board of the Leaders as

Teachers & Mentors (LT&M) program, which

leverages NASA’s wealth of human and intellectual

capital by connecting recognized program and

project management experts in NASA and the

aerospace industry to practitioners of all levels

across the agency. LT&M participants, some active

managers and some retired, reach beyond their

immediate circle of colleagues to provide guest

lecturing, teaching, consulting, and mentoring. 

The worst thing is to say, “Hey, thanks

for being around. Good luck. Have a

good life,” and then walk away.
26 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

THIS JOB WOULD, NO DOUBT, POSE CHALLENGES. be on site in just two days, in order to have transition

Engineering was near completion and most of the time with the old project manager. I worried this

equipment was on site—but only 20% of construction wouldn’t be enough time to learn everything that I

had been completed. I would have just six weeks to would need to know.

complete construction, start up the facility, and begin After thinking it over for a night, I accepted the

production. I was flattered to be considered, but realisti- assignment, packed my bags, and arrived on site ready

cally knew I had only done one similar, but smaller, to debrief with the project manager—only to discover

project in my career. the project manager had decided not to return to the

I had managed that project from the start to the site. Thus, my transition time was zero. I focused,

end—so I had no experience with assuming another instead, on meeting the rest of the team and learned

manager’s project. This assignment would be a three- another key piece of the puzzle: There were serious

to six-month job at a remote location. I would need to interpersonal and functional issues within the team.

I had been in a technical/project management assignment about two years, when one day

my boss asked me to come to his office to “discuss an opportunity.” When I arrived in his

office, he indicated that the project manager of one of our biggest ($10M+) and most

important projects had requested to be removed from the job immediately, and the organization was going to grant the request. He felt I was the most experienced person he had

and thought I would be a perfect fit for this job. 

———————————

987654321098765432109BY1W.1SCOTT1CAMERON098765432109876543210
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 27

Team members were candid with me—many told

me that they didn’t like other people on the team, or

they wanted to be working outside their current

functional areas. The R&D, engineering, construction,

and manufacturing personnel had formed a variety of

alliances amongst themselves, and none of these

alliances were focused on getting the job completed on

time to meet the business need.

By noon on the first day, I knew this was going to be

an interesting challenge, to say the least. The good news

was that the project files were organized and in good

shape and the team members appeared competent. With

the clock ticking, I also realized I didn’t have time to

train new people. I decided to trust the remaining team

members and focus on their strengths while trying to

use each hour of every day wisely to build team unity.

I used the first two days to join up with each team

member on a one-to-one basis to understand what he or

she felt they needed to be successful. I used the information to define an execution strategy to meet the schedule,

and then I began trying to break down the interpersonal

and functional barriers I had inherited. These join-up

meetings were a critical component for me to revise the

existing execution strategy. During these meetings I

discovered if an individual’s success criteria were different

than the team’s success criteria. Even though a person has

agreed to the team’s criteria, they may actually be

motivated by other criteria, which could negatively impact

the project. A one-to-one, face-to-face, join-up meeting

was the only way I knew to build solid trust between the

project manager and the team members.

I also decided to not look back or focus on what

caused the team to become segregated, but to focus on

moving forward. Thus, I decided never to utter the

words I have heard spoken often by project managers

assuming an existing project: “You wouldn’t believe how

screwed up this job was when I took over.”

After the first two days it was time to tackle the files

to determine the technical scope and see what omissions

and cost issues, if any, we were facing. This strategy

worked well and by the end of the week the team began

to focus on what was needed to meet our timeline. We

began a 24/7-work schedule with the project team and

construction crew working extended hours. As the days

passed, the team began to function better and began to

pull together. We even made time for team-building

activities, which were viewed positively and continued to

sharpen our focus as a working unit.

To make a long story short, we performed a miraculous turnaround, but missed the start-up date by a

week. Instead of berating us for not meeting the original

schedule, management was elated we came that close—

considering where we were six weeks earlier. The team

continued to work better and better with one another

and, by the time the team disbanded twelve weeks after

start-up, it was a very cohesive unit.

This experience taught me something that has been

born out over time: A successful transition doesn’t

necessarily lie in time spent with the exiting project

manager. Don’t get me wrong—that can be a big help.

But the success of a transition actually lies in getting to

know the people you will be working with, understanding their perceptions of what is and isn’t working,

and taking the time to read and analyze existing files to

get a flavor of the project as well as the cost, schedule,

and technical commitments that have been agreed to or

modified over the course of the project. •

54321A1ONE-TO-ONE,0123

123FACE-TO-FACE,1JOIN-UP

654321MEETING1WAS1THE01

ONLY1WAY1I1KNEW1TO1BUILD

0SOLID1TRUST1BETWEEN123

45THE1PROJECT1MANAGER

AND1THE1TEAM1MEMBERS.67

098THERE1WERE1SERIOUS76

5INTERPERSONAL1AND4321

FUNCTIONAL1ISSUES1WITHIN

0123THE1TEAM.45678901234

W. SCOTT CAMERON is the Capital Systems

Manager for the Food & Beverage Global

Business Unit of Procter & Gamble. He is

also a regular contributor to ASK Magazine.
PASSING THE BATON

LESSONS IN REGRET

By Terry Little

I HAVE LED SIX MAJOR DEFENSE ACQUISITION PROGRAMS

during my civil service career. For most of those, I was the

first leader the program had and did not have to adjust to

someone else’s legacy. This was both good and bad.

The obvious good was that I was able, for the most

part, to fashion things as I wanted them. These included

patterns of interaction inside and outside the project

office. I chose who would be in leadership positions. I

developed the managerial philosophy and leadership

vision. I decided my role vis-à-vis others in the office.

I created the expectations and goals. The bad part was

that all the while I was doing this I never considered

what I might be leaving my successor to deal with. My

reasoning was simple: I never intended to leave. I should

have known better.

Every time I left a program, it invariably went into a

nosedive that lasted anywhere from a few months to, in

one instance, more than two years. I could blame my

successors for failing to pick up where I left off, but that

would ignore the obvious. I was the common element in

every case. I had failed miserably in preparing the way for

my inevitable successor—failed five times! What had 

I done or not done?

For one thing, I had adopted many non-standard

practices which suited me, but would likely be unsuitable for my successor. Consider earned value and

metrics as an example. Because I did not agree with

earned value and metrics, I simply did away with them.

I worked on a face-to-face basis getting my information

first hand and verbally. My way involved an amount of

travel that any reasonable successor would simply not

tolerate. Additionally, the DoD’s “best program management practices” places a lot of emphasis on using earned

value and metrics as tools. Anyone replacing me would

probably be adhering to these.

The second thing I did was to make many managerto-manager agreements that we never formalized in

writing. They were just good faith understandings

between two people. What happened when my

successor arrived? There were no more understandings.

My successors honored the written agreements, but had

no allegiance to the unwritten ones I had made.

The result was sometimes major turmoil.

Third, I unconsciously fostered a tailored mentality

among both the people who worked for me and the

contractors’ project personnel. For instance, everyone

knew that I was impatient with detail and wanted to get

quickly to a bottom line that I could measure against my

intuition for making decisions. Good for me, but bad for

my successor—likely to be a more typical program

manager who would expect detailed analysis.

I also developed a somewhat deserved reputation as

a bridge-burner. If one of my peers from outside the

project office didn’t agree with what I was doing, I simply

went around or ignored him or her. It worked for me, but

my successors had to rebuild lots of bridges, which took

time, energy, and focus away from executing the project.

I cared more for people’s passion, loyalty, and their

ability to get results than I did for how they did things. In

that way, I put some real “odd-balls” in responsible

positions. I was more than willing to sweep up any broken

glass—a willingness that my successors did not share.

Perhaps my worst fault was that I never groomed

anyone to be my successor. I could have done that easily,

but since I didn’t intend to leave, it never occurred to me

that I should do that. Some people take longer to learn

from their mistakes. It has taken me failing to do this five

times before I finally learned to begin a succession

planning process in earnest starting from Day 1.

In a perfect world, a program or project would have

one manager from birth to death. But we don’t live in a

perfect world. What should you take from all this? You

decide. My conviction is that leading a project in a way

that best allows a seamless transition to another leader

at some uncertain time in the future is fundamental to

project success. •

TERRY LITTLE is the Director of the Kinetic

Energy Boost Office at the Missile Defense Agency. 

One of the most seasoned program managers in DoD,

he is also a regular contributor to ASK Magazine.

28 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 29

THE PMDP 

ROADMAP

SPECIAL FEATURE: APPL’S PROJECT MANAGEMENT DEVELOPMENT PROCESS

The Project Management Development Process has been a

great boost for my professional development. Having gone

through the program—and having received recognition for

advancing through all four levels of it—I’ve had opportunities

that wouldn’t have been available to me otherwise.

—Rex Geveden, Deputy Director, Marshall Space Flight Center
30 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

“”

NASA’S COMPLEX AND HIGHLY TECHNICAL MISSIONS

rely on effective project teams and managers. Since

1993, through its Project Management Development

Process (PMDP), the Academy of Program and

Project Leadership (APPL) has offered direction to

the Agency’s project practitioners as they advance in

their careers.

PMDP helps identify and sequence professional

experiences, courses, and other project-based learning

experiences that support individual career goals and

center activities by outlining competencies at four levels

of development. The result is that PMDP provides

NASA project practitioners with a road map to the

knowledge and competencies appropriate for their job—

and the jobs to which they aspire.

Plus, new this year, APPL has rolled out its

electronic Project Management Development Process

(ePMDP) tool, a learning management system that

includes a dynamic presentation of the PMDP levels,

competency areas, competency organizational structures, Individual Development Plans (IDP), and online

PMDP enrollment.

APPL’s website, www.appl.nasa.gov, provides access to

ePMDP, as well as other online resources for NASA practitioners

enrolled in the Project Management Development Process.

• PMDP LEVEL I: TEAM MEMBER

At Level I, the project team member demonstrates an

awareness and understanding of NASA’s project

management (PM) tools, techniques, and lexicon. A

Level I project practitioner is an active, contributing

member of a team—often a functional expert, business

manager, systems engineer, scientist, or project control

agent. Level I portfolios are validated by a practitioner’s

immediate supervisor.

Required training: APPL’s Foundations of Project

Management class (or equivalency). Information about APPL

classes, including schedules, is available in the Career

Development section of the APPL website, www.appl.nasa.gov.

• PMDP LEVEL II: SUBSYSTEM LEAD

Practitioners at this level have at least two years of

project team experience (including two years as a

subsystems lead) and must demonstrate the application

of PM tools, techniques, and lexicon at the project

subsystem level, including utilization of PM best

practices. Level II portfolios are validated by the Center

Peer Group and PMDP panel.

Required training: APPL’s Project Management and

Systems Management classes (or equivalency).

Developing NASA leadership

I’m certified at Level I of PMDP, and I’m

in the process of finishing up my certification for Level II. Though my title

doesn’t read “project manager,” I have

come to realize that everything I do requires some sort of

project management skills. 

Over the past couple of years, I have worked with the

Integration Engineering Section for the International

Space Station. Right now, Space Station is reorganizing,
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 31

“” “”

and I’m going to help out over on the operations side. We

have limited resources, but high technical demands.

Efficient project management is what ties those two

together—and certainly the findings of the CAIB Report

bear this out. As an Agency, we can’t afford to base our

decisions on a limited viewpoint (cost and schedule) when

there are critical technical requirements that have to be met.

It’s important now that we use the CAIB Report to try

to see what we need to do to become better as an

agency—and I think that the PMDP process supports this

effort. Effective project management is key to getting us

where we need to go. 

—Bill Stinson, Kennedy Space Center

• PMDP LEVEL III: PROJECT MANAGER

Level III project mangers must have at least eight years of

project team experience and five years of successful

project management—in addition to demonstrating the

integration of PM tools, techniques, and best practices

across subsystems at the project level. Level III portfolios

are validated by the Center Peer Group and PMDP panel.

Required training: APPL’s Advanced Project Management

class (or equivalency).

Expanding horizons

I started out in operations on the Shuttle

Program and for more than ten years 

I was a systems engineer on the floor. 

I went from a greenhorn apprentice

working for a senior systems engineer to be a lead

systems engineer with people working for me. 

At some point, I set a goal of becoming a project

manager—and I knew there was a lot I needed to learn.

So, I went and sought opportunities that would expand my

exposure to project leadership. 

PMDP was part of that process for me. I received my

Level III PMDP designation last year. In addition to what

I’ve gained through the curriculum and hands-on experience, I’ve benefited from all of the people that I’ve met

through the process. Over the years that network has

become invaluable to me. 

Not everyone wants to become a project manager,

but I think that having project management experience is

an essential part of doing any agency job. Projects are at

the heart of all of NASA’s work. I encourage everyone in

my division to be at least Level-II certified, because it gives

them a formal way of looking at and understanding

project work by understanding how to deal with schedules,

logistics, people, and all the rest. 

—Hector Delgado, Kennedy Space Center

• LEVEL IV: PROGRAM MANAGER

Leaders with responsibility for a large agency-wide

program must demonstrate strategic vision of PM

principles, tools, techniques, and best practices. Level IV

managers must exhibit the ability to manage a complex

program or set of intricate projects with multiple associated interfaces, performing appropriate trades across

projects and providing reviews and recommendations to

projects—including cost, schedule, and technical

performance management. Program managers’ PMDP

portfolios are validated by the Center Peer Group,

PMDP Panel and an agency-wide panel.

Required training: APPL’s Program Management and

International Project Management classes.

The path ahead

I feature my Level IV PMDP certification

prominently in my resume and job applications. I think my promotion to my

current position and the one before this

were directly influenced by my Level-IV PMDP certification.

The leadership here certainly mentioned it frequently. 

The best part of PMDP is that a career development

path is laid out for you. To some people it may look like

you’re merely “checking off” a list of requirements. In

reality, as you go through the process, it turns out to be a

strong enhancement to your career development. That’s

because it is put together by people who understand what

it takes to move through the different levels of program

and project management. So, if you take the pains to go

through it, I really think you emerge from that process

being highly suited to provide effective program and

project management.

—Rex Geveden, Marshall Space Flight Center 
32 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

PRACTICES

ROGER LAUNIUS, THE PREVIOUS CHIEF HISTORIAN, HAD

accepted a job offer from the Smithsonian. I guess you

could say I was the logical person to step in while the

search began for his replacement. I had been with the

NASA History Office since 1995, and had worked closely

with Roger.While not officially called his deputy, I suppose

you could say I had functioned in large part as one.

I had established and overseen a successful intern

program in our office and had also worked with various

outside historians as contractors; the work had piqued

my interest in project management. Even though I

understood my work as chief historian would be

temporary, I looked at it as a good career opportunity. I

enjoyed doing historical research and working on my

own, but I wanted to improve my management skills.

My time as acting chief historian and the experiences that led up to it have underscored a management

principal that’s worth repeating: Projects are people.

Managing History: A PRACTICUM

In the summer of 2002, I was

asked to serve as interim 

chief historian for NASA 

until a permanent replacement 

was hired.

BY STEPHEN J. GARBER
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 33

Practice One: Leverage your resources to 

create win-win situations for both you and 

your team members.

Here is an example of some useful practical knowledge I

gained managing a small project that I thought would

serve me in good stead in my new assignment. Several

years before I became the interim chief historian, I had

been given the task of managing the History Office

website, including supervising a small volunteer staff. We

usually have one or two people who do some volunteer

work for our office, and I used them to post new content

to the site.

Then there was this other person, Chris Gamble.

He wasn’t working as an official volunteer for us, but he

spent a lot of time volunteering criticism about our

website—especially regarding every place he noticed a

typographical error. I appreciated his feedback but I

needed to find a better way to channel his help.

It occurred to me that I should try to recruit Chris

into doing something more proactive, and I asked him if

he would be willing to look over some new Web pages

before we “went live” with them. That way he could

catch errors before they went public on the Web, rather

than later. He agreed.

After Chris had worked with us for a while, it wasn’t

such a big leap to ask him if he would be interested in

preparing out-of-print publications for the Web in an

electronic format. Since then, he has formatted literally

dozens of books for us that are now available online. As

a small token of our thanks, I send him free copies of all

of our new publications—but he continues to work on a

volunteer basis. If we were to hire a computer professional to do all this HTML work, it would cost a lot

more than we could afford.

He’s done all this incredible volunteer work for us

from his home in Switzerland. I’ve never met him in

person, and I think I’ve spoken on the phone to him

once; we communicate by email and snail mail. A happy

ending to the story (although he continues to work with

me) is that I nominated him for a prestigious NASA

award, which he received. Afterwards, he wrote me a

moving email, telling me how proud he is to be part of

the NASA team.

Sometimes when I’m having a bad day, I think

about Chris Gamble. I’m just glad to work at an agency

that engenders such enthusiasm from the public and in

an office at NASA that gives me the flexibility to leverage

resources in unusual ways. I don’t think too many other

people in government have the opportunity to tap such

volunteer efforts.

Personalities rub people different ways, and dealing with

all the different personalities around me when I began

working in the role of the chief historian was the big

challenge I faced. Suddenly, I understood why, for

example, Roger had clashed with certain people. Often 

I clashed with them, too. In the past I tended to vent or

openly criticize other people I was unhappy with.

I realized quickly that as head of the department I

couldn’t afford to do that any longer; it would be

counter-productive to our work, besides being unprofessional and unkind.

Today, my communication style varies, depending

on the person I’m dealing with. I like to use the coaching

analogy: You’ve got to figure out what each player needs

to stay motivated and productive; some may need

reassurance, some “tough love,” and others “just the

facts.” In practice, though, I know that there’s not an

easy answer for each personality.

One person I work with, for example, kept calling

me and wanted to have long phone conversations to

discuss every little detail of the project he was working

on. I began scheduling regular tag-up meetings and

asked him to save all non-urgent items for our meetings.

Then the tag-up meetings began running longer than I

wanted. I began scheduling meetings with start and end

times. I took a stronger role in leading the meetings and

I closed the meetings on time. Our meetings became

more efficient, but then I was concerned that we might

not get around to covering everything we needed to

cover. So, you see, it’s not as though I’ve found a perfect

solution, but I have learned to think through different

options for communication.

It’s not as though I’ve found a perfect solution, but I have learned to think 

through different options for communication.

Practice Two: Because moving from team member

to manager changes responsibilities, you may need

to develop different communication strategies for

dealing with people you already know. 
34 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

Making history at NASA 

Just one year after the agency was formed, the NASA History Office began its work of documenting and preserving the

organization’s remarkable history. Every year, the chief historian oversees publication of a number of new books,

monographs, pamphlets, and newsletters on aerospace history, in addition to publishing invaluable out-of-print books

and monographs online.

As a member of the History Office, STEPHEN J. GARBER has written on such aerospace history topics as President

Kennedy’s attitudes towards space, the design of the Space Shuttle, and the Congressional cancellation of NASA’s Search

for Extraterrestrial Intelligence program. His Masters thesis compared cultural views of technology in the U.S. and the

Soviet Union by contrasting the designs of the U.S. Space Shuttle and the Soviet Buran Space Shuttle. 

“One interesting part of my job is responding to ad-hoc requests from all sorts of people who have ideas about what we

should cover,” says Garber. “I often hear from retired scientists or engineers who now want to write the history of the

program that they last worked on.”

Garber’s approach is to try to offer some guidance on the nature of history, and how history can be useful in everyday

life.”Basically, we all consider the past, at least subconsciously, in making decisions,” explains Garber. “But we can

usually make better decisions by considering history more explicitly and analytically.”

To give non-historians direction, Garber developed a packet, “Thinking about NASA History,” which can be found online

at http://history.nasa.gov/thinking/index.html.

I often think back to two professors I knew in grad

school. One taught a class on strategic management and

pointed out that some people prefer to get their information verbally and some prefer the written form. This

seems obvious, but I hadn’t thought about it that way

before. At the time, I was a grad assistant for another

professor who liked to call meetings with me and his

other assistant to “chew the fat” for a while. These bull

sessions seemed like a waste of time to me and I couldn’t

figure out why he liked to talk so much. I had wrongly

assumed that because he was a researcher and writer, he

always liked to get his information in written form. So

the obvious moral to the story is that each person has a

different communication style.

Practice Three: Identify those people whose

judgment you trust and be willing to seek 

out their advice.

To get through this situation and others that have come

up, I have relied on people around me for advice—often

people I had known, but never turned to in the past.

There is one particular person in my office that I’ve

always thought of as a level-headed individual. I hope

she doesn’t mind that I’ve begun to use her as a

sounding board. Indeed, it seems to have encouraged

her to use me as a sounding board, as well, for things

that she’s wrestling with.

Roger was very good about offering to help after he

left. Sometimes I turned to him to ask his advice on

situations, even if I already had a good idea of how I

would handle them. I didn’t call him with every little

decision, but I talked to him when I thought a situation

warranted extra attention. When he was still my boss, he

had often asked me for my input on things. We seemed

to be in sync in terms of our judgment in many cases.

I also had lunch with the head of our History

Advisory Committee a few times over the year I served as

chief historian. I felt that it was a good thing to do when

I was feeling a lot of stress or when I didn’t know how to

handle certain situations. It wasn’t as though he could

offer any magic advice—but he is older than I, again has

good judgment, and in general is a reasonable person

with some gravitas. At first it surprised me when he would

ask me personal questions like, “How is your wife doing?

How is your health?” I wanted to focus our precious

lunch hour on a host of work-related questions. But I

quickly realized that talking about those personal things

helped me to put any problems at work in perspective.

Finding mentors like these people has been helpful

in grounding me, giving me perspective, and reinforcing

my initial leanings.

The story ends, or perhaps it’s just a chapter

In November of 2003, I finished my temporary assignment as the chief historian and handed off the job to Dr.

Steven J. Dick. I’ve returned to my role as a senior

member of the History Office.

Was it a good year? I think so. Taking on a senior

management position was a stretch for me, but knowing

what I know now, I will be happy to stretch myself again

when the right opportunity arises. •

Finding mentors like these 

people has been helpful in grounding me, giving me perspective, and reinforcing my initial learnings.

PRACTICES CONTINUED
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 35

INTERVIEW 

T OM GAVIN

Thomas R. Gavin joined the Jet

Propulsion Laboratory (JPL) in 1962.

Currently the Associate Director of Flight

Projects and Mission Success, he has

garnered a long list of engineering 

and management positions, including

serving as mission assurance manager for

both the Voyager and Galileo projects,

spacecraft system manager for the

Cassini mission to Saturn, and deputy

director for JPL’s space and earth science

programs. His previous assignment was

director of space science flight projects.
GAVIN WAS HONORED IN 2003 AS A FELLOW OF THE

American Astronautical Society at their national

convention in Houston, Texas. He has received NASA’s

Exceptional Service and Outstanding Leadership

medals, and Aviation Week & Space Technology magazine’s

Laurels Award for outstanding achievement in the field

of space.

You’ve been with JPL for 41 years. What were some of the

early lessons you learned from the project managers you

worked under?

The technical challenges in those early days were

immense. I learned from the early practitioners in the

space program, such as John Casani, Bill Shipley, and

Casey Mohl. They were all bright, disciplined thinkers

who emphasized understanding problems in great

technical depth. In fact, we’re still following the principles that they laid down 40 years ago.

What is something that you learned from them that you

still use today?

Casey, for instance, would have coffee every morning in

the cafeteria at 7:15 a.m. Everyone was welcome to

come, sit down, have coffee, and ask questions. Guess

what I do? People know that I come in to the cafeteria

around 7:30 a.m., and, if they want to talk, they know

where they can find me.

Do you remember making mistakes or having missteps

when you were working for any of those legendary

project managers? If so, how did they respond?

I was the mission assurance manager for the Voyager

project and John Casani was the project manager.

Casani has a very systematic approach in examining

issues or problems. When you had to present a problem

and the potential solution, Casani would very quickly

work the discussion to the boundary of your understanding of the issue. He always worked it with you so

that you were discovering the soft spots in your

solution. It was always a constructive learning experience with Casani.

So, the response wasn’t to slap you down?

No. It was very much to help me. I had the opportunity

of a terrific on-the-job learning experience.

So, you got to see the processes modeled?

Yes. I learned incrementally. I absorbed it all, piece by

piece. I didn’t really have to think about what I needed

to learn; I was lucky enough to see it modeled over time.

We recognize that in today’s environment of short

development schedules, engineers don’t necessarily have

the luxury of incremental learning. With new projects

frequently on the horizon, we need to supplement their

hands-on experience with training.

To that end, we at JPL have compiled many years of

experience in our Flight Project Practices and Design

Principles and we have developed a project’s manager

class—where the role and responsibilities of project

management are explained to newly appointed and

prospective project managers. This class is popular and

provides a detailed look into the life of a project

manager. As a result of this class, we have increased our

pool of engineers ready for a project manager assignment, and we have also had engineers recognize that

project management may not be for them. This

unexpected outcome from this class is beneficial to both

the employees and the Laboratory.

36 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW CONTINUED

The Voyager 2 spacecraft captures an image of 

Saturn’s rings.

Technicians install the Huygens probe on the Cassini

orbiter in the Payload Hazardous Servicing Facility.
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 37

Uranus as seen from the Voyager 2 spacecraft.

“Someone said to me

once, ‘Why would

you want to run

scared?’ I said,

‘Because it makes

me think of all the

things that could go

wrong, so I can deal

with them before

they do.’ “

As someone whose responsibility it is to groom project

managers, what do you look for? What do you expect in

people who want to be project managers?

First of all, they must have the necessary technical and

leadership skills and personal integrity.

You also must be able to inspire the confidence of

the project team who is going to work for you. Take Pete

Theisinger, the project manager of the Mars Exploration

Rover, for example. He took on the job of launching two

spacecraft from a dead start in 37 months. His team

members had to have faith that he was going to lead them

and look after them.Those are the qualities that I look for.

How do you spot the real leaders? 

You have to watch their careers. What challenges have

they faced? What commitments have they made and

have they met those commitments? What have they

delivered? In many ways, this is a natural selection

process. Around here, if you say you want to be a project

manager, the first question is always going to be: What

experience do you have? What have you delivered? 

The fact that you want to be a project manager

doesn’t mean you are going to get the job. Part of the

experience set for a project manager has to be delivery

responsibility—what have you delivered successfully?

Did you do it on time? Did you do it on money, be it

hardware or software?

In addition to delivery experience, we are looking

for the total package. How were your communications

skills? How did you deal with problems? How did you

deal with stress? It’s those kinds of things.

As you were going through that process yourself, was

there a point where you said, “This is going to make or

break me”?

Sure—again, for me it was Voyager. I was named mission

assurance manager when I was 30 years old, and I was

on the mission until it launched in 1977. Because of my

work in the first couple years of the project, I was given

responsibility for the radiation hardening of the spacecraft from all of the mission’s electronics. They said,

“Okay, you go do this job.” I had that development

responsibility from 1974 until launch.

Voyager leveraged everything in the rest of my life at

JPL. On the other hand, if Voyager had not gone well, they

might very well have said, “Well, we saw what he did.”
At the time, did you think you were in a little over your head? So, you delivered the goods. Then you had to leave the

I thought I was in way over my head. I was thinking, “You project when it was time for operations. How does it feel

want me to do what?” Voyager was a real stretch for me. to hand off a project to someone else?

You just walk away from it. You get the new manageDon’t you think there’s irony here? One of the things ment ready, and then you walk away.

you’re talking about is making certain that people are It was interesting with Cassini because as we were

prepared to advance to the next level. On the other hand, approaching the launch, I would warn the younger staff,

you’re talking about stretching, about making a leap. “You’re about to experience a feeling of separation.”

That’s right. You’ve got to make people stretch a little. I There were as many as 700 of them on the project team

decided early on that I love to run scared. Someone said at one point. I would say to them, “You’ve been working

to me once, “Why would you want to run scared?” I now for five or six years with all of these people. You’re

said, “Because it makes me think of all the things that a part of this great Cassini team here at JPL. We’re going

could go wrong, so I can deal with them before they do.” to launch it, and then all of this is going to go away.

Voyager was my biggest stretch. With the Cassini You’re going to have a sense of loss. You need to be

project, on the other hand, there was no reason that I prepared for that.”

couldn’t do well with that. I was the spacecraft manager

for Cassini, and by that time I was well prepared for it. How was it for you, personally?

Actually, when we came back from Cassini, it was kind of

I’m sure you still found a way to scare yourself. funny. Just imagine it: You’re the leader of the band.

I did. Before Cassini, I had always worked on the technical You’ve got everybody watching you. You’re down at the

side of the house, where the emphasis was on meeting the Cape. You’ve got the headphones on and you’re

engineering requirements first and foremost. Cost was launching the spacecraft. Everybody is cheering and

secondary. Now I had a different role. That was the first high-fiving, right?

time on a project that I had to manage the money, and it Then I get back to JPL and walk into my office. Do

was definitely a stretch in that sense. So, I poured a lot of you know what I saw in the office? Boxes and boxes and

effort into learning about cost estimating and cost perform- boxes. The guy who was the manager for operations

ance. I stumbled for a while but ultimately succeeded. came by and said, “Hi, welcome back. When can you be

out of here?”

But in the end you returned money on Cassini. How did When I came back from Voyager, it was the same

you manage that? thing. I had been down at the Cape for four months. I

Some people will argue that we just had a lot of money showed back up at JPL, walked up to the Voyager

to work with. I would say we were disciplined. From the Missions Support area and my badge wouldn’t work. I

start on Cassini, I knew what reserves we had for the rang the bell. The girl said to me, “Can I help you? Who

spacecraft. The budget was $611 million, and $71 are you and why are you here?”

million of that was reserve. We made a series of decisions

about how we would implement the project, and what So, I guess the only way to get through that is to find the

type of management systems we would put in place to next project?

make certain we understood where the money was. That’s right. Projects end. That’s our reality.

We did a lot of fixed-price contracting, for example. But I love it. Listen, we are privileged. Everybody

So, we said, “Let’s make sure we get the requirements who works for this agency is privileged. We’re privileged

right the first time, because if we fix-price this and then to serve the American people the way we do. It sounds

we go back and change requirements, we’re going to corny, but look at what the American people have

hemorrhage money.” Some of the contractors bet that we allowed us to do. We need to do our very, very best. We

couldn’t discipline ourselves, but we did. We spent the should kick our personal interests aside. We’re doing

first two years of the project making certain we under- these things in the name of science and for the

stood the requirements and had the right design. American people. I never forget that. •

INTERVIEW CONTINUED

38 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 39

Voyager 1 launches aboard a Titan III/Centaur 

rocket on September 5, 1977. 

“As we were

approaching the

launch, I would warn

the younger staff,

‘You’re about to

experience a feeling

of separation.’

“
40 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

THE PROJECT MANAGER WAS OVERSEEING THE CONSTRUCTION

of a new complex of swimming pools for a university,

when the school’s athletic director asked him to also

remodel the basketball arena. He’d never done a remodeling project before, and this particular project was

extensive. The entire arena needed

an overhaul. He’d established a

good relationship with the athletic

director, and since his project was

winding down, he agreed to tackle

the remodeling job.

One consideration in his

planning was that the basketball

stadium was used by many of the

school’s sports groups, so there

was only a small window of

opportunity to complete the

job—the last three weeks of

summer vacation. This timeline

was nonnegotiable.

His first draft of the project

schedule required a one-month

timeline to complete the remodel as proposed. Working

with the athletic director, he reduced the scope of the

project and drafted a schedule with several contractors

working in parallel where possible. The three-week

timeline could be met.

He presented the initial plan to the school’s administration for approval. The plan had the last day free for

any emergency that might arise (Figure 1). The administrators, based on their experience with previous remodeling jobs, asked for a revised plan with two days at the

end for emergencies. What he gave them instead was a

plan with no free days at the end.

Why? After meeting with potential contractors, he

found that it was impossible to accurately estimate the

time needed for some of the remodeling tasks until the

work had actually started. If one contractor exceeded the

estimated time, for example, that would delay the start of

the next contractor’s work. The contractor who followed

the first would not sit idle; instead he would move to

another job, further delaying his start time and rendering

the entire schedule useless.

Prior to developing a schedule,

he established two criteria to reduce

uncertainty. First, he reached an

agreement with the athletic director

that there would be no changes to

the project. Second, he would select

his contractors on the basis of

proven reliability, not just cost.

The schedule had to absorb

changes as work progressed

without collapsing. He did this by

inserting time buffers—a half- or

full-day between tasks—to follow

tasks that were on or close to the

critical path and had a high

probability of time overrun. These

would allow him to absorb schedule changes without

stressing the overall timeline. A bar chart depicting the

project schedule would look like a checkerboard, with

black squares representing planned tasks and white

squares representing the time buffers (Figure 2).

The result was excellent. While he did use some of

the time buffers, he never had to change the scheduled

start time of any of the contractors. This convinced the

administration to adopt a “checkerboard” system for all

future remodeling projects.

The story I heard from this project manager demonstrates what I have seen time and again: Successful

project managers create project schedules that can easily

checkmate uncertainty by loosening the connections

between uncertain tasks. •

Checkmate to Uncertainty

Coping with project uncertainty requires, at times, surprising solutions.

I recall a story related to me by a project manager that illustrates just such a solution

FROM THE EDITOR-IN-CHIEF Dr. Alexander Laufer

TIME RESERVE

Figure 1: Proposed Initial Schedule

Figure 2: The Checkerboard Schedule

TIME

TASKS TASKS

TIME

TIME BUFFERS

NP-2004-02-337-HQ