Welcome to ASK

Dr. Edward Hoffman

I sat mesmerized the other evening listening to a discussion about the space program.

The event was sponsored by the Smithsonian Institution. A panel of prominent media

insiders were sharing stories of the Space Race and the Apollo dramas that unfolded with

it.

Walter Cronkite regaled the crowd with recollections, humor and his sheer passion for

space adventure. By the end of the two hours, we were all spellbound. The power and

wonder of storytelling was as much on display as anything.

For me it also brought back memories of my first experiences at NASA eighteen years

earlier. As a student intern I was involved in research to identify the characteristics of

superior leaders.

I have always remembered one strong impression from that early work. It was an

interview with a software manager at NASA Goddard. The interview was like most others,

until the end when I got up to leave. The manager started smiling and walked to a corner

to show me samples of his work, reams of computer printout paper. I found it amusing

because the pages were indecipherable to me. However, the enthusiasm, passion and

stories the manager shared have stayed with me forever. I remember thinking that if

someone can get so excited about computer printouts this must be a phenomenal place

to work.

A couple of years later I started working as an employee for NASA. I was, and remain,

amazed by the talent, dedication and passion of the people who work here. In particular,

the people who work on projects always seem to have so much energy and focus. Much

of this is conveyed in the hallways and after hours through stories and recollections.

As the Director of the NASA Academy of Program and Project Leadership (APPL), I always

wanted to find a way to informally promote greater sharing of the passion, joy, agony

and lessons of working on a NASA project. I have always believed that if talented and

passionate people have a chance to talk to one another and share experiences, great

things will take shape. But how do we do this in an environment that always seems to be

accelerating ever faster and with the time to talk about such things becoming preciously

scarce?

Over the past two years forums have gathered some of the best project managers to

share knowledge and tell stories related to project success. The idea was to create and

maintain an informal environment for talented and passionate people to share. Now it is

time to take another step. The first issue of ASK introduces another vehicle for

conversation and sharing.

ASK will provide a format that is easy, accessible and open. The stories and columns that

appear in this bi-monthly magazine will offer simple yet powerful advice, lessons,

insights, humor and narratives that underscore what makes NASA projects so meaningful

– the competence and passion of the people who work on them.

We need to find ways to communicate with each other as Walter Cronkite and the media

panel did in sharing stories of the Space Race. We need to find ways to make it easy for

practitioners like the software manager to explain the importance of their work. ASK is a

step in that direction. ASK

ABOUT THE DIRECTOR

Dr. Hoffman is director of the NASA

Academy of Program and Project

Leadership. Responsible for the

development of program and project

leaders and teams within NASA, he

develops training curricula,

consulting services, and research

projects and special studies in

program and project management.
Arrogance: Number One Enemy of Learning

by Alex Laufer

Learning from Experience

I was confused and didn’t know how to react when Jim Carroll, a highly regarded figure

in the construction industry, proudly presented me with his "Nine Elements for Project

Success," the product of two years arduous labor. These nine elements were presented

as a well-accepted model, as if they were based on solid findings, and were meant to

serve as guidelines for the successful management of capital projects. To my mind,

however, the nine elements were based on weak hypotheses and were clearly deficient.

Jim, who is now the President of Flour Daniel/Morrison Knudsen, LLC, was at the time in

February 1988 serving on the Construction Industry Institute (CII) Project Organization

task force. The CII, a national research organization established in 1983, is located at the

University of Texas in Austin. It brings together 90 owners and construction companies

with 30 universities in an effort to improve the management of capital projects.

When I was first invited to join this task force, it was just after it had experienced a

breakthrough. In one of its most productive meetings, the task force was able to identify

the "Nine Elements for Project Success." The task force then appointed a small team of

five members, headed by Jim, to produce a handbook for practitioners that would

thoroughly explain each of these nine elements. I met this team at its first meeting,

where Jim allowed me to peruse the nine elements in their rough form and asked me to

write a chapter on project strategy. I honestly felt, however, that I could not fulfill his

request.

I just could not accept the "Nine Elements for Project Success." First, they did not cover

very important areas of capital projects. Second, they were stated as the "one-best-way"

principles, completely ignoring the rich variety of project contexts stemming from the

different environments, organizations, technologies, projects, and people.

There was another issue complicating the matter for me. I was very flattered being

invited to join the CII task because I knew that at that time I was the only foreign

scholar invited to work for the CII. It offered me access to some of the most progressive

organizations in the world, and the ability to collect invaluable data from them. I came to

the CII with the understanding that I was expected to conduct research for them. I did

not feel that my accumulated theoretical research findings allowed me to prepare a

chapter useful for practitioners.

I spent a full three hours talking with Jim. To be more accurate, I should say arguing and

debating with him, often quite heatedly. At first he stonewalled me. I could not produce

the tiniest dent in his rock-hard opinion. Jim stubbornly maintained that applying these

nine elements was the way, and the only way, to achieve project success. After all, it

took the task force two years to agree on these elements, and Jim was clearly in no

mood to retreat and re-examine them. He wanted to make further progress and bring

back to the task force tangible products, that is, finalized chapters of the handbook.

It was close to midnight when I realized that I would never be able to convince Jim of the

weakness of the nine elements and was almost about to give up. As a last resort, I asked

him whether he would be ready to put the nine elements to a personal test. That is, I

asked him to see whether the application of the nine elements could explain the success

or failure of the projects with which he was involved during his career. Jim confidently

agreed to put the elements to the test.

 

A

D

th

th

A

L

of

at

C

F

T

T

BOU

r. La

e A

e A

cade

eade

 the

 the

olleg

acult

echn

echn

T THE EDITOR

ufer is the Editor in Chief of

SK Journal and a member of

dvisory Board of the NASA

my of Program and Project

rship. He is a visiting professor

 Civil Engineering Department

 University of Maryland at

e Park and a Professor at the

y of Civil Engineering at the

ion-Israel Institute of

ology.
In one of my earlier careers as a rhetorician, I learned that the best way to understand a

subject lies in listening to individuals talk about it through their own experiences. In ASK

this issue, we apply that principle to the subject of mentoring. Of all the forms of

developing a project manager, none is probably more effective than learning on the job

under the guidance of a mentor. In our Stories section, some of NASA's most respected

project managers talk about mentoring. Not by lecturing us on the subject, but instead

sharing their experiences either as a mentor or mentee, telling us what happened to

them in the very personal form of a story.

The point of this issue, and to a larger extent ASK Magazine itself, is not to arrive at a

consensus about the subjects we cover, but to create a vehicle for sharing knowledge.

With the participation of our reader, ASK promises to be a very powerful tool for

iKnowledge at NASA and beyond. Ask me what ASK is about and I'll tell you without

pause, to initiate conversations that will jump off the pages of the magazine and into the

offices and down the halls of NASA centers all around the country.

It strikes me that people who love what they do love to talk about it, and when they find

others who love the same things it may just be the most gratifying conversation we can

have. This idea crystallized for me during my interview with Liz Citrin. I asked what

excites her about the MAP mission she's leading out of Goddard Space Flight Center. Her

eyes burned with fire and the office suddenly got cozier, more intimate as Liz described

how much fun it's been and the thrill of pursuing scientific discoveries.

We are looking forward to what our readers have to tell us about ASK this issue. What we

hear from you we plan to share in our Loop (feedback) section next issue, as the

conversation about mentoring and other subjects we cover this issue continues.

Todd Post

ABOUT THE AUTHOR

Todd Post is the editor of ASK

Magazine and a member of

Edutechltd, a diversified

management consulting firm

providing technical services to

Government and private sector

clients. He has written for many

publications both in print and online.

Click here to contact Todd, and tell

him what you think about this issue

of ASK.
ABOUT THE AUTHOR

Mr. O’Neil is currently employed by

Pace & Waite Incorporated in

Huntsville, Alabama, supporting the

Marshall Space Flight Center’s Glove

Box Project Office in Project

Management, Integration and

Operations of the International

Space Station Glove Box.

From Apprenticeship to Management

by Tony O’Neil

Twice in my NASA career I have had the opportunity to mentor young assistant mission

mangers. The first experience occurred when I was Mission Manager for the International

Atmospheric Laboratory for Applications and Science (ATLAS). ATLAS was a series of four

missions to map the earth’s atmosphere over the period of one solar cycle. This was the

first of the four, a $60,000,000 project with a three-year launch schedule that was

extended to four due to Shuttle Manifesting slips.

One day shortly after I was assigned the Mission Management role, my supervisor called

me into his office and asked if I would have any problem if they offered me a young

woman assistant manager. In the early days of Spacelab missions, there were not as

many women engineers in project management at Marshall Space Flight Center (MSFC)

as there are today. I was uneasy with this request at first until I found out who the

person was. As it turned out, I had met this young woman, Teresa Vanhooser, in the

ground operations discipline on a previous mission. Both she and I had similar ground

operations backgrounds. Also, I felt that we could have a good working relationship.

In my mind, three conditions must exist right away between a mentor and mentee. First,

they have to be able to get along with each other. Second, both have to make up their

minds at the start that they want this experience to work. Third, both have to be open

and completely honest with each other. Understand if all hell breaks loose around them,

it’s going to be the two of them against the world.

My approach to working with Teresa was relatively simple. She shadowed me in several

key areas, for example, scheduling, budgeting and communications, and as I gained

confidence in her I gave her more responsibility. The activities were routine. We started

each day by going over the monthly calendar. I assigned her the job of updating it every

day. The monthly calendar contained all scheduled meetings, major milestones,

deliverables, reviews, and personal leave.

We also forged a daily plan in these meetings. We covered what we’d accomplished the

day before as well as what we hadn’t, and we made sure to reschedule any unfinished

business. I also asked her to develop the overall master schedule for the mission. The

master schedule is the road map that the whole project team uses to understand where

we are and where we’re going. I assigned her these jobs thinking it would be an effective

way to bring her quickly up to speed on all aspects of the mission.

As the project progressed, the time I invested in Teresa decreased significantly, while her

contribution to the project increased markedly. Initially, we went to every meeting

together. We spent the first year going over every meeting afterwards in the privacy of

my office. I felt we needed to do this so as to develop a common mindset as to where we

stood on such things as mission problems, costs, and the schedule among other

concerns, and we also discussed personnel relationships. Effective project management is

not just about how to use the tools at your disposal, but how to interact with people and

how to understand how others interact. Teresa has excellent people skills and I felt

comfortable trusting her intuitions about members of the team.

 
From Apprenticeship to Management (Continued)

by Tony O’Neil

After a year or so, the schedule of activities proliferated to the point that conflicting

engagements prevented us the luxury of both being present at all meetings. This was

difficult for me, I have to admit. Although I had no doubt Teresa was capable of

representing us at the meetings, it was the first time things really were out of my

control. I had to remind myself often that letting go was unavoidable. Indeed, the mentor

must allow the mentee to take on more responsibility. It’s the only way she will gain

independence and learn for herself. Mentors may find this difficult to do, but it is

absolutely necessary.

I handled her involvement with the budget the same way, giving her responsibility as we

went along. After two iterations working together to develop the budget with our mission

budget analyst, I gave her the responsibility of working individually with the budget

analyst, and then had both of them walk me through it line item at a time.

In preparation for major reviews, we first worked on the presentation charts together.

Later, she would build some of the charts and I would build others. We would review the

package and make appropriate changes as required. Most of the time we had dry runs

with upper office management prior to presenting review data to the Center

management. At first I had Teresa sit in the back of the room and observe the

presentation, and if I were directed to make changes in the presentation material she

would record that. This gave her a feel for the people in upper management whom we

had to work with. Eventually, when she was on the block herself making these

presentations, she already had some experience by watching me take the heat for

mistakes and getting grilled by management.

As the mission progressed, and I gained more confidence in her, I gave Teresa signature

authority in my absence. In fact, during the final phases of the mission, she chaired

several major engineering and operations meetings on my behalf. During the Launch and

Flight Mission, which operated 24 hours a day, I managed the flight team on one shift

and she managed the team on the second shift.

We completed ATLAS 1 successfully. Afterwards I shifted to a new mission with a new

assistant, and Teresa was named Mission Manager for the remainder of the ATLAS series

and has become an outstanding project manager.

Working with Teresa, and with my next assistant too, was a rewarding experience for

me, and I believe serves as an example of how mentoring can be an effective approach

of transferring project management knowledge. Once craftsmen passed on their

knowledge to the next generation through apprenticeships. Why should it be different

with project management?

Lessons Learned

1. When mistakes are made, the mentor should accept responsibility for the mistakes

and both the mentor and mentee should plan corrective actions to recover.

2. For mentoring to work, the mentor and mentee must have mutual respect and trust in

each other. They must be committed right from the start to being open and honest with

each other.

3. Mentoring includes many activities, such as meeting one-on-one, conducting team

meetings together and eventually separately, using project tools (e.g., monthly calendar,

master schedule), discussing people and relationships, etc.

4. The mentee gains valuable independence by gradually assuming more individual

responsibility.
ASK
ABOUT THE AUTHOR

W. Scott Cameron is Capital

Systems Manager for the Food &

Beverage Global Business Unit of

Procter & Gamble. He has been

managing capital projects and

mentoring other capital

management practitioners for the

past 20 years at Procter & Gamble

within its Beauty Care, Health Care,

Food & Beverage, and Fabric &

Home Care Businesses.

SHAZAM and His Mentor

by W. Scott Cameron

It's amazing how the things you learn growing up stick with you. Take my introduction

early in life with mentoring. I was introduced to this concept in a 1970s Saturday

morning television show called Shazam.

The protagonist, a young boy named Billy, traveled the country in an RV with an

advisor--whom he called "mentor"--getting advice and guidance while encountering new

experiences each week. The mentor was a pipe-smoking, middle-aged guy who wore

tight fitting turtlenecks. In the show, Billy also had a staff of elders he consulted with

each episode. These elders consisted of no less than the mythic heavyweights Solomon,

Hercules, Atlas, Zeus, Achilles, and Mercury. Once Billy had consulted with his mentor

and the elders, he would yell Shazam and magically turn into an adult "Superhero" who

wore a tight fitting body suit that showed off his potbelly when he flew. He of course

saved the day by using the wisdom of his mentor and elders.

Why do I cling to this memory? For the past seven years, I've been a mentor to almost

20 new and experienced Project Managers (PMs). Fortunately, I haven't had to wear tight

fitting turtlenecks or drive an RV. Coincidentally, the PMs I work with do not directly

report to me but rather to several hierarchal chains (i.e. their elders). Getting all the

links in these chains to see that a well trained PM increases the chance of a project's

success sometimes feels like nothing short of an Olympic feat.

Over these years I've formulated some principles or assumptions that guide me as a

mentor. I don't promise they'll work all the time for you, but taken together they have

been extremely helpful to me.

● PMs will accept help but they will rarely, if ever, ask for it- My major

assumption! I had to devise a way to gain the PMs acceptance of my mentorship

role since none of them directly reported to me. I also had to ensure that I met

with them on a regular basis so we could build a relationship.

● A PM and a mentor must find a common ground to work from- The only

common ground I figured I could quickly negotiate with each PM was that my

role was geared to make them successful. This goal was quickly agreed to by

each PM. However, each PM took a wait-and-see attitude to verify that I was

going to be true to my word. My feeling was if the PMs were successful the

projects would be successful. Although this may not always be the case, I

figured the odds were in my favor.

● A mentor must never let the PM's project fail- - If the PM ignores the

mentor's advice and the mentor feels the project will fail, the mentor must bring

this to the attention of the PM's hierarchy. Although this sounds contrary to the

previous point, I believe it is a must. In the last seven years, I have not been

faced with this situation but it is something I am ready to address if the

situation arises.

● PMs should explain their plans to the mentor. The mentor should

actively listen to these plans and determine if they will or will not workThere are many ways to successfully execute projects. The role of a mentor is to

determine if the PM's plan is sound and will work. It is NOT the role of the

mentor to get the PM to do it exactly as the mentor would.

● A mentor must allow a PM to experience "little" failures so that the PM

can grow. . If a PM never experiences negative feedback from others, she or he

will not grow. The challenge to the mentor and PM is determining what "little"

failures looks like.

● A mentor must take time to listen to what others are saying about the

PM's project- If the only data or viewpoint a mentor gets is from the PM, then

only one side of the story is heard and the mentor won't be able to properly

coach the PM to be successful.

● Part of the mentor's role is to be a venting source for the PM- No action

or words of wisdom may be required, just the ability to listen and let the PM

vent. New or experienced PMs do not have many vehicles to allow them to feel

secure while venting their frustrations.

● A mentor must not be seen as competing with the PM- I do not attend the

project team meetings but am copied on the resulting meeting notes. If I

showed up at the project reviews, the project team might become confused as

to who was in charge. A project can have only one overall PM.
To date, by using combinations of these assumptions or principles, I estimate that 95

percent of the PMs and their projects have been successful. How can I be sure of this?

Not one of the PMs has ever had to yell Shazam!

As I continue to mentor PMs, I imagine I will add new assumptions or principles to the

list above, and some will be subtracted because of the individual needs of PMs and their

hierarchies. ASK
Tough Questions

by Terry Little

Driving back to my hotel, I felt exhausted. I had just spent four days at the Defense

Systems Management College, meeting with 12 small groups of program management

students from all Services to discuss a case study they had just completed. I was there

to give the students a chance to ask questions that they felt the case study had not

answered.

While I drove I found myself wondering why I had dedicated so much time and energy t

this work. It wasn’t as if I had no idea what I was getting into. I had been doing this

three times a year for the past three years. And it sure wasn’t because I had nothing el

to do. I was managing one of the Air Force’s largest and most important programs. Tha

by itself was more than a full-time job.

Nor was it because I liked to hear myself talk. An introvert by nature, I don’t fashion

myself a professional educator. Nor did I expect some tangible reward or recognition. I

knew that I was as high in the pecking order as I was ever going to get and while the

school appreciated my service, I am not sure my boss would be happy if he realized ho

much time I was spending at this.

So why was it worth it?

I thought back on the day. Many of the questions were ones that I had heard over and

over. For these I had stock answers; however, in almost every section I got a few new

questions that really forced me to reflect. "What were you thinking when you...?" "Why

did you make the choice to...?" "Did you consider...?" "If you had it to do over again

would you still...?"

As I thought about my answers, I soon realized that these students were teaching me t

think about things I had never thought of before. They were enriching my experience in

way that I could have never anticipated. It was a richness I was convinced, made me

better in the job I was doing.

I also thought about the students and reflected on my experience there as a student

almost ten years ago. I had left the school with my head crammed with facts, but with

none of the practical knowledge or insights to understand what the day-to-day life of a

project manager was really like.

In my training there had been no opportunity to interact with real practitioners - no

opportunity to hear real firsthand anecdotes or war stories that would take me beyond

the theory. What are the tough decisions? What is most important when everything

seems important? How do you deal with risk and adversity? What’s the role of intuition,

values and judgment in the decision process? How do you deal with dysfunctional

teaming relationships? How do you handle higher-ups when they demand that you do

something you think is unwise? How do you recover after a mistake?

I felt like these students, partly as a result of my having shared my time with them and

given candid answers to their questions, would have a much better understanding and

ability to deal with these sorts of real world issues than I had when I left school.

Hopefully, they will not have to learn as many things the hard way as I did. Hopefully,

they will understand that the most difficult issues they face rarely have a pat answer.

As I continued towards the hotel, I began to feel exhilarated even. These students and

their eagerness to learn, their zest to grow as professionals, had recharged my old

batteries – cracked through some of my cynicism and made me feel more vital than eve

What I had done was the right thing for the students, for the Department, and for me.

Was it worth it? Absolutely!! I had struck a blow for progress. ASK

o

se

t

w

o

 a

r.

ABOUT THE AUTHOR

Mr. Little works in the civil service

with the Department of the Air

Force, where he has been a program

manager for five major defense

acquisition efforts. A former English

teacher, he plans to return to

teaching upon his retirement.
Supplier Integration

by Richard Day

A mission’s success often depends on the performance of our suppliers. In a very real

sense, suppliers perform relative to how well they are integrated within the larger team.

To help suppliers feel like part of the team, the Project Manager should welcome them

immediately upon their selection. Use the most personal vehicle available, such as a

face-to-face meeting. The more familiar the project manager becomes with the suppliers

the better able he or she will be to develop a strategy for using them. It’s a good idea to

assess the strengths and weaknesses of suppliers with evaluation materials. You can also

use whatever past performance information may be available. The project manager’s

main focus should be developing a positive, long-term relationship with his or her

suppliers. Good ones are hard to come by. You want to make sure the good ones realize

you appreciate them.

Procedures

1. Welcome supplier to the team immediately upon selection.

2. Establish regular communication, especially with key personnel and executive

management.

3. Independently assess supplier strengths and weaknesses using evaluation materials

and all available past performance information.

4. Visit supplier’s facility as frequently as possible.

5. Invite supplier to events at your site and/or major integration site.

6. Continue to build the relationship after delivery.

ABOUT THE AUTHOR

Mr. Day serves on the Advisory

Board of NASA's Academy of

Program and Project Leadership. He

is the senior executive at Goddard

Space Flight Center responsible for

the formulation of systems

management policy and guidelines.

He has earned the NASA Medal for

Outstanding Leadership and the

NASA Medal for Exceptional Service.
ASK
Rapid Prototyping

by Kern Witcher

Rapid Prototyping is a viable approach to product development on projects and initiatives

whose success depends on a significant amount of customer input. The customer is

allowed to look, touch, and feel the product prior to final development and

manufacturing. Rapid Prototyping is also useful in situations where requirements are

difficult to describe. Product prototypes can be developed on an incremental basis and

tested against the requirements prior to building the final configuration. This is an

approach that works especially well in developing software tools that have Man-Machine

interfaces. Overall, Rapid Prototyping provides quality and timely customer feedback,

mitigates requirements "creep," causes fewer changes to the final design, and results in

higher quality end products at less cost.

Procedures

1. Define customer or end user.

2. Assemble the customer, designers and developers into an Integrated Product

Development Team. Note that some members of the team may require training.

3. Develop as a team the preliminary set of requirements.

4. Baseline the requirements. This will provide traceability and configuration

management.

5. Develop an initial prototype that provides the look and feel for customer feedback.

6. Incorporate comments and develop the next version of the prototype.

7. Develop another version of the product by adding functionality. The designer and

product development team also benefit from the availability of the prototype.

8. Incorporate comments and develop the next version of the prototype.

9. Develop a final version of the product by adding functionality.

10. Place final version under configuration control.

ABOUT THE AUTHOR

Mr. Witcher is the Deputy Program

Manager for Operations in the

Geospace Applications and

Development Directorate at John C.

Stennis Space Center.
ASK
 

ABOUT THE AUTHOR

Mr. Jansen is currently the Manager

for Launch On-need at Johnson

Space Center in the External

Carrier’s Office of the International

Space Station Program Office. Until

recently he was a Project Integrator

for Johnson Space Center’s

Engineering Directorate.

ed

 I

r.

I

Natural Relationship

by Michael C. Jansen

Experience Before Age

One of the team leads I worked with was a chief without braves. A senior engineer, he

grew thoroughly disillusioned as he watched his technical area whittle down from its

heyday of 10 percent of our division’s civil service workforce, plus a healthy contingent of

contractors, to two part-time civil servants and as many contractors. It was apparent to

him (and to me) that there was no management support for his area, neither within the

Program Office he supported, nor therefore from our line organization.

Since he was eligible for retirement, he was seriously contemplating hanging up his

slide-rule, despite the fact that he hadn’t intended to retire for several years yet. The

truly sad thing was that he and I could see clearly that his technical area was indeed vital

to the Program. That fact was simply going unrecognized.

With some prodding and youthful exuberance, I got him and his decimated team to flesh

out a minimum-but-necessary set of tasks that should be performed by his technical area

in order for the Program to be safe and succeed. We also worked out the requisite

staffing and funding levels they would need. We then approached the Program Office with

our well-researched plan and gained acceptance thereof. That single success suddenly

gave him back a meaningful team (about 50 percent greater than during its heyday) and,

more importantly, a powerful sense of his own vital purpose.

Now that the team’s products were required for flight certification, suddenly my colleague

the senior engineer was too busy, and far too energized, to contemplate retirement. I

noted that increasingly he would drop by my office to ask advice regarding how to

approach the Program Office on certain matters, on working issues with international

counterparts, on personnel matters, on sizing and development of new tasks, and on

such personal matters as career development (this, from a near-retiree!). I was delight

to be of assistance.

After a couple of years, his visits became less frequent as he gained confidence in his

own abilities. I have since moved on to another organization and we rarely interact, but

still hear occasionally about his team and its continued growth and achievement under

his able leadership.

This example illustrates that one can benefit from mentoring at any point in one’s caree

Contrary to the stereotype of the aged veteran taking the younger mentee under his

wing, it can work the other way around too. It was natural for me to try and help this

senior engineer. We worked together in the same office, and it was obvious that my

helping him was good for everyone.

You Just Can’t Fake It

The people I consider to have been mentors to me grew into their roles gradually and

subconsciously. The mentor relationships became natural extensions of existing work

relationships and, as such, never had a forced or strained feel about them. They were

very successful experiences. I learned greatly, and (I perceive) my mentors derived

satisfaction from watching me grow professionally. I believe the same characterization

applies to the half dozen or so work colleagues to whom I (in hindsight) have acted as

mentor.

In contrast, I once volunteered to be a mentor for an at-risk middle-school student as

part of a work-sponsored educational outreach program. I assume that the young man 

was paired with wanted to be there; participants had to volunteer and be screened and

recommended by their teachers, and he seemed as enthusiastic about the program as

any self-conscious pre-teen might appear to be. Despite our radically differing

backgrounds and ages, we seemed to get off to a good start, and his grades slowly

began to improve.
Natural Relationship

(Continued)

by Michael C. Jansen

Soon my workload increased, and this voluntary sideline became more and more of an

unwelcome intrusion. I persevered in mentoring the student out of obligation, and did my

best not to let on that my mind was elsewhere. He knew it. Soon his fledgling

enthusiasm waned, and he began to miss our scheduled meetings. After a while, when I

heard his family had moved out of the district, I was more relieved than anything; I

could concentrate on work and leave this unfortunate fizzled effort behind me. I have to

wonder, though, how much better off he might have been had he had a more dedicated

mentor.

Someone who mentors out of obligation must be an exceptional actor to create the

illusion of putting the energy and personal interest into it that a natural mentor would,

and mentees are quick to pick up on (and be turned off by) the artificial nature of such a

relationship.

Lessons Learned

1. Relative age is unimportant; a young person can be a mentor to a senior person. The

mentor needs only to be more experienced than the mentee in an area of mutual

interest.

2. The mentor relationship should become natural extensions of existing work or

personal relationships and, as such, never be forced or have a strained feel about it. ASK
Mentors Come in All Shapes and Sizes

by Michelle Collins

I was a new engineer at one of NASA's contractor sites, straight out of college and ready

to conquer the Agency. Of the 120 engineers there, I was the only female. To say I stuck

out is putting it mildly.

At the time I was assigned the repairs on the "burn pit" fence. The company burned a lot

of propellant, and the fence was in a constant state of damage. Not very stimulating or

challenging work, but I was new and what did I know? I received a few other projects,

mostly uninteresting stuff, the installation of a sidewalk, repairing a lead floor. I was not

sure how to go about getting more challenging design jobs, but soon I was feeling like

something had to give.

After some months went by, a seasoned facilities engineer (i.e., near retirement) was

requested by his supervisor to mentor me. I don't know anything about what led to this,

only that one day he came up to me and said he was going to "take me under his wing."

His name was Harold; he smoked cigars, dressed a bit scruffy, looked cross-eyed at the

world, and when he spoke relied heavily on expletives.

Did this have something to do with my being the only female? I’m not sure, but I suspect

it did. Maybe they thought because of my gender I needed a helping hand. Unsure

whether I should be offended or grateful, I decided not to let it affect my core beliefs or

rattle my self-confidence.

Harold definitely wasn’t part of the "crowd," as such there was. He didn't get along well

with many of the engineers, perhaps because it was a fairly young crowd and most

engineers come out of school a bit arrogant, especially towards people without an

academic degree, like Harold. He had no formal education as an engineer, just a lifetime

of construction management experience.

The first day he took me out in the field to a major facility modification he was

responsible for. He showed me how to read the blueprints for this type of job. With

Harold you had to learn quickly; he wasn’t about to waste his time, and he was

unforgiving if you had trouble keeping up. Old school all the way, Harold expected me to

learn what I needed and use it right then on the job.

After introducing me to the contractors, he walked me through the plans and the

construction site. He left it up to me to check on the site per his instructions. On

occasion, he guided me through some of the more critical issues, such as my weld

inspections at the top of the support I-beams. Some issues, such as investigating "fair

wages," insurance benefits, and safety practices of the on-site contractor workers, I

conducted on my own after I got his instructions. Would I have known to do these things

with only a college diploma to call myself an engineer? Forget it. These were things you

learn from experience. Fortunately for me, Harold had a wealth of it and was willing to

share it generously.

Later, Harold included me in another major modification, this time to the "tank farm" for

the storage, weigh-up, and loading of the two main ingredients of the Space Shuttle

rocket motors. Once again he introduced me to the contractors, went over the design

and construction plans, and then turned over much of the responsibility of the

modification oversight to me. Naturally, he retained ultimate responsibility and monitored

the activity closely enough, so that I knew I would not be left in a position to make a

catastrophic decision or miss something serious. On one occasion, for instance, there was

a discrepancy between the blueprints and the actual physical configuration. Harold

resolved the issue but made sure I understood his methodology. He was right-on with his

proposal and dealt eloquently, despite his usual penchant for expletives, with the

contractor's concerns. On this occasion and others, I learned from Harold how to have a

firm but mutually respectful relationship with contractors, and how to negotiate

compromises.

But the most important lesson I learned from Harold was still to come. Like many of my

co-workers, I had a backlog of jobs that got pretty deep, some of which had to be

relegated to the bottom of the pile because they were insufficiently funded or scoped.

Moreover, a few of the area managers had presented operational concerns to me and

asked me to look into possible modifications. In some cases they had submitted work

orders, which got bogged down somewhere, and in the other cases they hadn't bothered

to initiate a work order due to the lack of funding or the length of time it would take to

eventually get through "the system." They were frustrated, as I was, with the

documentation and funding "wickets," which regularly resulted in changes not occurring

ABOUT THE AUTHOR

The Managing Editor of the ASK

Journal, Dr. Collins is currently on a

one-year detail to NASA

Headquarters from Kennedy Space

Center where for the past five years

she has conducted research on air

pollution control technology. She

also is responsible for the

iKnowledge Initiative within NASA's

Academy of Program & Project

Leadership (APPL).
Mentors Come in All Shapes and Sizes

(Continued)

by Michelle Collins

Considering the hazardous environments most workers had to face, I felt that some of

the modifications needed to be addressed, and quickly. However, I had no idea how to

get a work package through "the system" or get funding. Like every organization, we had

"bean counters," but they proved to be a dead end. Enter Harold.

"I'm going to walk you through finance and introduce you to everyone," he said to me

one day. I really didn't understand the significance of this gesture at that time, but I

quickly found out how invaluable that was and would be throughout the rest of my

career. I not only learned every step a work order takes, but every step in the funding

approval process, as well as when funding is not available how to find alternative

sources, how to make my packages a priority, and, most importantly, WHO to talk to.

Over and over I have found it to be the individual who makes the difference, no matter

where, when, or what you're involved with. By introducing me personally to each

individual in the flow, Harold established my credibility with them and gave me the

opening for personal work relationships. I became a "known" person and my reputation

was associated with his. Thank goodness his reputation was golden.

Individuals have their own idiosyncrasies or attitudes that may be disagreeable or may

just be a response to events at that moment in time for them. I learned while being

mentored by Harold to identify "where to draw the line" and to be tolerant of another's

frame of reference when trying to get a job completed. For instance, when Harold

introduced me to the head of finance, I took the opportunity to ask him for funding of a

project. He said he'd give me the funds I requested only if I gave him a hug. Naturally,

he didn't ask Harold for a hug, but I trusted that Harold would indicate if the person was

disreputable or way out of line. I gave him a hug in good humor, got my funding, and

established a very good relationship for future requests. Incidentally, he didn't do it

again, which confirmed my assessment that the introductions set up a sort of jovial

"tone" and nothing more.

Twelve months after taking me under his wing Harold retired. On my next project I was

assigned to work as co-engineer on the design and construction of the High Energy

Propellant Testing and Forming Facility with a budget limitation of $1M. The facility

occupancy involved a variety of hazards ranging from office space to propellant milling

and tension testing to storage of high-energy propellants. The facility was completed on

budget and within schedule, and was not only featured in the company's national

newsletter, but also visited by the company's senior executives. After completion of the

High Energy Propellant Testing and Forming Facility, the same engineer and I were

assigned the design and construction of the new Nitroglycerin Weigh-up Facility. At that

time, I was also the Engineer-In-Charge of numerous facilities. All of this happened in

less than three years. I suppose you could say I came a long way from the "burn pit"

fence.

I am convinced I would not have had the capabilities or the opportunity to work on these

projects had it not been for the mentoring I received from Harold. I also believe we

would not have been granted the latitude in design and construction we had if not for

what I learned from Harold in combination with the experience of the co-designer. What’s

more, I understood clearly how to obtain both support and funding, without which these

projects would have been difficult, if not impossible, to complete. What I got out of my

experience with Harold no doubt accelerated my career and has made me a better

project manager.

I didn't choose my mentor, nor would I have guessed one could have such an impact, but

I thank my lucky stars he took the time to mentor me.

LESSONS LEARNED

1. Great Mentors aren't always easy to spot, and they can come from a very different

background.

2. The mentor can provide you a jump start in relationships by your association with him

or her.
3. Exercise patience and diligence; you may not recognize the benefits until much later.

4. Individuals make the difference. ASK
How Did I Get Here?

by Charlie Stegemoeller

Growing up, I rarely had to look for guidance. On my first job outside of home, for

instance, I learned the value of workmanship. It was the summer before I started

seventh grade, and like many young men at that age, I got my first taste of the working

world by mowing lawns. The man who hired me for this position taught me to step back

and look at my work, to evaluate it and consider whether I had done all that I could, and

to ask myself was I ready to show this work to someone. This lesson has proven

invaluable to me my entire life.

I was fortunate growing up to have had many fine mentors. There was never a shortage

of people who were willing to offer me advice or teach me the most valuable lessons of

life a young person needs to know. What has been different about my NASA experience

is that I have had to seek out my mentors.

Once In – Then Where?

When I started at the Johnson Space Center (JSC) in June of 1985, I was assigned to the

Business Administration Directorate as a technical analyst reviewing the Space Shuttle

Program. As fortune stood, I worked for a very dynamic lead and team and focused on

the "big picture" of planning and implementation across the Agency’s Space flight

programs. I was provided access to historical views of Agency resource planning and

tradeoffs in management approaches. Following the loss of the Challenger, we conducted

a rapid yet full agency assessment associated with tradeoffs necessary to rebuild the

fleet of vehicles, meet the commitment to the ISS assembly, deal with the loss of

reimbursable payloads and the costs to procure the expendable launch fleet necessary to

fill the intervening void.

The Business team was not in the habit of developing or evaluating its personnel, and as

an engineer in a budget group I realized it was quite possible they would not understand

my strengths or potential. I knew I had to actively engage others in my development.

The team I was on counseled each other as we approached the task. As I was new, I

asked many questions of them and the various NASA and non-NASA people I worked

with to develop my portion of the analysis. There was precious little time for anyone to

guide me along, so I took the initiative myself.

I remained within the Business Directorate my first three years in a series of

assignments: first as technical analyst supporting independent assessments within the

JSC Comptroller’s office; then as lead for the Center’s Institutional Budgets; and then as

the lead resource manager for the Crew and Thermal Systems Division within JSC’s

Engineering Directorate. These assignments exposed me to the full range of internal

resources activity within the Center and within the Agency. I met the key managers

across the Center and observed the successful approaches to managing large

organizations. I was also exposed to the management styles and personalities that were

not as successful in defending tasks and managing resources, and these lessons from

what did not work have proven as valuable to me over time as those that did.

 

ABOUT THE AUTHOR

Mr. Stegemoeller is currently

Manager for Human Space Life

Sciences Programs Office at Johnson

Space Center, responsible for the

organization and direction of the

Human Exploration and

Development in Space Enterprise

Lead Center programs for Biomedical

Research and Countermeasure,

Advanced Human Support

Technology, and the Space Medicine

crosscutting function.
How Did I Get Here?

(Continued)

by Charlie Stegemoeller

The assignment within the Crew and Thermal Systems Division exposed me to the dance

of art and science in advanced technology developments, and it was at this point that I

realized I needed to move out of the Business Directorate. I had figured out by then that

I wanted to be involved in the planning and implementation of policy and programs that

furthered the human exploration of space.

On Towards the Flight Program

I moved into the Space Station Freedom Project Office as the Technical Assistant for the

Manager for Development. This office was staffed with experienced Apollo and Shuttle

development managers and technical personnel. I intentionally sought out guidance and

insight from these men and women on how things had been done in the past.

Throughout this journey I continued into more technical project management-oriented

responsibilities requiring the associated training to meet the tasks. My experiences have

led me to value the hands on training offered by the variety of tasks I have been

assigned and volunteered for versus the formal trainings that were available. Throughout

my career I have stayed abreast of on-going training, but only as it was periodically

inserted into my assignments. More often than not, I would ask the people I worked with

for their experiences and solutions to certain tasks I was working on.

In Freedom, my assignments required me to interact with all of the office managers and

technical leads. I used these interactions to extract the methodology and basis for the

technical and business decisions that were underway. I also used the informal time to

allow them to reflect on their stories from when they had been part of the initial activities

with Gemini, Apollo, and Shuttle. They would reminisce "on the good old days," and from

this I learned about the successes and failures of the past and to place them in context

with the present. But this was not a formal process for learning. No one was assigned to

mentor me or anyone else on the team. I knew that the older team members were the

source of knowledge from the past and would aid in my ability to contribute to the future.

It was my decision to seek out the stories and lessons learned.

One such story is from Gemini. The team had just finished fabrication of the new urine

containment bag and was just one day away from flight at KSC. They needed to certify

the bag for up to 7 g’s. They filled the bag with water, found the strongest man they

could find, ran a piece of rope from the board they nailed the bag to, and calculated how

many revolutions the man would need to swing the assembly overhead to reach 7 g’s.

The bag passed the test and the unit was bundled up and flown to Canaveral as the new

flight article. The moral of the story is all tasks are accomplishable – just be creative!

Mir and More

As Freedom became Alpha, I transitioned into the Space and Life Sciences Directorate,

becoming the Payload Project Manager for the Phase 1 NASA/Mir Research endeavor.

Every aspect of the development and implementation schedule had been shortened to

align with a schedule of political events. My team was as young as I was with flight

experience mostly in short duration missions on the Shuttle. The rigors of long duration

space flight and the complexities of merging two distinct space-engineering cultures had

not been fully considered as the plan for joint experiments and operations was signed.

This job required me to lift up the team each time we met hurdles and to find common

ground for solutions for implementing our requirements within the Mir platform and

program constraints. I had few senior managers and little time to seek out assistance.

This condition opened my mentoring pool now to include Russian-trained managers and

technical leads. I sought out their knowledge and approaches for managing the

complexities of long duration space flight and the approaches associated with managing

the personnel within these structures.

The senior Russian lead, Oleg Lebedev, a veteran of many Russian space flight

endeavors, provided me with council and friendship as we negotiated the means to

integrate into the Russian platform. As our relationship developed, he shared his insights

into organizing the American proposals into winning Russian strategies. No US or Russian

policies were violated. More importantly, new strategies were formed to enable the

desired results.
The Phase 1 assignment required me to use every aspect of the technical, professional

and personal skills I had acquired in managing such a complex and varied suite of

crosscutting tasks – people, politics, cultures, technologies, research and space flight. All

of my mentoring experiences came into play, and the team – both Russian and American

– came together to achieve the objectives.

The Present Plateau

Upon completion of this assignment, I was selected to manage a new Lead Center office

for the coordination of the Human Space Life Sciences Programs at JSC, and this is where

I am now. This position has allowed me the opportunity to directly influence and develop

original policies and approaches for the human exploration of space. This assignment is

what I recognized and sought out from the beginning.

 
How Did I Get Here?

(Continued)

by Charlie Stegemoeller

From the very beginning, I plotted my career path and identified the choices to make and

the organizations and individuals who might contribute to my development. I sought out

supervisors, my managers and peers for feedback and guidance on task-related

performance as well as career evaluation and direction. I struck out on this path on my

own based on my internal voice telling me that it was not expedient to wait for someone

to come up to me and tell me how I am doing and how I might succeed. The character of

NASA is one where they will catch up to you if you are not performing, but let you go on

if you are. My self-established pattern of proactive dialogue with managers and peers is

what has afforded me a great deal of cross cutting experiences, insight, and connections

across JSC and the Agency. Had I depended upon the formal performance review process

or on someone else to recognize my potential value and seek to develop it, I suspect I

would not have arrived where I am.

I now am engaged in the process of sharing and creating stories with peers in pursuit of

the goals of this Agency. I find that these exchanges are a form of collaborative

mentoring, and I have also found that by drawing people into sharing their approaches,

their stories, I have engaged them into collaborating on the insights required to solve

problems. I am very pleased to find out that as I continue my quest for learning, this

time through sharing stories, I am also helping my peers by practicing some kind of

mentoring.

Lessons Learned

1. Leadership (entrepreneurial) behavior manifests even in self-development. However, it

must not be misunderstood as self-development in the sense of opportunistic, politically

focused, How-can-I-get-ahead behavior. Rather the focus is on task, organization,

learning, growth, volunteering, etc. Career growth can occur by making a few smart

career choices (continuously) but is primarily through learning.

2. People develop primarily on the job, by doing, by working with and for experienced

people, and by seeking feedback.

3. The best preparation for leadership is not by staying within one function, but by

experiencing a variety of tasks. ASK
y

 

ABOUT THE AUTHOR

Mr. Hrastar is the Director of

Systems, Technology, and Advanced

Concepts, responsible for providing

systems engineering support for all

Goddard Space Flight Center

projects. Previously, he served as

Acting Director of the Earth Science

Systems Program Office and as

Deputy Director of the Space

Sciences Directorate.

How to Say NO

by John Hrastar

Put ‘N’ and ‘O’ together and you may just have the most powerful word in the English

language. Since becoming a project manager myself, I have learned that using this word

is often associated with project success.

A project manager who knew how to say no mentored me in my first job in project

management. At the time, I was Systems Engineer for an in-house science mission. If

you wanted to make changes to the spacecraft after the design was approved and being

implemented, you had to convince the Configuration Control Board, which was chaired b

him.

More than once I brought suggestions for changes that I was sure would improve the

system. He acknowledged they were good ideas, but he was focused on meeting the

basic requirements and deemed the changes unnecessary. They might add cost and also

delay the project’s completion, he argued. I understood his point of view, but it was still

frustrating. Imagine, here I was a young, newly minted project manager, thinking I

finally had a chance to put my own original stamp on something. I was cocky, brimming

with "Can-do" attitude, and that one syllable, -No-, had the effect of opening the ground

under my feet and bringing me to a dead halt.

It was humbling, to say the least, but I learned a great deal about project management

from that guy. The guy was right. In the end, the mission met its tight objectives, and

most importantly, produced excellent science.

On my next project I had a chance to practice what I learned. It was a very large and

expensive astronomical observatory and I was the Systems Manager working for the

same project manager. The science instruments were very large, very heavy, and very

complex.

As Systems Manager, I had the responsibility for resource management. One instrument

team was having trouble with various aspects of the design. The material had to be

changed or a collimator redesigned, and so on, and so on. I knew I had to do something

before things spiraled out of control.

At one point when another request came in I knew it was time to say no, and I did so. It

was not so much that I didn’t have the resources left to allocate; rather I saw that

setting a precedent was necessary for the sake of the whole project.

Naturally this caused the instrument principal investigator (PI) and his team great

distress. It is difficult to argue with an expert scientist about the instrument he proposed

and won. Although I am an engineer, I was not an expert in that instrument design so I

could not tell them how to solve their problem.

Challenging an expert team is not easy because they are convinced they are building the

instrument they were charged to build. They gave all sorts of reasons why their request

was crucial to the project’s success, and the PI threatened to go over my head to the

project manager. Nevertheless, I was convinced their design discipline was flawed and

must be addressed, or else the whole project was in jeopardy.
How to Say NO

(Continued)

by John Hrastar

Did they go to the Project Manager? I don’t know because I never heard anything. I felt

confident about what the answer would be. I do know they improved their processes, and

I took this as a tacit admission that they realized they had to tighten up. Following this I

forged a good working relationship with the PI, and the instrument the team delivered for

the observatory helped to make it a very successful mission.

Just saying no at the appropriate point in a project can have a profound effect. You don’t

necessarily need to know how to solve the problem. The refusal forces a reappraisal of

the issue, possibly stimulating more creative solutions.

Lesson Learned

You can be a mentor without realizing it. Your example teaches those things that are not

found in textbooks. ASK
  

ASK: You came to Project Management from a systems engineering background, correct? 

Citrin: That's right, but at first I started in software, then moved on to be a technical 

officer on a large development contract, then a manager of software development, and 

then into systems engineering. I was a Lead Systems Engineer for four years, and then 

an assistant project manager before becoming project manager on MAP. 

ASK: What excites you the most about MAP? 

Citrin: The science is tremendously exciting. To study the microwave background left 

over from the Big Bang is just an incredibly ambitious project. Personally, I find scientific 

missions much more interesting than technology missions. I like the ones that go for big 

discoveries. Let's face it, big discoveries are exciting, and they're definitely more visible. 

We've had a television crew here, and lots of magazine articles have been written about 

it. 

ASK: When you started at NASA, did you think you'd be leading projects on such big 

issues? 

Citrin: Absolutely not! I didn't plan my career to get to this point. 

ASK: Was there a significant event in your career that stands out more than others that 

you can point to and say "This led me here?" 

Citrin: My first project manager was a very dynamic woman. She unofficially adopted me 

as a mentee and gave me several opportunities to take on responsibility. The project 

went through several reorganizations and each time she approached me about taking on 

more responsibility. I started as one of the most junior people on the project and when I 

left I was one of the most senior. She also encouraged me to get involved in new things. 

ASK: What do you mean she encouraged you to get involved in new things? 

Citrin: Well, for one thing I was at a disadvantage because I didn't have an engineering 

degree. I came into NASA with a computer science background. Not having an 

engineering background was a significant piece missing from my training. She 

encouraged me to take jobs where I could get hardware experience. That was a 

completely unknown area to me, so it was a huge learning experience, and fun, really 

fun. 
An Interview With Elizabeth Citrin 

(Continued) 

ASK: You said there were many opportunities to take responsibility. Can you describe 

one? 

Citrin: On some of the new missions that were under development there was a need for 

people. I would even go so far as to say a desperate need. Almost immediately I got put 

in charge of a whole software effort. I was only working in a maintenance mode for a 

couple of months when I moved over to the development side. I had little experience so 

it was hard work, but things like that pay. People know you. If you're willing to accept 

the challenge and take responsibility, people respect you for that and the opportunities 

start to multiply. 

ASK: Was it a career decision on your part to take on more responsibility, or is that just 

your disposition? 

Citrin: A bit of both. 

ASK: What's been your biggest challenge as a project manager? 

Citrin: Overall, I guess it's been hard for me to let go of the technical detail. My role as a 

systems engineer was very technical. I just don't have time to deal with all that 

anymore. The schedule is my biggest concern right now; we're almost at the end of this 

mission. As a systems engineer I had to confirm schedules, but my primary responsibility 

was the technical integrity of the mission. 

ASK: Is project management a skill you learn mainly by doing? 

Citrin: I think it's very hard to train a project manager to be ready for everything you 

face. Certainly no one knows everything, and you have to get training. 

ASK: What's the biggest challenge in managing a project the size of MAP? 

Citrin: We ask a lot of people, and there are some very stressful periods. We ask people 

to work late. We ask them to come in on weekends. We talk about balance, but I've 

never seen it consistently achieved. When things get out of control, it's important to be 

able to explain why you're making the decisions you make, and to get feedback from 

people too. If people know I listen to them, they are going to listen to me. 

ASK: Is it possible to be a successful project manager without interpersonal skills? 

Citrin: It's a drawback for sure, but I don't think it's impossible. I worked for very good 

project managers who I thought did not have good people skills, but they had other 

things going for them. They were extremely intelligent, they were consistent in their 

approach – it wasn't always the warmest approach, but you knew what to expect. You 

don't have to be best friends with everyone you work with, as long as you understand 

what's happening and feel that you're heard. I think that's enough. 

ASK: How do you strike a balance in managing all the individuals on a project and trying 

to hold them together as a team? 

Citrin: I spend a lot of time on the floor, and in meeting with groups of various people. 

We have a core leadership team, 8 to 10 senior leaders, and of course a deputy project 

manager, but I find I get the best information by being on the floor. I know all 120 

people who work on this mission. Something I learned from the previous project 

manager of MAP, Richard Day, when I was his deputy project manager, is one of the best 

decisions you can make as a project manager is to pick the team yourself. I mean hand 

pick them. At Goddard we have a matrix organization, and in theory I could say I need 

three power system guys and they'd supply them. Richard's approach was to handpick 

everyone personally, and that way he formed a team that was not only technically 

excellent but also functioned well as a team. 

ASK: Isn't that a time consuming process? 

Citrin: Working all that stuff out at the beginning has made for a much smoother 

operation over time. He was able to develop a collective mind set right at the beginning. 

The whole team bought into how we were going to do this mission. As a result, it's one of 

the best in-house development teams at Goddard. 

ASK: How do you keep people energized on a project that lasts for years? 
An Interview With Elizabeth Citrin 

(Continued) 

Citrin: I think it's healthy to have some turnover on a project. Its good to get fresh 

ideas. Some project managers think that people feel betrayed if they don't get to stay 

around to the end of the project. I think we need to maintain some amount of coming 

and going. 

ASK: Reflecting on your own experience coming up through NASA, what do you think are 

the best ways to train younger project managers? 

Citrin: I'm a big advocate of experience in different areas. It's valuable no matter where 

you end up. If someone is working in one area, getting better and better at it, that's not 

necessarily the best way to get experience in project management. Training also helps fill 

in the gaps. 

ASK: Is it a leap then to say the better project managers are generalists, not specialists? 

Citrin: I think the best ones are, but I haven't done a survey of all. There are other ways 

to learn too. Working for someone who is a good project manger obviously. I was lucky 

to work as Richard's deputy project manager. It was a great learning experience. I would 

have never been ready for this, but he's a great project manager and I learned a terrific 

amount from him. 

ASK: Sometimes you don't realize the pratfalls of a job until you have to confront them 

day-to-day. Has there been anything like that for you since you've become a project 

manager? 

Citrin: You have to be careful how much emphasis you place on process. I wouldn't say 

that process is a pratfall because it has a place, but it can become overemphasized at the 

expense of the work you do, which is really the science or the engineering. The process 

should support that work, not the other way around, and I think there's always a danger 

of that happening. 

ASK: How do you keep that from occurring? 

Citrin: By staying focused on the objectives of the mission. These missions tend to be 

long, shorter than they used to be granted, but four or five years still are a long time. 

There's a tendency just to get caught up in the intermediate milestones. With MAP we've 

been able to stay focused because our PI has been great at explaining to the whole team 

what we're doing and how it's important to the science. We have an ALL Hands meeting 

every six months to talk about new developments in the field, so our whole team 

understands what we're doing and what's important to the science. 

ASK: Given what you know now as a project manager, are there any experiences you 

wish turned out differently? 

Citrin: When I was the assistant project manager on MAP five years ago, we were trying 

to develop a different organization structure. We had two very strong line organizations 

at Goddard. They both developed the same mission operations hardware and IT 

hardware, but they used different approaches. We thought let's take the best of both and 

use one ground system; we’ll pick the best people from each group, we'll architect this 

system; and I took the lead on it. I said I know ground systems, I know we'll get 

reasonable people, and I know we can do this. I worked on it close to eight months and it 

was hell. The friction was so bad, as well as the lack of cooperation and the unwillingness 

to make it work, I finally gave up. I said I don't see how this can work for our mission. 

ASK: What did you learn from that experience? 

Citrin: Let me add something first. It turned out that higher level management wasn't 

ready to give up and said, "Look, let's do this as a trial effort for six months and then if it 

still hasn't worked out, we'll go back to the old way of doing things." It turned out that it 

did work out, and on MAP we have one ground system. Two organizations did get 

together and we took the best of both. Afterwards I asked myself did it not work out at 

first because of something I did. I don't think it was. Rather, I think it just takes time. I 

got tired and gave up. I should have hung in there a little longer. I think it has changed 

my behavior. I'm not ready to leave things off if I believe they can work. 

ASK: If NASA said to you, we'll give you whatever tools you need to be a successful 

project manager, what would those be? 
Citrin: I would want to work with other project managers who are considered the best in 

the field. Maybe not even work with them, but have some direct interaction. I'm talking 

about intense, hands on experience. ASK