appl.nasa.gov

ASK Magazine • Issue Fourteen

OCTOBER 2003

Inside

CASH FLOW WOES

SCHEDULING REALITIES

REQUIREMENTS AND “DESIREMENTS”

A MASTER PM’S LESSONS LEARNED

Academy Sharing Knowledge

The NASA source for project management

INTERVIEW

Donald Margolies
We had the money, and we thought we knew 

how to do this thing—but our flawed cash flow plan 

stood between a successful project and us.

—Dr. Kenneth L. Atkins, from his “Mr. Stardust’s Wild Ride” (p. 16)
appl.nasa.gov

Table of Contents

ASK 14 October 2003

STORIES

6 Enough Is Enough 

It was the wrong answer because it made a simple design more complex and added 

little value to the mission at a major cost in time and dollars BY JAMES BARROWMAN 

10 The Clock Is Ticking

In my world of designing and creating new products, the one constant is speed—

not to mention the byproduct of speed: pressure BY DAN GUNDO 

14 Listening to That Voice Inside

I had a lot of experience making quick decisions, but something told me to follow 

my instinct that this decision required more consideration BY DAVE STICKEL 

16 Mr. Stardust’s Wild Ride 

When I looked at the schedule and what had to happen with our initial funds,

anxiety set in BY DR. KENNETH L. ATKINS

20 One Way or Another 

I try to work through every scenario I can think of in advance to have everything 

lined up like dominoes—but things still go wrong BY CHRISTIAN ZAZZALI

FEATURES

24 See Attachment

When I receive an email I tend to want to stop everything and answer it 

BY W. SCOTT CAMERON 

26 Requirements: The More the Better?

In truth, most so-called “requirements” are really “desirements.” They have little or 

nothing to do with real need BY TERRY LITTLE

SPECIAL FEATURE: KNOWLEDGE SHARING

28 Tipping the Balance

As I quickly discovered, a constellation of forces needed to be brought together to say,

“We are going to make this happen” BY CLAIRE SMITH 

PRACTICES

32 Lessons from the Dark Side

Mistakes are all right, but failure is not. Failure is just a mistake you can’t 

recover from BY JERRY MADDEN

INTERVIEW

34 ASK Talks with Donald Margolies

In building project schedules, Donald Margolies of Goddard Space Flight Center uses 

the best resource available to any project manager, the people working on the project

IN THIS ISSUE • 3

One-of-a-Kind, Two Ways

BY TODD POST

REVIEW BOARD • 4

FROM THE DIRECTOR’S DESK • 5

Surf’s Up

BY DR. EDWARD HOFFMAN

LETTER FROM THE 

EDITOR-IN-CHIEF • 40

Management as

Improvisation

BY DR. ALEXANDER LAUFER

SPOTLIGHT ON APPL 

See insert following page 33

ON THE COVER

Dust collector used on Stardust mission JPL
2 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

WELCOME TO THE ACADEMY OF PROGRAM AND PROJECT

Leadership (APPL) and ASK Magazine. APPL helps

NASA managers and project teams accomplish today’s

missions and meet tomorrow’s challenges by providing

performance enhancement services and tools, supporting

career development programs, sponsoring knowledge

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

other government agencies.

ASK Magazine grew out of APPL’s Knowledge

Sharing Initiative. The stories that appear in ASK are

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

primarily from NASA, but also from other government

agencies and industry. These stories contain genuine

nuggets of knowledge and wisdom that are transferable

across projects. Who better than a project manager to

help another project manager address a critical issue on a

project? Big projects, small projects—they’re all here in ASK.

Please direct all inquiries about ASK Magazine editorial

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

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

email to tpost@edutechltd.com.

APPL DIRECTOR AND PUBLISHER 

Dr. Edward Hoffman 

ehoffman@hq.nasa.gov 

EDITOR-IN-CHIEF

Dr. Alexander Laufer 

editors@edutechltd.com

EDITOR

Todd Post

tpost@edutechltd.com

ASSOCIATE EDITOR

Jody Lannen Brady

jbrady@edutechltd.com

CONTRIBUTING WRITERS

W. Scott Cameron 

Terry Little 

KNOWLEDGE SHARING MANAGERS 

Denise Lee

dlee@edutechltd.com 

Therese Salmon

tsalmon@edutechltd.com

EDITORIAL ASSISTANT

Michael Derocher

mderocher@edutechltd.com 

DESIGN

Hirshorn Zuckerman Design Group, Inc.

www.hzdg.com 

SENIOR PRINTING SPECIALIST

Dave Dixon

ddixon@hq.nasa.gov 

PRINTING

Fontana Lithograph, Inc.

STAFF

ASK ONLINE

http://appl.nasa.gov/ask
IN THAT WAY, WE FEEL A KINSHIP WITH AMES RESEARCH

Center technologist Dan Gundo, who builds one-of-akind hardware for NASA projects and has given us a

story about one. In “The Clock Is Ticking,” Gundo

writes about an exercise bed he built for space scientists

studying ways to counter the atrophying effects of

microgravity on human muscles. The novelty of the

exercise bed is only part of what we think you’ll find

interesting in the story. Best of all is how Gundo learned

to work with his customer to define project requirements clearly enough and early enough to allow him to

meet a challenging deadline.

Requirements challenges come up in another story,

“Enough is Enough,” by James Barrowman. On the Rossi

X-Ray Timing Explorer mission, Barrowman worked

with the science team to put down on paper what constituted “good enough” science before development work

on the spacecraft began. This looked prescient when a

technical problem emerged, and suddenly the scientists

forgot about what was good enough.

This story is not the first to appear by Barrowman in

ASK. In Issue 3, we featured his story “Pin the Deputy’s

Badge on Me” about doing double duty as program

manager and deputy project manager in the Explorer

Program Office at Goddard Space Flight Center. You can

read Barrowman’s other story by going to the ASK

archives on our Web site.

Donald Margolies is also making a repeat appearance in the magazine. We featured a story by Margolies in

Issue 9 about an episode on the Advanced Composition

Explorer (ACE) mission, for which he was project

manager. In the interview you’ll find in this issue,

Margolies invokes examples from ACE to discuss the

challenges of scheduling. After reading the interview, you

may want to read more about ACE. Again, visit our Web

site and you’ll find several stories about ACE in Issue 9.

If it sounds as though I’m pushing our Web site,

then I guess it’s because I am. After several issues not

having a Web companion to our print edition, ASK is

back online at appl.nasa.gov/ask.

We’ve taken advantage of being part of the expansive

NASA portal to introduce many new features. For

example, in this print issue we’ve collected several lessons

learned from retired Goddard project manager Jerry

Madden. These lessons first appeared in 1995 when Jerry

released his underground cult classic, “A Project

Manager’s Lessons Learned.” We’ve pulled together some

of our favorite here from the 128 Madden collected. If you

want to read all of the lessons and you don’t have a wellconnected friend with the original copy of the lessons, you

can find them all on the ASK Web site. And by the way,

you can also read an interview we did with Madden that

appeared in Issue 4.

What else this issue? In early 2004, a NASA spacecraft will intersect a comet and return home in 2006 with

some microscopic particles of stardust, another one-ofa-kind mission. This is the subject of Jet Propulsion

Laboratory project manager Ken Atkins’ story “Mr.

Stardust’s Wild Ride.” The spacecraft is presently on its

way to rendezvous with Comet Wild II, but Atkins will

tell you how precipitously close the project came to an

early demise. This story will be a jolt to anyone who

thinks the only money issue that matters on a project is

how much you get. Atkins shows that when the money

arrives can be just as important.

There is plenty more good stuff in Issue 14, so go

ahead and dive in. •

One-of-a-Kind,Two Ways

Though each issue of ASK Magazine addresses the concerns of project

management, this issue, like all previous issues, is a one-of-a-kind product filled

with the unique and often innovative insights of individual project practitioners

IN THIS ISSUE Todd Post

ASK 14 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 of the Goddard Space Flight Center was

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

1997 and still operating successfully. He

received the NASA Medal for Outstanding

Leadership for his work on ACE and a NASA

Exceptional Service Medal for the Active Magnetospheric

Particle Tracer Explorers (AMPTE) mission.

DR. GERALD MULENBURG is the Manager of the Aeronautics

and Spaceflight Hardware Development

Division at the NASA Ames Research Center.

He has project management experience in

airborne, spaceflight, and ground research

projects with the Air Force, industry, and NASA.

He also served as Executive Director of the California Math

Science Task Force and as Assistant Director of the Lawrence

Hall of Science.

JOAN SALUTE is the Associate Director of Aerospace at Ames

Research Center. She has managed many

NASA projects including those involving flight

testing of thermal protection materials,

commercial technology, commercial applications of remote sensing, and remote sensing

science projects. She has been at Ames for 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 14 FOR PRACTITIONERS BY PRACTITIONERS 5

EARLIER THIS MORNING, I WAS UTTERLY DISCOMBOBULATED

when I turned on my computer. For some inexplicable

reason, I couldn’t get onto the Internet. Understand,

Web surfing isn’t a hobby for me. My time on the

Internet is an addiction.

I call my service provider and the help person tells

me that the problem is my card—a 10/100 or 100/10

something. I have to switch my card

to an open slot. Huh? I don’t know

how to open the computer shell.

My helper assures me he’ll be

here (invisible but connected) to

help me get through it. If his grandmother could be instructed to fix

her computer over the phone,

surely I can be, too. (His naiveté is

scary, but forget about that—I’m in

good hands.)

I get the Dell open. I even find

the card. But all my slots are filled. He tells me to

switch the cards to see if the problem is the card or the

slot in which it’s seated. My fingers start to quiver.

Suddenly, a thought comes screaming from my brain:

Why am I here? 

The answer, I’m afraid, is a sign of the times. I

desperately want my high-speed internet service. Crazy, I

know, but I have become a Web junkie. I need (the key

work here is “need”) to read New York newspapers to

hear about my favorite hometown teams. I need ESPN to

tell me what’s happened in the sports I follow and what’s

going to happen next. Of course, I need to check out

NASA Watch to feel in the know. Then I need to check

flights, since my wife Dianne and daughter Amanda are

on a short vacation. I also need to check my e-mail for

presentations I’ll be working with colleagues. If this isn’t

enough, on Saturday my son Daniel and I need to play an

on-line game with my brother and his friends in Phoenix.

“Place firm pressure on the cards—”

It’s okay. My helper is right here.

“—but don’t force them.”

NYPost.com, ESPN, Dianne and Amanda... I’m on

my way. I fumble to put the second

card in it’s slot.

It’s in place! Eureka! 

I turn on the computer and....

Yes, it all works. Touchdown.

Grand slam. Happy feet!

“Thanks, kid,” I say and then I

hang up and begin to surf.

The Web has become a

source for everything: work, play,

collaboration, networking, information, research, stories, news,

music, communication, decision making, pictures,

surveys, assessments, and everything else. When the

system goes down, I start to react like a man with a

crack habit.

By no small coincidence, this story coincides with

the fact that on July 31, the APPL Web portal debuted.

New and improved, as they say. Working with Jeanne

Holm’s JPL team, the NASA Chief Information Office,

and a group of brilliant Web fanatics, we’ve built an

amazing virtual APPL. First up, ASK Magazine is again

available online—when, where, and how you want it.

The Web will also allow us to expand some of our ASK

features, so keep an eye on us and enjoy.

Be careful, however. You might just find

appl.nasa.gov is addictive. •

Surf’s Up

Saturday morning and I could be at the gym, doing something healthy.

Instead, I’m sweating away as I perform surgery on my Dell computer

My fingers start to quiver.

Suddenly, a thought comes

screaming from my brain:

Why am I here?

FROM THE DIRECTOR’S DESK Dr. Edward Hoffman
6 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 7

THE SPACECRAFT WAS NEARLY INTEGRATED AND HAD managed by my Explorer Program Office, but it was

passed some of its early mechanical and electrical unique in being the first project we had agreed to do for

testing. One of its instruments, the Proportional a fixed price. NASA HQ agreed, in return, to provide us

Counter Array (PCA), had a gas leak in one of the five with the funding profile we needed to make it happen.

proportional counter modules that made up the array. We were both trying to break the unhealthy spiral in the

The science division where the instrument was being Explorer program that saw current missions overrundeveloped wanted a gas replenishment system added to ning and pushing subsequent missions downstream to

assure the PCA would last for the entire mission. the point where their science was becoming marginal.

Adding a gas replenishment system would mean The science community was upset and wanted better

interrupting spacecraft integration and testing; devel- performance from NASA.

oping a new subsystem and integrating it onto the I summarized my arguments to the director. The

spacecraft; modifying all the PCA modules; including a Engineering Directorate had taken responsibility for the

complex integration of the instrument onto the space- spacecraft development when we established XTE as an

craft; and implementing a more complex performance in-house project at Goddard Space Flight Center, and

and environmental test process. It was the wrong answer also was supporting the PCA development.

because it made a simple design more complex and “It adds complexity,” I reiterated. “It’s a significant

added little value to the mission at a major cost in time cost impact for only a marginal reliability increase.”

and dollars. Our mission couldn’t afford the additional His response was music to my ears, “Jim, I won’t

budget and schedule risks. stand in your way, but you’ll have to convince the scienXTE was the latest of a long line of projects being tists and engineers.”

Enough Is Enough

by James Barrowman 

“It’s the wrong thing to be doing,” I told the director of

engineering, trying to head off a last minute change in our X-ray

Timing Explorer (XTE) project
8 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

Now comes the real work

My next stop was the science division where the instrument in question was being developed. I was anticipating a fight because I knew that the scientists and

instrument engineers thought they needed the system in

order to assure a longer life for the PCA. There was real

disagreement on the benefits of the change and the

impacts. Four of the PCA modules were sealed well and

leak tests had confirmed they would last beyond two

years. Only one module had a

problem. None of this was outside

the parameters of the project’s basic

requirements, and I knew that I was

going to need to rely on those

requirements if I was going to win

this argument.

I entered the fray, so to speak,

because the XTE project manager

had asked me to get involved. I was

the Explorers program manager, but

I worked with my project managers in a way that

encouraged them to consider me their deputy. They

gave me jobs to do that helped them out. In the process,

I created a stronger bond so that they didn’t simply view

me as a boss, but as somebody who supported them. The

project manager and the spacecraft manager wanted to

stay focused on the mission development while I fought

the political and technical battles necessary to prevent

disrupting progress.

As part of our plan to pull XTE off for a fixed price,

we worked closely with the science team to document

the mission requirements. We struggled together to

make the requirements specific, clear, and to the

greatest extent possible quantitative. As a result,

the XTE project plan identified performance requirements on all the major mission elements. Two of the

requirements bore directly on this situation: The

mission had to last two years, and four of the five PCA

modules had to be operative for that time period. Of

course, the scientists’ goal was for XTE to last much

longer than two years and to have all five PCA modules

operating as long as possible.

It’s important to note here that we didn’t negotiate

our requirements in isolation at the beginning of the

project. Our requirements were well thought out and

realistic because they were established after we had taken implementation approaches into consideration

during initial formulation. First, the

scientists laid out broad goals.

Eventually, we gained an understanding of the architecture, implementation, and programmatic issues,

and we were able to sign off on

realistic requirements.

Sealing the deal

When it was time to remind people about these requirements, I met with the instrument team and laid out the

total situation, both technical and programmatic. All the

key scientists and managers had signed the XTE project

plan, and we supposedly had a firm and broad

agreement on our direction and plan. “These are your

requirements, guys,” I said. “You signed up for them, and

you agreed to them.”

I didn’t have to say it explicitly because it was clear

what I was getting at: Where’s your integrity? If you didn’t

mean this, why did you sign up for it?

They weren’t happy, but they agreed not to pursue

the gas replenishment system. Our mission requirements were being met. The scientists stood by their

requirements and confirmed their understanding that we

We were both trying to break

the unhealthy spiral in the

Explorer program that saw

current missions overrunning

and pushing subsequent

missions downstream to the

point where their science 

was becoming marginal.

Left: Liftoff on December 30, 1995. Middle: The XTE project team stands in front of the launch vehicle at 

Cape Canaveral. Right: The Proportional Counter Array (PCA) instrument has five xenon gas detectors used 

to study x-ray emitting objects in the Milky Way and beyond. 
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 9

had taken on this mission for a fixed

price in response to concerns from

the broader science community.

Once that decision was made,

my engineers refocused on the question of the leak. The

instrument development team redoubled their efforts to

seal the fifth PCA module. Eventually, they found a

tolerance build-up and fixed it in time to get the module

delivered on schedule.

The XTE mission was ready on time and well within

budget. It is now on orbit as the Rossi X-ray Timing

Explorer (RXTE) mission in honor of astronomer Bruno

Rossi. RXTE has dramatically improved the understanding of the high-energy phenomena in the universe,

discovered black holes at the center of galaxies, and correlated the size of black holes to the size of the galaxies.

Not only did the mission meet its requirements,

RXTE is still scientifically productive after seven years in

orbit, and there has been no degradation of the PCA

performance. The time we spent

working with the scientists to get

the right requirements clearly

understood and mutually accepted

has reaped a far greater return on investment than we

dared to imagine. •

LESSONS

• Clear, documented requirements help you control the

scope of your project and resist unnecessary changes.

Have all key parties sign off on the requirements to

assure that they understand and are committed to them.

• Get your project requirements right as soon as

possible, but not prematurely. To assure they are

realistic, requirements should not be finalized until after

implementation approaches have been considered.

QUESTION

How do you know you are done defining requirements?

Deputized

As head of the Explorers Program, JAMES BARROWMAN oversaw the successful

launch of eight Explorer missions in three years. In his story, “Pin the Deputy’s

Badge on Me” (ASK 3), Barrowman explained that the program’s tight resources

inspired him to serve as deputy to the project managers working under him. “In

addition to reducing overhead while maintaining technical positions,” Barrowman

wrote, “I felt this would change my relationship with the project managers from

boss to supporter.” But did it work?

Despite competing time demands, initially “nervous and disoriented” staff, and

occasional differences of opinion, the novel arrangement translated into a

successfully run program. Barrowman summed up the experience this way: “In

the end, the project managers and their staffs were satisfied, I was satisfied,

and we were all able to operate an effective and efficient program.” 

Over the course of a 22-year career as a project and program manager at

Goddard Space Flight Center, Barrowman received the NASA Outstanding

Leadership Medal, the GSFC Award of Merit, and two NASA Exceptional Service

medals. He has been a longtime supporter of APPL programs, and can be

reached at jbarrowman@comcast.net

The project manager and the

spacecraft manager wanted

to stay focused on the mission

development while I fought

the political and technical

battles necessary to prevent

disrupting progress. 
10 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

tic tick

tock

k

tock tick

tick

tock

tick

ticktock

tick ticktick

ticktock

tick

tock

tick

tick

toc

tick
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 11

Recently, I worked on creating a one-of-a-kind device for a Space

Station group studying exercise physiology at another NASA Center.

They approached my department at Ames Research Center to design

and build an exercise bed that allowed users to perform the motions that

they needed for ground-based research. The real challenge was that

they needed the device designed, built, and delivered in just one month. 

I DREW UP ROUGH SKETCHES OF A DESIGN FOLLOWING THE

initial plan described to me. The bed was intended to

simulate doing squats while in a horizontal position as if

on a moving sled. They wanted to incorporate a resistant

device called an Interim Resistive Exercise Device (IRED),

an adjustable cable tied into a reel to provide a measured

amount of resistance. This device was used on the Station

for exercising in space; we were taking the same resistant

reel and incorporating it in this bed.

In the early stages of a design project, I communicate with a customer as much as I can and as often as

they will tolerate. There’s a lot of learning that needs to

go on, and I prefer to spend a little bit of extra time here

because that can save a lot of time later. In the beginning,

you need to volley the information back-and-forth, so

that you understand the customer’s requirements and

they know what you’re capable of doing.

the clock is ticking

by Dan Gundo

tick

to

tick ck

k
SYNCHRONIZING OUR WATCHES

They liked my initial sketches, so I started

adding more detail. I also started to identify

the shopping list of materials. I explained why I recommended certain materials over others, and how I would

go about building the bed based on the resources that I

had available to me. We also were narrowing down the

cost of it. All of these issues have to be considered from

the perspective of producing a design as quickly as

possible. This whole process I’ve described happens in a

matter of days, sometimes even hours.

When I’m designing something from scratch, there

are a lot of uncertainties. In my design for the exercise, I

implemented adjustability into the device—more than

they had asked for initially—because I knew that people

of different heights might need to use the bed. I put

more travel in the foot rest when I realized that it didn’t

have enough range.

It’s okay to be flexible and change something many

times while it’s still a design, because it’s a heck of a lot

easier to change your design on paper than it is to

change things once you have metal cut, welded, and

machined. Sometimes researchers will come up with

another idea and another idea and another. These can

have major ripple effects on all of the parts, pieces, and

components of how the device is sized, shaped, and

built. So, there comes a point when I want the customer

to say, “Okay, I’m settled on this design. This is it. We’re

going to move forward with it and we’re not going to

change anything.”

From my perspective, the priority on any project is

to deliver it on the due date. I can make the most

wonderfully innovative device that has ever been seen on

earth, but if I don’t get it done in time for the customer

to use it, then it’s all been a waste.

ELEVENTH HOUR

You can probably guess where this story is

going. At the point at which I thought we

were ready to start buying the materials and cutting

metal, my customers introduced a significant change to

the requirements. Somebody within their group decided

that a counterweight to neutralize the weight and

introduce vertical motion of the hips was crucial to the

performance of the exercise. It changed the complexity

of the project substantially—just a couple of weeks

before the due date.

When my customer came back to me asking for this

last-minute change, I knew that the responsibility was on

my shoulders to make it happen. I wanted to build a

product that met their needs, but I didn’t quite understand the details.

I had to know for certain, without a doubt, what they

wanted—and there was no time in our schedule or travel

money in the budget to arrange a face-to-face meeting.

To try and get that over the phone, or in a faxed sketch

wouldn’t eliminate my doubt. So, in order to hold their

feet to the fire on specifics, I said, “I need you guys to

create detailed drawings and then send them to me as

soon as possible.”

Now, I don’t normally ask a customer to do the design

work on a project, but this was a customer who had worked

with hardware exercise devices before and who had added

a last-minute function to the design. I wanted them to

realize the ramifications of a change like this—hopefully,

preempting any additional changes. I like to retain as much

flexibility as I can during a project, but the customer has to

understand that the manufacturing process doesn’t allow

for ambiguity. I had to shift responsibility for finalizing the

design to my customer at this point.

To their credit, they stepped up and delivered the

drawings right away. There were a few mistakes but we

were able to make the fixes and corrections, and still

keep moving forward. We had the idea in mind.

THEN WE START ROCKING

When you’re doing design and fabrication on

a unique product and you’re being asked to

deliver on a tight deadline, the project is laced with

unknowns. The path of these projects can change at any

time—but there is still a method to the madness. One

thing I do is keep close track of everything that needs to

be accomplished during the development process—from

clarifying objectives, to sketching and sizing, to assembly.

Throughout the years, I have developed a file where

I keep track of sources for unique parts, tools, and

12 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

I can make the most wonderfully innovative device that has ever been seen

on earth, but if I don’t get it done in time for the customer to use it, then it’s

all been a waste.
instruments—things like special bearings that I don’t

keep stocked because they’re not needed often. I have

contact information for these sorts of materials and for

all my available vendors, so that I don’t waste time trying

to track down a part or a tool required by an eleventhhour development.

I’m also prepared to suggest trade offs when they’re

necessary to finish on schedule. For example, we planned

to paint the frame of the bed, but we ran so short on time

that we didn’t paint it. It wasn’t going to affect the

function of the device. That was an easy compromise;

others are more difficult.

Initially, they wanted the frame made out of steel.

Cutting, machining, shaping, and welding steel requires

more time than alternative materials. Aluminum is easier

and quicker to cut and machine. Plus, it’s much lighter and

easier to handle. It cost a little bit more money, but I was

able to save time by building the frame out of aluminum.

When you’re short on time, man-hours are

something that you can’t make up. When we encountered

some warping in the welded frame, I went to the

researchers and told them, “We can still get this done if

you’ll increase the service request to support more people.”

They agreed to it, and I brought in additional shop technicians to help solve the problem. They were also critical in

addressing a last-minute problem with linear bearings.

All projects like this one involve some degree of trial

and error, building and rebuilding, reaching compromises, and learning from mistakes. In the end, our

customers had to compromise slightly on cost, but we

completed the project on time.

In my world of designing and creating new products,

the one constant is speed—not to mention the byproduct

of speed: pressure. Some projects may not involve the

same level of pressure, but when you complete a quickturnaround project on time and you’ve met all of the

challenges that at first seemed overwhelming, the reward

also seems to be that much greater. •

LESSONS

• When creating a unique project, customers don’t

always know the details of what they need at the start

of a project. Close communication between the project

team and the customer facilitates a continuous

learning process.

• Knowing when to be flexible and when to be firm is a

hallmark of successful project management.

QUESTION

How important is face-to-face communication when working

with a client?

ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 13

Ever since space missions began, NASA has worked

to address problems caused by the deterioration of

bone and muscle tissue due to weightlessness. One

method for evaluating prevention and recovery treatments for this problem is to expose normally healthy

individuals to periods of bed-rest that duplicate many of the spaceweightlessness symptoms. Bed-rest participants remain in a prone

position for up to thirty days without sitting up or standing. 

The exercise bed described here by Ames Research Center prototyping specialist DAN GUNDO is typical of the kinds of projects he

works on. Gundo uses a process he describes as “prototype-asdesign” to create unique, one-of-a-kind research hardware for small,

high-risk projects. Prototype-as-design is a highly interactive,

integrated process that allows multiple iterations of complex aspects

of a desired R&D product to be quickly evaluated and adapted into

a properly functioning whole.

This is Dan Gundo’s first appearance in ASK Magazine. You can

contact him at Daniel.P.Gundo@nasa.gov.

I wanted them to realize the ramifications of a change like this—hopefully,

preempting any additional changes.

THE UNBEARABLE LIGHTNESS OF MICROGRAVITY
14 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

ALONG WITH OUR PROCUREMENT MANAGER AND THE

project manager of the recently completed project,

I traveled to the vendor’s shop where these modules

were fabricated. On the earlier project, after the bugs

were worked out of the design, our company purchased

more than twenty of these units. The first unit cost

about $180,000, but as the design was tested and

reworked, the T&M price came down to about

$120,000 per unit for the remainder of the order.

As soon as I walked into Company A’s shop, I

started getting a sales pitch. The shop supervisor, who

I knew from a previous project, said, “Well, Dave, I’d like

to introduce you to Sam, who’s going to be your fabrication and assembly manager. Any time you

want anything, day or night, just call Sam.” He went on

to tell me, “Here are the machines that are ready to

chunk out all your parts the minute you tell us to start

cutting steel.”

I liked what I saw in the shop, even without the

sales pitch.

And then, on top of that, our procurement manager

and the project manager from our first project took me

off to the side to give me their own version of the sales

pitch. They told me that sticking with Company A’s

current design and fabrication would make my life easier

and would allow me to focus on other parts of my

project. It was very tempting to think about putting this

part of the project behind me.

At the end of the day, we regrouped with

Company A’s personnel in a conference room. The

vendor’s representatives said that if I would give them

the green light, they would deliver the 50+ machines I

LISTENING

TO THAT

VOICE INSIDE

BY DAVE STICKEL

A few years ago, I was managing a

project whose scope included the

addition of several new unit operations

to existing production lines. Part of my

project involved adding a fabricated

module similar to one another project

had recently purchased on a T&M

(Time & Material) basis from Company

A. This company had done a good job,

so prevailing wisdom dictated all we

had to do for this part of the job was

to adapt the design to our production

lines, and go.

THIEN-KIM PHAM
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 15

needed at about $118,000/unit. My procurement

manager and fellow project manager thought this was

what I should do, but I was uneasy. It just didn’t make

sense to me.

This particular unit operation is similar to a

number of other unit operations throughout the

manufacturing process, and the design for this one

wasn’t all that dissimilar from them. I knew we had paid

a lot less for those other unit operations.

So I said, “I’ve just got to think about this.” I didn’t

know exactly what I wanted to think about, but I knew I

didn’t want to make a decision right on the spot. I had a

lot of experience making quick decisions, but something

told me to follow my instinct that this decision required

more consideration. In the cab to the airport and on the

plane on the way home, I kept hearing from my two

compatriots that I was making a big mistake by not

accepting this offer.

When I got home, I checked my phone messages.

Company A’s shop superintendent had left me a

message. He said, “After you left today, we got together

and we sharpened our pencils, and we decided that we

can do your project at about $108,000 a machine.” It

wasn’t hard to figure out the math; we would save

$10,000 on each of the 50 or so machines. And I said,

“Wow! All I did was say I wanted to think about it, and I

saved a half a million dollars.” My delay of six hours was

paying dividends.

But I still wasn’t satisfied. This unit operation

wasn’t on the critical path of my project, so there was no

reason I had to make the decision immediately. I had

time in my schedule, and I decided to go out for competitive bidding. We bid Company A along with a number

of other shops I was familiar with. A few weeks later, I

received a bid from Company A for $93,000 per unit.

But they still didn’t get the job. We awarded the contract

at $67,000 per unit to Company B, where I also knew the

people.

At the pre-award meeting at Company B, I said,

“You know, I’ve got to be honest with you. You’re the

lowest bid. Are you confident that you understand this

bid?” Long ago, I learned that it isn’t good business to

take advantage of an underbid—because if you put

someone out of business and they don’t deliver, your

own program suffers, too.

They told me they were confident. And it turned

out well. They had done their homework, and we had

done ours in working with them and making sure they

understood what they were getting into.

In the end, I saved more than $2.5 million by

following my gut instinct, which said, “I’ve got time to

think about this.” I took advantage of the opportunity to

step back even when everybody else was telling me,

“You ought to do this right now.” Because of that

project, I’ve been willing to trust my instincts more. •

LESSONS

• Many leaders who commonly use intuition are

reluctant to talk about it, considering it too soft and

“mystical” a process to openly acknowledge. But the

more we share and discuss stories of decisions based on

intuition, the more we learn about when and how to

employ it.

• Trusting one’s intuition doesn’t necessarily mean one

has to abandon well accepted processes.

QUESTION

Some people say: “Don’t listen to your intuition. Intuition is

nothing more than justification of luck.” Do you agree?

GOT MILK?

In his 26 years with Procter &

Gamble, DAVE STICKEL has been

involved in capital projects as project

manager, cost engineer, and start-up

leader. Currently, he serves as the

Global Process Owner for Capital Project Management

Technology, part of the Corporate Engineering organization at P&G.

“My favorite story about Dave,” says ASK feature writer

W. Scott Cameron, also of Procter & Gamble, “is the

time when he asked me to review a hierarchical presentation he was going to give.” Cameron didn’t think

Stickel directly stated what he wanted from his

audience. “My feedback,” says Cameron, “was that

he’d done an excellent job of describing a cow, but he

should tell his audience it was a cow and not make

them guess he had described a cow.” Stickel took the

feedback positively, and Cameron assumed that was

the end of the story. 

A few months later when he visited Stickel’s office,

Cameron saw a picture of a cow tacked on a bulletin

board with the phrase “It’s a cow” under the

picture. “I guess Dave took my input to

heart,” says Cameron.
MY EXPERIENCE AS A FIRST-TIME PROJECT MANAGER ON THE

Stardust mission brought those days back for me. The

point is that one can work hard and succeed in an

activity only to find the success is just an “entry ticket”

to a larger, more daunting set of challenges. Confidence

and the thrill of victory suddenly give way to anxiety

regarding a new potential for failure. One then must

revisit and develop a new determination to succeed at

the next level. I’ve learned that you go through several

steps in an adventure—the first being euphoria, second

being anxiety, and then, finally, resolve.

As a pre-project manager, I found myself part of a

team—comprised of the Jet Propulsion Laboratory (JPL),

Lockheed Martin Astronautics (LMA), and our Principal

Investigator from the University of Washington—

competing against 27 other proposal teams to “win”

selection under NASA’s 1994 Announcement of

Opportunity for the fourth in its Discovery program

series of low-cost, highly focused projects. Our entry was

Stardust, a mission to fly through the dust cloud

surrounding the nucleus of a comet called Wild 2, catch

some of the cometary particles and bring them back to

Earth. As a tantalizing bonus, our proposal included a

secondary objective to capture some particles of an even

more elusive nature. Galileo and some of our earlier

spacecraft had discovered a particle stream going across

the solar system, and we wanted to try to catch some of

that stardust. We proposed to trap these smaller, speedier

16 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

by Dr. Kenneth L. Atkins

I served nine years in the Air Force, and I had the good fortune to become a pilot during that

time. I can still remember the day I got my wings. One day, I was one of the most senior student

pilots in the Air Force and, the next day, the greenest fighter pilot that they ever saw.
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 17

particles on our way to the comet. Hence, the name

Stardust for the proposed project.

Our proposal package was the subject of thorough

discussions and reviews during an intense, competitive

approval process. After we submitted the proposal, there

was the usual lag time between submission, review, and

then notification. I went back to my day job, which was

in line management.

Then one day I got a call from the Principal

Investigator (PI), Dr. Don Brownlee, who said, “Hey, we

won! We actually won this thing!” He was incredulous. I

was stunned. I was going to manage my first project!

Stardust had been selected from a field of 28 mission

proposals to be part of the “Faster, Better, Cheaper”

Discovery program series. Approval meant that we were

locked into a $200 million contract. Not only was our

total budget set, the funding would be delivered to the

project based on the dollar amounts we had allocated for

each phase of the project.

And I thought, “Gee, this is really great! We did it!

We succeeded!” Then, I had another thought, “But

there’s no team.” Like me, they had all gone back to their

day jobs. So, I had to go round all these people back up

again—and, once I had, we were all in a wonderful state

of euphoria. Suddenly we were walking around the

laboratory and people were saying, “Oh, there they go.

Those guys won. They’re the next big deal here.”

The euphoria fades

After we pulled the team together, we went to work on

the project. We were all excited, saying things like,

“We’re going to bring back a thousand ten-micron size

particles; we’re going to get pictures; we’re going to

catch some stardust.” Then we took a closer look at our

budget as we put our work structure and our organization together.

I looked at the $9.6 million budgeted for startup,

and could see that it wouldn’t be enough to get the
project going. Eventually we would

have all the money we needed—but

when I looked at the schedule and

what had to happen with our initial

funds, anxiety set in.

My team came to me and

confirmed my anxiety with specifics

on our initial dilemma. “The

telecom radios are ‘long-lead’ items.

To make our schedule we need to

get on contract right away. How are

we going to get those contracts

funded now? We don’t have the

money budgeted in our Phase B pot

to get started on time.” And I

realized that we had made a big

mistake.

That’s when I learned that it’s one thing to put the

money together. It’s another thing to put it into all the

right buckets, and it’s an even more crucial thing to get

it out in a timely fashion. As we worked through the

problem with LMA, our contractor, it was clear we had

been overly optimistic in how much time their subcontractor, Motorola, would need to prepare a new contract

for the transponders. We also discovered that another

LMA project already had a contract in place for the same

transponders we needed to buy. If we could act quickly

we could simply “add” our units to that contract, but we

needed about $11 to $13 million immediately.

I met with the PI and told him, “We’ve got to be

allowed to spend our transponder money earlier than we

planned. In fact, we need to commit it now.”

And he said, “Well, golly, you know our budget

profile says NASA doesn’t provide that money now; they

might not even have the cash available. Our deal was

based on not starting the transponder contract till Phase

C. If we ask for it now, we’re going to look...”

“You don’t need to tell me how we’ll look,” I cut

him off. “We may have the money budgeted for later, but

if we can’t get it on this existing contract in Phase B

instead of C, we’re dead!”

So much for the euphoria of winning the

proposal, and thinking we had everything locked up

when our project plan was signed. We had the money,

and we thought we knew how to do this thing—but

our flawed cash flow plan stood between a successful

project and us.

Before this realization ever occurred, I had put

together a small advisory group of Tom Gavin, flight

systems manager on the Cassini

mission; Tony Spear, the project

manager on the Mars Pathfinder;

Mike Sander, past project manager

on SIR-C who was currently

director of JPL’s Technology and

Applications Program; and Joe

Savino, a long-time “guru” of the

electronics division. As I struggled

to find a way out of the problem, I

definitely needed some advice, and I

went to them. I laid out my

dilemma, and said, “Look, if I can’t

get Headquarters to revise my cash

flow and give me a better funding

profile than I’ve got, we won’t be

able to do it.”

And they said, “You know what, you’re absolutely

right.”

“I didn’t want to hear that, guys,” I told them. “I

came here looking for a miracle.”

Time for resolve 

I had competed with other project teams to win approval

for my project, but it turned out that I had promised

something that I couldn’t deliver. That old cliché, “the

Devil is in the details,” took on new clarity. If my project

stumbled so quickly, I would essentially be putting the

credibility of NASA’s selection process in doubt.

I decided that the best thing to do was to be upfront

about my mistake. I accepted the fact that sometimes the

only way out...is through! I was going to have to go to

the NASA Discovery program manager and say, “I’m not

going to spend any of your money unless I can

guarantee we can launch this project successfully.” I

wasn’t going to ask for any more money for the overall

project than originally budgeted, but I needed to have

the cash flow changed.

So, I mustered as much of my courage as I could

(with my tail between my legs) and set up a conference

call with Mark Saunders, who was the Discovery

program manager at that time.

I said, “Mark, I’ve got good news and bad news. The

good news is the project looks OK for the amount of

money we signed up for. But the bad news is that unless

we get some money earlier than we’re scheduled for, I’ll

have to put my badge on the table and walk away. We just

won’t be able to make the critical path.” Along with our PI,

Don Brownlee, and LMA program manager, Joe Vellinga,

18 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

It’s one thing to put the money

together. It’s another thing to 

put it into all the right buckets.

A technician completes work on the

collector used to capture cometary

particles and interstellar dust. 
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 19

I explained the dilemma and the potential to utilize the

existing contract to make schedule if we could fund it now.

That’s when the miracle happened. He said, “How

much do you need?” Just those words implied hope. I

expected something more like what a rebellious son

might hear in a woodshed. “Are you guys nuts? You made

this deal, now live up to it.” Or worse.

Before he had time to reconsider, I said, as casually as

possible, “Oh, I need about eleven to thirteen million.”

(Inside I was anything but “casual,” because that was a lot

of money to have incorrectly planned in a budget profile.

I considered it to be a big mistake, but I was desperately

trying to keep my cool.) And he said, “Well, you’re in luck.

Our Near Earth Asteroid Rendezvous project is currently

under-running, so my funding flexibility happens to be

good right now. I can ‘prefer’ [send early] the money.”

It goes without saying that salvation does wonders

for depression. After some appropriate-level gratitude

statements and a little groveling-recovery, we ended the

telecom with a new level of appreciation for careful cash

flow planning and a resolve to not be in this situation again.

Certainly, our admiration for the Discovery

program manager, Mark, who had been so tough during

the competitive phase of the proposal, skyrocketed.

What wisdom. What mercy. He could rightly have sliced

and diced us before giving us the money, but he chose

to listen. He chose to understand. And with his own

flexibility, he had achieved a higher level of motivation

and resolve in the project leadership team by working

with us, not on us. It was a good day.

Stardust was successfully launched on February 7,

1999. It has been flying extremely well, and has spent

quite a bit of time with its collector exposed to the

stardust mentioned early on in this story. It’s on its way,

hopefully, to a successful fly-through with the comet in

January 2004—and a return to earth in 2006 with both

comet particles and stardust. I was even able to give

money back at the end of the development and launch

phase of the project, almost a million dollars.

This thing about cash flow is something that I’m

now preaching to all the proposal teams in my current

role as a review board member. At the beginning of a

project, cash flow is king. The reason I had this screwup was because I had looked at my overall budget and

said, “We can do this.” I was inexperienced, and I didn’t

see cash flow as an issue.

I started this story by talking about my days of

excitement in the Air Force. I’ll finish by talking about

times of leisure now in my semi-retirement. I’ve played a

lot of golf during my life, but I never took any lessons. So,

frustration with my game and results has a long history.

Just recently, I faced the fact that I had no clue as to

what I was doing wrong. I went out and hired a pro to

help me. At the first lesson, he said, “Here’s how your

grip needs to be.” And he went through a lot of other

things, but the bottom line was, “If you don’t set up

correctly, you can’t hit the shot.” You can imagine how

that line struck home!

And this is what’s key to the story I just told about

Stardust. If you don’t have that cash flow set up correctly

along with the budget and the schedule, you can’t “hit

the shot” and you’re going to be in trouble. •

LESSONS

• Effective budget planning considers not only how

much money a project requires, but also when the

money is needed.

• Many times, project success isn’t the result of not

making mistakes; it’s the result of having the courage to

face mistakes head on and take action.

QUESTION

Does your work environment engender courage?

OUTREACH

If all goes as planned, the Stardust spacecraft that

DR. KENNETH ATKINS and his team launched in

1999 will travel 242 million miles from Earth to

encounter Comet Wild 2 in January 2004. En route to the

comet, the spacecraft will collect interstellar dust particles

believed to consist of ancient pre-solar grains and nebular.

Stardust will capture and store these particles by extending a

tennis racket-sized collector filled with a product called aerogel

(a glass foam, which is the lightest solid known to man). 

Also on board: two copies each of a pair of microchips,

engraved with over a million names—including names

submitted by the public during a 1997–1998 outreach

program, and all the names of soldiers memorialized on the

Vietnam Memorial in Washington, D.C. One set of chips will

remain on the spacecraft as it goes on to orbit the sun. The

second set will return to earth along with the aerogel collector

in January 2006, aboard a 125-pound reentry capsule.

The story by Atkins was based on his presentation 

at the February ’03 APPL Masters Forum. Atkins can be

contacted at Kenneth.L.Atkins@jpl.nasa.gov. Visit the Stardust

Web site at http://stardust.jpl.nasa.gov
THEANOY OR ONE WA

ZAZZALI TIAN BY CHRIS

R
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 21

IBUILD A PROJECT A HUNDRED TIMES IN MY week before the job was finished, and then install them.

head before we start work on it. I put formal plans into Great idea, everyone agreed. It would require a little

writing, but I also try to work through every scenario I more money for shipping, but that was acceptable.

can think of in advance to have everything lined up like With a week to go, I believed that the job was going

dominoes, with all the details in place. well—until I got a phone call from the superintendent.

But things still go wrong—like the time we had “The doors are here, the frames are here, all 25 of

twelve weeks to demolish one floor of a building, then them, and they look great,” he told me. But then he

build it back. After reviewing the client’s drawings, I told added the line made famous in the Apollo 13 movie:

them that the twelve-week schedule wasn’t going to “Houston, we’ve got a problem.”

work the way they had things sketched out. “What’s the problem?” I asked.

“You have us finishing the frames after the drywall’s “The frames don’t fit in the freight elevator.”

in,” I pointed out to them. “But the door frames are clear “Then carry them up,” I told him. “You know, get

oak, and there’s not enough time.” I outlined the man- some guys and haul them up the stairs.”

hours and the timing required to do the job the way they “We’ve already tried that. They won’t make the first

had stipulated, and explained why it couldn’t be completed turn because of the jog and the—”

on schedule. Then I offered an alternative solution. “I’ll be right there,” I told him.

Instead of waiting to build the frames on site, I It was at that point that I got that feeling in the pit

suggested having them built in advance at a Canadian of my stomach that every manager gets when a

millwork factory. We could have them shipped down the problem crops up with about a week to go on a project.

I got that feeling in the pit of my stomach that every manager gets

when a problem crops up with about a week to go on a project.
AS FAR AS THE CLIENT WAS

CONCERNED, THE JOB WAS

COMPLETED ON SCHEDULE.

BUT WE KNEW THAT DISASTER

HAD BEEN NARROWLY AVERTED.
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 23

It’s about the time you start thinking, “Maybe I should

just keep driving.”

How was I going to get these oversized frames up to

the 12th story of a building and installed in a week for

one of our best clients? This was a client worth millions

to my company. I couldn’t ask them for more time; they

had already scheduled the movers and the utility installations. Everything had to happen that weekend. I still

needed to file inspections before the client could move

in, and I couldn’t schedule the inspections until we had

the doors on and working properly.

As I was driving to the site, I started thinking of new

approaches to the problem. The superintendent had

told me that the frames couldn’t make the first turn. But

could they make the second? I called back and asked.

“What difference does it make if they fit through

the second turn?” he asked me. “We can’t get them past

the first turn.” But I was already thinking: Let’s figure

out a way to get rid of the first turn.

In the meanwhile, I arrived at the site. As I parked, I

looked at what was next to me: another one of my

company’s projects.We were constructing a building right

next door, and we had a tower crane sitting on the site. So

I asked the superintendent, “How about if we carry the

frames down to the 12th floor from the roof?” And he

answered, “We didn’t think about that. But the frames

aren’t on the roof; we have them on the loading dock.”

I went over and spoke to the superintendent on the

other job. In a matter of minutes we had the frames lifted

to the roof with the crane. Then all we had to do was to

carry them down two flights, instead of up twelve.

It all worked out, and our customer never knew

there was a problem. As far as the client was concerned,

the job was completed on schedule and the doors

looked great. But we knew that disaster had been

narrowly averted. Back when we were planning the job,

all I had needed to say was, “How are we going to deliver

these pre-built frames to their locations? Let’s check the

freight elevator.” Just one more detail, and we would

have had everything running smoothly.

I’ve learned that whenever I come up with a unique

solution to a problem, I need to be prepared to consider

the implications of applying that solution. What

elements of my plan are affected by the solution? What

elements of the project need to be adjusted based on

these changes?

But if it were only that simple...the truth is that

while we can avoid some problems by asking the right

questions, there still will be problems to be solved and

lessons to be learned on every project. Recognizing this

helps me to be mentally prepared to meet the challenges

in front of me, armed with two essential tools: experience and flexibility.

I try to remember what I learn on projects and carry

those lessons forward. Now, for example, I give every

contractor on every job the dimension of the freight

elevator with the pricing proposal. With that, I no longer

own the problem. It’s the contractor’s responsibility to

build something we can fit in the elevator.

Just as importantly, when problems do pop up, I try

to stay open-minded about potential solutions, and put

creative thinking to use. I try to remember that what

doesn’t go up, might just come down. •

LESSONS

• Even experienced project managers can’t anticipate

every potential problem. Part of planning ahead should

include allowing oneself the flexibility to rethink the

plan and improvise if necessary.

• Unique solutions to problems sometimes create a set

of new problems unique in nature as well. In dealing

with sudden changes in planning, try to consider what

other elements of the project will be affected, but don’t

second guess yourself into a state of inaction because

you can’t anticipate every contingency.

QUESTION

How do you create a culture that fosters both detailed planning

and flexibility?

On almost every day of the

year, HITT Corporate Interiors

begins work on about twenty

commercial construction projects

and completes another twenty.

As a senior project manager for HITT,

CHRISTIAN ZAZZALI has multiple project

managers reporting to him at any given time. His

job: to keep all the plates spinning.

Zazzali has been with HITT since 1999. He has

received the Associated Builders & Contractors’

Excellence in Construction Award.Zazzali’s story

“Thanksgiving Hocus Pocus”appeared in ASK 10.

He can be reached at czazzali@hitt-gc.com.
24 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

by

see a

W. SCOTT CAMER

ttachmen

ON

t
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 25

SINCE E-MAIL GENERATES ITSELF ON A ROUND-THE-CLOCK,

daily basis, it’s not unusual for me to receive an average

of fifty e-mails a day, or more than 300 a week. That’s a

lot of e-mail.

I have spoken with many of my fellow project

managers about my relationship with e-mail. In my case,

reading and responding to it is a temptation almost too

hard to resist. When I receive an e-mail I tend to want to

stop everything I’m doing, and open and answer it.

Indeed, in my life you could say e-mail is a force to be

reckoned with.

Interestingly, my fascination with mail began a long

time ago. I trace it back to my days as a young boy when

I started receiving my first letters from friends and

family. Walking home from school, I was often filled with

curiosity, wondering if I had received any mail that day.

In college, I knew the exact time the mail was delivered,

and I headed for my mailbox as close to that hour as I

could. After that, I served in an Army Reserve Post Office

Unit, where I came to realize how important a postal

unit was to the military. There were many others like

myself, far from home, who relied on the written word to

stay connected to the people in their lives.

Over the years I have changed in many ways, and so

has the mail. But the same sense of connection, and the

same urge to respond to someone who has written me,

remains. The 24/7 nature of e-mail has compounded the

situation. It is relentless in its pursuit of my time and

attention—and, as such, e-mail has become something I

have had to manage in a variety of situations.

I’ve learned that being seduced by e-mail is far from

uncommon experience. I was talking with another

manager and he told me he was having problems with

some of his younger engineers, as they were spending

more time on their computers answering e-mails than

on the shop floor managing their projects. He wanted

the engineers to interact more with the people on the

shop floor, and he felt this problem was having a

negative impact on their performance and how their coworkers perceived them. When he confronted one of the

engineers, the response he received was that it was the

engineer’s job to answer e-mails—not necessarily to be

on the shop floor all the time. They both had a point.

Project managers must lead by example. As we

continue to increase the amount of time we spend on

tasks like e-mail, so must we continue to improve our

time management skills. We need to make conscious

decisions about the minutes and hours we will spend

staring at the screen and emptying the inbox, and how

we will utilize this tool to our advantage.

Another situation I’ve had to deal with is whether to

take my computer on vacation or leave it at the office.

After much thought and negotiation with my family, I

decided to take my computer on vacation. I have received

many comments about this decision (i.e. are you a

workaholic, are you crazy, a vacation is for rest not

answering e-mail). I really can’t argue with these

comments, but I have imposed some restrictions on

myself so my vacation isn’t just an alternative work

location: I don’t read my e-mail every day of vacation, I

don’t let what I read in an e-mail change the timing of

any of our vacation plans, and I only access my e-mail

during “dead time” when my family is doing other things.

I’ve reasoned taking my computer on vacation is

healthy for me. It reduces my stress level upon return to

work. While it’s still easy for me to get excited about a

letter waiting in my mailbox, coming home to 350 or

more e-mails is hardly what I would call “seductive.” •

“SEDUCTIVE” IS A WORD RARELY ASSOCIATED WITH PROJECT MANAGEMENT. AN

EXPRESSION LIKE “24/7,” ON THE OTHER HAND, IS ALL TOO FAMILIAR. MARRY THESE

TWO, AND ANOTHER WORD IS BORN: “E-MAIL.”

W. SCOTT CAMERON is the Capital

Systems Manager for the Food & Beverage

Global Business Unit of Proctor &

Gamble. He is also a regular contributor

to ASK Magazine. He can be reached at

cameron.ws@pg.com.

What worked for snail mail, works for e-mail:

Back when snail mail was the only mail I had to

contend with, a performance coach taught me a

few tips that I continue to use today.

• Touch each piece of mail only once.

• Either pitch the mail or respond immediately.

(As a last resort, defer action until another day.)

• Keep a minimal number of files so you’re not

tempted to warehouse a large amount of mail.
26 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

REQUIREMENTS

THE MORE THE BETTER?

BY TERRY LITTLE
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 27

FOR AS LONG AS I CAN REMEMBER, WE IN THE DEPARTMENT

of Defense have based our development programs on

user requirements. The process is more or less sequential.

The user develops the requirements, supposedly driven

by the threat, and the developer structures a program to

satisfy them.

Great process, right? Nope. It’s a bankrupt process

that has failed time after time.

In truth, most of the so-called “requirements”

are really “desirements.”

They have little or

nothing to do with the

threat or real need,

but everything to do

with what the user or

sponsor thinks may be

possible. And what’s the

worst part? Much of

what ends up in the

requirements stem from

what overly optimistic,

fiscally naive program

people—government or

contractor—eager to “sell” the program have told the user

or sponsor they can do.

When the chickens come home to roost, as they always

do, one can invariably trace many a program problem 

to having written unrealistic expectations into the requirements. It’s a self-fulfilling prophecy.

How does one deal with this? Simple. Nothing ever,

ever, becomes a requirement until two things happen: (1)

there is a solid understanding and acceptance of the

requirement’s cost and schedule implications; and (2)

knowledgeable technical people are so confident that the

program can meet the requirement within the cost and

schedule that they are willing to bet their jobs on it.

Yikes!! Does this mean that we never undertake

high-risk projects? No. What it does mean is that when

you undertake high-risk activities, you agree on an expectation or requirement that includes failure, or falling

short, as a real possibility, and your cost and schedule

reflect the risk. The other thing that it means is that you

may have to start a project with some requirements open

until after the work progresses to a point where the

requirement meets the two criteria above.

The process is also flawed because there are usually

too many requirements. Something about the

engineering or designer mentality seems to demand hosts

of requirements as an input to the technical process.

Granted, it’s more comforting to have someone else issue

the requirements than it is to have to derive them. But,

being overly constrained by too many requirements with

too little wiggle-room will invariably create problems. In a

perfect world, a sponsor’s requirement would only be to

obtain a certain capability with the detailed technical

requirements derived from what’s truly possible.

Linked to this issue of over-specification is the

problem of prioritization of requirements. If everything is

equally important, then

nothing is important.

In my estimation, a

program or project

should start with only a

few key requirements.

“Few” means not more

than four or five, and

“key” means that, if the

program doesn’t meet

these requirements, it

should be terminated.

Finally, within DoD

cost is almost never a

requirement, much less a key requirement, but it should

be—always. Cost is a technical issue. We can only buy 

as much technical requirement as we can afford. It’s 

true when we buy a car, and it’s also true when we initiate

a project.

My practice has been to put cost—which may be

development, production, or both, depending on the

program—into the technical performance specification.

Why do this? I do it to make clear that everyone on the

project, most especially the technical people, must own

cost just as they do performance. Cost can’t be just the

concern of the project manager or the budget analyst.

Everyone has to own it.

So what does all this mean? Simple. One sows the

seeds of a project’s success or failure during the

requirements stage. With bad seeds the fruit will be

bitter indeed. •

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.

Being overly constrained by

too many requirements with

too little wiggle-room will

invariably create problems.
28 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

Tipping 

SPECIAL FEATURE: KNOWLEDGE SHARING
AS AN ACTIVIST FOR THE PROJECT COMMUNITY AT NASA’S

Ames Research Center, I see my role as finding out what

resources project managers need to help them run

successful projects. I need to go out and advocate for

those resources, if necessary, and I need to be

supportive—not just for the projects, but also for the

project managers and their teams. It’s not something I

can do sitting at my desk waiting for the phone to ring.

To me, that’s what an activist does. It’s public service. In

this case, my public is the project-practitioner community.

From the streets of Palo Alto to the stars

When I first came to California in 1972, I went to work

at a drug abuse treatment center, right in the middle of a

Palo Alto business community—a community who,

incidentally, circulated petitions in an attempt to prevent

us from moving in. They didn’t want drug addicts living

in the neighborhood or hanging around their businesses.

At the time, the only place people detoxified was in the

street or in jail. Or they died.

Within two years, the very same business people

who got the petitions signed to have us barred were

getting petitions signed for the city to continue our

funding in the same location.

How was that?

It was about building relationships. For example,

the leader of the we-don’t-want-those-folks-in-here

movement was a barber whose shop was right next door

to our drug treatment center. A few of us from the center

would talk with him over a game of chess because we

ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 29

e

the Balanc

JOAN BAEZ

by Claire Smith

your needs met, you had to be an activist. 

Pennsylvania—from a culture and a community where in order

I come from a small coal mining town in

had to stand up for yourself.

afford to sit around and wait for the world to give things to you. 

to get

You could not

You
learned he liked to play. He got to know us. Then we

started going out to lunch with him. Eventually, we

brought clients to his shop for haircuts. Little by little, he

became a part of the community that we were serving, and

an advocate. And this all happened before the night his

son overdosed. That night, we were the people he came

to, the people who saved his son’s life.

We were building a community—just like we’re doing

now at Ames, and with the Academy of Program and

Project Leadership (APPL). This time around, we’re trying

to build a community of practice. We’re trying to spread

the message that knowledge sharing isn’t something that

you do to people. It is something you do with people.

APPL West 

When I came to Ames in August of 1998 in the

Training and Development Group, I was the fifth

person in that job in two years. People were skeptical

that I would be any more successful than my predecessors, but a part of my approach is that I don’t carry

around other people’s legacies. After all, if I didn’t

believe in people’s capacity to do wonderful things, I

never would have been a drug treatment counselor. I

would have been a drug dealer.

One of the items on my to-do list was to learn if

anybody was interested in project management

training. I didn’t come in with an agenda. My approach

was: What do you want? What do you need? How can

I help you? 

I didn’t know anybody. The fact that I was in a

position of having to ask questions helped me connect

with people at Ames. For example, as I talked to people,

I found out that the number one reason why people

weren’t going to training was the lack of travel dollars.

There were other issues, of course, but that was one I

thought I could handle. I said, “Well, if we can’t go to

Wallops Island, Virginia [where APPL conducted all of

its project management training courses], then we will

bring APPL to Ames.”

The very first time I met with Ed Hoffman, the

APPL Director, I said, “Ed, what do you think if we

turned Ames into APPL West and brought APPL

resources to the West Coast?”

He said, “Oh, oh, okay, sure.” Later, as Ed tells it, he

turned to Tony Maturo, APPL Deputy Director, and

said, “Who is this nut case from California?”

The only catch was that I had to make it happen.

But it was even more complicated than that. As I quickly

discovered, a constellation of forces needed to be

brought together to say, “We are going to make this

happen.” For example, my organization managed the

training conference center building. Lodging, however,

was managed by another organization. Then there were

the procurement people, whose buy-in was needed in

order to release Ames training dollars to do these

residential courses. So I had to convince a lot of different

people that this was good for the project management

community and good for Ames, in terms of bringing

courses here that people wanted.

The first thing I did was to take a community-organizing approach. Rather than simply throw it together and

say, “This is a Claire thing,” I wanted it to be something

that was independent of me, something that would

continue because it existed as part of the culture, rather

than because one person wanted it to happen. I invited

other people to join me in planning our first steps.

We started off with one class. We made up flyers.

We had leaflets. I passed them around like I did in the

It’s not something I can do sitting at my desk waiting for the phone to ring.

30 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

Ames Research Center wind tunnel facilities at Moffett Field, California.
old days. I put them on people’s windshields. I handed

them out as people walked in the cafeteria. I did a

mailing. The class filled.

Ed Hoffman came out for the class—probably to see if

the “nut case” could pull it off.While he was here, I decided

to have a community meeting to introduce APPL. I hoped

to pose a question to my fledgling community, “What can

we do here at Ames to really look at and pay attention to

project managers, and project management development

and training?” That would be the first time we asked this

question in a public forum, but not the last. In fact, it is a

question we ask continuously. Asking it is part of how we

are building a community of practice here at Ames.

During the planning meeting for the APPL

community meeting, I was told that no one would come.

“It will never happen,” people told me. That gets back to

the message I received when I first arrived at Ames:

Nobody cares. Nobody is interested. Nobody will come.

It will never work.

But I decided, as always, that I would try it anyway.

And, you know what—people came. There was clearly 

an appetite, and it was obvious from the energy on

display at that meeting that people wanted the opportunity to come together as a community.

That APPL West community meeting was just the

beginning of a project that continues on today. I still see

myself as an activist. I still think there’s so much more

we could be doing. But here’s the happy ending to my

story: I’m not alone. •

ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 31

We’re trying to spread the message that knowledge sharing isn’t something that

you do to people. It is something you do with people..

For more information about knowledge sharing at Ames, contact Claire Smith at csmith@mail.arc.nasa.gov

At The Tipping Point

“A lot of folks don’t even know the project leaders who work in the same building, let alone 

in the same code, let alone in the same center, let alone in the same agency,” says CLAIRE SMITH,

commenting on the conditions that led to the burgeoning Knowledge Sharing Initiative (KSI)

she has organized at the NASA Ames Research Center. Since coming to Ames five years ago,

Smith has worked to nurture a community of practice among the Center’s project managers.

Today, her KSI mailing list goes out to almost 1,500 practitioners. In addition to distributing

ASK Magazine and hosting guest speakers (including Stanford professor Robert Sutton, author

of Weird Ideas That Work), Smith has planned and promoted scores of events designed to bring

the project management community together. “We’ve had pizza parties. We’ve gotten together

for dinner,” says Smith. “Anything that brings people together to tell stories that share experiences and ideas has the effect of building a community.”

Cartoon drawing provided by Claire Smith’s old friend Joan Baez.
32 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

PRACTICES

“NOT ALL SUCCESSFUL MANAGERS ARE COMPETENT AND NOT ALL FAILED MANAGERS ARE

INCOMPETENT,” READS JERRY MADDEN’S LESSON #21. “LUCK STILL PLAYS A PART IN SUCCESS OR

FAILURE, BUT LUCK FAVORS THE COMPETENT, HARD-WORKING MANAGER.”

DURING HIS DISTINGUISHED 37-YEAR CAREER AT NASA, WORDS TO THE WISE

Madden synthesized in-the-trenches experience into his

“100 Lessons Learned for Project Managers.” [#90] The seeds of problems are laid down early....

Eventually, the list grew to include 128 lessons, but the Review of most failed projects or of project problems

name never changed, and the collection of mostly indicates that the disasters were well planned to happen

serious, sometimes funny observations about project from the start.

management remains widely recognized—and often

quoted—inside and outside the Agency. [#122] Too much cost data on a proposal can blind you

to the real risks or forgotten items.

Among the wisdom captured in Madden’s lessons, were

words of warning. Madden identified both the common [#126] Make sure everyone knows what the requirepitfalls of project life and the best ways to avoid taking ments are and understands them. Much easier to say

the plunge. Never one to shy away from difficult than do....You have to have the right people look at

subjects, Madden’s lessons talk frankly about project requirements. A bunch of managers and salesmen

management’s “f” word: failure. Here we excerpt fifteen nodding agreement to requirements should not make

of Madden’s lessons that deal with project challenges. you feel safe.
[#3] The source of most problems is people but damned

if they will admit it. Know the people working on your

project, so you know what the real weak spots are.

[#20] Managers who rely on the paperwork to do the

reporting of activities are known failures.

[#91] A comfortable project manager is one waiting for

his next assignment or one on the verge of failure.

Security is not normal to project management.

[#110] Though most of us in our youth have heard the

poem that states “for want of a nail the race was lost,”

few of us realize that most space failures have a similar

origin. It is the commonplace items that tend to be

overlooked and thus do us in. The tough and difficult

tasks are normally done well. The simple and easy tasks

seem to be the ones done sloppily.

KEEPING TROUBLE AT BAY

[#44] Mistakes are all right, but failure is not. Failure is

just a mistake you can’t recover from; therefore, try to

create contingency plans and alternate approaches for

the items or plans that have high risk.

[#54] All problems are solvable in time, so make sure

you have enough schedule contingency—if you don’t,

the next project manager that takes your place will.

[#31] Redundancy in hardware can be a fiction. We are

adept at building things to be identical so that if one

fails, the other will also fail. Make sure all hardware is

treated in a build as if it were one of a kind and needed

for mission success.

[#78] History is prologue. There has not been a project

yet that has not had a parts problem despite all the

qualification and testing done on parts. Time and being

prepared to react are the only safeguards.

IF AT FIRST YOU DON’T SUCCEED

[#32] Don’t be afraid to fail or you will not succeed, but

always work at your skill to recover. Part of that skill is

knowing who can help.

[#97] Talk is not cheap. The best way to understand a

personnel or technical problem is to talk to the right

people. Lack of talk at the right levels is deadly.

[#22] If you have a problem that requires the addition of

people to solve, you should approach recruiting people

like a cook who has under-salted, i.e., a little at a time.

[#29] In case of a failure:

a. make a timeline of events and include everything

that is known;

b. put down known facts—check every theory

against them;

c. don’t beat the data until it confesses, i.e., know

when to stop trying to force-fit a scenario;

d. do not arrive at a conclusion too rapidly. Make

sure any deviation from the norm is explained —

remember the wrong conclusion is prologue to

the next failure;

e. know when to stop. •

ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 33

LESSONS FROM THE MASTER

Les Meredith, former Director of

Space Sciences, had this to say of

JERRY MADDEN and his project

do’s-and-don’ts: “God only gave us 

Ten Commandments. Jerry has

listed over a hundred instructions for a Project

Manager. It is evident a lot more is expected from a

Project Manager.”

Madden retired from NASA in 1995 as Associate

Director of Flight Projects at Goddard Space Flight

Center. Considered by many of his peers to be one of

NASA’s premiere project managers, Madden’s reputation for frank, on-target observations of project

management continues to be celebrated today, as his

list of lessons is handed down to a new generation of

project managers. 

Naturally, not all of Madden’s wisdom made it into his

“100 Lessons.” Marty Davis, who worked under

Madden at Goddard, recalls one of the unwritten

lessons: “Show up early for all meetings; they may be

serving doughnuts.”

Jerry Madden can be reached at maddenjeremiah

@netscape.net.

USE PAGE FROM

ADVERTISING SPREAD
34 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

MARGOLIES RECEIVED THE AWARD IN RECOGNITION FOR HIS

innovative leadership of the highly successful Advanced

Composition Explorer (ACE) mission. ACE launched in

August 1997, and has been providing scientists with

information about space matter and near-real-time

advance warning of geomagnetic storms. ACE is one of

several missions run in the NASA Explorer Program,

which is characterized by relatively low to moderate cost

and small- to medium-sized satellites capable of being

built, tested, and launched in a short time.

Most recently, he served as observatory manager on

another Explorer Program mission, the Microwave

Anisotropy Probe. Prior positions at Goddard include

project manager for the Total Ozone Mapping

Spectrometer mission, deputy project manager for the

Explorers and Attached Payloads Project, observatory

manager for the Solar Optical Telescope Project, observatory manager for the Active Magnetospheric Particle

Tracer Explorers Project, and spacecraft manager for the

Magnetic Field Satellite.

As he approaches retirement, Margolies has been

active in the APPL Knowledge Sharing Initiative,

including serving as a member of the ASK Review Board.

His other awards include NASA’s Exceptional Service

Medal and the Goddard Space Flight Center

Outstanding Service Award.

You wrote a story about your work on the Advanced

Composition Explorer (ACE) project for ASK (Issue 9). I

remember that you said that your “primary objective was

to launch on schedule.” How do you get a project team to

make that happen?

I have approached it in a number of ways. For example, on

one project I have gone so far as to take my team away from

our normal business site for a week. Everybody sat down

and developed their schedules, and then using such high

tech tools as pencils, paper, and rulers, we put together a

networking diagram. People could look at that and say,“No,

no, this isn’t right, we need to do this first.” That was one

way I got people together to agree on a schedule.

On some projects, schedule slips have been blamed on

tension between the science team and the project management team. Did you do anything specific to try to mitigate

that sort of tension on ACE?

I worked closely with both the principal investigator,

Dr. Edward Stone, and the payload manager, Allan

Frandsen. My relationship with Al took on much greater

significance as the project evolved, because fairly early

on Dr. Stone also became the director of the Jet

Propulsion Laboratory. At any one time, there were

always several things competing for his time and

attention. Still, we communicated regularly.

INTERVIEW 

Since 1963, Donald Margolies has served in a number of management positions

at the NASA Goddard Space Flight Center, and in 1998 received NASA’s

Outstanding Leadership Medal 

USE PAGE FROM

ADVERTISING SPREAD

Donald Margolies
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 35

Did you two have some kind of system set up for that?

Only in that we made it a practice not to ignore communication. Dr. Stone and I set up a schedule to talk with

each other on the phone every week. Even if it was to say

that the weather was nice in California and there was

nothing much happening here at Goddard, we always

kept the appointment.

What are some of the common pitfalls you’ve seen on

projects in terms of how scheduling is treated?

Well, I’ll give you an example. On one project, I went to

visit my contractor, and I met with their scheduler and

project manager. We went into their war room, and there

were schedules all over the wall. They were wonderful, as

detailed as can be, and so I had to ask: “Who developed

the schedule?” The scheduler said, “I did.” And so I

asked another question, “Did the people doing the work

have input?” He said, “No.”

The next day I notified the contractor that I wanted

the project manager and his scheduler removed from

the project, and I told him to start building schedules

that were representative of what work really needed to

be done. As a project manager, there are certain things

you can dictate: the end date, maybe certain review

period dates; but in terms of what else has to be done,

you’ve got to ask the people who are doing the job.

So you felt that schedules they had shown you had no

basis in reality?

None. Here were these wonderful schedules, detailing

every single thing you ever wanted to know about the

project—and it was totally irrelevant. Now, understand,

I am not against using schedulers. I have worked with

several good ones. But you need to talk to the people

doing the work. You need to find out what they have to

do and how long it’s going to take. Even if you do it that

way, your schedules can still be fallible, but at least you

have something that everybody has bought into

because they helped to develop it.

Were there any unique scheduling challenges you

faced on ACE?

The scheduling challenge on ACE was working with

twenty science institutions. It was a big team, spread out
36 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW CONTINUED

widely across the U.S. and parts of Europe. They were all

experts in their own scientific and technical domains,

but creating and adhering to schedules wasn’t their forte.

So the real challenge was making sure all of the

schedules converged on the same launch date.

In what way, for example by looking at a decision you

made at some stage of the project, were you able to

address that challenge?

At the start of the project, I had the choice of spreading the

limited amount of money I had among all the players, or

looking at and mitigating the greatest risks on the project.

I responded by putting the bulk of the money into

trying to identify the key risks in the development of the

science instruments and mitigating these to the best

extent that we could. I wanted to enter the development

phase with the least amount of technical, schedule, and

cost risk as possible. To do this, I had to limit spacecraft

development funding at the Johns Hopkins Applied

Physics Laboratory (APL).

What were the risks involved in doing this?

In holding APL back by three months, or six months,

I knew I could be shooting myself in the foot if they were

not able to recover. But I believed, even with a slow start,

APL would be able to catch up.

Why? This was my third mission with APL, and I

thought I understood the culture there. Mary Chiu, the

APL Program Manger, was new to me, but I knew many

of the other key people on the project. APL had built

spacecraft many, many times before. My concerns about

APL being able to do the job actually were quite minimal.

On the other hand, no one was certain how effectively we could mitigate the risks with those problem

instruments. The greatest uncertainty on a science

mission is in the development of the instruments. There

were nine on ACE, five of which were new. Because I was

limited as to how much money I could get in the early

stages of the project, the question was: What was the

best way to use it?

How did things turn out?

Once we got more funding, I told APL to start ramping

up on the spacecraft development. As it turned out, they

were able to catch up.

You’re never right a hundred percent of the time.

Still, you have to go with your judgment. Experience

counts for a lot.

At one of APPL’s Masters Forums, you told a story about

how you worked with Mary Chiu to address a schedule

concern you had about APL. What struck me about that

was you said you learned something about people’s

motivations on projects.

Yes, I remember. The story was that APL had fallen

behind schedule as we were approaching our integration

and test phase. We not only had to integrate the spacecraft and test it, we had the nine instruments coming in.

It looked to me like there was only one of two ways to

make up the difference: either put some people on

double shifts, or work on the weekends. Neither was an

attractive alternative, but we had a lot to do and the work

had to get done.

I asked Mary to go ahead and tell her people to do one

or the other. She told me that she couldn’t do that. Her

people were salaried and she couldn’t direct them to put in

overtime, where they wouldn’t be paid for their work. I

have to admit that took me aback. For one thing, I wasn’t

asking for a lot of time—perhaps seven days at most.

But I have to give Mary credit. She pointed out

something that was a no-brainer, really. Technically, she

couldn’t require her people to work the extra hours, but

she also knew that she didn’t have to tell them to do

anything. Professionals don’t have to be reminded that

they have a job to do. It was so obvious that I was astonished and embarrassed that I hadn’t realized it myself.
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 37

Sensors on the Advanced Composition Explorer satellite measure

solar phenomena like the flares seen in this x-ray image.
38 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW CONTINUED

A closer view of the Sun’s surface during a solar flare.
ASK 14 FOR PRACTITIONERS BY PRACTITIONERS 39

These were people at APL that you’d worked with before? 

Yes, that’s true. I knew a number of people on the APL

team because I’d worked with them before, and I recognized that what she was saying was true. These people

would come in and work the extra hours; they would

work Saturdays, Sundays, nighttime, whatever it took to

do the job. All we had to do was put it out there that we

were behind schedule, and they would rise to the

challenge on their own. And they did. Ultimately they

recovered all of the time.

So what was the important piece of learning about

people’s motivations on projects? 

Well, it is much better to let people come up with a

solution and implement it than for you to force it down

their throats. Isn’t that preferable to mandating that

they do the work? Think about it from APL’s standpoint, if they heard NASA telling them to work harder

than they already were—with NASA knowing full well

these people weren’t going to get paid for this—it would

be like NASA was trying to get something out of them

for nothing.

The mission launched, and it has been very successful in

terms of the science collected. But are you satisfied in how

you met the challenges you identified? 

Let me put it this way, we picked a target launch date

three and a half years in advance of launch, and if there

had not been a launch vehicle problem on a different

mission we would have launched on that day. As it was,

we launched four days late.

That’s incredible when you think about how common

launch slips are. Six months, or a year is hardly unprecedented. So are there any rules of thumb that you would

encourage project managers to follow when building

schedules?

Just this. There is this tendency to think there’s only one

way to get from A to B. It turns out there are an infinite

number of ways to get from point A to point B. What

may work on one project may not work very well on

another project for a variety of reasons.

The lesson I’ve learned is that while it’s good to

have a road map, you have to realize the map is good for

today, but it may change tomorrow, and it may change

again the next day. Use the schedule as a tool and be

flexible, if you can. Cultivate a great team, take advantage

of their experience, and pray for good luck. •

Solar activity reflects changes below the Sun’s surface.
40 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

DESPITE THE BEST PLANNING, GAPS EMERGE BETWEEN THE

model and the reality of most projects. Often, when

unexpected problems arise during project implementation,

quick thinking and a pragmatic approach are the tools

managers need to bridge the gap.

I was reminded of this when I spoke with a project

manager in charge of modernizing old buildings for the

Federal Government. Though he had straightforward

goals (removing asbestos, updating wiring, etc.), achieving

these goals proved anything but straightforward. The 

real challenge, the manager discovered, was completing

his work without disturbing the tenants still occupying 

a building.

QUIET ZONE At one of his sites, a Federal courthouse,

workers had continually violated noise restrictions

imposed during the hours that court was in session.

Typically, when noise complaints came in, someone

from the project office found the source of the problem

and reminded workers of the restrictions. When

confronted, workers explained that they either hadn’t

known about the restrictions or had forgotten them.

The solution? Directly addressing those who could

control the noise—the workers—and making it clear that

they would be held responsible for their actions. The

project manager posted the noise restrictions at every

construction entrance—along with a warning that

violation of noise controls could “result in immediate and

permanent removal from the job site.” A simple sign was

all it took to address a significant threat to project success.

LIVE WIRES On another project, demolition work on

one floor of a building disrupted the telecommunication

service to occupied offices. It turned out that years of

office space reconfigurations had resulted in tangled

wiring that wound its way between floors and through

offices. For example, stripping a telephone closet on the

12th floor cut service to offices on the 14th floor.

The obvious solution was to hire a technician to

systematically trace all the wires and eliminate the

problem upfront—but the project couldn’t afford this.

Instead, the manager found a retired technician willing to

work “on call” to identify live communication lines before

renovation began in an area, using a listening device. This

low-cost solution provided a satisfactory solution.

A NOSE FOR TROUBLE When the roof of a fully

occupied office building needed to be re-tarred,

occupants complained that the noxious fumes were

reaching their offices. The project manager learned that

fresh-air intakes on the roof were sucking in the fumes

whenever the wind blew in their direction. The air

intakes couldn’t be turned off completely, if the building

was to remain occupied.

The building manager threatened to evacuate all

5,000 occupants, which would bring the project to a

standstill. When experts couldn’t come up with a

technical solution, the project manager came up with an

innovative fix: He invented a new occupation. He hired a

“sniffer” to sit beside the intakes and sniff the air for tar

fumes. When the wind blew fumes towards the intakes,

the sniffer turned them off temporarily—never for more

than a couple hours, and well within acceptable limits.

KEEP IT SIMPLE As this manager learned, the

unknowns of project work often require immediate

response. Thankfully, high-performance results don’t

necessarily require high-tech solutions. Quick, simple,

and inexpensive fixes are sometimes the answer to

keeping a project on schedule and within budget. •

Management as Improvisation

Things are supposed to work a certain way—

and then there’s what really happens

FROM THE EDITOR-IN-CHIEF Dr. Alexander Laufer

NP9-2003-09-314-HQ