appl.nasa.go appl.nasa.gov

Academy Sharing Knowledge

The NASA source for project management

INTERVIEW

Dennis McCarthy

Inside

WHEN TO SAY “NO”

GETTING OFF THE GROUND

DEVELOPING TEAM UNITY

POSITIONING FOR SUCCESS

ASK Magazine • Issue Nineteen

AUGUST 2004
My philosophy was to delegate and empower people.

To me, that’s the job of the project manager:

empowering and removing obstacles. —Dennis McCarthy, from his ASK interview (p. 33)
appl.nasa.gov

Table of Contents

ASK 19 August 2004

STORIES

6 Embracing Change

My division manager called me into his office and said, “Bob, I really need your help”

BY BOB LOESH 

10 A Balancing Act

We believe we have to be perfect...maintain the 1950’s sitcom home while having 

a fulfilling career BY LYNDA RUTLEDGE

12 Fly Safe, But Fly 

One thing was certain, the airplane and the program had to be grounded until 

we could figure out what had happened BY KENNETH SZALAI

16 For Safety’s Sake

We needed someone who would say, “Hey, I’m interested in this; it could be 

the wave of the future” BY JOAN PALLIX

22 Testing Positive

Because the spacecraft is going to Mercury, its launch date was constrained,

and everything that came before it had to go according to plan BY RON ZELLAR

FEATURES

18 The Camera Never Lies 

The success bar for an engineer’s presentation skills was set fairly low 

BY W. SCOTT CAMERON

20 Mentoring: Teaching What It Means to Be a Leader

Many senior people give mentoring lip service but are unwilling to spend the time 

to do it BY TERRY LITTLE 

SPECIAL FEATURE 

25 In Search of the Ideal Project Manager 

The first project manager had a reputation as a tough, hard-nosed manager 

and he lived up to that reputation in person BY OWEN GADEKEN 

PRACTICES

28 Rapid Prototyping for Success on Sage III

There’s nothing as frustrating as knowing your triple-redundant system needs to 

attach three wires to their dual-redundant two BY ED MAULDIN

INTERVIEW

33 ASK Talks with Dennis McCarthy 

A project management veteran of thirty years, Dennis McCarthy discusses 

lessons learned while working on a project called “the discovery of the century”

IN THIS ISSUE • 3

It’s Showtime

BY JESSICA SIMMONS

REVIEW BOARD • 4

FROM THE DIRECTOR’S DESK • 5

Life in the Fast Lane 

BY DR. EDWARD HOFFMAN

LETTER FROM THE 

EDITOR-IN-CHIEF • 40

Managing Projects in a

Dynamic Environment

BY DR. ALEXANDER LAUFER

ON THE COVER The Cosmic Background

Explorer’s (COBE) image of the infrared sky.
2 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

WELCOME TO THE ACADEMY OF PROGRAM AND PROJECT

Leadership (APPL) and ASK Magazine. APPL helps

NASA managers and project teams accomplish today’s

missions and meet tomorrow’s challenges by providing

performance enhancement services and tools, supporting

career development programs, sponsoring knowledge

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

other government agencies.

ASK Magazine grew out of APPL’s Knowledge

Sharing Initiative. The stories that appear in ASK are

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

primarily from NASA, but also from other government

agencies and industry. These stories contain knowledge

and wisdom that are transferable across projects. Who

better than a project manager to help another project

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

small projects—they’re all here in ASK.

Please direct all inquiries about ASK Magazine editorial

policy to Jessica Simmons, EduTech Ltd., 8455 Colesville

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

or email to jsimmons@edutechltd.com.

APPL DIRECTOR AND PUBLISHER 

Dr. Edward Hoffman 

ehoffman@hq.nasa.gov 

EDITOR-IN-CHIEF

Dr. Alexander Laufer 

allaufer@eng.umd.edu

EDITOR

Jessica Simmons 

jsimmons@edutechltd.com 

PROJECT MANAGER: KNOWLEDGE SHARING

Denise Lee

dlee@edutechltd.com 

KNOWLEDGE SHARING MANAGER

Therese Salmon

tsalmon@edutechltd.com 

CONTRIBUTING WRITERS

W. Scott Cameron 

Terry Little 

Ray Morgan

Scott Tibbitts

EDITORIAL ASSISTANT

Michael Derocher

mderocher@edutechltd.com 

DESIGN

Hirshorn Zuckerman Design Group, Inc.

www.hzdg.com 

SENIOR PRINTING SPECIALIST

Jeffrey McLean

jmclean@hq.nasa.gov 

PRINTING

Fontana Lithograph, Inc.

STAFF

ASK ONLINE

http://appl.nasa.gov/ask
I’M THE NEW EDITOR OF THIS WELL-ESTABLISHED, AWARDwinning magazine known in the project management

community for its innovative knowledge sharing

approach. So the writing skills wouldn’t be enough. I

knew I needed to really get inside the culture of NASA

and good project management.

When you know there is a lot to be learned, I’ve

found that humility is the best way to go. Acknowledge

your weaknesses, ask questions of the right people, and

hopefully turn those weaknesses into strengths.

Sometimes you have to push a little, like Dennis

McCarthy tells us in his interview about finding a rocket

to launch COBE. The best thing is to get on the agenda

of the people who know the answers; I didn’t only rely on

books, I pushed for people to show me what they know.

Who was I getting to answer all my questions about

this new culture? Other APPL team members, ASK staff,

and mainly the storytellers themselves. Yes, the best

lessons I learned were from the ASK archives—straight

from the mouths of the project managers. The magazine

has always picked the best of the best and hoped that

their examples would help others. So I went straight to

ASK ’s website and started observing project managers in

their natural habitat.

My research paled in comparison to the methods

Owen Gadeken describes in his story, “In Search of the

Ideal Project Manager.” In the end, he realized that there

is no “single” way to project management success. Yet he

and others helped me see some common attributes in

successful managers: the real role models are those who

get results while being true to themselves and their

teams. Ken Szalai gives us an example of such a role

model in his mentor, Cal Jarvis, and how his vision and

his focus on results pushed their project to success.

Not every article in ASK is a success story; each

shows the struggles of being a leader. The storyteller

takes the temporary role of the mentor, and like Terry

Little writes in his article on the topic, the students of the

audience get to ask, “Is this something worth emulating?

Is it something to avoid?” The stories are a way for

readers to observe project managers in action from afar.

While much of my cultural education can best be

written in outline form, like you’ll see in Alex Laufer’s piece

on “Managing Projects in a Dynamic Environment,” the

lessons can best be “illustrated” by referencing the ASK

examples used to hammer home his many points. In the

short time I’ve worked with Dr. Laufer, he’s told me repeatedly to “show, not tell.” And he’s right—we need to see the

action, to decide who to emulate, to figure out what

qualities we respect.

On that note, I hope that you will let Linda Rutledge

and Ed Hoffman show how balancing your career and

home life enhances both, let W. Scott Cameron show you

just how valuable communications skills are to engineers,

allow Ron Zellar to show how a little music and candy go

a long way towards creating team spirit, and observe the

actions—some fruitful, some not—that our other

featured storytellers show us in their narratives.

I feel honored to have been given the opportunity to

join the team that brings you these narratives. So sit

back, relax, and enjoy the show. •

It’s Showtime

I was hired to fill some pretty large editorial shoes

IN THIS ISSUE Jessica Simmons

ASK 19 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, Systems DONALD MARGOLIES retired from the Goddard Space Flight Center

Management Office, is a member of the NASA in January 2004. He was Project Manager for the

Program Management Council Working Group. He Advanced Composition Explorer (ACE) mission,

supports the Agency’s Chief Engineer Office and launched in 1997 and still operating successfully.

MSFC in the review/development of Agency and He received the NASA Medal for Outstanding

Center Program/Project Management and Systems Leadership for his work on ACE, and a NASA

Engineering policy. He led the development of Exceptional Service Medal for the Active

MSFC’s Project Management and Systems Engineering Handbook as Magnetospheric Particle Tracer Explorers (AMPTE) mission.

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

manager for three separate microgravity payloads that flew on various DR. GERALD MULENBURG is a member of the Systems Management

Spacelab missions. Prior to his project management experiences he Office at the NASA Ames Research Center in

served as the Integration and Test Team Lead for the Tethered Satellite California specializing in project management. He

System Mission. His career with NASA began in the late 1980’s as a has project management experience in airborne,

member of the Space Shuttle Main Engine Engineering Team. spaceflight, and ground research projects with the

Air Force, industry, and NASA. He also served as

DR. MICHELLE COLLINS works in the Spaceport Engineering & Executive Director of the California Math Science

Technology Research Group at Kennedy Space Task Force, and as Assistant Director of the Lawrence Hall of Science.

Center. She has over twenty years experience in

aerospace spanning engineering, R&D and project JOAN SALUTE is the Associate Director for Projects in the Information

management. She is on the Florida Institute of Science and Technology Directorate at the Ames

Technology Department of ChE Industrial Advisory Research Center. Joan currently is on detail to

Board, the National Fire Protection Association’s NASA Headquarters. Joan previously was the

Technical Committee for Halon Alternatives, and the United Nations Associate Director of Aerospace. She has managed

Environmental Programme Halon Technical Options Committee. many NASA projects including those involving

flight testing of thermal protection materials,

HECTOR DELGADO is Division Chief of the Independent Technical commercial technology, commercial applications of remote sensing,

Authority in the Independent Technical Authority and remote sensing science projects. Joan has been at Ames for 22

and Systems Management Directorate at the years, and recently completed the Sloan Fellowship to attend the

Kennedy Space Center. Previously Hector was the Stanford Graduate School of Business.

Division Chief of Process Tools and Techniques in

the Safety, Health and Independent Assessment HARVEY SCHABES is the Systems Management Lead in the Systems

Directorate. In 1995, he served as Senior Technical Management Office at NASA’s Glenn Research

Staff to the NASA Chief Engineer at NASA Headquarters in Center. He is responsible for providing oversight

Washington, D.C. He has received many honors and awards for independent assessments of programs and

including the Exceptional Service Medal, Silver Snoopy Award, and projects and for defining Center strategic plans

various achievement awards. and policies. He is also leading the Knowledge

Sharing activities at GRC in collaboration with

DR. OWEN GADEKEN is a Professor of Engineering Management at APPL. He started his career with NASA in 1983 in Icing Research,

the Defense Acquisition University where he has and since then has served in numerous organizations in support of

taught Department of Defense program and project the Space Station Program.

managers for over 20 years. He retired from the Air

Force Reserve as a Colonel and senior reservist at CHARLIE STEGEMOELLER has served as the Associate Director,

the Air Force Office of Scientific Research where he Space and Life Sciences Directorate, Office of

helped manage the basic research program for the Bioastronautics at the Johnson Space Center since

Air Force. He holds adjunct faculty appointments at the Federal 2002. The Office for Bioastronautics is responsible

Executive Institute and the Center for Creative Leadership. Owen is a for coordinating and implementing the NASA

frequent speaker at project management conferences and symposia. Bioastronautics Strategy—the pursuit of tools,

techniques, and policies to reduce risks, improve

DR. MICHAEL HECHT has been with NASA since 1982 at the Jet efficiencies, and return benefits to earth through the conduct of

Propulsion Laboratory (JPL). He is instrument human space flight operations and research. He joined JSC in 1985

manager and lead investigator for the MECA soil- and has served within the JSC Comptroller’s office, the former Space

analysis payload on the 2007 Phoenix mission to Station Freedom Project Office, and as a key member of the

Mars, reprising a role he played on the cancelled NASA/Mir Phase One Program. He received the NASA Exceptional

2001 Mars Surveyor Lander mission. In the course Service Medal in 1996, and became a member of the Senior

of his JPL career, he has served in line, program, and Executive Service in 2002.

project management, and has participated in research ranging from

fundamental semiconductor physics to martian geophysics. HUGH WOODWARD is the President of Macquarie Business Concepts,

a consulting firm specializing in effective project

JODY ZALL KUSEK coordinates results based management at the portfolio management. Before this position, he had

Africa Region of the World Bank. She is currently a 25-year career with Procter & Gamble. He served

involved in supporting the efforts of several African as the Chairman of the Project Management

governments to move to a focus of performance- Institute (PMI) for consecutive terms in 2000 and

based management. She has spent many years in 2001. He was elected to the Board of Directors in

the area of public sector reform, serving the Vice 1996, and before being elected as the Chair, served as vice chair and

President of the United States, the U.S. Secretary of in several other key leadership roles.

the Interior and the U.S. Secretary of Energy in the areas of Strategic

Planning and Performance Management.
ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 5

I HAVE HATED WRITING THE COLUMN FOR THIS ISSUE. She’ll ask, “Did you know about that?” and I’ll say, “No,

This is unusual since I tend to look forward to writing I just work there.”

for ASK. At this time, however, I resent its intrusion as So things are crazy. People ask,“Ed, when will you get

another requirement in a whirlwind of short actions, a minute to talk?” I’m thinking, “Talk, are you kidding?

constant travel, and little chance to reflect or contem- When will I have a chance to sleep through a night?”

plate. I hate knowing that I am way past deadline, and if This doesn’t seem like the way it should be. Have I

I don’t get this in tomorrow I slow down the issue. Can’t missed something? Is my leadership style the cause of

let that happen; sit down and write. Now. my problems? I wonder how does this affect the team? 

This is the problem, I feel too busy, with no end It is now midnight, which is becoming common. My

in sight. writing assignments are increasingly being done at 11

There is so much going on at NASA. More tasks, p.m. or 4 a.m.. Everyone else is comfortably asleep, and I

more changes, more deadlines, more reviews, more am not taking time away from anyone or anything else.

phones ringing, more meetings—more, more, more. Another bonus of such hours is that in a strange way I feel

(Wasn’t that a disco song in the ’70s? Is it obvious my I have stolen time. During these hours I get to catch up,

mind is starting to turn to mush? Was it only yesterday or at least get closer to the moving target. Of course sleep

that I was young? Someone did call me “old NASA” the deprivation is probably not a good thing, but let’s assume

other day. Hmmm.) this is a short-term fix. Tomorrow, order will settle in, and

The number of project assignments is incredible. balance will return. Keep thinking those thoughts.

Lengthy preparation for a major program review, organi- So what can be concluded from organizational life

zational assessment interviews and reports, on-going in the fast lane? Is it appropriate to have more questions

budget preparations, the list goes on. than answers? Ronald Heifetz of Harvard University has

Then there is the travel. Over the last two months a whole book entitled Leadership Without Easy Answers—

alone I have visited Houston three times, Los Angeles so maybe it’s not just me.

twice, Denver once, Albuquerque once, Hampton once At any rate, I just seem to keep piling up the

(let’s not consider that travel since it’s only 250 miles questions. Have I flunked the balanced life test? Is the

from home.) On two of my trips, flight crews of United world moving that much faster, or am I falling behind?

and Southwest Airlines greeted me by my first name. When will the chaos become order? Can this be the new

The only travel I would really appreciate at this time is a steady state? Is confusion and ignorance a good thing?

trip to Australia—24 hours of uninterrupted, no cell (Definitely don’t want to seem complacent or comfortphone flying. able these days.) Maybe this state represents a readiness

Surrounding all of my chaos is NASA 2004. for new challenges, changes and exciting work? Whatever

Perhaps it is me, but it seems as though the organization it is, how come no one ever mentioned this stuff in my

is flying faster than the speed of light. The rumor mill is Organizational Behavior or Leadership textbooks? 

buzzing with change. My phone is ringing with Certainly no coverage on this in any Project

questions of, “What have you heard, what do you Management writings or courses I have come across.

know?” It is embarrassing to admit, but I usually know Heifetz’s book will have to be my guide, because this is

nothing. I usually hear about what happened when I where my column ends, a lot of questions and no clear

walk down to breakfast, and my wife reads from the Post. answers. At least no easy ones. •

Life in the Fast Lane 

Stream-of-consciousness commentary on the hectic life of a NASA manager

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

I WASN’T EXPECTING TO RETURN TO THE VIKING PROJECT,

but as they were approaching the encounter, my division

manager called me into his office and said, “Bob, I really

need your help.” When my division manager started

talking to me like that, I knew I was going to say “yes”

before I even heard what he needed me to do.

PINPOINTING THE PROBLEM

The First-Order Image Processing and Enhancement

System (VISRAP) group had run into some problems.

The supervisor in charge of that group had gotten

heavily involved in trying to get new state-of-the-art

hardware to work and wasn’t managing the software

development too well. They were partially through

coding and trying to integrate the software and were

running into major difficulties. It just flat out didn’t run.

One of the objectives was to get Viking Orbiter image

data to the scientists as fast as possible so that they could

make the best decision about where to land the Viking

Lander on Mars.They wanted to make a pass of the planet

in order to send back the Orbiter image data in real time.

They would then process and enhance the images so they

could use them to choose the best landing spot.

As soon as I came on board, I realized that the

group’s problems had less to do with technology than

with poor development processes and communications.

Due to the schedule pressure the programmers had

stopped documenting design changes that they were

putting into the code. I had run into this problem before

on other projects. The programmers got so caught up in

the coding and testing that the design documents were

never updated, and the other team members had

outdated versions of the interface design and functions

between the design elements. When they went to test or

use the software, new versions of the code had different

functions and interfaces than the design documentation

specified, and those that other team members were

I joined the Viking project in its early days 

in 1971 as the Orbiter Software System

Engineer and stayed on board through

several months after launch. Viking was a

significant step in the technology of onboard

computers and software for NASA and the

Jet Propulsion Laboratory (JPL). But with

those advances came many problems to

solve. We’ve come a long way since then as

well, but some of the fundamental issues,

the problems we faced, and the solutions we

found are all still relevant today. 
using for their code. The design elements were incompatible and would not operate together.

By the time that I was called in, several months of

not keeping the design documents updated had passed

and the programmers couldn’t remember all they’d

designed and coded. They had to analyze the code to

determine the correct interfaces and functions, and

there were no updated design documents to help them.

They also had not updated the test documents; so they

had to spend five or ten times as long to fix a problem

during integration that could’ve been easily solved if the

documentation was current and correct. Months on the

project had gone by like this. When the team put their

software together for integration and testing: the

software failed. There was no current documentation to

help them understand why.

I saw it primarily as a management issue. The

programmers and the other team members had not

been given the direction, disciplined process, and

motivation to ensure successful development and

integration of the product as a whole. Staying on

schedule was stressed as a major priority, and they

lacked the focus to understand what it would take to

deliver on time. They followed no system for coding and

documentation; basically, there was no control.

CRACKING THE CODE

So recognizing the problem is one thing, but solving 

it is another.

I understood how they had gotten themselves into

this mess. In fact, it was learning from my own mistakes

that helped me begin to tackle their problem. When I’m

in the creative mode of coding, I can think of a million

things I should have done better in the design phase. It

takes a lot of discipline not to just throw the changes

into the code without concurrently coordinating the

design and updating the design and test documents. I

knew I would have to do my best to provide the team

with that same discipline.

The programmers were anxious about my takeover

as soon as JPL management made the announcement.

First, they didn’t like me because I was an outsider.

Second, these were programmers who previously had

the freedom to do all the coding they wanted without

documentation. Then I came in and slammed on the

brakes. I said, “We’re turning this ship around and going

back to the drawing board.”

The first thing I did was to shut everything down. I

said, “There will be no more coding, designing, or fixing

of errors until we’ve caught up the documentation.” I’m

still looking for the first programmer that would rather

do documentation than code, so let’s just say that they

were not happy campers! I laid out a controlled process

to keep these problems from repeating: coordinate the

design to resolve the interface and incompatibility

problems, document the agreed-upon design changes,

and correct the code to reflect the coordinated and

compatible design.

To do this, we had to keep programmers who

knew—and hopefully could remember— what they had

done huddled around the machine. It was a really inefficient way to do business, but my plan was for this to be

the last time we’d be wading through all the old code.

Now each time we found a problem, it was coordinated

across the team and documented.

Because of this “catch up” process, several weeks

were tacked onto our already stretched schedule to get

the design understood, coordinated, and put to use. But

I was convinced that we could make up some of the time

by testing efficiency; we’d perform the team coordination and keep the design and test documents current.

Each time they completed a certain amount of the

design updates, we reviewed them together. They made

it clear that they were still annoyed with me, but that was

okay. We were on the road to recovery.

Once we had a handle on the documentation, they

resumed coding and testing. I would schedule updates

every two to three weeks to address changes that had

been agreed upon by all affected staff. After the schedule

was coordinated and everyone agreed to it, the entire

team got a copy of our new plan.

When we got started on coding the coordinated

changes, for a while I still went to their offices every day and

asked them to “show me your documentation.” My intent

was not to micromanage, but to hammer home the importance of working as a team. They started doing it on their

own, at first out of resentment to show me they could. But

my strategy worked. Believe it or not, they began to see that

8 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

I CAME IN AND

SLAMMED ON THE BRAKES.

I SAID, “WE’RE TURNING THIS

SHIP AROUND...”

The Viking lander model.
WATCH AND LEARN

BOB LOESH has figured out a few

things over the length of his 47-year

career, which he began as a

programmer at the RAND Corporation in 1957.

Currently he is the Director of Engineering and

Technology Development at Software

Engineering Sciences, Inc., but the majority of

his time was spent at the Jet Propulsion

Laboratory working on high profile projects

including Viking and Galileo. During that time, he

served as NASA’s “go-to” guy for software

problems, uncovering what he believes to be the

major obstacles keeping software project

managers from reaching their full potential. 

“Number one, we don’t have any basic, formal

training—either at the universities or in

companies—for our software project manager

people,” says Loesh. “We put them on a project,

they get along with people, they relate to

management, and we promote them.” But he

says there is no training or formal way for them

to learn techniques. And because of this, there

are not many good models of successful software

project managers for them to emulate.

This goes hand in hand with what Loesh describes

as a second major problem: lack of mentorship.

“We don’t mentor our people. We don’t pass

along our experiences, guide them through

problems, or let them watch what we do and learn

from it,” he says. “You look at occupations like

bricklaying or machine work, and there’s an

apprenticeship. They do that for a couple of years

and they learn all the right things to do.”

Without formal training or a way to learn from of

others, each manager is thrust into their

software project with only the lessons of their

own experience. Each new project manager

continually recreates the wheel. Loesh adds,

“We’re going to repeat these problems over and

over again unless we figure out a way to

effectively train new software project managers.”

ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 9

I MANAGED THE PROJECT

BY WALKING AROUND

AND INTERACTING WITH

THE TEAM.

other people’s documentation was useful. They could get

things done quicker and with a lot less stress and effort.

After several weeks, the system started showing

signs of working correctly during the integration testing.

And for accomplishing the integration, the level of team

efficiency improved by orders of magnitude. The

success and pride that came from making the system

work was a huge motivator.

HERE TO STAY

At this point I continued to make it my job, several times

a day, to hand-carry proposed changes to each person. I’d

say, “Let’s talk about these changes,” and they’d tell me

they didn’t have the time. So I’d ask them, “What do you

need to be able to get the time this afternoon?” Before

long, people started realizing that I wasn’t going away.

As I managed the project by walking around and

interacting with the team, I got to know which people

were a little quicker and which ones had more trouble. I

also got to know which people weren’t good at

managing their workloads. I kept the lines of communication open about how much work each team member

was carrying, and which person was the best choice to

implement new changes.

I also got to actually see the work that was taking

place rather than reading an email or hearing about it on

the phone. It took a lot of personal time; but after making

major process changes and overcoming huge setbacks,

the last thing I wanted was for the project to fail because

of bad work habits or the lack of interest on my part.

The time I invested paid off in the end. The images

of Mars were delivered by this group to the scientists

and mission designers on schedule, and they were used

to accomplish a successful landing. •

LESSONS

• Discipline AND creativity are the keys to getting a

software project completed on time.

• A direct contact, communication-by-walking-around

management style can be the most effective control system.

QUESTION

To be a good project manager, is it necessary that your team

likes you?

An artist’s rendering of the Viking spacecraft.
A B 

There are certain things that happen to you during your

ALANCIN A LANCIN

BY LYNDA RUTLEDGE

G A CT

career that end up being the ultimate learning experiences. Not because you did the right thing,

but because you did it completely wrong. You look back and ask yourself, “Why did I do this? 

It made no sense.” Then you lay out all the ways that you could have handled the situation better.

FOR WOMEN ESPECIALLY, THIS TYPE OF SITUATION CROPS UP scheduled the following week to brief our Program

all the time.We are trying to pull our weight as contributing Executive Officer, so we holed ourselves up to prepare.

members of the workforce, but we also believe that we have

to be perfect wives and perfect mothers. We want to DROPPING THE BALL...

maintain the 1950s sitcom home. And we want to do that At this time I had a Technical Director who was

while having a fulfilling career. It’s like a juggling act, and frequently out of work, and we’d have to bring her up to

every now and then we’re going to drop a ball or two.That’s speed when she came back. We had worked to prepare for

when you figure out which balls really have to stay in the air. this weeklong session from seven in the morning to nine

It’s one of the learning experiences that I’m talking about. at night. She was out during this period as we attempted

My lesson came during an extremely stressful time in to lay out everything we’d need for the briefing.

my career in the mid-’90s. I was working on an Air Force With next week’s deadline looming overhead, I

program using intense simulation techniques. This made knew that we’d have to start putting the actual brief

it crucial that all five contractors involved, along with the together as soon as our meeting was wrapped up. We

Government, stayed on the same page. To achieve this, we had a long flight home, so I approached my Technical

were working six months of weekends and long hours. Director about working on it then. “How about I get a

Besides that, two hurricanes hit our area within seat next to you, we can work on the brief, and then I’ll

three weeks of one another. There were homes go off and generate it on my computer?” I asked her.

upturned, insurance companies to deal with, and many Initially she thought that this was a good plan. But

people couldn’t get to work. The base was shut down when we got to the front desk to check in, she found out

two or three times in the midst of the disasters. that there were not two seats available in the row she

Still, we were desperately trying to get on contract wanted. She insisted that she had to sit in the exit row. She

within six months. It seemed impossible, given all our told me, “I want to sit there, and I’m already not feeling

obstacles, and our days got longer and longer. We ended good. We’ll just come in tomorrow and work on it.”

up flying to meet other members of our simulation Tomorrow was Saturday. We’d already worked

group for a weeklong session out of town. We were weekend after weekend. My daughter was home sick with

10 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

T
bronchitis, and I didn’t have a babysitter for her the next that, because not balancing your life is one of the pitfalls

day. So I told her, “Well, I don’t have a babysitter. I’d really that many of us have experienced. You get caught up in

like to do it tonight on the plane if we could, or I can come the mission, the work, the it-has-to-be-done-right-now.

in on Monday and we can hit it first thing.” We still had a Sometimes though, it can wait. Sometimes Monday is

few days left to do that. She said, “No. I want you to come just as good as Saturday.

in tomorrow.” I didn’t know what else to do, so I said okay. When you realize that, you start to realize that

By the time I got home though, my daughter sounded prioritizing your life doesn’t have to come at the expense

pretty bad. She was four years old and had always had of your career. Balancing your family life and your work

respiratory problems. She was coughing really harshly, and life actually makes you more productive. If you can

I knew from the sound that she was going to need to go to balance your children, your husband, and your job, then

the doctor. So I thought, I’ll take her with me to work, we’ll you can start to balance your financial managers, your

knock out the briefing in a couple of hours, and then I’ll be contracting officers, and your engineers. It’s a skill that

able to take her to the doctor when we’re finished. covers a broad spectrum, and one that makes you better

So that’s what I did. I went to my boss’s office the at balancing all the aspects of Program Management. •

next morning, and she was talking with an engineer.

They were just chatting away. At this point my daughter LESSONS

was really hacking; I mean, she was sounding worse and • In a dynamic environment of ever-changing demands,

worse. Every now and then I’d poke my head into her choices, and opportunities, it is essential to learn when

office—holding my sick child—and ask her if we could to say no.

make another plan. “Do you want me to do it first thing • Once you have established a priority, don’t be afraid to

Monday? Can I take my kid to the doctor and come actively put it first.

back later? Do you want me to come in on Sunday?” • In the long run, maintaining a balance between your

But she just kept telling me, “No. Just wait.” career and your personal life will enhance your focus

I waited outside that door for four hours. And after and productivity on both fronts.

four hours of standing there, she came out of her office and

said to me, “You know, I’m kind of tired. Why don’t you go QUESTION

on home?” I couldn’t believe what I was hearing. By that When does trying to attain perfection in one aspect of your life

time I had long ago missed my window for the doctor. mean neglecting another?

NOBODY’S PERFECT

As it turned out, I went in on Monday, finished the

briefing, and the whole thing went off without a hitch. It

could’ve waited—well, it did wait—and it was fine. My

daughter though, coughed all weekend long, and there

was a lot of guilt on my part.

This was a turning point in my career. I realized that

I can’t do it all. I won’t be the perfect mother, I won’t be

the perfect wife, I won’t be the perfect Project Manager,

or worker, or whatever title I happen to have at the

moment. I also realized that I would never let anything

like this happen again. I would need to keep a clear focus

on balance—balancing my career and my life—and I

would have to prioritize when I was faced with a

situation like this one. Sometimes you just have to say

no, and I’ve said it since then.

In my head, I lay everything out. I say to myself,

“This will take priority,” and then I work the long hours,

do the traveling, manage everything...but there are times

when I just have to say no. People usually understand

ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 11

LEADING BY EXAMPLE

LYNDA RUTLEDGE knows how difficult it can be

for a woman to juggle her family and a career

in project management. But just because she

recognizes these difficulties doesn’t mean she

wants special treatment. In fact, Rutledge

wants just the opposite.

A program director once told her, “I just like to give women

more latitude.”

“That is when I told him, ‘You’re a male chauvinist,’”

Rutledge says. “I could tell he was mortified. He asked me,

‘What do you mean?’ and I told him, ‘You treat women

differently than men. We don’t want to be treated differently.

What kind of example does that set for junior people when

they see somebody senior behaving that way? Is that the

example you want to set for future leaders?’”

Instead, Rutledge leads by her own example. She strives to

balance her personal life with her career, to organize her

priorities, and to always know when to say no. “These are skills

that all good project managers need,” she says.

Sometimes you just have to say no, 

and I’ve said it since then.
0010110110011010010110110100101101101001

0 1

1

01

0 1

01

1

1 0

0 1

101 01 11 0 1 0 1 0

0110 1

0101 1

1 0

0 1010

1 0 0 0 01 1 1 0 0

0110110101011101010010110110101011101010010110110101011101010010

1010 110 101

1

11101010010110110101011101010010110110101011101010010110110101011101010010

1 0

11011

1010 110 1 0 11011

Risk management process is a front-burner topic in all aircraft and spacecraft communities.

A former colleague of mine noted that a zero mishap rate in experimental flight research can

only be assured by padlocking the hangar doors. However, achievement of the objectives of

a flight program still requires accomplishment of the mission—flying.

12 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
program adapted the 

I

LEARNED A LESSON ABOUT MANAGING RISK FROM A

great project manager—Calvin R. Jarvis. The Phase I

Apollo Guidance System to the 

F-8 airplane, and in 1972 it flew without any mechanical

pilot controls, becoming the first aircraft to fly with a

digital computer in full control.

I got to work for Cal Jarvis on the F-8 Digital Fly-byWire (DFBW) project. The Phase I program adapted the

Apollo Guidance System to an airplane, In 1972 it flew

without any mechanical back-up system, becoming the

first digital fly-by-wire aircraft. Its safety depended on its

full-time, full-authority primary DFBW control system.

Cal managed both high-risk pioneering programs

with great success. He was a master Project Manager,

always keeping cost, schedule and technical performance

in balance, but never trading them for safety.

The Crisis

I was chief engineer and software manager of the second

phase of the program, where three digital computers

were configured as the first fault-tolerant airplane

DFBW system. The Draper Laboratory developed the

flight software. IBM supplied the flight computers.

The F-8 DFBW aircraft had flown about a dozen

flights, and was making good progress. A systems

engineer called and told me that the preflight self-test

had failed while preparing for the next day’s flight.

Early in the program we had encountered a few selftest problems in the control surface tests, which had very

small tolerances, so I assumed it was a tolerance problem.

While troubleshooting the self-test failure on the

airplane, however, I froze and my heart sank as I realized

ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 13

The F-8 Digital Fly-by-Wire

(DFBW) in flight.
14 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

the problem was far worse than some self-test tolerance

setting. I discovered that a half-dozen instructions in the

computer’s flight software did not match the program

listing! I could tell the paper listing was correct — so the

flight computer had contaminated instructions.

This was impossible, unbelievable. There was no

immediate explanation. One thing was certain, the

airplane and the program had to be grounded until we

could figure out what had happened.

I called Cal Jarvis immediately and told him about

the problem. He asked quietly, “Does this mean the

flight tomorrow is off?” “Cal,” I said, “This is a

catastrophe! I have no idea what is wrong. This is a spear

through the heart of the program.”

“How about flying Tuesday or Wednesday next

week?” Cal asked. “You just don’t understand,” I said.

“This is a monumental disaster.” Cal wasn’t listening to

my doomsday remarks. He asked me to document the

problem and work with Draper and IBM to find out

what happened.

Problem Found, but the Crisis Remains

The Draper Laboratory and IBM identified the cause of

the problem the next day. An error in the “Assembler”

software was found that could produce a contaminated

computer load tape while correctly producing the

software listing.

We verified that the paper listing was correct. This

was to be a key finding. We also established that prior

flight tapes had not been contaminated. We informed the

Space Shuttle program about this problem since they

were using the same computer and Assembler software.

I told Cal that IBM was fixing the Assembler flaw

and we were developing a new check process that would

verify future tapes to be correct. We would then

reassemble the flight code, generate a new load tape,

load the computers and carry out the preflight tests. I

estimated it would take a couple of weeks.

Risk Management

Cal noted that the F-8 schedule was critical, with

upcoming flight tests of some Space Shuttle software.

On Thursday he asked, “Is next week out of the question

for a flight?” By this time my patience was wearing thin.

I was only thinking of safety, my primary focus. Cal was

concerned about safety, too, but he was also thinking

about flying safely.

He asked me how many memory locations had

been contaminated. I said that the handful of

instructions in the self-test program was the only thing

we’d found so far, but that there were about 25,000

instructions and data words that we hadn’t checked yet.

Cal then asked the key question, “If we could prove

that these were the only contaminated memory

locations, and we corrected them, would we be able to

fly next week?” That was a good question—could we fix

the problem expeditiously? I looked at the pictures on

his wall, of the other experimental aircraft he had

worked on, which all flew successfully. I decided to think

about his challenge.

Risk Elimination

I subdued my emotional response, and started to focus 

on the technical issues. We didn’t have a means to

automatically check the computer memory against the

accurate printed listing. The listing took up 250 big pages.

I laughed to myself and thought, “How long would

it take to manually check a computer memory dump

against the listing?

Let’s see, there are 25,000 memory locations. If we

had five teams of engineers, and they could read aloud

and verify one memory location every 10 seconds, five

teams could verify 30 memory locations a minute. That

would take about 14 hours.

I proposed this to Cal, and he smiled and said,

“How about flying next Wednesday?” I said we could do

it. We got a few more than five teams together, alternated

the reader and verifier every couple of pages or so, and

The F-8 Digital Fly-by-Wire

(DFBW) in flight.
ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 15

added breaks. We finished by Friday afternoon, and did

not find any other errors. I guess sometimes pioneering

work needs solutions rather than elegance.

We had a process for patching the software on site,

and so we manufactured and verified a corrected load

tape. The self-test was run and passed several times. I

signed the software release document as the Software

Manager (with more humility this time) and developed

the technical briefing for management.

I presented the technical findings and explained the

carefully controlled manual checking process. Cal

offered another explanation for flight readiness. “We all

agree that the intended software load, as represented by

the listing, was qualified before the contamination, and

we had many successful flights. Therefore correcting the

six incorrect computer words to their original value

means the patched software load is also qualified.”

After some hard questions—like “Why didn’t you

anticipate this?”—senior management approved the

flight. We flew on Wednesday, as Cal had asked.

We also worked with Draper Lab and IBM to

develop a 100% closed loop check process of the load

tape and listing against the original machine code

produced in the mainframe.

Years Later

This event happened more than 25 years ago. The F-8

DFBW completed a long and safe flight research program.

I learned from Cal Jarvis that the role of the Project

Manager is to complete the project successfully. Cal

Jarvis never lost sight of that, but he never cut any

corners or sacrificed safety for schedule. I realized Cal

Jarvis’s success on the F-8 DFBW was not just good luck.

Cal Jarvis went on to manage several more projects,

including the joint US-Russian Tu-144 supersonic flight

research project, and eventually ran the entire Dryden

Flight Projects organization for several years.

The bottom line is that it is possible to conduct

high-risk missions safely, but it takes intense effort and

an open, communicating organization. Today, you can

visit Dryden and see the F-8 DFBW, the X-29, and

several other experimental aircraft on display. This is a

testimony to the ability to fly high-risk programs safely.

It had been instilled in me that the objective of an

important endeavor, like experimental flight research

and test, is to fly safely. Padlocking the hangar doors will

eliminate flying accidents, but will not advance the cause

of flying. •

LESSONS

• Effective managers keep their cool when unexpected

situations arise. This enables them to calmly see the big

picture while zeroing in on the specific problem.

• Project success requires a keen focus on results, even

if the processes and solutions employed to get them are

not so elegant.

QUESTION

To what extent is the project leader’s attitude towards a setback

reflected in the attitude of the team?

KENNETH J. SZALAI served as Director of the NASA Dryden Flight Research Center from

1990–1998, retiring from NASA after 34 years of service. He is currently an aerospace and

management consultant in the United States and in Europe.

Digital Fly-by-Wire, or DFBW, is a digital electronic flight control technology. A digital

computer receives pilot maneuver commands and rate, altitude, and acceleration information

from sensors. The computer uses this information to direct the hydraulic actuators to move the

aircraft control surfaces in such a way that the aircraft maneuvers according to the pilot’s commands. All this

information is electronic, and is carried by wires, hence “fly-by-wire”. The cables, pulleys, and other mechanical

devices formerly used to connect the pilot stick controls to the surfaces or hydraulics are removed in a pure fly-bywire system.

The digital computer software also provides powerful artificial stabilization of the vehicle so that the aircraft

designer is no longer bound by traditional design constraints. DFBW enabled the first moon landing. The NASA

Dryden F-8 DFBW program was the first to achieve digital fly-by-wire control for an aircraft, in May 1972. Now

virtually all military aircraft and modern airliners use DFBW control.
16 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

SO WHY DEVELOP CONTROL TECHNOLOGIES IN THE FIRST PLACE?

“We had all these organizations—the NASA Integrated Action Team, the Shuttle Independent Assessment Team, and the U.S. Air Force—

looking at accidents like the Arian Shuttle and the Challenger and asking why,” explains Joan Pallix, of the NASA Ames Research Center. 

“One of the things they found is that we don’t have any systems that understand when there is something wrong with them and can

autonomously diagnose their problems.”

Pallix says that this technology will become essential for ensuring the safety of vehicles like airplanes and spacecraft. “Until now we’ve

had no way to test vehicle’s complex systems to make sure that what we’ve built is right,” she says. “Usually a problem has to do with a

failure in the structure of the vehicle, or the propulsion system, or the control system. That’s why we are focusing on intelligent flight control.” 

There are hundreds of things that can go wrong inside a vehicle, but Pallix and her team are developing flight software that will eliminate

the most common sources of failure. What’s unique about it? “The ‘neural net’ is a system that actually learns,” she says. “It notices when

the pilot tries to do something and the plane doesn’t react. Then it reuses the surfaces to make it happen.”

BACK IN THE MID-1980S AN ISRAELI FIGHTER PILOT COLLIDED WITH ANOTHER

VEHICLE DURING A TRAINING MISSION. THE WING WAS TORN FROM HIS F-15 DOWN

TO THE WING ROOT. HIS TRAINER ORDERED HIM TO EJECT, BUT THIS HIGHLY SKILLED

PILOT REFUSED AND PROCEEDED TO STABILIZE THE AIRCRAFT BY USING HIS

REMAINING CONTROLS IN A HIGHLY UNCONVENTIONAL MANNER. HE MANAGED TO DO

THE IMPOSSIBLE BY SAFELY LANDING A SINGLE-WINGED PLANE.

THAT’S VERY, VERY HARD TO DO. IN A SIMULATION AFTER would have it, one of the passengers on the plane

the incident, it was found that only one in ten of the was a pilot who had just completed 100 hours of

pilot’s peers could have successfully completed that engine-only flight training, which involves flying

same maneuver. Ideally, of course, we want to without surface controls. He recognized that there

develop technology that enables all pilots to have was a problem on the plane and made his way to the

the same capability to land safely. cockpit to offer his help. Amazingly, this experienced

These mishaps aren’t just happening to military passenger and pilot worked together to crash-land

aircraft, either. In the past 20 years, there have been the plane, saving more than half of the lives of the

a number of commercial aircraft mishaps resulting passengers. All would have been lost if not for the

from loss of primary control systems. For example, unique experience of this unexpected passenger.

there was a serious incident in Sioux City, Iowa with

a DC10 carrying a full load of passengers. An engine PUSHING FORWARD

component failed and exited the engine compart- Recognizing these stories as representative of a

ment, penetrating the fuselage and severing the national technological need, my group at the NASA

hydraulics required to manipulate the aircraft Ames Research Center, Resilient Systems and

control surfaces. Under normal circumstances this Operations, began funding technology development

would result in an uncontrolled crash. As luck to enable seriously damaged aircraft to autonomously

020

030

040

050

090

011

FOR SAFE 060

070 TY’S SAKEBY JOAN PALLIX

080
ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 17

regain control. We had started to develop and flight test an

intelligent flight control system, or “neural net controller,”

0 designed to adapt to the loss of various control surfaces

and devices on commercial planes and spacecraft. We 20 believed it would be revolutionary in changing the level of

safety on these vehicles. 30 Our conviction wasn’t enough proof for NASA

Headquarters and Congress; good ideas abound, but 40

budget is limited. They needed to see a clear future in

our project and a definite plan to infuse the technology 50

into future aircraft or they’d cut our funding. The

60 Federal Aviation Administration (FAA) is responsible for

safety regulations in the national airspace and helps

70 government agencies to make this type of funding

decision. Historically we’ve had trouble getting the FAA

80 on board. They wouldn’t back a project just because it

was supposed to make things safer. They’d need to see

90 research on how the system works with a human being

in the cockpit—and that takes time. 11 Still, FAA support was important for the project, I

made it my mission to write the requirements in a way 22 that put it on track for success. I didn’t simply tell the

people on the program that FAA buy-in was important,

I went a step further. I wrote it into the actual requirements that we get FAA agreement. By placing that on

the project’s “critical path,” I knew that the issue would

get attention.

Though the FAA typically deals with the certification of finished products, I knew that having their

support up front would give us a much better chance of

survival with Headquarters and Congress. At first, my

efforts were ignored. They weren’t interested in

spending time on a speculative project at such an early

stage of development.

They didn’t want to talk to us about a system until

some company said, “We’re going to put it in our

vehicle.” No company was going to put it in their vehicle

unless they knew that it was certifiable and cost effective.

Congress wouldn’t and shouldn’t fund a system that no

one was committed to putting in their aircraft. It was

something of a Catch-22 as far as funding goes.

A LITTLE HELP FROM OUR FRIENDS

I realized that I couldn’t do it alone, so I made a new plan: I

started networking. I used my contacts to get someone’s

attention at the FAA. We do a lot of work with pilots and

researchers inside our NASA organization stationed at

Dryden who, in turn, have a lot of direct contact with the

folks at the FAA—so we enlisted their help.

We know the Dryden people well since they fly all

the software we develop. I was able to convince one of

the guys there to help me push it through. I explained to

him that our program wouldn’t have credibility unless

we found an advocate at the FAA, someone who would

say, “Hey, I’m interested in this; it could be the wave of

the future,” and convince their bosses to let them go and

have a look.

He understood how important the project was, and

he worked hard to reach an agreement with the FAA.

They were reluctant to commit to a standard certification process for a project that wasn’t even finished—but

they finally agreed to what they a called “mock certification” process for our system.

This was a major success! We had gotten the goahead to work on our experimental project, and we

could test it with our provisional certification. This was

exactly the “green light” we needed to ensure continued

funding for our work on the neutral net. •

LESSONS

• Sometimes the success of a project is determined by

how much you believe in it and how much you are willing

to push. New development projects are never handed out

readymade; you have to be willing to shape it and keep it

moving whether you have initial support or not.

• It is important to know the politics involved in the

approval of your project. You need to not only know

what you’re selling, but who you’re selling to.

QUESTION

Is it the role of the project manager, or the project sponsor to scan

the project’s external environment and maintain constant

communication with the project’s stakeholders?

JOAN PALLIX earned her Ph.D. degree

in chemical physics from Yale University in

1987. With a diverse background in quantum

dynamics, chemistry, laser spectroscopy,

materials science and solid-state diagnostics, diagnostic

instrumentation, measurement systems, and optics, she has

published numerous papers in those areas. Over the last ten

years, she has held various supervisory and managerial

positions for scientific research and engineering projects at

NASA. Pallix currently manages the Resilient Systems and

Operations project at NASA Ames Research Center.

01

0

0

0

0

0

0

0

0

0

0
THE

SO, WHEN I ENTERED THE WORKFORCE I ALREADY KNEW much more effectively than the typical engineer, and only

communication skills would be considered an important minor improvements were needed to be seen as having

asset; but I was an engineer, and the stereotype of better communication skills than my peers. Needless to

engineers at that time was that they didn’t have well- say, I felt pretty good about myself.

developed writing and speaking skills. Because of this, the During an annual performance evaluation, after

success bar for an engineer’s presentation skills was set working for about five years, my boss suggested I attend

fairly low, and I evaluated my own skills. What I came up a communications training course instead of the

with, in my “unbiased opinion,” was that I communicated standard technical or project management (PM) courses

18 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

CAMERA 

NEVER

L

BY W

IES

. SCOTT CAMERON

THROUGHOUT MY LIFE, PEOPLE HAVE ALWAYS STRESSED TO ME THE IMPORTANCE OF

EFFECTIVE COMMUNICATION WITH OTHERS. ONE OF THE FIRST TIMES I REMEMBER

HEARING IT WAS IN THE SIXTH GRADE. MY ENGLISH TEACHER WOULD HARP ON ME

ABOUT HOW HIS SPEECH CLASS WAS GOING TO BE SO IMPORTANT TO ME IN THE FUTURE.

BUT BEING ONLY 12 AT THE TIME, THE IMPACT OF THIS SAGE ADVICE FELL ON DEAF EARS.

I HEARD THIS SAME ADVICE AGAIN IN A COLLEGE SPEECH COURSE. THE COURSE DIDN’T

HELP ME GET OVER BEING NERVOUS ABOUT SPEAKING IN FRONT OF PEOPLE, BUT IT DID

REITERATE THE IMPORTANCE OF VERBAL COMMUNICATION.
I had attended in the past. Most of my previous training

recommendations were based on increasing my

knowledge of the nuts and bolts of PM and engineering

(i.e. making schedules, scope development, cost control,

team dynamics, etc.) so I was somewhat taken aback by

this suggestion.

Apparently, the feedback I had received—from not

only my hierarchy but also from my peers—indicated

that I could benefit from a communications course.

I thought I had good presentation skills, and it had

always appeared others liked my presentations and

meetings. But I decided to take the feedback as an

opportunity to improve and made the decision to attend

a two-day communications course.

The course I chose was different from any other

training I’d experienced. Its sole purpose was to improve

your verbal communication/presentation skills by

addressing three separate situations encountered in the

workplace. One situation was a one-on-one meeting with

another person, another was a two-minute question and

answer session, and the last was a five-minute prepared

presentation with a question and answer period at the end.

The presentations were videotaped and critiqued during

the first day of the course. They were taped again at the

end of the second day so you could evaluate your progress

and hopefully see a positive difference.

I was shocked at what I saw on the first tape. Yes,

that was me talking in each of the situations, only now

I was seeing myself as others saw me. They say the

camera never lies, but this was not the way I had

envisioned myself. My eye contact was terrible,

I swayed back and forth, there were too many hesitations, my body was stiff, I didn’t have a command of the

material or the stage... the list could go on. To make

matters worse, in a class of fifteen other students,

I compared my style to theirs and realized I was not

even in the top 50% for communication skills. Each

taped presentation pointed out the different flaws in

my communication, and I got to see the impact it had

on my audience first-hand.

I completed the course, and I am happy to say it has

had a positive and lasting effect on my verbal communication skills, how I view the presentations of others, and

how I provide feedback for them. Because of lessons 

I learned from this course, my boss and my peers

commented on the marked improvement they saw in my

communication skills in a variety of settings.

To this day I call upon these communication skills

constantly, since as a Project Manager I am often the focal

point of many one-on-one, project team, and review

meetings. I’ve learned it is important to be able to step back

and see yourself the way others see you. It helps you gain

credibility, and if you are not credible, then your effectiveness as a project manager can be greatly diminished.

When I coach and mentor project managers, I find

myself focusing on their “soft communication skills” as

potentially huge growth opportunities for them, but also

as ways to differentiate themselves from other Project

Managers. I try to pass along that taking a communication training course and seeing yourself as others see

you can improve your overall effectiveness.

After all, effective communication is a must for

project managers and it’s our job to set the success bar

higher for the future of project management. It still

amazes me how my sixth-grade English teacher had it

right all those years ago, but I just didn’t listen. •

ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 19

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.

“THE FEEDBACK I HAD RECEIVED—

FROM NOT ONLY MY HIERARCHY BUT ALSO FROM MY PEERS —INDICATED THAT 

I COULD BENEFIT FROM A COMMUNICATIONS COURSE.”
LET ME COUNT THE WAYS... The second reason formal programs fail is that they

No one that I know in a senior position got there tend to be cumbersome and unwieldy. Everyone clamors

without some mentoring along the way. Usually they’ve to become part of a formal mentor program; they view it

had informal mentoring, and usually it started early in as some sort of right or important square to fill. This

the career with more than a single mentor. But there are leads, in turn, to a bureaucratic selection process where

many different ways to get the benefit of mentoring. It paper matters more than real accomplishment. The

can be done in a way that is formal, informal or in a way truth is that many people can derive no benefit from

I like to call “informal-informal.” mentoring, because they think they already have all the

It’s been my experience that formal mentoring answers, because they have limited potential, or because

programs almost never work, and there are varying they view mentoring as just a way to get a better job with

reasons for this. One is that such formal programs higher pay. Mentoring needs to be selective.

demand a pervasive management commitment across an

organization that almost never exists. Many senior STEPPING UP

people give mentoring lip service but are unwilling to My strong preference is for informal mentoring; I want

spend the time that it takes to do it. Notice I said to pick whom I mentor. For instance, in my current job

unwilling rather than unable. Many so-called leaders fail I have selected seven people within the Agency. How did

to recognize that mentoring is as important as anything I select them? I used my own observations, and the

they do and more important than most of what they do. opinions of others whom I respect, to identify GS-15s

20 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

ME

TEACH

NTO

ING WHAT IT M

R

EAN

I

S TO B

N

E A L

G

EA

:

DER

BY TERRY LITTLE

RECENTLY I CHAIRED A PANEL INTERVIEWING CANDIDATES TO FILL AN S.E.S. POSITION WITHIN THE MISSILE

DEFENSE AGENCY. WE INTERVIEWED SEVEN CANDIDATES: SIX FROM THE DEPARTMENT OF DEFENSE AND ONE

WHO HAD RETIRED FROM PRIVATE INDUSTRY. FIVE OF THE CANDIDATES, ALL GS-15S, WERE UNACCEPTABLE FOR

THE POSITION. THE SIMPLE REASON WAS THAT THEY DIDN’T COMPREHEND WHAT IT MEANT TO BE A LEADER.

AND THE SAD TRUTH IS THAT NO ONE EVER TOLD THEM. THEY NEEDED MENTORING, BUT NEVER GOT IT.
ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 21

with high potential to become SESs. Only one of those

people actually works for me and there are two that I

frankly don’t like very much. That’s OK because not all

high potential people work for me or are to my liking.

And why did I choose GS-15s instead of GS-12s or

GS-13s who might be in their more formative years?

The answer is two-fold. Number one, mentoring takes a

lot of time and effort, and I have limited time and energy.

I would rather do a reasonable job mentoring a few than

a pitiful job mentoring many. Number two, mentoring is

everyone’s responsibility and not just the responsibility

of those in senior positions. Put another way, every GS13 has an affirmative responsibility to mentor those

below him or her in the pecking order. The same is true

for every grade level. Part of my role in a senior position

is to communicate my expectation to those below me

that they have a mentoring responsibility for which I

hold them accountable.

AN INFORMAL GATHERING

So how do I do my informal mentorin

person I mentor regularly—nominall

also meet with everyone I mentor as

a group once each six months. In

between, I send articles or suggested

readings, as well as some words of

counsel that come to me. To me and

to them it’s critical that these things

be predictable and personal—

something they can count on and

that means something to them as div

When we recently met as a grou

importance of maintaining unbridled

g? I meet with each

y once a quarter. I

erse individuals.

p, we discussed 

 passion about o

work, while avoiding counterproductive displays 

emotion. We tried to come to grips with how to maint

our dignity and grace in the face of adversity. We a

addressed the importance of focusing on the job-aft

next as a guide star for deciding what to do now. In 

cases of the individual meetings, I typically answer a

questions and give direct feedback on areas where ea

person may need improvement. For instance, I told o

individual recently that his manner of dress (casual, with

a short sleeve shirt, no tie and relatively disheveled hair)

impacted his ability to influence people and left a bad

first impression. He argued that his manner of dress

shouldn’t matter. I countered that whether it should or

shouldn’t matter is irrelevant. It does and he should do

something about it if he wants to lead. I told another

person that she did too much talking when she should

be listening. I gave her several examples. Both people

thanked me for the feedback and related that no one had

ever given them such constructive feedback in their

entire careers. Perhaps it was easier for me to do this

since neither of the persons worked for me, but I think

it’s a pretty sad commentary that neither of these two

had ever had the benefit of the most basic mentoring

tool: timely, constructive feedback.

WHAT KIND OF ROLE MODEL ARE YOU?

Finally, my favorite mentoring is what I call “informalinformal” mentoring. I like it because it’s unconscious

and natural for the mentor (especially valuable for a lazy

one like me) and because those getting the mentoring

don’t even know that it is happening. Its working

is simple. As we progress up the career chain,

our behaviors become more and more visible to an

increasingly larger number of people. We are not

conscious of it, but others take their cues from those

aucratic pyramid than they are. They

iors and make judgments about it. Is

 emulating? If so, how can I adapt that

behavior to my unique personality?

Is it something to avoid? If so, how

do I sensitize myself so that I don’t

do it unconsciously? Much of what

we turn out to be as individuals is a

derivative of what we have learned

higher up the bure

observe our behav

it something worth

from observing others—not from

what others have told us, what we

have read and so forth. When others seek to emulate us,

the we have mentoring at its finest. Each person may have

ur his or her own style that precludes direct “copycatting.”

of But when one sees basic leadership principles working

ain effectively in real life, it can have a profound effect.

lso I believe that mentoring is so important and so

er- neglected that I intend this article to be the first in a

the series I will write on the subject. For the readers, my

ny hope is that these will contain an idea or two that may

ch provoke you to become better mentors. •

ne

WE DISCUSSED THE IMPORTANCE

OF MAINTAINING UNBRIDLED

PASSION ABOUT THEIR WORK,

BUT AVOIDING COUNTERPRODUCTIVE

DISPLAYS OF EMOTION.

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.
22 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

NEAR THE END OF THE 2002, AND AFTER MONTHS ON early 2003, it was clear that action had to be taken to

Goddard’s MLA project, I became concerned that the clearly quantify the magnitude of the remaining work.

software test effort had not made as much progress as Another manager and I made some inquiries about

was needed. why the test effort was struggling. We found that the test

The development effort was nearing completion, procedure environment wasn’t as easy to use as we’d

but the testing effort seemed to be struggling. We had hoped, and that delays in production of the flight

created a loose schedule when the team was formed, but software were translating into delays for the test effort.

now it wasn’t serving our needs. It was difficult to tell I asked the software Test Lead to come up with a

how much work was left in the test effort, and detailed schedule that showed delivery of all the test

instrument integration was just a few months away. By procedures by June 30th. I asked that it include all the

As a line manager overseeing the software development team for the Mercury Laser Altimeter (MLA) on the

satellite MESSENGER (MErcury Surface, Space ENvironment, GEochemistry and Ranging), which is scheduled for

launch in July, I was charged with the responsibility of making sure the software delivery was complete and on

time. Because the spacecraft is going to Mercury, its launch date is constrained by planetary alignment. And since

the launch was constrained, everything that came before it had to go according to plan.

TES+ING POSI+IVE

by Ron Zellar
empty staff positions required to pull it off. That way, we

could see exactly how much work was left to do and how

many people were needed to do it.

I knew the prevailing opinion of adding newcomers

late in a project was that it didn’t work. Putting more

people on a job supposedly causes greater delays, since

it distracts the already established team from making

progress. Still, we needed more manpower to get the job

done. And after looking at the Test Lead’s schedule, I

realized just how big our problem was. Realistically, in

order to develop the test procedures required to test all

of the functionality in the flight software, our test team

would have to double or even triple in size.

The recovery plan

We decided that we needed to add five or six full-time

people to the project. Although we needed the help

desperately, we still knew the importance of getting the

right people. We needed people who had a proven track

record of success, and a background in software script

languages. A history with software testing would have

been a bonus.

The other branches in our division really came

through for us. They realized that this mission was an

important one for Goddard, and that on-time

completion was critical to its success. They took people

off their current projects part-time and delayed the

schedules on those projects. In the end we managed to

get eight part-timers, who were essentially the equivalent

of five or six full-time people.

As people were identified to us, we approached

them individually. Some were concerned about moving

to the project so late in the game, and we wanted to ease

their transition. We negotiated a “contract” with them.

“If you can help us out,” we told them, “then we will

make a commitment to you that we will not involve you

past June 30th.” This was the key for getting people to

agree to work with us.

By late January and early February, new people

began joining the team. In March the full team was in

place, and we scheduled a training session so the

existing team members had an opportunity to share

their knowledge about how the system worked. We were

trying to promote a unified team atmosphere. It gave the

senior team the opportunity to say, “Here, let me take

you under my wing,” instead of saying, “You’re an

outsider. Stay away.”

The best-laid plans...

The first thing we did as a newly organized team was to

plan a new schedule. We planned it in a lot of detail,

essentially week-by-week, using an earned value system.

This allowed us to keep on top of whether we were

making our plan or falling short of it. It also allowed us

to keep everyone informed about our progress.

Things were going well for a few weeks, but then we

started to fall behind schedule again in late April. This

time, we saw the slip right away. We met with the entire

team to address the issue. I asked them, “What can we

do to recover? What can we do to get our results to

match our plan?” The meeting resulted in many

recommendations and some greater insight into the

team’s challenges.

For example, one recommendation was to acquire

another test bed. I talked to the Project Manager and was

able to get time on a second test bed and have it moved

The Mercury Laser Altimeter (MLA) software and development team from left to right: Anne Koslosky, Brett Mathews,

Samira Ghazi-Tehrani, Dan Berry, Maureen Armbruster, Dave McComas, Lisa Hoge, and Ron Zellar.

ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 23
24 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

into the software development area. This way the team

wouldn’t be constrained by limited resources. It went a

long way toward keeping the team’s momentum going.

I also reminded the team members that comp time

was available, and they made regular use of it. During this

time, though it was difficult to do, I always tried never to

refuse a request for leave. We all tried to create an

atmosphere in which it was clear that we needed to get a

lot of work done in a short amount of time, but in which

the team as a whole would fill in the gaps when necessary.

It was suggested that weekend work might be a

good idea for those team members who could do it. A lot

of people had children and other commitments, so I had

to be respectful of those who couldn’t come in. It was

definitely a “request” rather than a “demand,” and I left

it to the team leads to talk with their staff.

For those people who showed up on weekends, I

tried to always show my appreciation for their time and

efforts. I made sure that I was there on those extra days

as well. I usually found one or both of the team leads

there along with a few other staff members. I would call

ahead and ask what their lunch request was. Then I’d

stop on my way in to pick up sandwiches for anyone in

the lab. I made sure that everyone’s supervisor knew they

had worked on a weekend. My manager would even

make a special trip to an individual’s office just to thank

them for working extra hours.

The attitude seemed to spread. The Test Lead

brought in candy for everyone and music to listen to as

we worked. People were making a real effort to stay

positive. In response to that, others were more willing to

work additional hours without even being asked. The

workplace became a more “fun” place to be, but at the

same time there was an acknowledgement of my high

expectations leading to a more aggressive schedule.

People were giving their all, and for the most part they

were giving it with a smile. This demonstrated a real

dedication to success — the dedication to succeed as a

team and not as individuals — and created an

atmosphere that was mutually supportive.

Against the odds

By late June we had actually made up for lost time. The

test procedures were substantially ready. There were a

few exceptions, but these were well-noted and

understood. We began our formal acceptance testing of

the flight software. Some of the staff members even

decided to help us as best they could after their

committed deadline of June 30th had passed.

In the end there were a number of factors that

contributed to our success: a sense of commitment,

more attention to schedule, Branch Managers willing to

reassign their best people, and Division Managers that

championed our work. We did it despite the common

belief that it doesn’t work to add extra people in the

middle of a development cycle. The Product and Test

Leads continually exceeded my expectations and visibly

grew in their leadership capacity. As a testament to their

group effort, many members of the development and

test teams received awards and recognition from our

division for their outstanding efforts. Most feel, however,

their greatest reward will be the day MLA returns its first

science data from Mercury. •

LESSONS

• Fostering a positive atmosphere and an attitude of

team spirit may make all the difference in the success of

your project. People will be more willing to step up when

they feel like appreciated members of the team.

• High levels of team energy and enthusiasm are

sustained by both high expectations and an environment where each member can effectively work at the

peak of their capabilities.

QUESTION

When adding people to your project team, how do you know you

are getting the right people?

RON ZELLAR graduated from Virginia Polytechnic

Institute in 1991 with a B.S. degree in Physics and a

concentration in Astronomy. “When I got out of

school, I was working with scientists,” he says. “I

learned software as an aside, as a means of

tor for

 called

tation.

s first

 Space

ntains

ws the

s, and

spaceee the

ENGER

supporting them.” His “aside” soon turned into his career. 

He made the jump to flight software, becoming a contrac

the Naval Research Laboratory where he worked on a project

the Interim Control Module (ICM) for the International Space S

After leaving the Naval Research Laboratory, he landed hi

management position as an Associate Branch Head at Goddard

Flight Center. There he serves in a branch that develops and mai

flight software for Goddard’s missions. He oversees and revie

implementation of computer-based subsystems, instrument

sensor suites that enable the operation of Goddard's scientific 

bourn systems. One of his first assignments was to overs

development of the MLA software, an instrument on the MESS

Spacecraft set to orbit Mercury in 2011.

His motto: “Build cool stuff. Launch it into space.”

The Mercury Laser Altimeter (MLA) CPU board that operates

the MLA software.
ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 25
NEEDING MONEY FOR COLLEGE, I WAS ABLE TO funding, and the more visible your project was the more

get an Air Force ROTC scholarship and likely it was to be funded.

used it to get my undergraduate degree in My decision to watch Jim was reinforced when he

chemistry. The Air Force also allowed me was moved from the laboratory up to our product

to go on to graduate school and delay my entry to active division to manage a new major weapons program. Jim’s

duty. I earned my masters and was well on the way to my enthusiasm was contagious. He was a natural magnet

doctorate when I was finally called up to serve. I was elated who drew people and funding to his project. Still, he

when I got a laboratory assignment to work on new wasn’t perfect. Sometimes he got carried away with his

warheads for air-to-surface missiles. enthusiasm, and it affected his judgment. I watched one

My euphoria was short-lived. Immediately after I high-level briefing where his “can do” attitude led him to

arrived, the Air Force decided to contract out most of make several technical projections, which he later was

their warhead research. I was reassigned as an R&D unable to deliver. He was forgiven but this flaw eventuproject manager with responsibility for part of this ally caught up to him, and he was transferred to a deadresearch. As a consolation, I was sent off to a three-week end position in our test organization.

Air Force training program on R&D project manage- Finding the ideal project manager was proving more

ment, but I still felt inadequate for the task. I wasn’t sure difficult than I anticipated. I bumped around the laborawhy at the time, but looking back I think the training tory and future plans division for a few years and then

concentrated too much on the “programmatics” of cost, made a career change to training. I joined the faculty of

schedule, and performance, and not enough on how to the Defense Systems Management College (DSMC), the

really manage a project. center of project management training in the Department

Still wanting to learn, I decided to switch to a more of Defense (DoD). Our main mission was teaching future

practical strategy. There were lots of project managers in DoD project managers, but the faculty was also encourmy new organization, many who had been at it for years. aged to do research and writing.

I decided to pick a few and pay closer attention to what

they were doing. The best data came from having

The first and most obvious candidate was my managers recount critical incidents 

officemate Ed. He had worked in the lab for years and that occurred on their projects. was way above the rest of us technically. At first glance

he appeared shy, but he was quite personable when you I decided to channel my interest in the ideal project

got to know him. What stood out about Ed was his work manager into a research project. While my “people

ethic; he was so interested in his work that he had set up watching” strategy hadn’t exactly borne fruit during my

a small laboratory at home in his garage. Tinkering on early project management career, I concluded that the

his own, he had actually developed a new formula for approach was still sound. Surprisingly, this method of

incendiary material. He passed this on to his contractor, “success modeling” was widely endorsed by esteemed

and it later became the basis for a successful fielded publications from The Handbook of Leadership to the best

system. I was puzzled that Ed hadn’t been promoted to seller Think and Grow Rich. There were also high-priced

a higher level in the organization. consulting firms using it to create competency models

The puzzle didn’t last long however. As I watched and professional development programs for a variety of

more carefully, I discovered that Ed was weak as a career fields, which did not yet include project managecommunicator. He was a poor writer and had an outright ment. So I obtained some funding and started a research

phobia for giving briefings. Once when he was scheduled project myself.

to give a project briefing to upper management, he called There was no better place to study project manager

in sick, and his branch chief had to give the briefing for characteristics than DSMC, the “Mecca” for DoD project

him on short notice. managers. We had former project managers as faculty,

I decided to switch my attention to Jim, who was the future project managers as students, and current project

real star performer in our division. He was young, managers as guest speakers. This latter category interested

energetic, and articulate. He never seemed to miss an me the most. I took a lot of survey and interview data from

opportunity to talk about his project. This was important practicing project managers, but the best data came from

since our laboratory projects were always short of having these project managers recount critical incidents

26 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP
that had occurred on their projects. This is very similar to

the “learning through stories” approach used by NASA.

Our flagship course at DSMC was the 20-week

program management course and we prided ourselves on

bringing top-level project managers in as guest speakers. I

checked the list of guest speakers for the current course

and noticed that we had scheduled two high ranking Air

Force project managers one week apart. Each was a

brigadier general managing the largest project in his

product division. I would make it a point to watch both

speakers and look for the similarities.

They weren’t playing the role

of project manager.They were

being themselves.

The first project manager had a reputation as a

tough, hard-nosed manager and he lived up to that

reputation in person. He was a “pusher.” He pushed

hard on himself, his people, his contractors and on

anyone who got in his way. He was very confident and

articulate. As he talked to our students, I had a

momentary flashback to the movie Patton. Here was the

project management equivalent to George C. Scott as

General Patton making his famous speech to the troops.

The analogy was almost perfect.

A week later the second guest speaker came in, also

a brigadier general but from a different Air Force product

division. He was much more “low key” than his counterpart. While he spoke softly, he still commanded our

attention. What was most remarkable about this project

manager was his constant reference and deference to his

people. He attributed his success in project management

to pulling together an excellent team and giving them lots

of leeway and support to do their jobs. I again flashed

back to the Patton movie, and here was the equivalent of

Karl Malden as General Omar Bradley. Again, the analogy

was almost perfect.

Both project managers had come and gone as guest

speakers, and I took stock of what I learned. I had

expected to find some clearly evident characteristics

common to both. But this was not to be. In fact, I had a

hard time identifying any similarities between the two of

them at all. The appearance of two completely opposite,

yet successful, project management styles left me in a state

of “cognitive dissonance.”

Not wanting to give up completely, I reflected for a

moment. If the two project managers had no clear

similarities on the surface, what about less obvious

similarities? I thought about this for a moment. Clearly,

both were successful. They were one-star generals

managing two of the largest programs in the Air Force.

They achieved program outcomes and delivered

systems to the warfighter. They got RESULTS. (Both

continued to advance in their careers and later retired

as three-star generals.)

While their styles were quite different, both project

managers were true to themselves. What you saw was

what you got. They weren’t playing the role of project

manager. They were being themselves. They had

personal CREDIBILITY.

As it turned out, wading through lists of competencies from my formal research project provided no more

significant insight than I got from watching these two

experienced project managers. Every project manager I

interviewed or surveyed in my research was different, but

they were able to get results with a style based on their

personal credibility.

So what about the differences? That I have come to

realize is the nature of project management and life in

general. Projects are different, project managers are

different, project teams are different, and the environment

for each project is different and constantly changing. This

leads to my final conclusion that there is no ideal project

manager nor should there be. I think that is what attracted

me to project management in the first place and what will

keep me engaged in a lifetime of research and reflection in

this field. •

LESSONS

• Technical expertise and experience aren’t the only ingredients necessary to succeed in project management.

• You can learn a lot by carefully watching and listening

to experienced project managers, but you may need to

reflect on it to find the real meaning.

• Personal credibility and achieving results are key to

project management success, but there are many paths to

get there.

ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 27

DR. OWEN GADEKEN is a Professor of Engineering Management at the

Defense Acquisition University where he has taught the

Department of Defense Program and project managers

for over twenty years. He is a retired Colonel from the

Air Force Reserve and a Senior Reservist at the 

Air Force Office of Scientific Research. In addition to

serving on the ASK Review Board, Dr. Gadeken has published both his

stories and practices in various issues of ASK Magazine.
28 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

RAPID

PROTOTYPING

ON 

BY ED MAULDIN

SAGEIII

The integrated team works on the SAGE III instrument.
ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 29

SOMETHING NEW ON THE HORIZON 

THE SAGE III INSTRUMENT WAS A SPECTROMETER

designed to point at the sun during sunrise/sunset

and at the moon during moonrise/moonset in order

to unravel the vertical distribution of ozone and

aerosols in the stratosphere.

At the time when we were working on this

project, which was in 1992, the Clinton-Gore

administration had just taken office, and the Soviet

Union had just broken up. Russian Prime Minister

Victor Chernomyrdin and Vice President Al Gore

formed a commission to draw the two former

enemies closer together. They were looking for

potential joint ventures between the two countries.

The SAGE-III was in a marketing campaign looking

for a ride on a NASA spacecraft when we were told

WHAT IS PROTOTYPING?

PROTOTYPING IS PROBABLY THE OLDEST METHOD OF DESIGN. IT IS TYPICALLY 

DEFINED AS THE USE OF A PHYSICAL MODEL OF A DESIGN, AS DIFFERENTIATED 

FROM AN ANALYTICAL OR GRAPHIC MODEL. IT IS USED TO TEST PHYSICALLY THE

ESSENTIAL ASPECTS OF A DESIGN BEFORE CLOSING THE DESIGN PROCESS 

(E.G., COMPLETION AND RELEASE OF DRAWINGS, BEGINNING RELIABILITY TESTING, ETC.).

PROTOTYPES MAY VARY FROM STATIC “MOCKUPS” OF TAPE, CARDBOARD, AND

STYROFOAM, WHICH OPTIMIZE PHYSICAL INTERFACES WITH OPERATORS OR OTHER

SYSTEMS, TO ACTUAL FUNCTIONING MACHINES OR ELECTRONIC DEVICES. THEY MAY 

BE FULL OR SUB-SCALE, DEPENDING ON THE PARTICULAR ELEMENT BEING EVALUATED. 

IN ALL CASES, PROTOT

EASE OF CHANGE.

YPES ARE CHARACTERIZED BY LOW INVESTMENT IN TOOLING AND

A physical model can enhance

communication between designers

of different backgrounds and

native languages, and between

designers, builders, and users, 

who may not share common

terminology. Involving all these

stakeholders early in the project

can build on their collective

knowledge, minimizing errors, 

and enhancing the ability to react

to problems later.

SAGE III above earth’s atmosphere.
that we had been selected to be one of the eight initial

ventures in the Gore-Chernomyrdin Commission (GCC).

This raised the visibility of our project at the

Langley Research Center to the highest level. We would

report directly to the Vice President twice a year, and our

Center director wanted zero chance of failure on this

program. And while these were certainly benefits to our

project, our new focus and Russian partners were going

to change it considerably. Once the project became part

of the GCC, we had to make major adjustments. We

were going to have to adapt our instrument to the infrastructure of a Russian Meteor spacecraft and Russian

Flight Control Center. We decided to use rapid prototyping to integrate the changes.

FACING UP TO INTERFACES

In many cases, aspects of Russian spacecraft control

panels were opposite of those in American spacecraft.

For example, the Russian electronics were positivegrounded and ours negative-grounded. Interfaces that

get very little attention between American instruments

and American spacecraft became major issues in the

Russian spacecraft. There’s nothing as frustrating as

knowing your triple-redundant system needs to attach

three wires to their dual-redundant two.

We spent an entire year designing and testing

special bolts for attaching our instrument to the spacecraft. We built and tested prototypes for each difference

in our systems. In each case, problems were discovered

during prototype testing, and the solutions that were

applied to the flight hardware as we struggled to make

the prototype work resulted in our saving a considerable

amount of money and time.

Along with the Russians, we built interface simulators that were exact copies of the flight interface designs,

and these simulators went through a rigorous test

program. Many of the original designs didn’t work, and

they had to be redesigned, rebuilt, and retested.

DESIGNING A NEW GENERATION

SAGE III was a fourth generation instrument, and many

of the subsystems were radical departures from those of

previous generations. The “new” designs turned into a

huge problem for us. We were very concerned about

certain systems, so we purchased parts early in the life of

the project to make sure they would meet our needs.

Some didn’t. In one particular instance we had a part

delivered five times incorrectly, and we didn’t have the

time or budget to go for a sixth delivery. We relied on

prototyping to test a series of hardware and software

repairs for the system.

The older designs were huge problems in some

cases as well. Parts no longer existed. Processes no

longer existed. People that knew how to assemble the

instrument or manufacture the instrument had retired.

One of our biggest challenges had to do with an older

design for a flex-cable on the flight instrument. The

problem had been solved four separate times—each time

a new generation of the instrument was built. Even

though we had the flight drawings, all of the manufacturing procedures, and everything in front of us, we

could not reproduce that flex-cable. We had to essentially start from scratch each time because the processes

were different and the people were different.

We used rapid prototyping to solve the issues with

the flex-cable. This taught us a valuable lesson: very

early in the system design process, you should identify

the older subsystem designs that will be hard to

reproduce and submit these to rapid prototyping.

Designing by feedback may require

several cycles of incremental

design and implementation. 

Often, in order to do it quickly 

and correctly, one must be willing

to do it wrong first.

The sooner one finds errors of

design, the less costly the impact

to the project. The real-world

problems of ultimate acceptability

can be tested and verified quickly

by prototyping, before an extensive

commitment of resources.

30 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

Russian spacecraft 3M in orbit with

the SAGE III instrument on board.
ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 31

SAGE III instrument.
32 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

TAPPING RESOURCES

You can use prototyping simply for troubleshooting, but

I think there is an even better reason to employ this

practice. By prototyping, you’re actually getting to use

some of the most talented people on your team, which

are your machinists and your technicians. A machinist

can be a wonderful help in a design. When you sit down

with your machinist with a sketch of a prototype and say,

“This is what I want to do,” he can say, “Well, we really

should use this material instead of that material.”

The same goes with your technicians. They can 

say, “You know, you really should have a port here for an

alignment....You know, you need a hole here....

You need a removable bracket here.” You don’t get that

if you go straight to flight hardware. You’re not using

these people’s minds; you’re only using their hands.

When you take a flight drawing to a machinist, he gets

no say. If you have a piece of aluminum with a hole in it

bigger than the aluminum itself, he will deliver you an

envelope full of metal shavings. That has happened to

me in the past.

MODEL CITIZENS

On this project, and really on all my projects, prototyping was standard procedure. SAGE-III launched

successfully on December 10, 2001. Less than a month

later, NASA lost communication with the spacecraft

when the main transmitter went out and the Russian

GPS receiver didn’t work.

This is when all our joint repairs with the Russians

really paid off. Because of our intensive work together

during the prototyping phase, we had developed 

into a high-performance, unified, international team.

This close situation led each side to have an excellent

understanding of the other side’s half of the interface.

And in turn, this understanding led to quick, joint

solutions to extremely difficult problems. In the end,

together we were able to overcome the transmitter

failure. This got SAGE III operating and sending its

invaluable stratospheric data back to earth. And this

data is the key to understanding ozone destruction in

the stratosphere. •

ED MAULDIN retired in 2003

after 42 years of service at

NASA Headquarters and NASA

centers Ames and Langley, where he served

as Project Manager, Optical Engineer, and

Systems Engineer. Mauldin remains actively

involved with APPL, and is currently

teaching project management and risk

management courses to NASA employees.

“INTERFACES THAT GET VERY LITTLE ATTENTION BETWEEN AMERICAN INSTRUMENTS 

AND AMERICAN SPACECRAFT BECAME MAJOR ISSUES IN THE RUSSIAN SPACECRAFT. 

THERE’S NOTHING AS FRUSTRATING AS KNOWING YOUR TRIPLE-REDUNDANT SYSTEM

NEEDS TO ATTACH THREE WIRES TO THEIR DUAL-REDUNDANT TWO.”
ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 33

INTERVIEW

DENNIS 

MCCARTHY

WORLD-RENOWNED ASTROPHYSICIST

STEPHEN HAWKING CALLED THE

COSMIC BACKGROUND EXPLORER (COBE)

“THE DISCOVERY OF THE CENTURY, IF NOT

OF ALL TIME.” DEPUTY PROJECT MANAGER

DENNIS MCCARTHY, TOGETHER WITH NOWDECEASED PROJECT MANAGER ROGER

MATTSON AND THEIR TEAM, DESIGNED AND

BUILT COBE AS AN IN-HOUSE PROGRAM AT

GODDARD SPACE FLIGHT CENTER. THE

SATELLITE WAS BUILT TO GATHER EVIDENCE

OF THE BIG BANG, A THEORY WHICH STATES

THAT THE UNIVERSE WAS CREATED DURING

A GIANT EXPLOSION, LEAVING BEHIND

RADIATION AND SMALL TEMPERATURE

DIFFERENCES THAT CONTRIBUTED TO THE

FORMATION OF THE STARS, GALAXIES, AND

PLANETS. COBE WAS LAUNCHED IN 1989

FROM VANDENBURG AIR FORCE BASE IN

LOMPOC, CALIFORNIA, AND COLLECTED

FOUR YEARS WORTH OF DATA CONFIRMING

THE SCIENTIFIC PREDICTIONS ABOUT THE

THEORY OF THE PRIMORDIAL EXPLOSION.
DENNIS MCCARTHY WAS THE DEPUTY PROJECT MANAGER

for the COsmic Background Explorer (COBE) at

Goddard from 1983-1989. He stayed at Goddard in 1990

as the Associate Director for the Space Sciences

Directorate, moving in 1991 to Headquarters to be the

Program Manager for the Hubble Space Telescope

(HST). He followed the project back to Goddard in 1992,

where he was the Deputy Project Manager for the HST

Servicing Mission, and later Deputy Associate Director

of Flight Projects. After his various positions on HST,

McCarthy was Program Director for the Far Ultraviolet

Spectroscopic Explorer (FUSE), Johns Hopkins

University’s first Principal Investigator (PI) program.

Since 2000, McCarthy has been the Vice President and

Director of Engineering Services at Swales Aerospace,

where he is responsible for all engineering discipline

support to NASA, universities, and industry.

Altogether you spent close to 30 years of your career at

Goddard. Developing a satellite like COBE, which has

made enormous scientific contributions, must’ve been a

huge accomplishment for both you and the center.

It was.We were involved in Nobel-type science. COBE was

an in-house program where they were developing the best

they could develop. That has its upside and its downside.

The upside can obviously be seen in the success of COBE.

Can you talk about the downside in this type of project?

Let me explain it this way: there’s an analogy I use when

I give talks about these programs. I think of them as

essentially having three “pieces”—a spacecraft, the

instruments, and the ground system. When all three are

new designs, it just iterates, and iterates. Now combine

that with the fact that it’s an in-house program, and it’s

difficult to stick to a schedule. The reason is that inhouse programs are always looking for the “ideal” design.

In my experience, it’s an in-house mantra: develop

the best, because our projects are one-of-a-kind, and we

only do them once. It has to be the best we can possibly

do, and our hardware has to have all brand new designs.

When you get into this kind of thing, you can hardly

ever complete the project. Then the management team

gets criticized, because it can’t get done.

This is different from your experiences on other programs?

It was much different when I went to Johns Hopkins

University to manage the Far Ultraviolet Spectroscopic

Explorer (FUSE) in the late ’90s. The spacecraft and the

ground station were bought off-the-shelf. Both were

34 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW CONTINUED

“In my experience, it’s an 

in-house mantra: develop

the best, because our

projects are one-of-a-kind,

and we only do them

once. It has to be the 

best we can possibly do.”

Artist rendering of the COsmic Background Explorer (COBE).
fixed-price contracts. The only thing that was iterated Is this a problem particular to your project and center, or

was the instrument. When you only iterate one “piece” do you think that project managers always have to fight

and the other two are fixed, you can get it done much for control of their respective projects?

quicker and at cost. It happens in other places as well. I sat on a review

board for Mars Pathfinder and Project Manager Tony

Since COBE was in-house, how did you keep the team Spear. He had formed a Skunk Works on his project,

from continuing to search for that “ideal” design? and I’m thinking, “This looks familiar.” He was trying to

When we redesigned COBE for a Delta ELV after the control the Jet Propulsion Laboratory (JPL).

Shuttle Challenger accident, we froze the spacecraft I met with him privately before the review. I said,

design. We selected the ground system and said, “We’re “Tony, what can I do to help you? I’m not just here to look

going to go with what we’ve got; no more changes.” It under rocks and find things you’re not doing, because you

made a difference. don’t have the time or money.” It was a surprise to him,

If we hadn’t done that, it could’ve gone on much because no one had ever asked him what he needed in a

longer. An in-house program is sometimes like a situation like that. He told me he needed control of the

sandbox where everyone gets to keep playing and people that work in a matrix organization at JPL.

experimenting. Many in-house people have the

attitude of “We want to build the best. It’ll be done And did you take action? 

when it’s done.” Those same people expected me to let Yes. I got up in front of the Deputy Administrator and all

them play, and then to periodically go to Headquarters of the Associate Administrators and said that I believed

to get more money to fund it. That’s wasn’t my job, but that Mars Pathfinder would work. I went out on a limb,

that’s their philosophy. but I supported it as an engineer. Then I said that there’s

one thing he needs, and that is control of the people in

the matrix organization at JPL. I said, “I strongly suggest

ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 35

COBE’s image of the infrared sky.
and recommend that he co-sign their performance.”

And the Associates agreed with me.

Would it have been possible for you to have tried a

technique like co-signing on COBE?

No, no. The in-house people would never give up

control of their people on the project. Some of them

thought we were just the source of funds for their

sandboxes. When that’s the case, it’s a terrible

environment in which to try to build flight programs on

schedule. That’s the way it was for me until the Shuttle

accident in 1986. Then we had priority at the Project

Office, and we were given the requirement to get it done

on time. We eventually got the center to do it our way,

but it annoyed a lot of people. A lot of people still wanted

to do it the old way.

How did you get around that?

In our case, it took a crisis like the Challenger explosion

to get more control. When the accident happened,

we couldn’t find a way to launch COBE. I was 

working hard to find another rocket, evaluating every

launch vehicle in the world from the Chinese to the

European Arianne. NASA Headquarters was naturally

embarrassed, because here was this premier science

satellite that we were going to build and launch from a

rocket in another country.

So they found a way to launch it domestically?

The Associate Administrator looked around and found

one Delta-1 rocket left, and it was old—the last one ever

built. They said we could use it.

And it was possible for COBE to launch on a 

smaller rocket?

Well, the satellite originally weighed close to 12,000

pounds. However, if it wasn’t launched on the Shuttle, it

wouldn’t need the 5,000-pound propulsion system. It

also wouldn’t need the 3,000-pound structure that held

it across the Shuttle’s cargo bay. So I figured we could

fold everything up like the MARS Rover and launch it at

about 5,000 pounds from a Delta.

NASA looked at the figures and agreed to launch it 

from the Delta?

They decided to do it. Noel Hinners, Goddard’s Center

Director, got behind us. He said, “This program will be the

centerpiece of Goddard for the next 3 years. It will have all

the priority needed.” That’s what got us really moving.

For those of us who used to work there in the

1960s, it made us remember a time when we used to just

do things. Back then we didn’t have so many processes,

procedures, and reviews. We just built things. We were

always saddened in the ’80s that the younger people had

no idea you could do things like that.

So, this was a great model for the younger

professionals to see that when the system focuses on a

specific goal and clears the barriers away, that you can

get it done. In our case, our barriers were cleared by an

unfortunate crisis. Without the attention the project got

from losing the Challenger, and without some pushing

on the system on my part to find another way to launch,

36 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

INTERVIEW CONTINUED

“For those of us who 

used to work there in 

the 1960s—it made us

remember a time when 

we used to just do things.

Back then we didn’t have

so many processes,

procedures, and reviews.

We just built things.”

Annual average maps created from information retrieved from the Diffuse

Infrared Background Experiment (DIRBE), one of COBE’s three instruments.
it would’ve died. COBE would have faded into the

woodwork, and everyone would’ve forgotten about us.

Was it always you and the Project Manager against the

system, or did your team back you?

They did, and it really didn’t take long. But it started out

with control. When we formed the Skunk Works, we

said, “We’re in complete control of this project; we’ll

decide when you get it done.” We met with everyone

each week in the war room. We just took over.

Then, after a year and a half of a 3-year Skunk

Works, the workers tend to take over. I worked half that

time trying to move just an inch forward every day. After

a while, they look up, and we’ve moved five feet. And the

workers want to finish the job; they get a look in their

eye. My goal then was to get out of their way—to give

them what they needed and let them go.

How did you get the workers who wanted to “develop new

technology” to shift their focus to meeting time and

money constraints?

We just showed them that we were in control of the

project. We said, “We’re not asking any more questions.

We are going to get this done.” It didn’t take long for the

workers to throw the switch. Once it clicks that this is

not going to be the run of the mill sandbox—where

we’re just going to develop new designs—they want to

get it done. It’s psychological.

What exactly was the Skunk Works strategy that set all

this in motion?

We co-located everyone in one building, all of the

engineers, and we put offices in. The core team was

about 3-dozen people. They were working for us for the

next two and a half years, which was hard since their

matrix home was somewhere else. But we said, “We’ll

send them back when we’re done.”

We had a big “war” room and met there each week

so there could be frequent and direct communication.

We put every schedule on the wall, with the name of a

different team member on each one. That schedule was

their responsibility. I told them, “That’s not my schedule

up there, that’s yours.”

If you empower people, then they feel responsible.

My philosophy was to delegate and empower people. To

me, that’s the job of the project manager: empowering

and removing obstacles.

This must’ve been an amazing opportunity for some of

the people you empowered.

They still talk about it. There is a street sign at Goddard

that says COBE Road. It was a huge project spanning

seven years. The fact that they did it after the Shuttle

accident, it was the first NASA science mission, and they

did it in Skunk Works...it’s really satisfying. They kept to

a schedule, they got empowered and took responsibility,

and they ultimately made the project a success. •

ASK 19 FOR PRACTITIONERS BY PRACTITIONERS 37

COBE’s view of the Milky Way Galaxy in infrared light.
FOR ALMOST TWENTY YEARS, THE MAIN THRUST OF MY principles and each of these, in turn, is linked to two

research has been to gain an understanding of the stories from ASK, in which the sub-principle is demonelements that make for successful project management. strated. By reviewing the principles and the stories

Since I wanted to develop a “theory of practice,” most of together, I believe the reader will gain a deeper appremy research was based on first-hand data. I started by ciation of the principles, as well as their application to

identifying the most competent project managers, inter- project management in a dynamic environment.

viewing them, observing them in action, and listening The following two-colored figures should help the

carefully to their stories. reader gain a better understanding of the principles. The

This has indeed been a long and arduous voyage, first, “Results-Focused Leadership—Essence of the

since it was not always smooth sailing. Several times I Principles,” that graphically and most succinctly describes

reached the painful conclusion that in order to make any each of the principles, should help the reader see them as a

progress, I would first have to unlearn long-held concepts. single entity. The second, “Results-Focused Leadership—

In the end came the satisfaction, as I was able to formulate The Human Metaphor,” shows how we, as human beings,

a set of principles that could deal head-on with the current resort to many different yet complementary resources in

dynamic environment of project management. our lives. It should help the reader to better understand the

Readers of ASK will recall that I shared three of these unique nature of each of the five principles, as well as their

unlearning experiences in my columns in ASK 12, 13 and mutual interdependence.

16. I also discussed several milestones in my research, as The colors were selected to reflect some of the

well as some of my findings in ASK 1, 4, 7 and 18. In this unique characteristics of the principles.

column, I present a brief summary of my findings which Green (vegetation and growth) for planning: suggests the

have been reduced to five major principles.* growing, learning-based and evolving nature of project planning

ASK is one of the primary products of the and control in a dynamic environment.

Knowledge Sharing Initiative (KSI) of the NASA Yellow (sunshine and optimism) for attitude: suggests the

Academy of Program and Project Leadership (APPL). spirited nature of the required “will to win” leadership.

KSI broke ground following the first Forum of Master Brown (earth) for results-oriented implementation: suggests the

Project Managers that was held in July 1999 in down-to-earth, practical, results-based focus.

Leesburg, VA. The keynote speaker in that Forum was Red (heart) for people and organization: suggests the softer

the NASA Administrator, Mr. Daniel Goldin. aspects of people and teams, in particular, feelings, emotions, and

Therefore, this summer KSI will be celebrating its warm and trusting relationships.

fifth birthday. I join in this celebration by presenting Gray (drab, fog) for communication: suggests the endless, ongoing,

my current understanding of the five principles of non-heroic and tedious efforts required for project communication.

project management in a dynamic environment, linked (It also represents the nebulous ambiguity resulting from continuous

to 30 stories which were published in previous issues irrelevant and unclear information—a problem that frequent,

of ASK. Each principle is supported by three sub- intensive, and rich communication may help resolve.)

Managing Projects in a Dynamic Environment:

Results-Focused Leadership

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

This summer, the Knowledge Sharing Initiative will be 

celebrating its fifth birthday

* My 1996 book, Simultaneous Management, fully addresses principles 1, 4 and 5, and only partially principles 2 and 3. The book I co-authored with Ed Hoffman in 2000, Project Management Success

Stories, goes further by addressing fully the third principle, but still addressed the second principle only partially. A later reexamination of the data presented in both books showed that ALL five principles are fully

substantiated by the data. Reexamining the findings was triggered primarily by my work with NASA’s project managers in 1999-2000 (in the early stages of the KSI). A more recent research composed 

of four case studies (two from NASA and two from the USAF), also support all five principles. These four case studies will be published soon in a book co-authored by A. Laufer, T. Post and E. Hoffman.

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

COMMUNICATION

PULL & PUSH

PLANNING & 

CONTROL

ACCOMMODATING

CHANGE

IMPLEMENTATION

RESULTS-ORIENTED

PEOPLE & 

ORGANIZATION

TRUST-BASED 

COOPERATION

ATTITUDE

A WILL TO WIN

FIGURE 1

Results-Focused Leadership: Essence of the Principles 

PLANNING & 

CONTROL

MIND

PEOPLE & 

ORGANIZATION

HEART

COMMUNICATION

CIRCULATORY &

NERVOUS SYSTEMS

IMPLEMENTATION

HANDS

ATTITUDE

SPIRIT

FIGURE 2

Results-Focused Leadership: The Human Metaphor 

Y 2004MA ©ALEXANDER LAUFER,

**Project context affects the manner in which a principle is implemented as well as the extent to which a principle must or can be implemented. For example, when organizational culture does not foster trustbased teamwork, you must rely more on formal work processes rather than informal ones. Or, when project environment is stable and task novelty low, there is less need to adopt an evolving, learning-based,

planning process, and it is more appropriate to employ the traditional planning process that freezes project objectives and scope early on.

THE FIVE PRINCIPLES OF MANAGING PROJECTS 

IN A DYNAMIC ENVIRONMENT

Consider these five principles as a single entity composed of five complementary and interconnected sets of activities, each balancing the other.

• Implementation of any one principle and its impact on project success depends on the

implementation of all the others. To compensate for inability to fully adhere to a principle, be

prepared to modify the implementation of the others as well as adjust project expectations.

• Embrace and apply these principles as general guidelines that must be tailored 

to each unique context of the project (e.g., stability of objectives, speed, task’s complexity,

organizational culture, top management support, team members’ experience and skills).**
40 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP

PLANNING & CONTROL ATTITUDE 

1. Plan and Control to Accommodate Change 3. Develop a Will to Win 

1.1. Adopt a learning-based planning mind-set: start 3.1. Develop a sense of a mission and “own” the

by defining project objectives that are dictated by project. (When needed, engage in politics and

customer’s needs, however, don’t finalize them work hard to sell your project).

before you quickly explore the means and the Know Thyself—But Don’t Forget to Learn About the Customer Too, ASK 5;

Stumping for the Project, ASK 12 solutions.

Lessons from the Great Masters, ASK 3; The One Thing You Need to Know, ASK 6 3.2. When necessary, challenge the status quo and be

1.2. Start planning early and employ an evolving willing to take calculated risks.

planning and control process: continuously and Listening to the Voice Inside, ASK 2; What GOES Around, Comes Around, ASK 16

throughout project life collect feedback on 3.3. Persevere; keep trying until you get it right. Yet,

changes in the environment and in planning know when it is time to change course or retreat.

assumptions, and on project performance. Marbles for the Imagination, ASK 16; The Don Quixote Complex, ASK 5 

Check Your Ego At the Door, Please, ASK 4; Implementation Reviews, ASK 12 

1.3. Use an appropriate amount of redundancy to PEOPLE & ORGANIZATION 

contain the impact of uncertainty and enhance 4. Collaborate through Interdependence and Trust 

the stability of the plan: add reserves; loosen the 4.1. Take recruiting very seriously and spend as much

connections between uncertain tasks; prepare energy as possible on getting the right people.

contingency plans for extremely uncertain and The Idyllic Workplace, ASK 7; Start-Up, ASK 11

crucial tasks. 4.2. Develop trust-based teamwork and make sure

A Good Man is Hard to Find, ASK 15; Checkmate to Uncertainty, ASK 17 that team members feel dependent upon each

other and share the conviction that they are

IMPLEMENTATION mutually responsible for project results.

2. Create a Results-Oriented Focus Chaos is the Fraternal Twin of Creativity, ASK 3; Earthly Considerations on Mars,

ASK 12 2.1. Create and maintain a focus; decide what NOT to do.

How to Say No, ASK 1; Enough Is Enough, ASK 14 4.3. Throughout project life, assess team functioning,

2.2. Right from the beginning and throughout, focus ensure its alignment on project objectives, and

on results—both long-term and short-term. In renew its energy.

particular, prepare tangible intermediate products Keeping the Deal, ASK 7; The Journey Back, ASK 16 

(e.g., prototypes) that provide you rich and quick

feedback and that the customer can easily under- COMMUNICATION

stand and assess. 5. Pull and Push Information Intensively

Dropping in on Mars, ASK 13; Proof of Concept, ASK 13 5.1. Frequently and vigorously pull and push (ask for

2.3. Develop a pragmatic mode of operation: invest in and provide) information within and across

planning yet be ready to respond swiftly to functions and teams, including all project stakefrequent, unanticipated events; identify areas holders.

where the search for optimal solutions is worth- Open Newsletters, ASK 6; What Has He Done For Me Lately?, ASK 9 

while, but for the rest of the project, be ready to 5.2. Employ multiple communication mediums; in

embrace “good enough” solutions; for repetitive particular, extensive frequent face-to-face commuactivities or critical areas (i.e., safety), employ nication and modern information technology.

formal/standard work processes, otherwise, The Join-Up Meeting, ASK 7; Say What You Mean, ASK 16 

employ those that are informal or ad hoc. 5.3. Adopt a moving about mode of communication.

Simplify and Succeed, ASK 9; Thanksgiving Hocus Pocus, ASK 10 (Moving about helps you affect project performance by better understanding what is going on

and by influencing people’s behavior in a timely,

natural, and subtle way.) 

A Gentle Touch, ASK 9; Walking a Fine Line, ASK 17 •

LETTER FROM THE EDITOR-IN-CHIEF

NP-2004-09-370-HQ