Academy Sharing Knowledge

The NASA Source for Project Management and Engineering Excellence | APPEL S U M M E R | 2 0 0 7

National Aeronautics and Space Administration

Inside

LIVING WITH THE CONTRACTOR

GLENN’S SPACE MISSION EXCELLENCE PROGRAM

THOMAS DAVENPORT ON DEMOCRATIZING KNOWLEDGE
O N T H E C O V ER

A thermal vacuum test is conducted on Deep Impact instruments in the instrument 

assembly area in the Fisher Assembly building clean room at Ball Aerospace in Boulder, 

Colo. The high-resolution instrument (at right) is one of the largest space-based 

instruments built specifically for planetary science. It is the main science camera for 

Deep Impact, providing the highest-resolution images via a combined visible camera, 

an infrared spectrometer, and a special imaging module. Photo Credit: Kennedy Space Center
18 13

DEPARTMENTS

3

In This Issue 

4 

From the APPEL Director

60

Knowledge in Brief

61

ASK Bookshelf

62

The Knowledge Notebook

64 

ASK Interactive

INSIGHTS

9 

Space Mission Excellence Program: 

Launching Systems Engineers at Glenn 

BY KERRY ELLIS A mock preliminary design 

review helps program participants develop 

systems engineering skills.

13 

CompanyCommand: A Professional 

Community That Works 

BY DR. NANCY M. DIXON This online 

community thrives thanks to its critical value 

and a core team that actively encourages 

and acknowledges participation.

23 

Democratizing Knowledge at NASA 

and Elsewhere 

BY THOMAS H. DAVENPORT Do blogs, wikis, 

and other democratic knowledge tools have 

a role to play in NASA decision making?

27 

Interview with Bob Seamans

BY DON COHEN The former NASA deputy 

administrator refl ects on the importance of 

in-house expertise, the Apollo 1 fi re, and 

how leaders learn what’s happening in their 

organizations.

38 

Sustaining NASA’s Safety Culture Shift 

BY DAVID G. ROGERS Openness to learning 

from experience is the key to safety 

improvement.

45 

Creating the Future 

BY JOHN McCREIGHT Achieving ambitious 

goals depends on both clarity and 

commitment.

53 

Viewpoint: Lunar Opportunities 

BY PAUL D. SPUDIS A leading planetary 

scientist says returning to the moon will 

help develop knowledge and technology 

essential to future space exploration.

STORIES

5 

Working with Nuts Running Loose 

BY LEE GRAHAM Flexibility and communication 

made this collaboration between NASA and 

the Naval Research Lab successful.

18 

Living with the Contractor 

BY EDWARD INGRAHAM Being there is the 

only sure way to understand and infl uence 

a contractor’s work.

33 

Making a Deep Impact on Science 

BY RICK GRAMMIER Deep Impact’s 

successful rendezvous with a comet was 

the payoff for persistent efforts to maintain 

understanding between project teams.

42 

Featured Invention: Future Air Traffi c 

Management Concepts Evaluation Tool 

BY JOHANNA SCHULTZ Discussions with 

controllers, dispatchers, and pilots helped 

Ames researchers build an innovative air 

traffi c tool.

49 

Crossing Boundaries to Build Change 

BY ADRIAN WOLFBERG AND JOHN T. O’CONNOR 

A program at the Defense Intelligence Agency 

seeks ideas that bridge gaps between parts 

of the organization.

56 

Searching for Life on Mars; Managing 

a Diffi cult Project on Earth 

BY MATTHEW KOHUT To get an important 

scientifi c instrument ready in time for launch, 

Viking managers shifted from inattention to 

“over-attention.”

Contents

23

ASK MAGAZINE | 1
The Academy of Program/Project and Engineering Leadership (APPEL) and 

ASK Magazine help NASA managers and project teams accomplish today’s missions 

and meet tomorrow’s challenges by sponsoring knowledge-sharing events and 

publications, providing performance enhancement services and tools, supporting 

career development programs, and creating opportunities for project management 

and engineering collaboration with universities, professional associations, industry 

partners, and other government agencies.

ASK Magazine grew out of the previous academy, the Academy of Program/Project 

Leadership, and its Knowledge Sharing Initiative, designed for program/project 

managers to share best practices and lessons learned with fellow practitioners across 

the Agency. Reflecting APPEL’s new responsibility for engineering development 

and the challenges of NASA’s new mission, ASK includes articles that explore 

engineering achievements as well as insight into broader issues of organizational 

knowledge, learning, and collaboration. We at APPEL Knowledge Sharing believe 

that stories recounting the real-life experiences of practitioners communicate 

important practical wisdom. By telling their stories, NASA managers, scientists, and 

engineers share valuable experience-based knowledge and foster a community of 

reflective practitioners. The stories that appear in ASK are written by the “best of 

the best” project managers and engineers, primarily from NASA, but also from other 

government agencies, academia, and industry. Who better than a project manager or 

engineer to help a colleague address a critical issue on a project? Big projects, small 

projects—they’re all here in ASK.

You can help ASK provide the stories you need and want by letting our editors know 

what you think about what you read here and by sharing your own stories. To submit 

stories or ask questions about editorial policy, contact Don Cohen, Managing Editor, 

doncohen@rcn.com, 781-860-5270.

For inquiries about APPEL Knowledge Sharing programs and products, please contact 

the Knowledge Sharing Project Manager, Rosie Robinson, ASRC Management Services, 

6303 Ivy Lane, Suite 130, Greenbelt, MD 20770; rosie.robinson@asrcms.com; 

301-837-9067. 

To subscribe to ASK, please send your full name and preferred mailing address 

(including mail stop, if applicable) to ASKmagazine@asrcms.com.

Staff

APPEL DIRECTOR AND PUBLISHER

Dr. Edward Hoffman

ehoffman@nasa.gov

EDITOR-IN-CHIEF

Laurence Prusak

lprusak@msn.com

MANAGING EDITOR

Don Cohen

doncohen@rcn.com

TECHNICAL EDITOR

Kerry Ellis

kerry.ellis@asrcms.com

KNOWLEDGE SHARING MANAGER

Rosie Robinson

rosie.robinson@asrcms.com

KNOWLEDGE SHARING ANALYSTS

Ben Bruneau

ben.bruneau@asrcms.com

Johanna Schultz

johanna.schultz@asrcms.com

Katherine Thomas

katherine.thomas@asrcms.com

APPEL PROGRAM MANAGER

Jon Boyle

jon.boyle@asrcms.com

DESIGN

Hirshorn Zuckerman 

Design Group, Inc.

www.hzdg.com

SENIOR PRINTING SPECIALIST

Jeffrey McLean

jmclean@hq.nasa.gov

PRINTING

GraphTec

Issue No. 27
The articles in this issue of ASK touch on themes already 

familiar to regular readers of the magazine. Learning from 

hands-on experience is one. David Rogers’ “Sustaining 

NASA’s Safety Culture Shift,” Bob Seamans’ reflections on 

NASA in the sixties, Edward Ingraham’s “Living with the 

Contractor,” and Kerry Ellis’ report on systems engineering 

education at Glenn Research Center all attest to the unique 

educational value of experience.

Another theme is the power of stories—the subject of Ed 

Hoffman’s “From the APPEL Director.” Good stories give 

us the feel and flavor of other people’s experience; they are 

the next best thing to being there. And, as Ed writes, the 

stories we tell and hear help shape experience, tilting our 

efforts toward success or failure.

The overarching theme of the articles (and, of course, 

the whole purpose of ASK) is communication. Continual, 

effective communication is the essential foundation of 

cooperative work on complex projects. John McCreight’s 

“Creating the Future” puts communication at the center of 

successful organizational change. In “CompanyCommand,” 

Nancy Dixon details the thoughtfulness and attention 

needed to support effective online communication. Rick 

Grammier’s “Making a Deep Impact on Science” tells a 

story of careful, extensive communication overcoming the 

culture clash between two project groups.

Communication means listening as well as talking, which 

brings me to another important theme: openness to learning 

and change. As David Rogers suggests, experience provides 

opportunities for learning, but you can’t learn unless you 

reflect on experience with an open mind and a willingness to 

change. Lee Graham’s description of working with the Naval 

Research Lab shows that kind of flexibility in the process 

of understanding and accommodating an organization that 

works in a different way. The capabilities of the air traffic 

modeling and prediction tool described in this issue’s featured 

invention were developed because the inventors listened to 

the controllers, dispatchers, and pilots and modified their 

original concept to address the needs of those potential 

users. Listening underlies the value of the knowledge 

democratization tools Thomas Davenport describes (if 

people in power don’t listen, what’s the point of talking?); it 

contributes to the trust that Larry Prusak talks about in “The 

Knowledge Notebook” and encourages the innovations and 

connections discussed in “Crossing Boundaries.”

Learning depends on a willingness to confront your 

own weaknesses. That willingness is an essential part of 

the open-minded listening and reflection that lead to better 

ways of working. Without what one writer calls “higher 

modesty”—the belief that you might be wrong, no matter 

how smart you are—improvement is impossible.

Don Cohen

Managing Editor

In This Issue

ASK MAGAZINE | 3
What is your story?

That question can be taken in many directions. 

It can express powerful interest or doubt. In Brooklyn, 

where I grew up, people said, “So, what’s your story?” 

to make someone reflect on and change foolish 

behavior. But the same question can be a request for 

insight and inspiration from a life’s journey.

Telling the right story is an essential requirement 

for any person, project, or organization that hopes 

to succeed in a complex world. Individuals and 

projects thrive or fail because of stories, and the 

stories we ignore are just as powerful as the ones we 

tell. We proceed at our peril if we leave the stories 

of our mission to chance.

Stories change people and projects. Several 

years ago, teaching a course on leadership, I 

required students to share two stories that reflected 

leadership challenges they successfully encountered. 

I wanted to force honest learning based on reallife experiences. One student seemed particularly 

distant and cold toward the class. I developed my 

own internal story of him as a skeptic and resistant 

to this type of learning.

When the first stories were submitted, that 

student’s vignette of the impact of racism stirred 

me to my core. Believing the military was a place 

where he would not encounter discrimination, he 

started his army career filled with anticipation. He 

was emotionally broken when an officer’s racist 

label went unchallenged. In the twenty-five years 

since then, he had never described the incident, but 

he told the class that he felt compelled to tell it now. 

He was a different person after telling the story: 

engaged, alive, smiling. At the end of the class, he 

said he never realized the weight he carried until 

telling the story helped him let it go.

Every project or organization has a story 

that can promote or retard the effort. When the 

Apollo 13 movie came out, the International Space 

Station and the Supercollider were in a life-anddeath struggle to survive political scrutiny. The 

Supercollider was canceled while the International 

Space Station survived by one vote. A commonly 

held view at the time was that NASA benefited 

from the film that powerfully conveyed a story of 

struggle, passion, and purpose. 

Projects are modern-day quests that can tell 

tales of challenge, complexity, and meaning. They 

are purposeful journeys that involve personal 

commitment to overcome challenges that are sure 

to arise. Successful project leaders skillfully shape 

stories that communicate the value of the goal and 

the importance of collaborative effort. The stories 

can include challenges represented by milestones 

and feature everyday heroes who make sacrifices 

for the good of the mission.

Everyone lives a story and every project has a 

story, which unfolds whether or not conscious effort is 

made to shape it. A dysfunctional team tells a story of 

poor communication, distrust, ineffective leadership, 

and competition. A successful team benefits from a 

story of purpose, collaboration, trust, and focus.

Effective leaders communicate stories in ways 

that connect with people and create energy and 

support. Crafting and communicating your project 

story is a vital skill. The story must include a clear 

sense of purpose and value. It paints an honest 

picture of challenges and risks and provides action 

plans showing the path the journey should take. It 

values the team’s everyday heroes and what they 

learn from the trials and tribulations of the journey 

to project success. ●

From the APPEL Director

The Power of Stories

BY ED HOFFMAN 

4 | ASK MAGAZINE
WORKING 

WITH NUTS 

RUNNING 

LOOSE

BY LEE GRAHAM 

As I walked though the gates at 

the Naval Research Laboratory 

(NRL) for the first time, I couldn’t 

help but smile to myself. Six years 

previously, while doing a tour at 

the Office of Spaceflight at NASA 

Headquarters, I had driven by 

NRL many times and had often 

thought, “That sounds like an 

interesting place to work.” Little 

had I realized then that, as a deputy 

project manager for NASA, I would 

get a chance to be the senior NASA 

manager on site.

Photo Credit: Marshall Space Flight Center/Jose Matienzo

The final integrated vehicle is tested in the anechoic chambers at the Naval Air Station–Pauxtent River. 

STORY | ASK MAGAZINE | 5
SPELLING OUT THOSE EXPECTATIONS IN A WRITTEN AGREEMENT WOULD HAVE AVOIDED 

MANY OF THE REQUIREMENTS, DESIGN, AND INTEGRATION ISSUES WE WERE TO SEE IN 

THE FOLLOWING TWO YEARS.

With the Russians in the assembly critical path, the International 

Space Station (ISS) program had decided earlier that it needed 

to develop an “insurance policy“ to protect vehicle development. 

The program reviewed many options and settled on the solution 

of slightly modifying an existing NRL flight system. The project 

became the development and delivery of the vehicle to provide 

low-cost propulsion for the space station and was to be called 

the Interim Control Module (ICM). Budget and schedule were 

predicated on existing NRL processes, minimizing the use of 

NASA processes and, most important of all, not imposing new 

and unique system requirements to “human rate” the vehicle. It 

was to be “used as is.” None of this was formally documented; 

it was mentioned by some senior NASA officials while visiting 

NRL, with a few other NASA personnel in attendance. This 

lack of formal definition would cause many of the management 

and design problems the project was to face. Spelling out those 

expectations in a written agreement would have avoided many 

of the requirements, design, and integration issues we were to 

see in the following two years. Or at least it would have given 

us ammunition to defend our position and start the discussions. 

It’s a lesson I’ll never forget.

I joined the project prior to the preliminary design review, 

and I had an overall understanding of the requirements the 

vehicle needed to meet. Armed with this knowledge, I met the 

NRL program manager, Al Jacoby; his deputy, Bob Towsley; 

and the entire NRL team within an hour of coming through 

the gate. As I talked to them about how they were organized 

and how they operated, a number of points became obvious 

to me:

• They were a confident and technically competent 

organization. 

• They were a “skunk works”-type organization—very flat 

with a lot of delegated responsibility.

• Man, this is going to be fun. (Not, how do we integrate this 

fast-moving, rapid-prototyping, minimum documentation 

approach with the document- and process-heavy bureaucratic 

approach of the ISS program?)

• The use-as-is approach, using NRL processes, was probably 

overly optimistic, but it was a good starting position. 

• The program-provided requirements were not very 

detailed and would require some evolution later.

As the project matured over the following several years, the 

requirements and the resulting design changed and evolved. And 

changed, and changed. Our budget and schedule never really 

stabilized. We eventually completed the vehicle—just in time 

for the program to mothball it, since the Russians did fulfill 

their commitments. We also ended up addressing virtually all 

the points I had seen at the beginning.

Our NRL teammates were also civil servants, so they 

wanted to be treated as partners, not contractors. I learned that 

they, and only they, could call themselves the “Nuts Running 

Loose.” In addition, while NRL was very competent, it quickly 

earned a reputation with us as an overly confident, even at 

times cocky, workforce. (Sounds similar to us.) The phrase 

I most often heard from NASA folks was “but we have lives 

at stake in our missions, they don’t.” When I got to know the 

NRL people personally and learned about their integrity and 

some of their flight history, I discovered that they often had 

literally tens of thousands of lives depending on their missions. 

So their confidence began to be understandable. This joint 

understanding of motivations was the start of mutual respect 

that began the true team-building we needed. But in getting 

there, I spent a lot of time soothing troubled waters and getting 

folks on both sides to understand the other’s viewpoint.

One day I received a call about a heated exchange between 

our NASA civil servant quality assurance representative and one 

of the outstanding NRL technicians. I called all members of 

the on-site NASA office together to get the details and to calm 

everybody down. I reminded our folks that the technicians in 

this particular area were very close to completing their tasks 

and, since there was no other immediate work in sight, were 

probably going to be laid off in the near future. It was therefore 

understandable that the technician in question would be on 

edge; we needed to be sensitive to that and act accordingly. The 

folks involved in the argument apologized to each other later 

that day, and we got on with the job (and the NRL technician 

was picked up by another in-house project and kept working).

On another occasion I was called and told we had a 

“problem” with some of our NASA-provided governmentfurnished equipment. I found that a small air conditioner had 

malfunctioned and dumped some condensate water onto our 

EVA handholds. It turned out not to be a major problem. We 

were able to fix the air conditioner so it wouldn’t happen again, 

6 | ASK MAGAZINE
log the incident, dry the hardware, and press on. But as I walked 

out into our “high bay” area, and with this increased sensitivity 

to water damage, I noticed our powered-up flight avionics and 

power decks sitting in the open, right next to our only set of 

government support equipment that we would have to use in 

pre-launch and day-of-launch processing. When I pointed out 

the potential of a water leak destroying this hardware, Al Jacoby 

reminded me that we were in a large building inside a larger 

building. It was literally a separate building with about six feet 

of separation between the roofs. He also mentioned that the 

odds of any leak finding our hardware in the nearly 100,000 

square feet of production space were unbelievably remote. 

I still felt uncomfortable and wasn’t willing to let it go. So 

Al got an estimate for protective covering. The cost–benefit 

trade-off was a no-brainer for me, so we installed it. Some of the 

NRL engineers good-naturedly joked to me about “Lee’s Folly.” 

Fast-forward a couple of months: a hurricane came up the East 

Coast and hit the Washington, D.C., area with 60 mph winds 

that tore off a ventilation cover. Rain poured in. The area of 

the inner roof right on the edge of one of the protective covers 

turned out to have a hole in it. Sober expressions replaced the 

laughter. In addition, people started to ask questions about 

what other protection could be put in place. I saw covers appear 

around non-NASA flight projects near us. They had never had 

anything like this happen before, and they probably won’t again, 

but they learned to trust our opinions. 

On yet another occasion, during automated acceptance testing 

of one of our flight star trackers, we had an unexpected reset of 

the instrument. No analysis of the test data nor examination and 

additional testing of the flight hardware itself gave us any clues 

about the cause. We assembled a group of outstanding engineers 

from Marshall Space Flight Center, along with NRL ICM Chief 

Engineer George Flach and myself, and set off for the vendor. We 

spent two difficult days going over all the manufacturing and test 

records trying to find the cause. We eventually settled on a “most 

probable” cause that fit all the circumstances, since we couldn’t 

find definitive data. We unanimously agreed to make the unit 

our spare and only fly it when absolutely necessary. Even more 

importantly, the in-depth technical discussions increased both 

groups’ respect for the other’s technical abilities.

I was shocked at how fast NRL could make changes to the 

flight hardware and software. We could discuss a change in 

the morning, make a decision, and have the new drawings and 

procurements out by that afternoon. Because of this, it became 

obvious that the NASA folks needed to be tied in tightly with 

their NRL counterparts to stay aware of what was happening, and 

why, and to concur with the changes. Constant contact quickly 

became our standard way of doing business and helped keep the 

project on track. I, and many others, spent a lot of time on the 

phone making sure we stayed coordinated across disciplines.

Getting this fast-moving, bare-bones-approach project 

integrated into the program was a lot more difficult, however. 

We ended up creating new documents and products that the 

program absolutely needed but we hadn’t planned on. We also 

ended up killing some documents that the program team felt were 

initially needed, but only after a lot of face-to-face meetings and 

teleconferences. They were often deleted because the program 

people didn’t understand the functionality or interfaces of the 

ICM to ISS, and the documents they wanted didn’t make sense.

Just as important to me was how we worked with our 

NASA counterparts across the Agency. We were moving so fast 

that a delay of a few days, while people went off to study minor 

issues, would be devastating to the project. So I sat down and 

The ICM is inspected at the Naval Research Lab to ensure the adapter support 

posts are level with each other.

Photo Credit: Marshall Space Flight Center/Jose Matienzo

ASK MAGAZINE | 7
developed a set of parameters that would allow us to make some 

changes and corrections without having to ask permission. 

For Material Review Board dispositions, I developed a list 

of delegated authority criteria. The agreed-to approval authority 

would not require additional off-site NASA approval or review if

• The change didn’t affect the required performance of the item. 

• No new or re-do of any analyses of any kind were required. 

• There was no impact to any ISS interface(s).

• There was no impact to any NASA-provided hardware 

interface(s).

• There was no effect on the form, fit, or function of the item.

As you would guess, a certain level of trust had to exist 

between NASA and NRL, and even between the NASA on-site 

folks and other NASA personnel, to allow this to work. This trust 

was absolutely critical to avoid stop-work conditions on the shop 

floor. Just as critical was a desire to make the project a success. We 

did eventually reach an acceptable level of trust and commitment. 

On one occasion, we were scheduled to lift some major structural 

components for final positioning when NRL discovered their 

lifting equipment needed recertification. Neither they nor I were 

willing to lift the flight hardware with uncertified hardware, so 

a quick resolution was needed. I hastily called some friends up 

the road at Goddard Space Flight Center who agreed to loan us 

the necessary hardware. I signed the necessary paperwork that 

morning, loaded it in the back of my pickup, and headed back to 

NRL. The lift went off without a hitch. 

The biggest impact to the project came from the changing 

requirements, though. The program had originally created the 

ICM project to ensure the ISS could continue to function should 

the early Russian modules not show up. With political changes 

in the wind, and as the technical requirements evolved from the 

original idea of use-as-is, those of us building the vehicle started 

to see a fluctuating set of requirements from the program. The 

vehicle design had to change accordingly. This continued for 

most of the project life cycle. At the build level, we really had 

no requirements control because the program was responding 

to external factors. As a consequence, we developed a lot of 

hardware that wasn’t used in the final configuration. Parts of 

wiring harnesses, power converters, and other black boxes were 

designed, built, tested, and certified but never used. It was a great 

experience but not the optimum project management model. 

A number of us NASA human space flight folks gained a 

wealth of experience working directly with the NRL. We were 

able to get hands-on experience developing and assembling a 

complete space flight vehicle, including being test planners and 

directors on some development and integration tests. We also 

were able to gain valuable experience developing an Agencywide distributed team that included outstanding can-do folks 

from Marshall, Johnson, and Goddard, among others. 

I learned a lot. If I had to pick the top five lessons, they 

would be these:

1. Trust is the key to making any distributed or crossorganizational team work. It may take time to build 

between people working together for the first time, but it 

is always worth the effort.

2. Requirements stability is critically important. There will 

always be some level of requirements instability, but we 

need to be ever vigilant to avoid requirements “churn.”

3. Communication, communication, communication. E-mail 

is okay, but the telephone is better. Face to face is best. 

4. Project management folks need to be aware of and 

sensitive to the mind-sets and experiences of the different 

organizations supporting their effort. An encouragement 

approach might work well for one organization yet be an 

utter disaster for another. That’s one reason why project 

management is as much an art as it is a science.

5. It is possible to integrate a “skunk works”-type project 

into a “normal” program, but it requires both sides to 

be flexible. Just as important, it requires someone that 

understands both organization types and processes to 

guide the integration process. 

Would I do it again? In a heartbeat. ●

LEE GRAHAM joined the Constellation Program office after 

twenty-two years of working at Johnson Space Center or in 

support of NASA. His experience includes participation and 

leadership roles in both large program offices and in small 

“skunk works” project offices. His expertise includes systems 

engineering and integration, safety and mission assurance, and 

real-time operational flight support.

8 | ASK MAGAZINE
Intro

Space Mission Excellence Program: 

Launching Systems Engineers at Glenn

BY KERRY ELLIS 

Photo Credit: Kerry Ellis

SMEP participant Tom Doehne highlights part of his presentation for the class.

On January 8, 2007, twenty-three participants in Glenn Research Center’s Space Mission Excellence 

Program met for the mock preliminary design reviews they had been preparing for the past few 

weeks. When Harvey Schabes, one of the guest review board members, asked after one presentation, 

“Why did you pick the most expensive options each time? Is there not a risk of running out of 

money on this?” participant Leah McIntyre responded with a smile in her voice, “Because we want 

the mission to succeed.” The instructor, Joel Sercel, replied quickly, “The right answer is, you tell 

the board, ‘When we engaged with you and the key stakeholders you identified, you all told us cost 

was not an issue. What you care about most is risk and schedule. These figures reflect that.’ At that 

point, you find out if that was really their criteria. That’s the power of this methodology.”

INSIGHT | ASK MAGAZINE | 9
For more than sixty years, Glenn has excelled at research 

in aeronautics; the generation, storing, management, and 

distribution of power for space systems; electric, nuclear, and 

chemical propulsion; communications; and microgravity 

science. Glenn has also played a key role in developing engines 

and rockets that have launched NASA missions into space, but 

over time it has lost experience creating aerospace systems that 

will operate outside Earth’s atmosphere. As the Agency turns 

to the Constellation program and the new Vision for Space 

Exploration, it is looking especially for the skills required to 

create new space vehicles. Senior management at Glenn realized 

they needed new types of experts—systems engineers—to make 

a significant contribution to Constellation.

In March 2006, Glenn Deputy Director Richard S. 

Christiansen asked the center’s Organization Development and 

Training Office (ODTO) to help find and prepare candidates 

for the challenge ahead. The office responded by creating the 

Space Mission Excellence Program, also known as SMEP, which 

is currently led by training specialists Kathy Clark and Adam 

Ross. “We needed to produce highly trained systems engineers 

in a short amount of time, and we were creating a program from 

scratch,” Clark explained. 

Through courses that would offer hands-on experience 

and in-depth guidance from seasoned systems engineers, 

SMEP would strive to provide Glenn with systems engineers 

who possess leadership and communication skills as well as 

technical expertise. “It is important for systems engineers to be 

able to work with the project as a whole, including the human 

interaction involved,” said ODTO Chief Cindy Forman. They 

also wanted to expose program participants to new and different 

perspectives on systems engineering and help them recognize 

and define problems and potential solutions. 

The program would also provide participants with mentors, 

but in an unusual way. Martin Forkosh, SMEP’s workforce 

development manager, explained that the program differs from 

other training programs because it assigns participants to a 

variety of projects as systems engineers. “We take them out of 

the classroom and provide them an avenue for real, hands-on 

experience,” Forkosh said, and he played a key role in making 

this lofty goal a reality. “We wanted a workforce development 

manager who had contacts across the Agency, was an expert 

in his field, cared about training, and could find projects for 

participants to join,” said Ross. “Martin had all that and was 

previously chief of systems engineering, so he understood what 

we needed from candidates to get them reassigned.”

 With a bit of trepidation—because they were uncertain 

how the experienced workforce would respond to taking on 

“green” members and helping them learn the ins and outs of 

systems engineering—the training team began asking program 

and project managers if they would enlist the SMEP recruits for 

their projects. “The response from project managers was huge; 

it was really quite fantastic,” Forkosh said. Many eagerly took 

on the SMEP members and placed them on projects to work 

and gain hands-on experience. All participants work on these 

projects while they are taking in-classroom training, applying 

what they learn from both avenues of instruction.

The participants come with a variety of backgrounds and 

experiences. Charles Farrell spent thirty years in fluid dynamics, 

software development, management, and software engineering. 

He joined SMEP because he felt systems engineering 

best practices were more advanced than those in software 

engineering, and he wanted to apply his learning back to 

software engineering. Kathy Shepherd was previously a project 

manager for the Exercise Countermeasures project, part of a 

program at Johnson Space Center to study the effects of exercise 

on astronauts in space. She was looking for a change and wanted 

to expand her knowledge of NASA, referring to herself as one of 

the “new kids on the block” because of her six-year tenure with 

the Agency. James Scott spent twenty-three years researching in 

aeronautics and acoustics and was at a point where he wanted a 

transition in his career and could make it. “The mechanism to 

make such a change had never existed before, so I was excited 

MARTIN FORKOSH, SMEP’S WORKFORCE DEVELOPMENT MANAGER, EXPLAINED THAT THE 

PROGRAM DIFFERS FROM OTHER TRAINING PROGRAMS BECAUSE IT ASSIGNS PARTICIPANTS TO 

A VARIETY OF PROJECTS AS SYSTEMS ENGINEERS. “WE TAKE THEM OUT OF THE CLASSROOM 

AND PROVIDE THEM AN AVENUE FOR REAL, HANDS-ON EXPERIENCE.”

10 | ASK MAGAZINE
about the program,” he said. Another participant started down 

the systems engineering path two years ago; others are still 

acclimating to a shift made only a few months ago. 

Together the participants work on elaborate assignments 

that expose them to areas of systems engineering they may not 

have experienced yet in person. In early January 2007, I was 

invited to observe the outcome of the first of these assignments: 

a mock preliminary design review (PDR). 

Engineer for a Day

The first thing that struck me when I arrived for the PDR was 

the sense of community in the room. Conversations started up 

as people began filtering in at 7:30 a.m. and delivered donuts, 

homemade brownies, and other fresh-baked goods to a small table. 

Cheery “good mornings” peppered the air as people caught up and 

reviewed their notes before presenting the findings of their PDR.

As a non-engineer with a limited understanding of what 

goes into building spacecraft, I was concerned about my ability 

to follow the class and understand what was being presented. 

When I shared my apprehension with a couple of students 

near me, they candidly said they hoped they could answer 

my questions because they were also new to this and learning 

so much themselves. Reassured, I asked the most basic—and 

important—question I needed answered: “What exactly is a 

preliminary design review?”

The easiest way to define it is as a comprehensive, extremely 

detailed sales pitch. Participants were divided into two teams as 

if they were contractors competing for a $170 million project 

that would span six years. Each team would have about three 

hours to make its case before a review board about why it should 

be awarded the contract. For comparison, one participant told 

me that the actual PDRs for a couple of racks flying on the 

Space Shuttle took four days to present and probably six to nine 

months to create. 

A PDR includes a massive amount of information. In 

addition to meeting the client’s requirements, a contractor needs 

to show how it will garner resources to build the spacecraft and 

operate the mission, predict potential risks and explain how they 

will be reduced, project the overall budget and timeline, define 

critical milestones, and much more. Most of content presented 

in PDRs paints the big picture and provides supporting details 

about what is needed to build, launch, and relay and analyze 

data for a long-term mission—important information for a 

systems engineer to understand, since presenting and defending 

the project requires a grasp of the entire project and how the 

parts of it fit together and affect each other. To prepare for their 

PDRs, participants relied on requirements distributed in their 

previous class and information in documents or on the Internet 

from real PDRs of projects similar to the hypothetical one they 

were assigned.

The review board—there to test participants’ understanding 

of the process, ask pointed questions, and deliver immediate 

feedback—included CalTech course instructor Joel Sercel, 

Engineering Development Division Chief Dan Gauntner, and 

Photo Credit: Kerry Ellis

Harvey Schabes leans in to discuss part of a PDR with CalTech instructor Joel Sercel.

ASK MAGAZINE | 11
Center Operations Deputy Director Harvey Schabes. Welcoming 

the participants the first day was also Ricky Shyne, Deputy 

Director of the Engineering Directorate. As students from each 

team presented their sections of the PDR, time was reserved at the 

end for the review board to ask questions and make observations, 

detailing what had been done well and what had been missed 

or could have been done better. Participants were often asked to 

respond to questions as if they were in a real PDR and respond 

again as a student to clarify what they were learning and what 

would happen (or should happen) in an actual PDR. 

The practice also underscored the importance of predicting, 

defining, and mitigating risk to ensure teams had plans of 

action for any contingencies. After James Scott presented his 

team’s risk findings, Sercel clarified some of the confusion 

about identifying risks: “A risk is an event or condition that has 

a probability or a consequence. Cost overrun is not an event, 

but a consequence. Meteor damage to the antenna, however, is 

a well-defined risk. If a risk can be applied to any project, it is 

too general and therefore inaccurate.” Gauntner elaborated with 

a quick tip to help participants delineate the difference, “To 

define a risk, I find it helpful to start with a statement and then 

ask ‘why?’ five times to find the root cause. That is your risk.”

Stories from personal experience bolstered the generalizations. 

To help define an acceptable percentage probability for risk, 

Sercel shared one story about a JPL mission that was developing 

a composite propellant tank. The engineering team for the tank 

guesstimated that there was an 80 percent chance the tank would 

be delivered on time, “which was completely unacceptable,” Sercel 

said. So the team fully funded a back-up titanium tank in parallel.

Interaction among the participants and with the review board 

members was open and honest, with students challenging some 

of the board’s feedback and even inspiring some friendly debates 

among the board members about engineering requirements, the 

best way to accomplish goals, and new approaches to standard 

PDR requirements. Student-to-student conversations sprang 

up during the question-and-answer sessions as they discussed 

details and incorporated the board’s feedback into upcoming 

presentations. Though the exercise had been playfully described 

as a competition between contractors, it was obvious from the 

exchanges that there was one community in the room.

Each team learned from the other. They discussed the 

differences in their approaches and what they had learned from 

each other over lunch, so they all reached a cohesive understanding 

together. After the presentations were completed, the review 

board assigned a few “requests for action” and asked the teams 

to revise some slides for the next day to ensure they understood 

the feedback they had received the first day. The next morning, 

the line between teams was further dissolved as the entire 

group worked together to revise portions of their presentations. 

Gauntner observed these interactions as well, saying at the end 

of the exercise, “Everyone showed remarkable teamwork and 

camaraderie, which will be a benefit for exploration.”

Using their new hands-on experience to bolster the PDR 

exercise and taking lessons learned from their mock PDRs 

back to their projects creates a rich and ongoing educational 

experience for the participants. The students also discovered 

they were using their previous work experience in ways they 

had not anticipated. Shepherd said that her previous project 

management experience helped her see the whole picture that 

systems engineering required. Scott said he was surprised he was 

using much of his research background in systems engineering, 

because systems engineering is a completely different discipline. 

He also shared with me a realization we’d both come to that day: 

“You just can’t build spacecraft without systems engineering.” 

Future Generation

SMEP has more experience and mentorship ahead for the 

participants. By the time the program concludes at the end 

of 2007, Glenn’s office of development and training hopes 

its program of formal training, hands-on experience, and indepth exercises will have helped the next generation of systems 

engineers contribute to the Vision for Space Exploration. ●

12 | ASK MAGAZINE
Intro

CompanyCommand: 

A Professional Community That Works

BY DR. NANCY M. DIXON

Photo courtesy of CompanyCommand

Army Capt. Chanda Mofu, left, prepares to lead a joint 

American–Iraqi patrol. Since returning from Iraq, where he 

commanded two infantry companies, Mofu has stepped up 

to play a leadership role on the CompanyCommand team.

INSIGHT | ASK MAGAZINE | 13
CompanyCommand is a professional forum through which 

soldiers who have been given command of a company (about 150 

soldiers) learn from each other in the mess hall, over the hood 

of a Humvee in Iraq, and online at http://companycommand.

army.mil. CompanyCommand has been heralded by the army 

as its premier professional forum, notwithstanding its grassroots 

beginnings in 1995 by two young U.S. Army officers. Even after 

being brought behind the army firewall, CompanyCommand 

has retained its grassroots spirit and governance, remaining a 

community of young officers exchanging knowledge based on 

the daily struggles of frontline professionals like themselves. 

Company commanders are a rich source of knowledge about 

how to be effective leaders in the rapidly changing battle 

environment; they alone have firsthand knowledge of what the 

role demands. 

Conversation about subjects that really matter to this group 

of soldiers is at the heart of this forum: “How do I deal with the 

death of a soldier I am responsible for?” “Is it my responsibility 

to help soldiers be comfortable with the reality of killing or just 

train them to do it?” “How do I keep soldiers physically fit for 

the mountainous terrain and overwhelming heat and cold of 

Afghanistan?” “What have we learned about how to interact 

with Iraqis?” There are no doctrinal or clear-cut answers to these 

issues; they are the ambiguous questions of leadership. When 

answers are not clear, conversation with those facing similar 

issues is an essential means of deepening one’s own thinking 

about important subjects. 

Company commanders challenge each other’s thinking by 

raising difficult issues in the online forum; they meet together to 

read and discuss books through the Pro-Reading program; they 

provide emotional support in informal face-to-face gatherings 

on base; they celebrate each other’s lives and successes with 

pictures, honors, and recognition on the CompanyCommand 

Web site; they meet together at a yearly rendezvous; and they 

provide practical firsthand knowledge about the task they 

are all engaged in through conversations. 

These company commanders believe they are making a 

difference in each other’s professional development. They would say 

they are “giving back” to a profession that has given them much. 

The Core Team Is the Heart of the Community

This willingness to give back and to support each other does not 

occur without a great deal of effort by a volunteer group at the 

core of the community that actively builds the relationships that 

glue the community together. 

Any community that shares knowledge and supports and 

develops each other must have a small, socially connected, and 

committed group of members that takes responsibility for the 

majority of the activity in the system.1,3,4 CompanyCommand 

has some thirty dedicated volunteers, each responsible for a 

specialized section of the community: for instance, maintenance, 

war fighting, military police. Each core team member is a 

company commander, who is a specialist from the field he or 

she leads—someone who knows the ins and outs of the daily 

work of that specialty field.

Company commanders typically stay in their command 

post for only a couple of years before being rotated out 

to a new assignment. So the core team, like the whole 

of CompanyCommand, is a dynamic community with a 

constant influx of new members, while others are phasing out. 

The term “community” has become ubiquitous—everything from list serves to “MySpace” has been 

tagged a “community.” The kind of community I describe here is one whose members are dedicated 

to mutual growth and development—so I might label it a professional development community. 

14 | ASK MAGAZINE
Once out of command, core team members quickly realize 

that they are no longer in touch with the needs of soldiers on 

the ground and begin to look for the person who will follow 

them in leading their section. But not just any volunteer 

will do; they look for someone who, like themselves, wants to 

have an impact on the profession—who has a willingness to 

give back.

This core group maintains the care and feeding of 

CompanyCommand, but like any community, they require 

care and feeding themselves. The core group becomes a 

subcommunity within the whole, training, encouraging, and 

supporting each other in their efforts to be more effective core 

team leaders. As a vital part of that support, the core team holds 

a yearly rendezvous to celebrate successes and think about the 

needs of the community. Here a core team member describes 

one of those meetings: 

 The rendezvous was huge because that brought together 

such a group of like-minded professionals, and staying 

with that group of people for three or four days, talking 

with them, generating ideas, was a huge energy boost. It 

really just kind of got me reenergized and back into the 

thick of it. It gave me some huge ideas on reorganizing the 

taxonomy of how Soldiers and Families was organized and 

trying to make it more content friendly and trying to make 

it more user friendly. And it really just kind of reaffirmed 

what I thought I was doing with CompanyCommand 

and why it was valuable to me and why it was valuable to 

the profession.1

What It Takes to Connect the Community

In studying CompanyCommand, Tony Burgess, one of the 

founders, identified five roles core team members play in their 

communities.1 The words of the core team members themselves 

best describe what they do in these roles and why they choose 

to serve in this way. 

1. Contributor

Those who become core team leaders have themselves been active 

members of the forum, and as core team leaders they continue 

to bring all of themselves to the new role—their current work 

issues and problems as well as their knowledge and experience.

 [CompanyCommand is] a place I could give what I 

had to share and at the same time still ask; I could still 

be in a learning environment. It wasn’t, you know, a 

teacher–student type thing. It was truly a group of guys 

[saying], okay ... let’s throw this thing out there and see 

what people think about that.

2. Connector

In this role core team members connect people to other 

knowledgeable people and to content that is on the site, and 

they close the loop by finding out what actions the soldier who 

asked the question took as a result of the conversation, playing 

that back as well.

 You know that this guy over here has something to give 

and this guy over here is looking for it, and you’re the 

one who helps make that connection possible .... [I ask 

myself] what can I do to find the other people who have 

had this experience and get them involved with those 

guys who are over there [in combat] now? And you do it 

in a variety of ways. You use the Web site itself to make a 

call to arms, “Hey, you know this guy is out here doing 

this. Is there anybody who can help him out?” And 

people jump on it. Or you make the private connection 

[via e-mail or phone]. 

3. Facilitator

In this role the core team member works to deepen the 

conversations that occur in his specialty group, serving as a 

catalyst and sometimes a provocateur.

CompanyCommand team members (left to right) Chanda Mofu, Dan Dwyer, 

Nate Self, and Jay Miseli share ideas during the CC team’s annual “OnFire! 

Rendezvous,” which brings together the team for a face-to-face weekend of 

camaraderie, training, and planning. All four have led soldiers in combat. Self 

was awarded the Silver Star for his valor in Afghanistan.

Photo Credit: Mark Derber
 We recently debuted a question about whether or not 

commanders have a responsibility for teaching soldiers how 

to deal with killing. It’s a great question, and one that needs 

to be dealt with, but ... the problem was that it didn’t seem 

to generate a whole lot of conversation because there was an 

enormous amount of consensus there. So what I decided 

to do was play a little bit of devil’s advocate ... to post an 

opposing view ... and that generated some good responses 

from other people. I felt like I could put myself out there 

and make myself a 50-meter target for other people to take 

shots at and help generate conversation. 

This core team member used his provocative post to help 

those in the conversation clarify their own thinking about this 

issue by articulating the reasoning underlying their positions. 

Core team members often invite diverse views, from another 

perspective or from another specialty, to enrich a conversation.

4. Social Catalyst 

This role is about making connections and building relationships. 

One way core team members serve as social catalysts is by 

warmly welcoming new members and establishing a personal 

connection with them, sometimes through e-mail, sometimes 

by picking up the phone, and often by taking the time to meet 

them in person when the core team member is traveling to an 

area where the new member is located. 

Core team members acknowledge contributions in a 

personal way that builds the sense of community. This is such a 

vital part of their role that I include two quotes here to illustrate 

the nature of their responses. There are no all-inclusive, “thanks 

for your posting” messages that go out. 

 Anybody who posts or responds to questions, or provides 

a really awesome tool—anybody who contributes to the 

supply forum—I’d usually shoot back an e-mail saying, 

“Hey, what a great tool.” Or “What a great idea.” Or 

“What a great thought. I hope this isn’t the last time we 

see you contributing because you were really on target 

with your comments.” Or “The tool you provided, I see 

how that can help.” 

“[Name], you many not realize it, but you really helped 

that guy. Did you see the response that he brought up?” 

Or, “Did you see that this guy that you helped then 

turned around and added to two other conversations 

and imported this knowledge object, and now he’s a 

contributor to CompanyCommand and he’s working 

hard? That was because of your intervention; that was 

because of your answer; that was because of the content 

that you helped him find; that was because you just 

wrote to him and said, ‘Good work,’ you know; that 

was due to your intervention. Well done!”

In an ever-changing community of 2,000 company 

commanders, participants in the site cannot hope to build 

a trust relationship with each person in their specialty area, 

but they can know and have been touched by the core team 

members. Through exchanges illustrated by those above, 

the community takes on a spirit of openness and acceptance. Core 

team leaders create a tone and attitude that permeates the whole.

5. Steward

Core team members look for gaps in the knowledge of their section 

and find ways to plug those holes. They shoot videos of company 

commanders on the ground, interview heroes and generals, send 

out surveys to capture the collective thinking on issues, and watch 

the site to see what issues and concerns are rising through the 

conversations. They serve as a quality control for their section, 

although always in a way that continues to build relationships.

 ... it doesn’t mean that I just reach out and delete; it 

means that I reach out to that individual who put it up 

Photos courtesy of CompanyCommand 

Right Photo: U.S. Army Captain and CompanyCommand team member Jason 

Toole, right, with his company first sergeant in Afghanistan.

16 | ASK MAGAZINE
1. The quotes in this article are from Tony Burgess, Understanding the Core Group in a Distributed Community of Practice (Dissertation, The George Washington University, 2006).

2. Nancy M. Dixon, Nate Allen, Tony Burgess, Pete Kilner, and Steve Schweitzer, CompanyCommand: Unleashing the Power of the Army Profession (New York: The Center for the Advancement of Leader Development and Organizational Learning, 

West Point, 2005).

3. Etienne Wenger, Richard McDermott, and William Snyder, Cultivating Communities of Practice: A Guide to Managing Knowledge (Boston: Harvard Business School Press, 2002).

4. Nancy M. Dixon, Common Knowledge: How Companies Thrive by Sharing What They Know (Boston: Harvard Business School Press, 2000).

there and say, “Can you tell me why you thought this 

should be on CompanyCommand?” Because frequently 

what happens is that ... they wanted to do the right thing 

and they were in such a rush to get it up there that they 

didn’t really think about how to phrase it. So by talking 

to them and refining it and saying, “Give me the context 

behind this” ... you get some really great products. 

Ownership and Professional Pride

What I hear in these many quotes, and what I hope you as the 

reader hear, is the sense of ownership these core team leaders feel 

about CompanyCommand. It is their community, not the U.S. 

Army’s, and though they work hard to serve the army, they do 

so by helping company commanders meet their own needs for 

professional development. 

There is a final quote from an early study I conducted with 

leaders in the core team, which for me sums up the need for a 

professional development community: 

 As I become more senior, more professionally mature, I have 

a greater desire to have an impact on the profession—not 

only because I care about it and I care about the soldiers, 

but also because I’m going to continue to work inside this 

profession. If you believe in something, you want to have 

an impact on it because it’s going to come back to you at 

some point. So I ask myself, “What direction are we taking 

our profession?” You could ask that about your company, 

your battalion, about the Web site, about the army. In the 

same way that you are an active participant in shaping the 

government when you vote, you have the opportunity to 

be actively involved in shaping this profession.2

Professional development occurs when professionals face 

difficult issues that they care about and are able to reflect on 

that experience with colleagues who do similar work and in an 

atmosphere of trust and acceptance. ●

DR. NANCY M. DIXON is an author and consultant working 

with clients to create effective ways to hold knowledge 

conversations. She is the author of eight books, including Common 

Knowledge and The Organizational Learning Cycle, as well as more 

than fifty articles that focus on how organizations learn. 

IN AN EVER-CHANGING COMMUNITY OF 2,000 COMPANY COMMANDERS, 

PARTICIPANTS IN THE SITE CANNOT HOPE TO BUILD A TRUST RELATIONSHIP 

WITH EACH PERSON IN THEIR SPECIALTY AREA, BUT THEY CAN KNOW AND 

HAVE BEEN TOUCHED BY THE CORE TEAM MEMBERS.

Army Capt. Jason Toole talks with an Afghanistan National Police chief in 2006. 

After returning from his second deployment to Afghanistan, Toole became a 

CompanyCommand topic lead as a way to share what he had learned about 

that country and counterinsurgency operations.

Photo courtesy of CompanyCommand 

ASK MAGAZINE | 17
Title

BY 

Intro

I began working with Stanford University, the Gravity Probe B 

(GP-B) prime contractor, in 1993 and worked full time at the 

contractor’s facilities from 1997 to 2005. When I first visited 

Stanford, the GP-B team was working in a classic laboratory research 

environment. The team was brilliant to watch as they came up with 

solutions to the many technical issues they faced. They were not 

afraid to challenge each other on even minor technical issues. In one 

of my first meetings, I watched co-investigators argue about whether 

the atomic number of niobium was 92.90638 or 92.90637. I didn’t 

know the fifth decimal point of the atomic number of niobium off 

the top of my head! How was I to add value to this incredibly smart 

bunch of scientists and engineers? It turns out there were some 

useful things that I did know. To successfully launch GP-B, I knew 

that one day this team of academic researchers needed to create an 

aerospace infrastructure to perform the tasks that awaited them. We 

started pulling in the reins to convert GP-B from a research project 

to a flight program—not all at once but by introducing continuous, 

systematic improvements at a pace that allowed the majority of the 

workforce to adapt. Changing how a team works isn’t easy, especially 

if you need to maintain their trust and cooperation while doing it. 

Here are some important approaches.

BY EDWARD INGRAHAM

18 | ASK MAGAZINE | STORY
Learn and Teach

Initially I worked to become part of the team. I got beyond the 

review meetings to where the real work was going on. It was 

important to spend some energy becoming part of the team and 

proving my value. All new leaders or team members must do this 

to be effective. I think we all need to earn the right to be part of 

a team regardless of what our official roles and responsibilities 

are. Humans are social creatures and team dynamics play an 

important role in one’s effectiveness. Initially engaging others in 

what they do, listening more than talking, and helping others 

accomplish their tasks are all great ways to earn the right to 

influence the process. For the customer at a contractor’s facility, 

this is also a great way to gain in-depth knowledge of existing 

processes. It’s difficult to really understand what is broken 

without rolling up your shirtsleeves and doing some of the work 

yourself. You learn where the processes are breaking down. 

When Stanford said it didn’t have the resources or expertise 

to train its people, I worked with the team to devise a process to 

build flight hardware on campus and brought in other NASA 

personnel to help train and certify key members of its workforce. 

The training included the nuts and bolts of building and testing 

flight hardware for NASA, and it was designed specifically 

for Stanford’s applications. The engineers, technicians, 

scientists, and managers began to appreciate how everything 

from purchasing parts, writing test procedures, dispositioning 

discrepancies, and approving readiness reviews came together 

logically to demonstrate that their subsystems, systems, and 

eventually their spacecraft were ready to fly. The training gave 

team members a common understanding of how they needed to 

operate and demonstrated that NASA and the contractor were 

on the same team. 

Manage Change Thoughtfully

To be an effective project manager, you must see your role as the 

one in charge of understanding and monitoring all interfaces, 

whether subsystem to subsystem or team member to team Stanford engineer Ken Bower inspects the Gravity Probe B fused-quartz block, 

which houses the four fused-quartz gyroscopes. 

Photo Credit: Stanford University/Russ Leese

ASK MAGAZINE | 19
member. Interfaces require effective communication, whether 

between electronic boxes or humans. Be on the lookout for 

key interfaces that span organizational lines and could create 

a barrier within your team. For example, when I first started, 

the program had a weak system for process changes. A new, 

unified Program Change Board (PCB) system was organized at 

Lockheed Martin, Stanford, and Marshall Space Flight Center 

to handle all programmatic and technical changes for the 

program. I worked hard to get that system started and working 

efficiently. That meant modifying the contract to include 

INITIALLY ENGAGING OTHERS IN 

WHAT THEY DO, LISTENING MORE 

THAN TALKING, AND HELPING OTHERS 

ACCOMPLISH THEIR TASKS ARE ALL 

GREAT WAYS TO EARN THE RIGHT TO 

INFLUENCE THE PROCESS.

Photo Credit: Stanford University/Russ Leese

Stanford engineer Chris Gray inspects the number-four gyro under 

monochromatic light after it was removed from the Science Instrument assembly. 

20 | ASK MAGAZINE
NASA representation at the contractor’s level, which was key to 

coordinating all levels of the decision process. It gave everyone 

involved clear insight into what was going on. In the end, more 

than 675 changes were effectively processed.

Find Common Ground

When I came into the program in the early nineties, the 

challenge was not just to integrate flight subsystems but also to 

integrate NASA, Stanford University, and Lockheed Martin—

organizations with three very different mind-sets. To see the 

other teams as collaborators instead of competitors, team 

members needed to understand each other’s challenges and 

adjust their ways of thinking. 

When a large number of NASA engineers joined GP-B a 

couple of years before launch, the contractor team—which already 

felt overworked—resented spending what seemed like more time 

replying to NASA engineers’ questions than working on the 

project. NASA engineers, for their part, were not used to having 

only limited access to the contractor. Both sides were frustrated. 

We worked on getting them to see each other’s points of view 

and looked for solutions to the conflict. The contractor hired 

additional personnel. NASA changed its priority and emphasis 

to a risk-based management system. This served to substantially 

reduce questions about some subsystems that posed little or no risk 

to mission success and allowed concentration on mitigating issues 

that could threaten mission success. In the end, this compromise 

produced a solution that served the team and the project well.

Seek Out the “Doers” on Your Team

Sift through the “knowers” and find the “doers” for your project. 

There is a loose and imperfect relationship between knowing 

what to do and the ability to act on that knowledge. Many times, 

people confuse talking about what a group ought to do with 

actually getting it done. A “doer” is someone you can rely on, 

for instance, to get a particular system manufactured and tested. 

We had several “go to” team members who could jump into a 

difficult situation and succeed. A manager who is a “doer” creates 

positive change in the team to make it more effective and more 

able to create a product that fulfills its mission. Concentrating on 

words rather than turning words into action is the easiest way for 

managers to fail. One of the biggest mistakes I’ve seen a manager 

make is believing that just because he or she said something or 

documented it, it would be done. Do not confuse talking a lot, 

sounding smart, or using complex rhetoric with “doing.”

Understand Weaknesses As Well As Strengths

It is important to understand weaknesses in addition to strengths. 

The brilliance of the GP-B team members was actually both a 

strength and a weakness. For example, the Gas Management 

Assembly (GMA) used to hold and pump helium gas into 

Lessons Learned

• First, work to become part of the team. Earn the right to be 

part of the team through hard work and by demonstrating 

value as a team member. 

• Listen more than you talk. Before making process changes, 

analyze how and why the team uses its current processes.

• Cover your flank. Ensure that NASA speaks with one voice. 

Make sure your senior managers are aware of what you’re 

doing and will back you up.

• Accept ownership of problems. Move past unproductive 

blaming of others and begin to focus on figuring out what 

to do about problems. 

• Understand and manage the technical and programmatic 

interfaces.

• Know your contractors’ weaknesses. Help them by finding 

“doers” in your organization who can come in and help 

solve problems. 

• Look for problems in the dark spots. Problems are usually 

found in places where others are not looking.

21 | ASK MAGAZINE ASK MAGAZINE | 21
the gyroscopes to spin them up in the beginning of the flight 

experiment did not get a lot of management attention. While 

this subsystem was critical to mission success, it was basically 

a big plumbing system. The best engineers wanted to work on 

other, flashier subsystems.

Responsibility for the GMA shifted among a few 

development engineers until it ended up on Chris Gray’s lap. 

Soon thereafter, Chris proposed a series of tests to try to fully 

understand the performance of the partially built subsystem. 

Each time Chris came back with test results, they showed an 

additional problem. It was like putting your finger in a leaking 

dam and having another leak pop up. I quickly concluded that 

we’d need a major hardware change for the GMA and Gravity 

Probe B to succeed. The contractor had a hard time coming to 

terms with a major change at a late stage in the program. 

By this time, the team trusted me enough to accept my 

offer to fly in a NASA valve expert to help. Within a day, I 

had the best valve person from Marshall Space Flight Center 

at the contractor’s facility, and the NASA Program Office 

was preparing upper management for the schedule and cost 

impact of the major hardware change that might be necessary. 

By the time the decision was made to restart the development 

of the GMA system from scratch, NASA management and 

the contractor’s team were on board. NASA, Stanford, and 

the new subcontractor team designed, manufactured, tested, 

and integrated the new GMA system from scratch in thirteen 

months, and it worked flawlessly during the mission.

The Importance of Being There

Having NASA engineers and managers reside at contractors’ 

facilities, if done properly, reduces the risk of hidden 

problems and adds to the openness, trust, and unity of the 

entire team. And working day to day with flight hardware 

at a contractor facility provides training that no course or 

textbook can match. The time I spent at the contractor 

facility for the GP-B mission was an incredible journey 

and an invaluable experience that taught me how NASA 

should work with a contractor. ●

For more information on the Gravity Probe B mission, visit 

http://einstein.stanford.edu.

EDWARD INGRAHAM, PE, PMP, has nineteen years of 

experience working with universities or defense contractors for 

the federal government. For Marshall Space Flight Center, he 

served as the resident manager for the Gravity Probe B mission. 

He is currently working on detail at NASA Headquarters assigned 

to the Offi ce of the Chief Engineer. 

Image of a coated gyroscope rotor and matching housings.

Photo Credit: Don Harley

22 | ASK MAGAZINE
Democratizing Knowledge

at NASA and Elsewhere

BY THOMAS H. DAVENPORT

A couple of years ago, I assigned a case study on 

NASA’s approach to knowledge management to 

several teams of MBA students as a fi nal exam. 

As part of the exam, the teams were expected to 

make recommendations for how NASA should 

revise its approaches to knowledge. One MBA 

team suggested a major change in direction. 

Their recommendation went something like 

this: “NASA should abandon its current systems 

and approaches to managing knowledge and 

adopt a series of wikis instead.”

INSIGHT | ASK MAGAZINE | 23
A wiki is a system by which multiple individuals can edit a document 

over the Internet. It was a relatively new feature at the time, but it 

is much better known today because of the success of Wikipedia, 

a publicly edited encyclopedia. I didn’t give these students a high 

grade. I commented on their paper that, “I’d hate to fly on a Space 

Shuttle mission with expertise contributed by committee.” 

Since then, however, the “democratization of knowledge” 

has become an influential idea, and wikis, blogs, and social 

networking software have risen dramatically in popularity. A 

recent New York Times article described the embrace of these 

democratic tools by several groups within the U.S. intelligence 

community. MIT has formed a research center dealing with 

what it calls “collective intelligence.”

Were my students, then, only a bit ahead of their time? Was I 

an old fogy and an elitist in resisting this democratic movement? 

In this article, I’ll consider the tools and management issues 

driving the democratization of knowledge and speculate a bit on 

their potential relevance to NASA.

What’s So Good About Knowledge Democracy?

The general idea of making knowledge more democratic has 

strong appeal for many. It recognizes that knowledge is almost 

always a social construct and seldom the sole possession of a 

single brilliant individual. Why not engage the intelligence and 

expertise of as many people as possible? All of us together are 

clearly smarter than any one of us.

It’s also an appealing notion that knowledge democracies 

would eliminate political or hierarchical barriers to knowledge 

exchange. In a fully democratic organization, everyone’s ideas 

would be heard and considered. The democratization idea suggests 

that knowledge will flow more readily around an organization, 

and the best ideas will float to the top. NASA, of course, has 

encountered situations in which the broader dissemination of 

knowledge might have prevented failed missions.

Substantial technology that could yield a more democratic 

form of knowledge management is now available. Wikis are being 

considered, for example, for applications such as comments on 

patent applications. There are more than 80 million Web logs, 

or blogs, in which individuals express their opinions or personal 

knowledge in an informal fashion. Social networking software 

is primarily for social interchange now, but new versions of it 

are being introduced that allow sharing of business relationships 

and contacts. “Prediction markets,” such as the Iowa Electronic 

Markets, are being touted as yielding better predictions of 

difficult-to-forecast phenomena (most notably, in the case of the 

Iowa market, the U.S. presidential elections). These technologies 

could bring an approach to capturing and managing knowledge 

that is much more democratic and participative than those 

typically used to manage organizational knowledge.

Alas, however, this utopian vision can hardly be achieved 

through new technology alone. The absence of democratic 

knowledge technologies in the past is not the only reason that 

knowledge is hierarchical in nature. Software and the Internet 

won’t make organizational hierarchy and politics go away. They 

won’t make the ideas of the frontline worker in corporations 

as influential as those of the CEO. Most of the barriers that 

prevent knowledge from flowing freely in organizations—

power differentials, lack of trust, missing incentives, 

unsupportive cultures, and the general busyness of employees 

today—would not be addressed by technology alone. For a 

set of technologies to bring about such changes, it would have 

to be truly magical, and the tools employed for knowledge 

democracies fall short of magic.

For NASA, however, a more important issue in moving to 

a more democratic knowledge environment is the quality of the 

knowledge itself. NASA is full of experts on various topics, but 

in any specific knowledge domain some people are more expert 

than others. It would seem irresponsible to treat all knowledge 

equally where lives and very large amounts of resources are at 

stake, as they are on all NASA space missions. 

Therefore, I would argue that it is not a good idea for 

NASA to adopt a fully democratic approach to knowledge, at 

KNOWLEDGE IS ALMOST ALWAYS A SOCIAL CONSTRUCT AND SELDOM THE 

SOLE POSSESSION OF A SINGLE BRILLIANT INDIVIDUAL. WHY NOT ENGAGE 

THE INTELLIGENCE AND EXPERTISE OF AS MANY PEOPLE AS POSSIBLE?

24 | ASK MAGAZINE
least under certain circumstances, including situations in which 

there are clear right answers and where some people are more 

likely to provide those answers than others. Indeed, on the 

Internet and in other environments where knowledge creation 

and distribution have already been democratized (for instance, 

CB radio and community access television), knowledge quality 

levels are often degraded.

Some argue that knowledge quality can remain high in 

a democratic knowledge environment. The most common 

example given is Wikipedia, the wiki-based encyclopedia. A 

widely discussed article in Nature—itself usually a source of 

high-quality knowledge—reported that Wikipedia’s scienceoriented entries were not significantly more error-prone 

than Encyclopaedia Britannica’s, which rely heavily on expert 

writers and editors. There is more to this story, however. Even 

Nature found that Wikipedia had 32 percent more errors than 

Britannica, and in many cases the Nature reporters did not use 

actual entries from the real Britannica encyclopedia as the basis 

for comparison. For example, one entry they used consisted of 

several excerpts from Britannica entries strung together with text 

written by the Nature reporters; another came from a Britannica 

encyclopedia for children. While many democratically minded 

observers have used this comparison to support a more 

democratic knowledge management approach, I believe that it 

supports the opposite conclusion—that experts provide a higher 

quality of knowledge than the general public.

Finally, there are some who argue that these democratic 

and socially oriented tools can be used to distribute knowledge 

by experts. Why not, as some have suggested, get experts to 

write blogs on NASA’s intranet (or even the public Internet)? 

While this approach is certainly possible, and some companies 

I have encountered do employ it, I don’t believe it’s very helpful. 

There are already many tools for distributing the knowledge of 

experts—from corporate portals to online expertise directories to 

printed books. The power of social media is their social nature; it 

is, I believe, a misuse of those tools to restrict them to experts.

When Are Democratic Approaches Appropriate?

Under what circumstances, then, might it be feasible and even 

desirable to use these social and democratic tools? One fairly 

obvious set of conditions would be when there is no right answer 

but only opinions as to the best alternative. A debate on which 

U.S. presidential candidate might provide the greatest level of 

support for manned space travel, for example, would seem to be 

well-suited to a series of blogs and online discussions.

Democratic approaches may also be useful to debate 

questions (again, that have no right answer) when broad 

participation and commitment by affected parties is necessary 

for success. Organizations that care deeply about employee 

satisfaction, for example, might use blogs, wikis, or discussion 

databases to debate changes in human resource management 

policy. This participative approach would seem especially 

relevant to organizations like NASA where there are high 

percentages of well-educated knowledge workers.

Another setting well suited to democratic knowledge is when 

there is a correct answer, but the knowledge needed to elicit 

it is equally distributed among a population. In The Wisdom 

of Crowds, James Surowiecki refers to the frequent contests in 

which many individuals guess how many jellybeans (or other 

small objects) there are in a large jar. No individual knows the 

correct answer, but all are equally qualified to guess. In such 

situations, Surowiecki reports, guesses will vary widely, but the 

average of all the guesses is likely to come close to the correct 

number. One hopes that NASA usually has better means for 

coming up with an answer, however.

This “averaging” approach can also work when experts are 

the opinion holders. Individual expert predictions are often 

wrong, but collectively they can be impressively perspicacious. 

Law professor Cass Sunstein points out in Infotopia: How Many 

Minds Produce Knowledge that while an individual economist 

may not accurately predict economic growth every year, 

the average of a number of economists’ growth predictions is 

usually quite accurate.

ASK MAGAZINE | 25
Another (possibly more useful) approach for democratic 

knowledge at NASA is in situations where a non-accountable 

opinion may be more honest or accurate than those who are 

accountable for an outcome. Some corporations (HewlettPackard, for example) have experimented with “opinion 

markets” to predict sales performance based on multiple 

opinions; accountable salespeople may be likely to overestimate 

the likelihood of a particular sale. Pharmaceutical firms use the 

same tool to predict the likelihood that a drug compound will 

receive FDA approval. NASA might employ opinion markets to 

anticipate the likelihood of a mission failure. 

Finally, democratic approaches to knowledge can work well 

when the goal is only an approximate, convenient answer. Google, 

for example, employs a democratic approach to deciding what Web 

page you are seeking when you do a search. It ranks pages primarily 

on the basis of the degree to which other pages have linked to a 

page. The page-ranking algorithm may yield the site you seek, but 

it is usually just an approximate result. Similarly, while Wikipedia 

may have a lower definition accuracy level than Encyclopaedia 

Britannica, the wiki-based encyclopedia is free and convenient to 

use, and it usually provides a generally correct answer.

Choosing the Right Approach

There are, then, a number of settings in which democratic 

knowledge tools can provide an accurate or useful answer. But 

these are by no means the only settings in which organizations have 

a need for knowledge. NASA and other organizations seeking to 

manage knowledge and improve knowledge work need to analyze 

and diagnose the setting in which knowledge will be used before 

deciding on any particular technology to facilitate the process.

There is little doubt that democratic knowledge technologies 

should be employed to augment the more traditional, accepted 

approaches to creating, gathering, refining, and distributing 

knowledge. However, they should not be viewed as a panacea for 

NASA nor as the only useful tool in the knowledge toolbox. ●

MOST OF THE BARRIERS THAT PREVENT KNOWLEDGE FROM FLOWING FREELY 

IN ORGANIZATIONS—POWER DIFFERENTIALS, LACK OF TRUST, MISSING INCENTIVES, 

UNSUPPORTIVE CULTURES, AND THE GENERAL BUSYNESS OF EMPLOYEES 

TODAY—WOULD NOT BE ADDRESSED BY TECHNOLOGY ALONE.

THOMAS H. DAVENPORT holds the President’s Chair in the 

Information Technology Management Division and is Director of 

Research for the School of Executive Education at Babson College. 

He has written, co-authored, or edited ten books—including 

the first books on business process reengineering, knowledge 

management, and the business use of enterprise systems—and 

hundreds of articles for such publications as Harvard Business 

Review, Information Week, CIO, and many others. 

26 | ASK MAGAZINE
Robert C. Seamans was appointed associate 

administrator of NASA in 1960 and became 

deputy administrator in 1965. He later became 

secretary of the U.S. Air Force and then dean of 

the School of Engineering at MIT. Don Cohen 

spoke with him at the Robert C. Seamans 

Learning Laboratory on the MIT campus in 

Cambridge, Mass. 

I N T E R V I E W W I T H

COHEN: What was NASA like when you 

became associate administrator in 1960?

SEAMANS: A lot of people thought I was 

nuts to take the job because Eisenhower’s 

term was about over, and there was a 

real question as to what might happen 

next. Was Nixon or Kennedy going to 

be elected? That was still in the lap of 

the gods on September first, when I was 

sworn in. My first job was to try to see 

what was already going on. I’d served on 

NACA [National Advisory Committee 

for Aeronautics] committees, and I’d 

even been on an interim committee to see 

what NASA might do in certain areas, 

but it’s one thing to have a general idea 

and another to know what each of the 

centers is doing. Keith Glennan, who was 

the administrator, was very thoughtful 

and said, “Why don’t you take the first 

month and get around to every one of 

the centers?” I started off at Langley. The 

first thing that Tommy Thompson, the 

director, had set up was for me to get 

to know something about Mercury. I 

climbed into the simulator; John Glenn 

put the hatch down and went through a 

very modest simulation. Next I met with 

John Houbolt and one or two others. 

Oftentimes when you go for briefings 

you have a lot of people in the room and 

Robert 

Seamans

BY DON COHEN

INSIGHT | ASK MAGAZINE | 27
slides like you wouldn’t believe. All John 

had was three or four sheets pinned up to 

the blackboard explaining what’s involved 

if you go direct ascent to the moon, and 

what you might gain if you rendezvous 

in Earth orbit—basically you don’t have 

to build such a big launch vehicle. But if 

you go lunar orbit rendezvous, you don’t 

have to decelerate 4,000 feet to land on 

the moon and then accelerate to get back 

home. It’s a hell of a savings of energy.

COHEN: So you were presented with the 

lunar rendezvous idea as soon as you 

joined NASA.

SEAMANS: It was either my second or my 

third day.

COHEN: That’s a powerful argument for 

being on the spot and meeting people.

SEAMANS: I’m a great believer in not 

sitting at your desk all day long. You 

have to do your homework at some point. 

My wife will attest to the fact that I 

usually brought home one briefcase and 

sometimes two on weekends.

COHEN: At that point there was no 

government commitment to go to the 

moon.

SEAMANS: I was in one of Eisenhower’s 

final cabinet meetings with Keith 

Glennan to discuss the budget for 

NASA for the following year, which was 

something like $1.029 billion. I’d been 

with Keith to Morey Stans to see if we 

could extract more funds. Morey said, 

“You’ve got to be kidding, Keith.” Keith 

asked, “What do you want, Morey?” He 

said, “I want a bargain basement figure.” 

WE FELT VERY strongly THAT WE COULD NOT manage APOLLO 

UNLESS WE HAD technical competence WITHIN NASA TO 

COVER any aspect OF any problem THAT MIGHT ARISE.

28 | ASK MAGAZINE
At the cabinet meeting, Kistiakowsky, 

Eisenhower’s chief scientist, gave a short 

presentation on what it would take to go 

to the moon: something like $20 to $35 

billion. Somebody said, “If we let those 

scientists go to the moon, the next thing 

you know they’re going to want to go to 

Mars.” Eisenhower said, “I wish someone 

would tell me what is the best possible 

program in space that costs no more than 

a billion dollars.”

COHEN: Did that attitude change as soon 

as Kennedy came in?

SEAMANS: When Jim Webb and I went 

to Dave Bell, who became director of 

budget, we started discussing some of 

the things we thought should be added, 

or at least discussed. Bell said, “The 

president is very busy. He knows space is 

important, but he doesn’t feel any great 

rush about it. He wants to get his mind 

around it next year for the following 

year’s budget.” It’s one’s prerogative at 

that point to say, “That’s unacceptable,” 

so we had a meeting with President 

Kennedy. The president said, “OK, Jim, 

what are we here for?” I was amazed 

when Jim said, “We’re here to hear Bob 

Seamans tell us what more we ought to 

be doing.”

COHEN: You weren’t prepared for that?

SEAMANS: He hadn’t told me, but I knew 

how much we’d put in to the Eisenhower 

people for the second stage of the Saturn 1,

for a larger rocket, for studying 

possibilities beyond the Mercury project. 

I was able to run through the figures: for 

instance, if we get $45 million more, we 

can have the Saturn 1 ready for a manned 

flight in ’65 rather than ’67, and so on. 

Kennedy immediately said, “I want that 

in writing tomorrow morning.” George 

Low had already run one study on what 

it would take to go to the moon—a short, 

general study, nothing very quantitative. 

The idea was that it seemed technically 

feasible; there didn’t seem to be anything 

major that couldn’t be handled. I also 

knew from that study the time that 

could be saved with additional money. 

We had Bill Fleming pull together a 

group to really think through all the 

different things that would have to 

be done and in effect make a gigantic 

PERT [Program Evaluation and Review 

Technique] chart of what it would take 

to go to the moon. We did it on the 

basis of direct descent. I wanted to base 

it on lunar orbit rendezvous but there 

was great hesitation on everybody’s part 

to do that. They said, “We don’t know 

enough about it.” We came up with an 

estimate of $12 billion and presented it 

to Hugh Dryden and Jim. Jim said, “I 

think we ought to put an administrative 

discount on it.”

COHEN: He didn’t think you could get 

that much?

SEAMANS: Not a discount of money. 

He meant discounting our ability to 

think of all the things that needed to 

be done.

COHEN: A discount in reverse.

SEAMANS: He said, “Let’s make it twenty.” 

That’s the number we used forever after.

COHEN: Presumably Cold War 

competition created support for 

that kind of investment.

SEAMANS: Hugh Dryden used to work 

with his counterpart from the Academy 

of Science in the Soviet Union. At 

one time Hugh said, “Couldn’t we 

accomplish more if we worked together 

on some of these things?” The Russians 

said, “Good God, don’t do that. Then we 

won’t be able to get money for anything.” 

We didn’t even know who we were 

dealing with in those days. It turned out 

to be Korolev, a very imaginative guy. 

He got Khrushchev to go along with a 

few shots against the wishes of the army 

of the Soviet Union, which didn’t want 

to see anybody else get funds for 

rocketry. Korolev did amazingly well 

with first the Sputnik, then a dog, 

then a flight around the moon that 

took pictures. Then Gagarin went up. 

Khrushchev could see the benefit of this 

effort on a worldwide basis. We here, 

including Kennedy, could see how we 

were losing on a worldwide basis. After 

Gagarin flew, Congress was mad as hell 

that the Russians had done something 

else ahead of us.

ASK MAGAZINE | 29
COHEN: Which led them to fund Apollo. Do 

you see any equivalent pressure now?

SEAMANS: The Japanese have geared up 

to do some things and the Chinese have, 

but there’s no real driver in the country 

today. I happened to be at NASA a 

couple of days before President Bush 

spoke and recommended that we have a 

program to go first to the moon and then 

to Mars. In all honesty, I was surprised. 

I don’t know whether he could see the 

glory in it or felt that would be a way 

to inspire the younger generation to go 

into science.

COHEN: Has NASA drawn on your 

experience of the earlier moon flights 

in planning the return?

SEAMANS: I was asked by Mike [Griffin] 

to sit in on a multiday review of the 

internal planning at NASA. I was 

impressed with the fact that an awful 

lot of thought and detail work had 

taken place. I was concerned that the 

cost estimates, which were questionable, 

were done by comparison with Apollo. 

The idea was that we were smarter now 

than we were then, so we ought to be 

able to build a capsule and launch 

vehicles for 25 percent less. I felt that the 

dollars were low and at some point there 

wouldn’t be enough money available, 

and Congress would be yelling about 

overruns. We were very fortunate on 

Apollo that we had about the right 

number to work with.

COHEN: Do you think the past experience 

on Apollo won’t save money?

SEAMANS: NASA not only has to go off 

into the future, they’ve still got a major 

program, namely the space station, and 

Mike has reintroduced going back to the 

Hubble. There’s a tremendous amount 

invested in the station—by ourselves, 

the Japanese, the Europeans, and the 

Canadians. We have a responsibility to 

finish it off in reasonable style. Once 

we get the launch vehicles for the lunar 

work, we will presumably also have 

vehicles that can sustain and operate 

the space station. In the near term, the 

four years before the shuttle fleet is 

supposed to be retired, you’ve got a heck 

of a lot you have to do to come close 

to completing the space station while 

at the same time going into the most 

expensive part of the lunar program and 

maybe the Mars program. It’s in those 

initial development years that you really 

have to spend a lot of money. To have 

one program phase out and mesh with 

the new program building up is really a 

difficult problem.

COHEN: Aside from the financial 

concerns, what lessons does Apollo 

offer for the new mission?

SEAMANS: There wasn’t any question 

that most of the Apollo work had to be 

done on contract: it ended up being 90 

or 95 percent. We felt very strongly that 

we could not manage Apollo unless we 

had technical competence within NASA 

to cover any aspect of any problem that 

might arise. Again and again, that proved 

critical. We had a lot of trouble with the 

second stage of the Saturn 2. One day 

when we were doing static testing at a 

cryogenic temperature, it just unzipped 

all the way down because there had been 

one small crack. Between Langley and 

Huntsville, we had as many competent 

people in fracture mechanics as there 

were in the country. I worry that we don’t 

have as much competence within NASA 

today as we did then.

COHEN: How can NASA develop 

and maintain that level of technical 

competence?

SEAMANS: You cannot have good technical 

people on standby doing nothing and 

suddenly put them on the job when 

you have a problem. You have to have 

competent people doing exciting work that 

is not central to the program so they can 

be thrown in to fix the problem even if it 

takes six months. We had a line item that 

was called SRT, Supporting Research and 

Technology, which meant funds in every 

one of our major projects for scientific and 

technical people to look at alternatives—a 

different material, a different gyroscope, 

or whatever. We had to keep fighting for 

that capability with the budget people.

COHEN: Coordinating all the Apollo 

work must have been a tremendous 

challenge.

30 | ASK MAGAZINE
SEAMANS: You needed to have not only the 

competence throughout NASA, you also 

needed to pull it all together. Somebody 

had to take a look at the totality of what 

was going on at NASA. As general 

manager, I was responsible not just for 

Apollo but for all the other projects we 

had. I had to balance the funding and 

the disposition of manpower. I also had 

to decide whether we were going to need 

new facilities. There was a problem down 

at the Cape because every single NASA 

center had its own senior person managing 

his or her project with no single person to 

bring it all together.

COHEN: It must have been a challenge 

even to know what was going on.

SEAMANS: I myself am a great believer in 

monthly project assessments. My view 

was the minority view. Most people felt 

they were a waste of time. It’s the way I 

worked when I was at RCA. From the 

time I got there, we had reviews of all 

major projects on a monthly basis. When 

I got to the air force, I said that was what 

I planned to do. They said, “Let us show 

you how we’ve been doing it.” I went into 

a room, a colonel clicked his heels, and 

some guy stood up and started running 

through a lot of slides. I asked how many 

levels in the air force had reviewed them. 

“Fifteen,” they told me. I said, “There’s 

no point in my being in the room,” and I 

got up and left.

COHEN: Did you think it wasn’t worthwhile 

to hear something that had gone through 

fifteen levels of review because it was 

removed from the people who had done 

the hands-on work?

SEAMANS: If it goes through fifteen levels, 

God knows what you get out at the 

other end. 

COHEN: Were your monthly reviews 

a way of uncovering problems, or 

opportunities to share expertise?

SEAMANS: More the second than the 

first, but you’ve got to have people who 

understand that they can’t hold back 

information. Sometimes there’s something 

you don’t want to tell anybody because 

you’re not doing well on some part of the 

project. You figure you can get it resolved 

in another month. 

COHEN: Engineers want to solve their 

own problems. Were there major 

surprises during the Apollo program?

SEAMANS: Of course the major event 

that had not been anticipated was the 

Apollo 1 fire. Just as I arrived home that 

day, my wife said George Low was on 

the phone. I picked up the phone and 

George said, “They’re dead.” I said, 

[THE APOLLO 1 FIRE] WAS A HORRIBLE WAY to get educated, 

BUT IT WAS A very real EDUCATIONAL experience.

ASK MAGAZINE | 31
“George, slow down. Who’s dead?” 

He had great difficulty talking about 

it. I went tearing over to my office and 

first called Jim Webb to be sure he 

knew and talked to George Mueller. 

We started thinking about what kind 

of group to put together to study the 

accident and make recommendations. 

That was far and away the worst 

experience.

COHEN: Did that tragedy damage 

morale?

SEAMANS: I don’t think so. It had a terrible 

impact on people immediately involved. 

Some people who had to fly into 

Washington for a hearing were in tears all 

the way in. It was a very sad time. [Apollo 

Spacecraft Program Office Manager] Joe 

Shea felt directly responsible, thinking 

if he’d only done something different 

it never would have happened. A lot of 

us felt that way. It was a horrible way 

to get educated, but it was a very real 

educational experience. I can’t say that 

we wouldn’t have succeeded if the fire 

hadn’t happened, but we made important 

changes because of it. We never should 

have had 100 percent oxygen in the 

capsule, but we’d gotten away with it 

with Mercury and Gemini. 

COHEN: You think there would have been 

an accident further down the line?

SEAMANS: Yes, and one that would have 

been more difficult to recover from.

COHEN: Did the fire lead to management 

changes as well as technical changes?

SEAMANS: The biggest one was to bring in 

Boeing as the integration contractor. We 

didn’t have a good internal system. When 

we had an interconnect between, say, a 

capsule and something at Huntsville, 

both parties would sign an agreement. 

We had a very large number of interface 

documents. It was better in the final 

analysis to bring in a company that was 

familiar with integration from their 

airplane experience.

COHEN: Landing on the moon eight years 

after Kennedy announced that goal was 

an amazing accomplishment.

SEAMANS: When George Mueller came 

in, the first thing he did was try to see 

whether we had a chance of going to the 

moon within the decade. He concluded 

that we couldn’t make it the way we were 

going. We launched four Saturn 1s with 

dead upper stages. The first launch was 

successful. We had three more. Basically, 

we were shooting I don’t know how many 

tons of sand into the Atlantic Ocean; we 

were not learning anything more. George 

recommended that we go to all-up systems 

tests. On the very first Saturn V launch, 

we piled everything on. If the first stage 

worked, we were going to get information 

on the second stage, and so on.

COHEN: Am I right in thinking that Wernher 

von Braun was against all-up testing?

SEAMANS: Yes. Wernher practically wept 

with relief the day we launched the 

Saturn V for the first time and everything 

worked. Also, the Apollo itself worked. 

We just didn’t have the LEM aboard 

because it wasn’t available. It was 

incredible. Without that approach, we 

never would have gone to the moon 

within the decade. ●

32 | ASK MAGAZINE
Title

BY 

Intro

MAKING A

How do you hit an object zipping through space 

at 23,000 mph, 268 million miles from Earth, 

and capture what happens after the impact with 

a camera 300 miles away? In 1999, a team of 

more than 250 scientists, engineers, managers, 

and educators set out to meet that challenge and 

discover what exists inside a comet.

Photo Credit: Canada-France-Hawaii Telescope, 2005

ON

SCIENCE

BY RICK GRAMMIER

STORY | ASK MAGAZINE | 33

The Tempel 1 comet appears against a background of stars (with two especially 

bright ones) as it passes in front of the Virgo constellation before impact.
The idea originated in 1978, when Alan Delamere, an engineer 

at Ball Aerospace & Technologies, and Mike Belton, then at the 

National Optical Observatory in Tucson, analyzed data from 

Comet Halley and found the comet was far blacker than they 

had anticipated. “So we asked ourselves: how could this happen?” 

Delamere said. The search for an answer evolved into a proposal 

by Dr. Michael A’Hearn (University of Maryland) to NASA’s 

Discovery Program to hit an active comet and gather data on its 

inner material and crust. When the idea was approved in 1998, 

it became eighth in the Discovery Program’s series of low-cost, 

highly focused space science investigations. It would be the first 

space mission to look beneath the surface of a comet.

A first-of-its-kind mission and tight budget weren’t the 

only challenges awaiting me when I joined the team as project 

manager in January 2004. The launch had already been delayed 

one year. If Tempel 1, the target for Deep Impact, sped beyond 

a reachable orbit from Earth, we would have to wait another five 

and a half years before the comet would circle around again. 

With the project already at risk of being canceled by NASA 

Headquarters due to significant financial overruns, a five-year 

delay was not an option. With one year remaining until Deep 

Impact’s last chance for launch, I faced a project with a fractured 

team and split responsibilities, incomplete development of flight 

avionics hardware and software, and a system-level verification 

and validation program that had not yet begun. 

Contributing Factors

Though the largest visible contributor to the launch delay was 

the development and delivery of the flight avionics, many 

other causes contributed to Deep Impact’s problems. Cultural 

differences between the Jet Propulsion Laboratory (JPL) 

and the system contractor, knowledge and experience gaps 

within the combined team, and an eviscerated independent 

check-and-balance process led to miscommunication and 

misunderstanding. The cultural differences were primarily 

rooted in the distinction between Earth orbiter missions—

using spacecraft architectures similar to those flown previously, 

which the system contractor was very experienced in—and a 

one-of-a-kind, complex planetary mission like Deep Impact. A 

good example of the difference between these types of missions 

is in the complexity of fault protection software required for 

each. An Earth orbiter may simply enter safe mode due to a fault 

occurrence; a planetary spacecraft will try to autonomously 

diagnose the fault and recover from it, entering safe mode only 

as a last resort. The cultural differences resulted in a great deal 

of misinterpretation and mismatched expectations that had to 

be continually recognized and managed. 

The contractor’s lack of deep space mission experience also 

had a significant impact on defining and planning for the flight 

system validation and verification (V&V) program. The contractor 

understood the need to validate that requirements were met for 

34 | ASK MAGAZINE

This spectacular image of comet Tempel 1 was taken 67 seconds after it 

obliterated Deep Impact’s impactor spacecraft. Scattered light from the 

collision saturated the camera’s detector, creating the bright splash seen here. 

Photo Credit: NASA/JPL-Caltech/UMD

WE ... ESTABLISHED AN ALTERNATING, WEEKLY TRAVEL SCHEDULE THAT HAD ONE OF US 

ON SITE AT THE SYSTEM CONTRACTOR FACILITY EVERY WEEK IN ORDER TO ENHANCE 

COMMUNICATION, QUICKLY IDENTIFY AND RESOLVE PROBLEMS, REESTABLISH AN 

INTEGRATED TEAM, AND PROVIDE FOR EFFICIENT KNOWLEDGE TRANSFER.
each component but not the importance of verifying that the 

flight system could operate as intended when all the components 

were assembled. This “test as you fly, fly as you test” approach 

had not yet been implemented on Deep Impact; combined with 

late system maturation, this presented a significant challenge to 

completing the V&V program in time for launch. 

Yet another source of problems was ineffective teaming 

arrangements between JPL and the system contractor. It was 

not always clear which organization had product delivery 

responsibility at each level and life-cycle phase. In some 

instances, the organization with delivery responsibility didn’t 

have the necessary skills or experience to deliver the product. 

This was further complicated by a lack of effective management 

and leadership at multiple levels within the project.

Finally, the project had an inadequate flight operations 

concept and plan. The original mission was designed to have an 

eighteen-month cruise period prior to encountering Tempel 1.

The one-year launch delay reduced the cruise period to six 

months, yet the amount of work that had to be done stayed the 

same; the management team never truly appreciated or analyzed 

the implications of this schedule compression. The operations 

schedule and staffing plan were also inadequate to accommodate 

such a workload, and the system contractor originally given the 

responsibility for conducting mission operations had no prior 

experience in conducting operations of this magnitude and no 

familiarity with the various ground systems and processes that 

were required. Last but not least, earlier budgetary problems 

meant that insufficient staffing and funding were available to 

appropriately plan for the operations and conduct the necessary 

operations team training.

Change in Course

Acknowledging the challenges I had in getting the project on 

track and meeting the launch date, the first thing I did was hire 

an outstanding deputy project manager, Keyur Patel, to help 

share the tremendous workload and grueling travel schedule. 

ASK MAGAZINE | 35

A technician at Astrotech in Titusville, Fla., conducts an illumination test on the 

Deep Impact spacecraft as a final check of performance.

Photo Credit: NASA
Together, we focused on opening all communication channels 

and ensuring our expectations were known and understood by 

all involved. We then established an alternating, weekly travel 

schedule that had one of us on site at the system contractor 

facility every week in order to enhance communication, quickly 

identify and resolve problems, reestablish an integrated team, 

and provide for efficient knowledge transfer. Next, we held 

several working meetings to go over JPL’s flight project practices 

and design principles to communicate expectations regarding 

project implementation and design practices and to bridge 

cultural differences. These had been previously reviewed in 

a piecemeal fashion and were not well understood across the 

entire team in the context of Deep Impact. The real value we 

gained from these meetings was in discussing together what 

each requirement meant and understanding whether each one 

was met or not. Not meeting a particular requirement wasn’t 

necessarily a bad thing, as long as we all understood the risk 

of each exception and whether or not that risk was acceptable. 

Engineers from each subsystem, as well as senior and mid-level 

management, participated in these meetings. 

One lesson I learned early in this process was to check that 

actions the team had agreed to were actually done as intended. I 

would converse with the contractor’s management or engineers 

and think we had an agreement; then I would come back to check 

on it, and find that the way they had worked on it was different 

than I expected. This was another manifestation of our cultural 

differences. I learned that at the end of these conversations the 

best thing to do was to say, “I think we decided this, and you’re 

going to do x, y, and z. What do you think?” 

We also reestablished the mission assurance (MA) rigor that 

had been eviscerated somewhere along the way. A few months 

before I came on board, an MA audit team had been formed 

to determine the state of affairs and provide recommendations. 

Nothing had been done with the recommendations, so we 

formed a Tiger Team of experts to implement them and correct 

the deficiencies. This was a painful and costly process, but you 

have to do the right thing right. It paid big dividends in the end.

We also changed how often the management review process 

occurred. Less than a year from launch we had a huge list of 

issues and risks and a lack of communication; I couldn’t wait 

for a monthly meeting to hear about the issues, so we moved to 

a weekly process. Because there were so many issues to review, 

we didn’t try to solve every issue in each meeting. We frequently 

defined action items and moved on, then revisited the actions 

the following week. I also invited the NASA Headquarters 

program executive and program office to call in to the meetings 

so they were aware of the issues and able to witness the progress 

being made. This helped keep the team focused on priorities 

from week to week while ensuring the management team was 

aware of the “big picture.”

Once the team found a better way to communicate, Keyur 

and I focused on helping them work better together as well. 

I organized the product teams—by component, subsystem, 

or some other deliverable—to take advantage of flight project 

experience and specific product knowledge, combining JPL and 

contractor members within teams. We also provided continuous 

management and engineering presence at the contractor site, 

which helped improve communication through continuous 

36 | ASK MAGAZINE

I LEARNED THAT ... THE BEST THING TO 

DO WAS TO SAY, “I THINK WE DECIDED 

THIS, AND YOU’RE GOING TO DO X, Y, 

AND Z. WHAT DO YOU THINK?”
interaction. This enabled the teams to more quickly share 

knowledge and identify and resolve problems together. Over 

time, this directly contributed to re-integrating a fractured 

team, building esprit de corps, and establishing an appreciation 

for team members’ expertise and dedication to getting the job 

done. Make no mistake about this: the teams on both sides of 

the Rockies were very smart, very dedicated individuals. The 

challenge here was to provide the team with the resources, tools, 

experience, and leadership to get the job done. 

Mitigating the Impact

These changes allowed Deep Impact to launch on schedule on 

January 12, 2005, but the problems were far from over once 

the mission was headed for comet Tempel 1. At launch, Deep 

Impact still had not passed a test encounter with the comet. 

Contingency plans for the encounter had also not yet been 

identified, developed, or tested. The operations team had been 

certified and trained but were still green in terms of hands-on 

experience. In short, too much work remained for the current 

size of the operations team.

To address this shortage, we retained a majority of the 

development team and continued to use the processes that 

had so successfully gotten us to launch. The daily operations 

were jam packed from day one, and we increased the staff 

tremendously in order to get the work done. We also formed an 

Encounter Working Group (EWG) to complete development 

and verification of the encounter plans, sequences, and 

contingency operations. This team was effectively “fire walled” 

from the day-to-day operations team so it could concentrate on 

the encounter development and V&V activities. This did cause 

some issues with bench depth and knowledge transfer to the 

daily operations team, but it was absolutely necessary in order to 

complete the tremendous amount of work in such a short time. 

Together we generated an elaborate decision tree, identifying 

every contingency that might prevent success. For example, 

if the small impactor had a failure prior to release, we had a 

contingency plan to either delay the release with a different 

maneuver sequence or target the entire flyby spacecraft (with 

impactor attached) for collision with the comet. We planned 

how to address each possible failure in detail so we would be 

prepared to salvage the science and mission under as many 

conditions as possible. We also conducted three risk reviews with 

the EWG and senior management to alert us to other issues or 

solutions we may have overlooked.

Big Bang

After an intense year of preparation and another six months of 

around-the-clock operations, the larger flyby spacecraft released 

its small impactor and maneuvered away from the impending 

collision to capture pictures of the impact. On July 4, 2005, 

Deep Impact successfully collided with comet Tempel 1—with 

no failures or surprises. The images of the approach, the impact, 

and its aftermath were relayed to Earth and will be analyzed 

and combined with data from other comet missions, leading to 

a better understanding of both the solar system’s formation and 

implications of comets colliding with Earth. Creating a culture 

of open and honest communication and rearranging teams to 

ensure everyone’s strengths were used wisely helped make this 

groundbreaking mission a comet-shattering success. ●

RICK GRAMMIER is currently the project manager for the Juno 

mission in the New Frontiers Program. His experience includes 

previous roles as project manager for Deep Impact, deputy director 

for Planetary Flight Projects at JPL, manager of JPL’s Office of 

Mission Assurance, and project engineer and deputy project 

manager for Stardust. He has a BS in engineering from the United 

States Military Academy and an MS in electrical and computer 

engineering from California State Polytechnic University.

At Ball Aerospace in Boulder, Colo., the infrared (IR) spectrometer for the Deep 

Impact flyby spacecraft is inspected in the instrument assembly area in the Fisher 

Photo Credit: NASAAssembly building clean room.

ASK MAGAZINE | 37
Sustaining NASA’s 

Safety Culture Shift 

BY DAVID G. ROGERS 

It’s been more than twelve years since I flew planes on and off aircraft carriers. One flight in particular 

literally changed my life. I was the aircraft commander and was flying with my squadron’s executive 

officer, who was two pay grades above me but had limited experience flying this particular aircraft 

and landing on ships. To maintain proficiency requirements, he was to get us aboard that day. 

During the approach, he got low and did not respond to the landing signal officer’s call for power. 

Then he got caught in a downdraft and got really low. The landing signal officer screamed for 

power then called to wave off the approach. When my XO was slow to respond, I was forced to take 

control of the aircraft, execute the wave-off, and get us aboard.

In Firing Room 1 at Kennedy Space Center, shuttle launch team members put the shuttle system through an End-to-End (ETE) Mission Management Team launch 

simulation. The ETE transitioned to the Johnson Space Center (JSC) for the flight portion of the simulation, with the STS-114 crew in a simulator at JSC. Such 

simulations are common before a launch to keep the shuttle launch team sharp and ready for liftoff.

Photo Credit: Kennedy Space Center

38 | ASK MAGAZINE | INSIGHT
After looking at the landing video, I was shocked to learn that 

we were dangerously close to crashing into the back of the ship. 

In the thirty minutes that followed our landing, I demanded 

a crew debrief that included a brutally honest self-assessment 

of my performance. I asked myself, “What did I do that led 

to the ‘success’ of the mission?” Then I asked what I did that 

contributed to nearly losing the lives of my fellow crewmembers 

and myself in the process. What I did right was take control 

when it was required. What I did wrong was wait as long as I 

did to take action. Although the XO was more senior and we 

got along very well, I did not assess his skill level appropriately. I 

put too much stock in his pay grade and position and forgot to 

consider that his experience with this aircraft and flying aboard 

aircraft carriers was very limited. I should have been just as 

cautious as I was with a pilot fresh out of training. I learned that 

reflecting on problems and near misses is both an individual 

and a team responsibility, which can help build excellence in 

both. NASA has begun incorporating this best practice in some 

areas, but it could do more. 

Understanding the Real Problem

Let’s suppose that an airline pilot fails to acquire an updated 

weather forecast at his destination. He is behind schedule, and 

his passengers will miss their connecting flights if he delays much 

longer, which will mean a financial penalty for the company. 

Approaching his destination, he notices that some other, smaller 

aircraft are diverting to fields with better weather. He sees the 

approaching storm ahead at the end of the runway but still elects 

to land. On his approach he encounters some dangerous wind 

conditions but manages to get the plane on the ground and taxis 

to the gate. The fact that the outcome was favorable, however, 

does not mean that the pilot made the correct decision. 

Suppose that pilot continues to operate in this manner for 

years and manages to land successfully each time. While the 

pilot’s experience level is high, we can see that his expertise level 

is very low. He has gained a lot of experience doing the wrong 

thing. His behavior illustrates the term “an accident waiting 

to happen.” Experience does not automatically translate to 

expertise. Experience provides us with a learning opportunity, 

but expertise is only acquired after we take time to evaluate our 

performance and apply corrections to improve and reinforce the 

skills that contributed to success.

Like the pilot, our NASA teams need to examine their 

experience rigorously in order to learn from it. Studies over 

the past twenty-five years have consistently reported that 

between 70 and 80 percent of accidents within high-risk and 

high-reliability organizations can be attributed to human 

performance errors. Challenger and Columbia represent the most 

severe, but certainly not all, of NASA’s human performance 

errors. The primary reason why we repeated the same mistakes 

is that we corrected some of the symptoms, but we did not 

effectively address the greatest contributing cause of our errors: 

our organizational culture.

Since human error cannot be completely eliminated, the 

trouble lies with a prevailing organizational culture that allows 

errors to go unchecked. Effective team skills and behaviors give 

us the tools necessary for avoiding mistakes, but our willingness 

and commitment to use those tools and continually sharpen 

them through constant evaluation and reevaluation is what has 

the largest impact on managing human error and developing 

exceptional teams. Without this, we as individuals, teams, 

and an organization are likely to slowly drift back to the same 

behaviors that created the culture that allowed critical errors 

to occur in the past. This is where we missed our opportunity 

after Challenger. We “fixed” many weaknesses and processes 

but never put in place a long-term cultural shift solution that 

continually improves how well we communicate and make 

decisions as a collective team.

A Case Where We’re Getting It Right

The Space Shuttle Program (SSP) Mission Management Team 

(MMT) is a recent example of a team that has embraced an 

EFFECTIVE TEAM SKILLS AND BEHAVIORS GIVE US THE TOOLS NECESSARY FOR 

AVOIDING MISTAKES, BUT OUR WILLINGNESS AND COMMITMENT TO USE THOSE 

TOOLS AND CONTINUALLY SHARPEN THEM THROUGH CONSTANT EVALUATION AND 

REEVALUATION IS WHAT HAS THE LARGEST IMPACT ON MANAGING HUMAN ERROR AND 

DEVELOPING EXCEPTIONAL TEAMS.

ASK MAGAZINE | 39
attitude that has brought about a definite cultural change within 

the NASA team at large. As a result of the Columbia Accident 

Investigation Board’s recommendations, the MMT began an 

intensive training program that included initial and yearly 

certification requirements for all MMT members. For the most 

part, people were aware of the skills and behaviors required 

of them; what they lacked were ways to develop and sharpen 

them. After two and a half years of senior program management 

leadership, team training, self-study, and numerous MMTspecific simulations, the MMT that served during STS-114 

represented a team far superior to what had been in place for 

more than nineteen years. 

After STS-114, the SSP deputy manager began to look 

at ways to build upon the team’s marked improvement. He 

recognized that the team training the MMT was receiving 

could be enhanced if it used their own real-world examples 

to illustrate the training concepts. By tapping into NASA’s 

own internal resources and talents, key Johnson Space Center 

Safety and Mission Assurance (JSC S&MA) personnel were 

asked to refine the training to better meet the specific needs 

of the MMT membership. The MMT team training is now 

taught by JSC S&MA and uses shuttle MMT examples taken 

from MMT training simulations and past shuttle flights. This 

training restructuring also provided the opportunity to include 

more effective team debriefing and individual team member 

self-assessment skills.

A turning point occurred when the chair of the MMT 

established his expectations during an MMT debriefing. This 

wasn’t done by memo alone, but through mentorship and superior 

leadership—by modeling the behaviors he expected his team 

members to emulate. As a result of this action, MMT debriefs 

are consistently characterized as being brutally honest and open, 

with all egos put aside both from a team perspective and in each 

team member’s assessment of his or her own performance. 

The impact of these measures has been profound. The 

shuttle MMT membership has shown a steadfast commitment 

to implementing continual improvement. They have adopted 

a learning organization mentality where every decision and 

team interaction, whether it occurs during a simulation or 

actual mission, represents opportunities to learn and improve 

both as a team and as individuals. They are especially sensitive 

to identifying areas where recent successes could lead to 

complacency. Dissenting opinions—viewed as alternative 

solutions among the team—are encouraged and actively sought. 

Recently, the shuttle MMT has taken a fresh approach to 

lessons learned. Lessons learned databases capture the “historical 

record” of errors, but they rarely raise the level of awareness 

sufficiently to prevent the same problems from reoccurring. 

Team debriefs and self-assessments work better because they 

are continually reviewed and give team members a chance to 

take accountability and actively implement specific actions for 

WE ARE ALL STAKEHOLDERS IN 

EFFECTIVELY MANAGING HUMAN 

ERROR. TO GAIN TEAM EXPERTISE, IT IS 

ESSENTIAL—WHETHER AFTER A MISSION 

OR A PROGRAM MILESTONE—TO GATHER 

EVERYONE TOGETHER AND EVALUATE 

THE TEAM’S PERFORMANCE AND HAVE 

EACH MEMBER ARTICULATE HIS OR HER 

SELF-ASSESSMENT. 

40 | ASK MAGAZINE
Space Shuttle Mission Management Team members take notes during an eight-day simulation at Johnson Space Center in March 2005, preparing for Return-to-Flight 

mission STS-114. 

Photo Credit: NASA

improvement. In order to keep lessons from being forgotten, 

the MMT conducts a pre-brief prior to its next event to remind 

the team of previous lessons learned and develop improvement 

strategies in order to keep from “running over the same land 

mines.” This concept is not new to us. It is the very essence of 

a continual improvement process. What makes this different is 

that the MMT is making this model a living, breathing process 

for continual improvement.

Continually Learn from Past Effort

We are all stakeholders in effectively managing human error. To 

gain team expertise, it is essential—whether after a mission or 

a program milestone—to gather everyone together and evaluate 

the team’s performance and have each member articulate his or 

her self-assessment. This critical and often overlooked step is, in 

my opinion, what separates the team of experts from the expert 

team. Whether at the program, project, or functional level, these 

strategies apply to all team environments. 

In order to effect a true cultural change, we must adopt a 

learning organization mind-set. We must never be satisfied with 

our current level of performance. We must always be asking 

ourselves, “How can we improve?” Expert teams recognize 

that they are only as sharp as their last decision. Achieving and 

sustaining a positive team culture and, in turn, organizational 

safety culture is not a discrete event but a journey. We must 

never let our guard down and allow ourselves to be fooled into 

believing that we have gotten as good as we can get. 

In these past few years, I have been pleased to witness 

these behaviors spill over to other boards, panels, and meetings 

across NASA, such as the past three flight readiness reviews for 

STS-121, 115, and 116; recent Shuttle Program Requirements 

Control Board meetings; SSP System Integration Control 

Board meetings; and also at recent Flight Techniques Panel 

meetings. Many in the NASA family are committed to not only 

sustaining but continually improving our safety culture in the 

midst of the current dynamic and challenging environment. 

It personally gives me a great sense of pride to be part of an 

outstanding organization that has demonstrated the integrity 

and moral courage to commit itself to doing all that is humanly 

possible to truly learn from our past mistakes. ●

DAVID G. ROGERS has served as a naval aviator and a shuttle guidance 

and control/propulsion instructor for twenty years. Since 2004, he has 

been a senior safety engineer with Science Applications International 

Corporation (SAIC) in the Shuttle Safety & Mission Assurance 

Directorate at Johnson Space Center. In addition to his technical 

contribution, much of his work centers on organizational culture, team 

dynamics, and developing methods to optimize team performance. 

He has recently spearheaded the effort to bring these techniques to 

NASA’s SSP MMT membership. david.g.rogers@nasa.gov

ASK MAGAZINE | 41
The Future Air Traffic Management Concepts Evaluation Tool (FACET), a unique software 

program used to model and predict air traffic trajectories both for research and real-time use, 

received NASA’s Software of the Year award for 2006. It is currently in use at more than fifty 

universities and licensed to more than 4,000 users in the FAA, at major U.S. airlines, and 

at air traffic control centers across the nation. FACET’s unique capabilities as a research and 

development tool will help guide development of the next-generation air transportation system.

Featured Invention: 

Future Air Traffic Management Concepts 

Evaluation Tool

BY JOHANNA SCHULTZ 

42 | ASK MAGAZINE | STORY

A FACET snapshot of air traffic over the United States on July 10, 2006, at 2:45 p.m. EST.

Image Credit: Ames Research Center
Human interaction was the sine qua non of the creation of 

FACET by researchers at Ames Research Center. “It’s fairly 

straightforward to develop tools and functionalities; the 

difficulty is in making these tools useful to the people who 

actually do the job,” says Dr. Banavar Sridhar, automation 

concepts researcher and project manager for FACET. Sridhar 

and his team discovered that the end user’s input was the 

key to devising FACET’s valuable innovative features. 

“One of the biggest surprises to me working on this 

project was how difficult it was to translate ideas from a research 

institution into actual usage. Often, what happens is that you 

make assumptions [based on theoretical calculations] that 

are hard to translate into the field,” Sridhar said. “You can figure 

out the algorithm, but it just isn’t going to work if you design it 

without the help of those who actually use it.”

While the concept may seem basic, this “listen to the 

consumer” approach took Sridhar and his team’s research to 

a new level. In fact, through extensive discussions with end 

users—air traffic controllers, dispatchers, and airline pilots—

FACET went from a fairly straightforward research modeling 

tool to a real-time air traffic control tool that currently helps 

monitor air traffic in skies across the country.

Sridhar, together with University of California–Santa Cruz 

scientist Dr. Kapil Sheth and a team at Ames, was looking 

at the issue of air traffic control and experimenting with 

ways to measure a controller’s workload, or the number of 

aircraft that one controller at a federal air traffic control center 

can monitor at any one time. Initially, the team focused on 

an air traffic control center in Ft. Worth, Tex.—near NASA’s 

Houston center—but Sridhar quickly realized that the tool 

would have to be more comprehensive than he’d initially 

conceived. “In order to know how busy an air traffic 

controller in Ft. Worth would be an hour from now, we had 

to know where the aircraft were coming from,” Sridhar recalls. 

“Although we were interested at first in one small location, our 

research problem depended on everything around it, so we 

decided to build a tool that could see and understand air traffic 

control all over the United States.” 

“Initially, we wanted to explore different futuristic concepts 

of air traffic management, but we found that in order to explore 

these concepts, a certain amount of realism was necessary to 

ensure that whatever we were doing was coming out of an 

environment connected to reality,” explains Sheth. “What we 

discovered was that people actually valued that a lot more.”

The team began approaching air traffic controllers and 

those involved in airline logistics, proposing functionalities and 

asking for input on additional features. “We had to become 

more customer-oriented as we moved from the research lab into 

an operational environment,” says Ames software developer 

Shon Grabbe. With every conversation, the team realized that 

additional functionalities and modifications were necessary. 

In early discussions with users, the team realized that speed 

and portability were key capabilities missing from contemporary 

air traffic control tools. “Our goal was to think outside the box 

and come up with a safer system to accommodate more traffic 

than it does today,” explains Ames researcher Dr. Karl Bilimoria. 

“We thought, rather than have air traffic controllers separate the 

traffic, which is very workload intensive and results in a lot of 

bottlenecks, let’s explore a future concept in which pilots do it 

themselves.” Pilots currently work with their airlines’ dispatchers 

before take-off to generate efficient flight plans consistent with 

airline policy, FAA regulations, weather, and traffic conditions 

and to determine the appropriate fuel load.

“We wanted to answer some basic research questions 

on the feasibility of going from centralized control authority 

(current operations) to distributed control authority (possible 

operations in the future, say twenty years from now),” 

explains Bilimoria. “We are not suggesting that FACET 

be put in the cockpit as an operational tool to assist pilots 

in separating themselves from other traffic. However, it is 

certainly possible to use FACET as a research test-bed for 

developing procedures and algorithms that would make 

ASK MAGAZINE | 43
their way to a future air traffic management system featuring 

airborne self-separation.”

The team’s flexibility and commitment to users translated 

into an entirely new air traffic control system that has been 

commercially available through the company Flight Explorer 

since February 2006. FACET models the National Airspace 

System and enables planning of traffic flows at the national 

level through four separate modes of operation: playback mode, 

to depict and analyze historical data; simulation mode, for 

predicting the evolution of traffic data; hybrid mode, using 

historical data for playing out various “what if” scenarios; and 

live mode, for real-time display and analysis of actual traffic data. 

FACET is unique in that it is both a research and an operational 

tool; researchers at more than sixty universities across the 

country are currently using several of FACET’s capabilities, and 

pilots, airline dispatchers, and air traffic managers at the FAA 

and several major airline carriers in both the United States and 

Australia use FACET to make minute-by-minute decisions on 

air traffic flows and routing. 

Unlike earlier systems, FACET can project air traffic an 

hour or more ahead. “When a controller separates traffic in a 

sector, he is looking at something that may happen within the 

next five to fifteen minutes,” Sridhar explains. “FACET is used 

to examine what happens to the system in the next one hour to 

several hours.” 

One airline dispatcher explains the software’s unique 

benefits. “FACET lets me test a reroute, put that into the 

equation, and predict what would happen. It also helps me 

identify a list of flights that are going to be impacted by some 

constraint and suggests an optimized solution that affects the 

minimum number of flights, or affects a larger set of flights 

the minimum amount. [FACET] auto-suggests not just one 

reroute, but several different reroute options to shortcut the 

dispatcher to a good solution. It is still my place, though, to 

decide [whether] to move them.”

Bilimoria says, “While our primary goal was always to 

contribute to NASA’s research, we found and seized those 

opportunities to go beyond, to get some practical implications 

outside NASA. Software is a very useful tool, but it’s humans 

that are ultimately there operating it and making the decisions. 

It’s the software’s job to help people make better, more informed 

decisions. We always kept the user in mind, and in the end that 

really paid off.” ●

UNLIKE EARLIER SYSTEMS, FACET CAN 

PROJECT AIR TRAFFIC AN HOUR OR 

MORE AHEAD. “WHEN A CONTROLLER 

SEPARATES TRAFFIC IN A SECTOR, HE 

IS LOOKING AT SOMETHING THAT MAY 

HAPPEN WITHIN THE NEXT FIVE TO 

FIFTEEN MINUTES,” SRIDHAR EXPLAINS. 

“FACET IS USED TO EXAMINE WHAT 

HAPPENS TO THE SYSTEM IN THE NEXT 

ONE HOUR TO SEVERAL HOURS.” 

44 | ASK MAGAZINE
Creating the Future

BY JOHN McCREIGHT 

Major organizational change—not incremental improvements, but dramatic, sea-change shifts to 

pursue ambitious new goals and meet major challenges—is hard. Our consulting firm has helped 

government agencies, corporations, and other organizations evaluate and carry out plans for largescale strategic change and learned some important lessons in the process.

INSIGHT | ASK MAGAZINE | 45
• Organizations only achieve strategic goals if their members 

understand them, and why they are the goals that matter.

• Members of the organization need to understand their 

particular roles and responsibilities during the journey to 

the desired future state.

• Understanding and commitment are not the same; change 

leaders must foster both.

• The change strategy must be a compelling story, not just 

a plan.

• To get where you’re going, you have to understand where 

you are now, the change timeline, and what end-game 

success will look like.

Most of this seems obvious. Of course people need to 

understand the goal and the plan for reaching it. Leaders of change 

efforts point to speeches by the CEO and piles of documents 

to show that they have informed their organizations about the 

plans. They will note that their senior management teams have 

signed on to the plan—sometimes literally, by appending their 

signatures to the change document, like signers of the Declaration 

of Independence, committing themselves to its principles.

But making speeches and publishing documents do not 

mean that the content has been understood and embraced—

nor that the often dramatic implications of proposed change 

are understood. Communication is more than documents and 

pronouncements; it is a dynamic process that includes as much 

listening as talking. Understanding comes from dialogue—

question, response, and comment—that brings what you mean 

and what your audience thinks you mean in line with one 

another. In addition, you need to enrich what you think with 

what your audience knows. This dialogue builds the trust and 

respect that can lead from understanding to committed action.

The 3 x 5 Card Test

Soon after an acquaintance of ours became the head of a 

well-regarded educational institution, we paid him a visit to 

congratulate him and to tell him that we would be happy to 

apply our competence designing and managing strategic change 

to his new organization, if he thought that would be useful.

“I respect your abilities,” he said, “but I don’t think I’ll 

need your services. We already have a strategy.”

He showed us a handsomely printed binder of materials 

that laid out the plan, complete with mission statement and a 

detailed list of objectives. It was signed by all the organization’s 

department heads.

A few months later, he called. It would be an exaggeration 

to say we were waiting for the call, but it didn’t exactly come 

as a surprise.

“We’re making no progress on our strategy,” he said. “I 

don’t understand why nothing is happening. Would you come 

and take a look?”

The first thing we did was analyze the strategy materials 

and develop hypotheses on change challenges. We then 

interviewed the heads of departments, asking them to help us 

see the organization through their eyes. We asked them to tell 

us what they thought it could and should be doing differently 

in the future, and when and how. 

We learned the most from what they didn’t say. No one 

mentioned the strategic plan. It was simply not a part of their 

thinking about their current work or what they hoped to do 

in the future. When, finally, we asked them directly about 

the strategic plan, they admitted that they were aware of the 

existence of what several referred to as “the leader’s strategy.” 

Clearly, it was not theirs.

We brought the leader and the department heads together 

for a meeting and passed out 3 x 5 inch cards to everyone. 

We asked each department head to describe the organization’s 

strategy on one side of the card, and their individual and 

department’s role in carrying it out on the other. Descriptions 

of the strategy were all over the map; explanations of individual 

and department roles in carrying it out were similar only in 

their vagueness.

AN EFFECTIVE PLAN FOR CHANGE IS NOT JUST A BLUEPRINT; IT IS A STORY THAT MUST 

CONVINCE AND INSPIRE THE PEOPLE WHO HEAR IT.

46 | ASK MAGAZINE
Part of the point of this exercise was to dramatize the extent 

to which the strategy, painstakingly described in a document 

signed by all present, had not been communicated—not 

absorbed by the people who were expected to carry it out—

and to show that those leaders had not “signed on” to the plan, 

though their signatures were on it.

Communication and Commitment

That 3 x 5 inch card meeting was the beginning of real 

communication. It began the dialogue about what the strategy 

should be, why it mattered, and what roles the departments 

and department heads should play in carrying it out. Together, 

they developed a change timeline and measurable milestones of 

success. Understanding and commitment grew out of a process 

that was both intellectual and social. The back-and-forth 

discussion—the questions, responses, suggestions, arguments—

clarified the leader’s plans and brought them to life. It also 

changed them as department heads reviewed the plan in light of 

their individual experience and the needs and aims of the groups 

they led. The process of being heard and involved, not dictated to, 

began the trust building that genuine commitment requires.

Telling a Story About the Future

Engaging the people who will direct the work in the planning 

and implementation process is essential to understanding and 

commitment. So, of course, is the quality of the strategic plan. 

It must be ambitious enough to inspire action but practical 

enough to be possible—a stretch, but energizing and really

important. It must be compellingly described. It must tell a 

story about today and the future that people can enter into and 

re-tell to others, including their families, to inspire action.

A technology client we partnered with had spent hundreds 

of thousands of dollars developing its plan for the future. A 

group of nearly sixty executives worked off site for ninety days 

to write the strategy document. As in the case of the educational 

institution, the result was physically impressive: a six-inch-thick 

binder, professionally written, designed, and published, with 

beautiful color graphics. The change strategy focused on five 

areas: new talent, improved governance, new technologies, 

improved technology infrastructure, and new processes for 

handling the massive quantities of information they expected. 

Goals and milestones were laid out in impressive detail. Yet, 

even the organization’s leaders, who had invested so much time 

and effort in the plan, were uneasy. They asked for our help 

before they presented it to their organization’s funders.

We spent weeks examining the plan and conducting interviews 

with senior executives to get their view of the strategy. Not 

surprisingly, the plan was less well understood than the executives 

who hired us hoped, and support for it—in terms of passion, and 

funding and talent commitments—was even weaker.

A chief problem, we quickly saw, was that the plan told no 

compelling story about what the proposed changes would achieve. 

It was full of painstaking detail about what would happen in 

different departments and units, about structural changes and 

new technologies to be purchased. Missing, though, was any 

vivid sense of customer needs and what competitive threats and 

important opportunities the plan was meant to address. The 

plan was all about what would change; it largely ignored why

change was necessary and why it would be worth the effort. It 

was full of dry details and abstract generalities about the future, 

but it never painted a vivid picture of what working in the future 

organization would look and feel like. Importantly, the plans 

were less than honest about the pain such change would cause.

There were problems with details of the plan—critical phases 

without sufficient funding, lack of clarity about how some phases 

supported others, lack of measurable milestones—but these 

weaknesses were less important than the lack of a compelling 

answer to the question, “Why does this matter?” An effective 

plan for change is not just a blueprint; it is a story that must 

convince and inspire the people who hear it. Like most good 

stories, it must have a hero. The crisis, challenge, or opportunity 

the organization is facing has to be vividly described, along with 

ASK MAGAZINE | 47
the intelligence, creativity, tenacity, and other resources required 

to overcome the threat and triumph in the end.

Triangulating on Truth

To lead organizations to a desired future, everyone critical to 

success needs to understand current truth—the resources you 

can count on and the weaknesses holding you back. We call 

the process of developing that understanding “triangulating 

on truth,” because you must look at the organization from 

a variety of perspectives to learn the truth about it. No one 

person or group has the whole picture. 

We interview dozens, and sometimes hundreds, of people 

to develop a full picture of an organization. Interviews include 

employees at all levels, plus investors, customers, partners, suppliers, 

and, often, competitors. We insist on the confidentiality of all those 

conversations to encourage people to say what they believe, not 

what they think their bosses, customers, or others want to hear.

Even without the fear of retribution, many people want to put 

a positive face on things, to emphasize the good and downplay the 

bad, and not talk about unrealized opportunities. But ignoring 

hard truths only prevents or delays dealing with them. 

Years ago, when we consulted for the police department of a 

major metropolitan area that suffered from a high crime rate, we 

rode along in squad cars on eight-hour shifts to understand what 

police officers really did and why. Riding with vice officers during 

one evening shift, we realized that everything we were seeing—

the drug busts, the roundup of prostitutes—had been carefully 

choreographed to make the point that more officers were needed. 

Though well-intentioned, this “show” threatened to undermine our 

consulting analysis: If we didn’t see the real problems, we wouldn’t 

be able to offer advice on solving them. To get to the reality, we 

sometimes stayed on for the next eight-hour shift, which had not 

been planned in advance. Sometimes we switched from the officer 

we were officially shadowing to another officer, who happened to 

stop at the same coffee shop for a break at the same time.

Triangulating on truth also means getting the perspective of 

people outside the organization. During that same engagement, 

we interviewed a local newspaper reporter who was disparaging 

the mayor’s efforts to improve the department’s performance. Her 

criticism included important hard truths the city needed to hear. We 

also interviewed a 22-year-old burglar in his jail cell to understand 

why crime was his career choice. In a city with limited employment 

opportunities for young men without a high school diploma, the 

fact that a burglar had a one-in-ten chance of being arrested, and 

approximately a one-in-a-hundred chance of being convicted, made 

burglary a rational career-choice gamble. We learned from him that 

discouraging crime depends on changing those odds, which led to 

recommendations that needed to get to high-crime areas more 

quickly and improve case building to increase conviction rates.

The human tendency to tell mainly the good news is matched 

by an equally powerful tendency to focus on the evidence that 

supports our beliefs. Successfully triangulating on truth means 

not only noticing contrary, uncomfortable, or minority views 

but paying special attention to them and giving them particular 

respect. Like a good scientist, change leaders should look for 

disconfirmation of their hypotheses more energetically than for 

support. We have seen change efforts fail because leaders clung 

to the good news and ignored the warning signs. The first and 

biggest step in solving problems is to recognize them. 

Major change is hard. To achieve it, change leaders need 

determination, patience, trust, tenacity, and good listening 

skills. They need a compelling goal and the understanding 

and engagement of the people who will make it happen. The 

commitment to seek and see the whole truth about an organization 

is essential for success in large-scale, sustainable change. ●

JOHN McCREIGHT has been a management consultant 

since 1968, following six years as a management systems 

program manager with Apollo and Minuteman contractors. 

His consulting focuses on large-scale strategic change. 

jmc@implementstrategy.com

48 | ASK MAGAZINE
CROSSING 

BOUNDARIES 

TO BUILD CHANGE

BY ADRIAN WOLFBERG AND JOHN T. O’CONNOR

On May 18, 2006, a small crowd in a Bolling Air Force Base auditorium in Washington, D.C., 

helped launch a new era at the Defense Intelligence Agency (DIA). Lieutenant General Michael D. 

Maples, the director of the DIA, walked up to the microphone and said, “I am here to hear your 

ideas.” Since that day, nearly a hundred volunteers from across the DIA have stepped forward first to 

share their ideas for how to improve the agency then to take the risks needed to act on those ideas. 

STORY | ASK MAGAZINE | 49
In an organizational culture that has long rewarded quiet 

adherence to a rigid command-and-control style, coming 

forward in an open forum to tell the director that problems 

need to be fixed is a major development. This program, called 

“Crossing Boundaries,” takes on the challenge of adopting 

the changes necessary to make the intelligence community 

more collaborative, imaginative, and open to new ideas. DIA’s 

experience offers lessons for innovation and organizational change 

that others may appreciate and use.

The success of the initiative has at least three critical sources:

• Consistent, visible support from senior leaders

• Focusing efforts on the “seams” between organizations, 

the potential points of connection and collaboration

• Encouraging the formation of networks of like-minded 

people to bring about change

The Government Culture

With more than 8,000 employees located at major sites in 

Washington, Maryland, Alabama, and other sites around 

the world, the DIA supports U.S. armed forces operations 

by providing critical intelligence collection and analysis for 

customers in the U.S. Department of Defense. DIA includes 

both active military and civilian personnel. 

Readers familiar with government agencies will recognize 

the DIA culture. Separate directorates—each managed by a 

deputy director who reports to the agency head—oversee human 

intelligence collection (Directorate for Human Intelligence, or 

DH), intelligence analysis (Directorate for Analysis, or DI), the 

complex discipline of measurement and signatures intelligence 

(Directorate for MASINT and Technical Collection, or DT), 

and other activities. The directorates formerly functioned as 

separate entities. Intelligence analysts in the DI knew little about 

how MASINT capabilities of DT might help them in their 

mission. Interactions were traditionally controlled by top-down 

decision making that protected and controlled information and 

stifled creativity and new approaches suggested by workinglevel DIA employees. There was little movement of employees, 

knowledge, or best practices among directorates. 

Changing the Culture

LTG Maples inherited an agency that was already changing, 

becoming a learning organization, and seeking knowledge 

through collaboration. One of the operating principles behind 

the DIA’s change strategy is to create a network of volunteers who 

are committed to improving mission performance by helping 

people collaborate and share knowledge more effectively. The 

DIA created the DIA Knowledge Lab to support these networks 

and drive adoption of new practices that would improve mission 

performance by enabling employees to collaborate, share, think, 

and imagine with more freedom than before. 

Crossing Boundaries

At the first Crossing Boundaries meeting on May 18, 2006, 

DIA employees volunteered ideas that included new methods 

of analyzing human networks, developing increased sensitivity 

to cultural differences, and helping people break down complex 

problems into smaller, solvable pieces. Maples and a small 

panel discussed each idea candidly, and he offered support and 

resources to help the volunteers move forward to explore their 

ideas further and potentially put them into practice. At the 

conclusion of the hour, Maples thanked the audience for being 

a part of Crossing Boundaries. Then the real work began.

A relatively new employee in the Directorate for Information 

Management proposed the idea of breaking down problems 

into smaller pieces. Working with the Knowledge Lab staff, she 

crafted her idea into a concept that could be tested in a pilot 

project. (Knowledge Lab pilots are limited-duration tests of 

ideas designed to determine whether they can provide value to 

the agency). Over a period of months, she refined her idea and 

worked with her home office, Enterprise Solution Management 

(ESM), and the Knowledge Lab to fashion a cooperative 

pilot (now called “Small Victories”). She negotiated with her 

management, recruited interested employees, and negotiated 

agreement among all parties. She began her Small Victories pilot 

50 | ASK MAGAZINE
in November 2006, engaging a team of ESM project managers 

to develop, coordinate, and deploy guidelines for ESM project 

management. The pilot participants will use a collaborative 

leadership model drawn from the health care profession as an 

organizing principle. The Knowledge Lab will evaluate the 

process, behavioral changes, and outcomes accomplished by the 

pilot team. 

Ideas and Changes

Since May 2006, DIA employees have volunteered eighty-eight 

new ideas to Crossing Boundaries. They have shared them with 

Maples and other attendees in open meetings that include a 

number of other senior DIA leaders who regularly contribute 

to these discussions. A number of Crossing Boundaries 

ideas have led directly to new actions by the agency, including 

the following:

• Creating a new award program to recognize employees 

who demonstrate significant collaborative behavior

• Reinstating random security checks at building entrances 

to raise the level of employee vigilance about protecting 

sensitive information

• Holding a “Leadership Day” to provide training and 

educational opportunities to help employees at all levels 

improve their leadership skills

• Bringing in adjunct faculty to improve training 

opportunities at the agency’s Joint Military Intelligence 

Training Center

• Investigating ways to improve the agency’s antiquated, 

paper-intensive time-and-attendance reporting system

• Reviewing the process for allocating office spaces in the 

agency to develop a more efficient and effective space 

management system

Proposals continue to come into Crossing Boundaries via 

e-mail, the internal Web site, and LTG Maples’ forum. 

A Learning Organization

Crossing Boundaries increases trust in the agency’s leaders, 

demonstrates that the agency values knowledge wherever it 

resides, and encourages employees to take risks and practice 

analyzing and solving complicated problems.

Increase Trust 

In November 2006, the Knowledge Lab convened the first 

quarterly Crossing Boundaries Roundtable meeting for 

employees who had volunteered their ideas to the effort. 

Roundtable participants described the director’s involvement as 

providing a “license for creativity” for employees to step forward 

and pursue their ideas. One participant described her conversion 

from the cynicism that some of her peers still express. “I’ve seen 

it work,” she tells them, and she encourages them to attend a 

Crossing Boundaries session to see for themselves. 

Seek Knowledge 

By demonstrating the value of seeking knowledge without regard 

for organizational boundaries, Crossing Boundaries exemplifies 

the new culture envisioned by senior national and intelligence 

community leaders. Anyone with an idea can propose it in an open 

forum. Feedback from senior leaders is immediate and public, and 

offers to help often come on the spot. Crossing Boundaries is not 

a panacea. Employees who propose ideas must still fight battles, 

and not every idea comes to fruition. But the premise of Crossing 

Boundaries—that all employees have something of value to add 

to the mission—is demonstrated every day.

Solve Problems 

DIA employees address complex and substantive intelligence 

issues daily. In Crossing Boundaries, they usually take on 

complex problems that are outside their areas of expertise 

and responsibility. For instance, many of the proposals for 

organizational change have come from analysts in the Directorate 

for Intelligence Analysis. The proposals for changing the time 

and attendance system came from analysts, support professionals, 

and technologists. These people take risks by making a public 

statement on behalf of change. We are all in their debt.

What’s the Secret?

People who are successful in Crossing Boundaries act. They build 

networks of supporters and advisors that cross organizational 

boundaries inside and outside DIA. For instance, the employee 

who started the time and attendance project networked with 

others in the Directorate for Human Capital and the Directorate 

for Administration, learning about the reporting process and 

identifying potential improvements. She then led a group that 

ANYONE WITH AN IDEA CAN PROPOSE IT IN AN OPEN FORUM. FEEDBACK FROM SENIOR 

LEADERS IS IMMEDIATE AND PUBLIC, AND OFFERS TO HELP OFTEN COME ON THE SPOT.

ASK MAGAZINE | 51
engaged another defense intelligence agency that provides the 

payroll service to DIA. Together, they identified potential 

changes that could significantly streamline the process. As a 

logical next step, the DIA’s lean Six Sigma process improvement 

group began a detailed study of the time and attendance process 

to identify the set of process changes appropriate to the agency’s 

needs. That study is under way now.

Another employee identified a potential change in how DIA 

collaborates with another intelligence agency. The change, if 

implemented, could improve mission performance in a sensitive 

area. He got immediate attention and support from Maples and 

senior leaders at a meeting in October 2006. He developed a 

paper that identified options for improvement, engaged other 

offices in DIA that had undertaken similar actions, and led a 

working group to explore details of implementation further. 

He engaged representatives of the other agency in a detailed 

evaluation of potential options. Today they are moving toward 

improving the depth of that agency’s support for DIA.

At the Crossing Boundaries meeting on July 14, 2006, 

another DIA employee proposed an idea for better sharing of 

useful databases and tools among analysts. He envisioned a 

regular communication of “News You Can Use” to the broad 

agency via an internal Web page that would publicize new 

analytical tools available to analysts. He has gathered a number 

of volunteers to serve on an editorial board and assess which 

tools “News You Can Use” would feature, and he has collected 

a list of numerous tools that already exist. His group is planning 

to begin “News You Can Use” operations in early 2007. The 

positive impact on the work of individual analysts could be 

significant. The group plans to use already available tools, 

including Intellipedia (the intelligence community’s version of 

Wikipedia), to provide this service. They do not need special 

permission or support from anyone. They are going ahead.

Building Networks

Crossing Boundaries participants form their own unique and 

changing networks of supporters. These networks contribute to 

problem solving in a number of ways. Through interaction with 

supporters and advisors, proposals become stronger and better. 

For instance, an employee who proposed saving funds provided 

to new employees to cover moving expenses found that his 

proposal may not conform to legal requirements of the hiring 

process for Department of Defense organizations. Rather than 

dropping the idea, he has worked with his network to develop 

a different approach that has the potential to provide the same 

savings within the bounds of current regulations. 

An Innovation Network 

As the Knowledge Lab has worked with these and other 

participants, it has found itself at the center of a virtual innovation 

center. The Crossing Boundaries network has the ability to apply 

its members’ experience to complex problems facing the agency 

that no one has solved before. It is a complex, ever-changing set of 

individuals who are pooling their energy, passion, and resources 

to address the issues that have seemed too difficult to fix. 

The Crossing Boundaries approach represents a real 

departure from usual change efforts in government. It works in 

the seams between organizations, draws support from all levels 

of DIA, and addresses issues that employees feel are critical 

to the agency’s mission. By calling on volunteers to take risks 

and pursue their ideas for change outside normal channels and 

chains of command, Maples has demonstrated trust in the 

judgment and capabilities of the DIA workforce. He has gained 

(and continues to gain) the trust of those employees who have 

taken up his cause. They are becoming his advocates, and they 

prove that change is real. Through them, the DIA is growing 

a new culture of breaking down barriers, seeking knowledge, 

and learning new ways to scope and solve problems. Crossing 

Boundaries represents a visionary, driven-from-the-working-level 

approach to remaking the culture of an intelligence agency. ●

ADRIAN WOLFBERG is an intelligence officer at the Defense 

Intelligence Agency, where he leads the Knowledge Laboratory 

to bring solutions from industry and academia to help solve 

organizational and behavioral challenges with DIA.

JOHN T. O’CONNOR is a Principal with Toffler Associates®, the 

executive advisory firm founded by futurists Alvin and Heidi Toffler.

52 | ASK MAGAZINE
Viewpoint: Lunar Opportunities

BY PAUL D. SPUDIS

When NASA’s Lunar Architecture Team began to review ideas submitted by the broader space 

community about what we should do on the moon, they had to reconcile many disparate thoughts 

and concepts and weld them into a coherent rationale. This process began with a workshop in April 

2006 that drew together a wide spectrum of attendees, all bringing their own backgrounds and 

agendas to the table. Their varied ideas converged to a surprising extent, with human settlement 

and preparation for Mars emerging as the primary goals of lunar return.

Refinement and expansion of these two themes and four others 

(science, economic expansion, international cooperation, and 

public engagement) took the remainder of 2006, with the results 

being presented at the Second Space Exploration Conference 

held in December in Houston. In conjunction with unveiling 

the six themes, NASA released a list (memorably called the 

“spreadsheet of death” by a colleague of mine) of 181 specific 

lunar activities, classified and rated by discipline and theme. 

It was never intended that all these activities necessarily be 

attempted by NASA; they were meant to demonstrate the scope 

and breadth of possible activities for humans and robots on the 

moon. It was necessary to examine all possible tasks and events 

in order to assess how well the emerging architectural details fit 

the potential list.

The sheer scope of the listed tasks and their collection into 

six themes led some to the conclusion that we really have no 

purpose for going back to the moon and that this effort is an 

attempt by NASA to retrofit a rationale on a goal that in fact 

has none.

Nothing could be further from the truth. The report is 

simply the result of the Agency attempting to satisfy as many 

of its constituencies as possible within the overall framework 

provided by the Vision for Space Exploration. So what was 

intended as the reason for lunar return by the architects of the 

vision? What, if any, are the objective reasons for a return to 

the moon?

For answers, read the vision policy documents, including 

both President Bush’s original speech and a strangely 

neglected (but highly significant) elaboration on it by 

Presidential Science Advisor John Marburger. The presidential 

speech announcing the vision three years ago is remarkably 

clear about our purpose in returning to the moon. President 

Bush said the following:

Beginning no later than 2008, we will send a series of 

robotic missions to the lunar surface to research and prepare 

for future human exploration. Using the crew exploration 

vehicle, we will undertake extended human missions to 

the moon as early as 2015, with the goal of living and 

working there for increasingly extended periods. 

In this artist’s concept of the future, an astronaut gathers samples on the 

surface of Mars while a robotic explorer stands by to help. The Vision for Space 

Exploration calls for aggressive human and robotic missions that will return to 

the moon and eventually explore Mars and beyond.

Image Credit: NASA

INSIGHT | ASK MAGAZINE | 53
Also:

Returning to the moon is an important step for our 

space program. Establishing an extended human 

presence on the moon could vastly reduce the costs of 

further space exploration, making possible ever more 

ambitious missions. ... The moon is home to abundant 

resources. Its soil contains raw materials that might be 

harvested and processed into rocket fuel or breathable 

air. We can use our time on the moon to develop and 

test new approaches and technologies and systems that 

will allow us to function in other, more challenging 

environments. The moon is a logical step toward 

further progress and achievement. 

These statements make clear that the purpose of going to the 

moon is development: developing new techniques, procedures, 

and technologies, all with the aim of making space flight easier, 

more routine, and more capable.

If this wasn’t clear enough, John Marburger’s speech

(http://www.spaceref.com/news/viewsr.html?pid=19999) two 

years later clarified our ultimate objectives:

President Bush’s vision also declares the will to lead in 

space, but it renders the ultimate goal more explicit. 

And that goal is even grander. The ultimate goal is not 

to impress others, or merely to explore our planetary 

system, but to use accessible space for the benefit of 

humankind. It is a goal that is not confined to a decade 

or a century. Nor is it confined to a single nearby 

destination, or to a fleeting dash to plant a flag. The 

idea is to begin preparing now for a future in which 

the material trapped in the sun’s vicinity is available for 

incorporation into our way of life.

And:

We have known for a long time that a huge gap 

separates the objects trapped by the gravity of our star, 

the sun, and everything else. ... Phenomena on our 

side of the interstellar gap, in what we call the solar 

system, are potentially amenable to direct investigation 

and manipulation through physical contact and can 

reasonably be described as falling within humanity’s 

economic sphere of influence. As I see it, questions about 

the vision boil down to whether we want to incorporate 

the solar system in our economic sphere, or not.

The administration clearly stated that we are going to the 

moon to learn how to use what we find in space to create new 

space-faring capability. The goal isn’t simply to return to the 

moon or even merely to send humans to Mars, but rather to 

extend human reach beyond low-Earth orbit and ultimately to 

all possible destinations beyond.

The Vision for Space Exploration is different from any 

previous space policy. By design it is incremental and cumulative. 

We make “steady progress” no matter how slowly we may be 

forced to proceed at any given time by fiscal constraints. Small 

steps that build upon each other create new capability over time. 

Our activities will teach us not merely how to survive, but how 

to thrive off-planet. Such a task includes inhabiting planetary 

surfaces, doing useful work while we are there, and extracting 

what we need from the material and energy resources we find. 

We will use these new skills and techniques to build a space 

transportation infrastructure that permits routine access to the 

moon and all cislunar space.

The significance of this last point should not be 

underestimated; access to cislunar space will revolutionize 

 ... WE ARE GOING TO THE MOON FOR ONE 

CLEAR AND UNDERSTANDABLE REASON: 

TO BE ABLE TO DO EVERYTHING ELSE 

THAT WE WANT TO DO IN SPACE. THE 

MOON IS OUR SCHOOL, LABORATORY, 

AND FOUNDRY.

54 | ASK MAGAZINE
space flight. Currently, we build disposable commercial 

space systems that have a specific design lifetime, after which 

they are simply abandoned. Combined with the high cost of 

getting to low-Earth orbit, this makes space flight difficult 

and costly. Hence, space largely has been left as the province 

of government, except for certain highly capitalized businesses 

such as global communications.

With the vision realized, satellites can be serviced, 

maintained, extended, and networked—space systems will 

be designed for an indefinite lifetime. Given existing launch 

costs, we cannot do this now. Even lowering such costs by an 

order of magnitude would still make even robotic servicing of 

platforms at geosynchronous orbit marginal at best. However, 

if we build a system that can refuel on the moon using locally 

produced materials, we create the capability to routinely go 

anywhere in cislunar space. Exporting fuel extracted from lunar 

resources will permit us to go anywhere, anytime, with whatever 

capabilities we need. This is the beginning of true space-faring 

capability. Such an environment would unleash imaginations, 

realize potential, and expand technology, science, exploration, 

and commerce.

In short, we are going to the moon for one clear and 

understandable reason: to be able to do everything else that we 

want to do in space. The moon is our school, laboratory, and 

foundry. The vision begins by building a highway through the 

heart of cislunar space, creating a transportation infrastructure 

for diverse users—scientists, miners, sellers, buyers, and, 

ultimately, settlers.

What is the role of NASA and the federal government in 

all this? It is not to industrialize space but to determine if the 

industrialization of space is possible. To accomplish such an 

expansive space vision requires us to understand exactly how 

difficult these tasks really are. Possible in theory is one thing; 

practical to implement is something else entirely. NASA must 

push the technical envelope to address and answer questions 

and develop new processes too expensive or too difficult for the 

private sector to tackle. Learning how to live on another world 

and extract what you need from it is a challenging task, one 

suitable for a federal research and development effort.

After understanding the technical difficulties and opening 

up possibilities, government should step back and let market 

forces work while still retaining a presence to enforce the law 

and ensure that compelling national strategic interests are 

served. Thus, while government will never become a resource 

producer, it is needed to ensure that corporations respect 

property rights and compete fairly in an open market, subject to 

the same antitrust and securities regulation as any other modern 

American business.

So why are some still asking, “Why are we going to the 

moon?” Some space constituencies are clearly uncomfortable 

with the strategic direction outlined above. For many, the idea 

of a government-funded program, controlled by and operated 

for the benefit of the academic science community, is the “right” 

way to run a space program. Such a science-driven agenda has 

been ascendant for the past fifteen years. During the Apollo 

era, the marshalling of national resources by the government to 

carry out space goals on a wartime footing was the dominant 

mode of operation.

Using what we find in space to enable exploration and to 

create new capability has never been attempted. The vision’s 

goal is to extend human commerce beyond low-Earth orbit. 

America’s desire to explore and create new wealth has allowed 

our society to thrive and to prosper. The Vision for Space 

Exploration extends that opportunity for all humanity into the 

solar system and beyond. ●

The views and opinions expressed in this article are the author’s 

and are not necessarily those of the institution for which he works 

or ASK Magazine. Read more at http://www.thespacereview.

com/article/791/1.

PAUL D. SPUDIS is a planetary scientist at the Applied Physics 

Laboratory in Laurel, Md. In 2004, he was a member of the 

President’s Commission on the Implementation of U.S. Space 

Exploration Policy and was presented with the NASA Distinguished 

Public Service Medal for that work. He is the author or co-author 

of more than 150 scientific papers and four books, including 

The Once and Future moon, a book for the general public in the 

Smithsonian Library of the solar system series. His Web site can 

be found at http://www.spudislunarresources.com. 

ASK MAGAZINE | 55
BY MATTHEW KOHUT

The primary objective of the Viking science mission was the stuff of dreams: to look for evidence 

of life of Mars. One of the instruments at the core of the mission was the gas chromatograph-mass 

spectrometer (GCMS). The GCMS was actually two instruments in one: a gas chromatograph 

and a mass spectrometer. Conducting gas chromatography and mass spectrometry in a laboratory 

was hard enough. Building even a lab model required experts who could keep up with the latest 

developments in the field, since the science was changing rapidly. The GCMS that Dr. Klaus 

Biemann, the leader of Viking’s molecular organic analysis team, had at MIT was the size of a room; 

its human operator could literally walk through it. Shrinking the instrument to a mass of less than 

15 kg and to fit in a 1 ́ x 1 ́ x 1 ́ box on a spacecraft, operate robotically, and survive the rigors of the 

journey to Mars and the Martian atmosphere presented myriad challenges.

MANAGING A DIFFICULT PROJECT ON EARTH

56 | ASK MAGAZINE | STORY
The technical challenges were compounded by managerial ones, 

including inadequate supervision and lack of communication 

among the contractors responsible for elements of the 

instrument. These concerns put the GCMS on Viking project 

manager Jim Martin’s “Top Ten Problems” list. Experienced, 

attentive management and a focus on performance over politics 

and standard operating procedures led to the instrument’s 

eventual success.

A Neglected Stepchild

In August 1968, the Jet Propulsion Laboratory (JPL) was 

given responsibility for developing, fabricating, and testing a 

lightweight portable “breadboard” (experimental model) of 

the GCMS before selecting a contractor to build the flight 

hardware. JPL also had responsibility for designing and building 

the Viking orbiters, managing tracking and data acquisition 

through the Deep Space Network, and managing the Viking 

mission control and computing center.

In September 1970, Cal Broome, who headed the working 

group in charge of overseeing Viking’s scientific payloads, told 

Martin that the GCMS was a “stepchild” not getting proper 

supervision because of the decentralized management structure 

at JPL. Two weeks later, word came back that JPL had taken 

steps to strengthen its control of the project, but the changes 

did not yield the results that Martin wanted. In January 1971, 

a five-day GCMS engineering model review was a disaster, 

resulting in between 200 and 300 “request for action” forms. 

The instrument’s mass and cost both far exceeded earlier 

estimates. At the March Science Steering Group meeting, 

Martin noted that funding increases, technical problems, and 

schedule slips were causing considerable concern about the 

future of the GCMS. 

The picture was not entirely bleak. That same month, the 

GCMS breadboard operated for the first time as a completely 

automated soil-organic-analysis instrument. Several technical 

problems were encountered, but Martin and the Viking Project 

Office considered it a step forward. There was no question about 

the JPL team’s technical talent; Martin’s concern was its ability 

to deliver a working instrument in time for launch. 

JPL’s oversight of the instrument’s contractors was a major 

source of concern. Beckman Instruments (gas chromatograph), 

Perkin-Elmer (mass spectrometer), and Litton Industries (data 

system) were building the components of an instrument that 

required the highest degree of integration, yet the three wouldn’t 

even talk directly to one another, despite the fact that their 

facilities were within a fifty-mile radius in California. None had 

been designated as prime contractor. 

In October 1971, Martin considered finding another 

organization to handle the GCMS contract. The project office 

awarded Bendix Aerospace a contract to study the feasibility of 

using an organic analysis mass spectrometer (OAMS) in place 

of the GCMS. On October 26, he added the GCMS to the 

Viking Top Ten Problems list.

Martin began the Top Ten Problems list in the spring 

of 1970 to give problems that could affect the launch date 

needed visibility and oversight. To make the list, a problem 

had to have a serious impact on “the successful attainment of 

established scientific and/or technical requirements, and/or the 

meeting of critical project milestones, and/or the compliance 

with project fiscal constraints.” Anyone associated with the 

Viking project could identify a potential priority problem 

by defining the exact nature of the difficulty and forming 

a plan and schedule for solving it. When Martin made an 

addition to his list, a person in the organization was charged 

with solving the problem, and someone in the project office 

monitored the progress.

Time for Action

At the February 1972 Science Steering Group meeting, a top 

scientist reported on the GCMS and OAMS, noting that both 

had advantages and disadvantages that could not be directly 

compared. That settled it for Martin. He decided in favor 

ASK MAGAZINE | 57
of continuing the development of a simplified version of the 

GCMS. He removed the GCMS from the Top Ten Problems 

list for the time being, knowing that in March he would take 

concrete steps to get the instrument on track. Martin decided 

to shift management of the GCMS from JPL to his Viking 

project office at Langley. According to cost projections, it 

would be cheaper by about $7.5 million to keep the GCMS 

project (rather than shifting to an OAMS) while transferring 

management of it to Langley. 

This decision to take the GCMS project from JPL was not 

made lightly. Though technically not a government institution, 

JPL was an integral part of the NASA family and the Viking 

mission. Martin knew his decision would cause rumblings, 

but the potential political fallout was preferable to launching 

the Viking spacecraft without a GCMS—an instrument 

critical in the search for signs of life on Mars. Although its 

development and fabrication were still far from ensured, he 

was confident that the project office at Langley could bring 

needed discipline. He sent Angelo “Gus” Guastaferro, Deputy 

Project Manager for Management, to California to rewrite 

the GCMS contract with JPL, and he appointed Joseph C. 

Moorman to manage the instrument. 

Back in the Top Ten

Moorman, who had been managing a biology instrument prior 

to taking over the GCMS, did not have experience corralling 

contractors or shifting a project from one center of operations to 

another. The Viking project was the first in his NASA career, 

and the difficulties presented by the GCMS would have been an 

extraordinary challenge for even a seasoned project manager. 

Six months later, Martin concluded that Moorman had 

not brought the GCMS up to speed. This was not a routine 

science instrument; it required strong systems engineering and 

experienced project management. He put the GCMS back on 

the Top Ten Problems list, where it remained for more than two 

years until shortly before launch. 

Beyond the Org Chart

By the end of 1972, Martin took action again. He reassigned 

Moorman and put Guastaferro, his deputy for management, 

in charge of overseeing the instrument’s development on a dayto-day basis. Martin did not care about Guastaferro’s title; he 

needed a senior person who could take effective control of the 

project and the contractors. 

Guastaferro’s first task was to establish a more productive 

and cooperative relationship among the contractors; his strategy 

was to shift from “inattention” to “over-attention.” He left 

Langley and relocated to California for the next two years so 

he could shuttle among their facilities to monitor progress. He 

also assigned Litton Industries responsibility as the instrument’s 

prime contractor, since its data system would ultimately 

integrate the information from the gas chromatograph and the 

mass spectrometer and send data back to Earth. 

Reaching Out for Answers

Guastaferro relied on Al Diaz, the GCMS chief engineer, to 

provide the technical expertise that the project required, since 

there were still significant problems to resolve. Guastaferro and 

Diaz sought help wherever they could find it, often reaching 

MARTIN DID NOT CARE ABOUT 

GUASTAFERRO’S TITLE; HE NEEDED A 

SENIOR PERSON WHO COULD TAKE 

EFFECTIVE CONTROL OF THE PROJECT 

AND THE CONTRACTORS.

58 | ASK MAGAZINE

Technicians inspect Viking Lander 2 in Kennedy Space Center’s Spacecraft 

Assembly and Encapsulation Facility #1. 

The flight GCMS is tested and prepared for its long journey through space to 

investigate Mars.

Photo Credit: NASA HeadquartersPhoto Credit: NASA Headquarters
out to experts in private industry and academia for answers. 

On more than one occasion, they discovered that others had 

overcome similar technical issues, but the solutions were 

proprietary or classified. 

One example involved a problem with electrical highvoltage arcing, which would ruin the instrument. The key 

to fixing this was developing an epoxy-like compound to 

insulate the circuitry from the conditions that made the 

instrument susceptible to arcing. The JPL team had not 

been able to devise the right formula. Guastaferro and Diaz 

discovered that a private industry contractor working for the 

Department of Defense had encountered this same issue with 

its own technology. While the contractor could not divulge 

the process to NASA, its representative told Guastaferro and 

Diaz to send him the component, and he would ensure that 

the problem disappeared. This “blind” handover had its risks, 

but Guastaferro and Diaz were more concerned with getting 

a working instrument to the launch pad on time than with 

ownership of the technical solution.

The Launch

One by one, dozens of technical issues were resolved. The 

GCMS critical design review in mid-July 1973 found only three 

major outstanding concerns, a vast improvement considering 

the previous difficulties with the instrument.

In May 1975, science payload manager Cal Broome advised 

Jim Martin that he could remove the GCMS from the Top 

Ten Problems list. Three months later, on August 20, 1975, 

Viking I was launched, followed by Viking II on September 9,

1975. In the summer of 1976, the Viking landers began 

sending GCMS analyses of Martian soil and atmosphere back 

to scientists on Earth. ●

The Viking Gas ChromatographMass Spectrometer

The gas chromatograph used a thin capillary fiber 

known as a column to separate different types of 

molecules, based on their chemical properties. Each 

type of molecule passed through the column at a 

different rate, emerging from the column in a defined 

sequence. The temperature of the column determined 

the rate of separation. 

Once processed by the gas chromatograph, 

molecules would then enter the mass spectrometer, 

which would evaluate and identify them by breaking 

each one into ionized fragments and detecting 

these fragments using their charge-to-mass ratio. 

This produced a unique profile of each compound 

that could be converted into a digital signal and 

transmitted to Earth.

Used together, these two components offered a much 

finer degree of substance identification than either 

unit used separately. Scientists considered the GCMS 

a gold standard for forensic substance identification 

because it performed a specific test. (A specific test 

positively identifies the actual presence of a particular 

substance in a given sample.) A working GCMS was 

absolutely critical to the organic analysis of the soil 

on Mars.

ASK MAGAZINE | 59
Knowledge in Brief

Three Heads Are Better Than One

When Megan was 14, she began to have trouble swallowing and 

could not seem to keep food down. Her parents brought her to 

the family general practitioner. He examined her and ordered 

some tests. Finding nothing obviously wrong, he assured Megan 

and her parents that the problem would take care of itself.

But Megan’s digestive problem got worse and she began 

to lose weight. She went to one specialist who prescribed an 

antibiotic that had no effect on her condition. Other doctors 

who examined Megan were baffled. She continued to have 

trouble eating and continued to lose weight.

Her parents took her to the Hospital for Sick Children 

in Toronto. Soon after she was admitted, three specialists 

entered Megan’s room together: an internist, an allergist, and a 

gastroenterologist. They had all studied her records. They asked 

a few questions and examined her. Then, in the room with 

Megan and her parents, they shared their ideas.

The allergist said he was fairly sure the problem was not a 

food allergy.

“Yes, I think it’s an infection,” the gastroenterologist said.

The internist agreed and thought he knew why the earlier 

course of antibiotic treatment had not worked.

Megan had been ill for weeks. Now, within five minutes, 

the three physicians agreed on a diagnosis and a treatment—

a particular antibiotic effective against the somewhat 

unusual infection she had contracted. Her rapid recovery 

proved them right.

Decision Making at W. L. Gore

The W. L. Gore companies have built their business on 

one chemical compound—polytetrafluoroethylene—and on

a particular idea of management. They have turned the 

polymer into electrical insulation, artificial veins, Gore-tex, 

and Glide dental floss. Gore prides itself on the independence 

and creativity of its employees. At Gore, anyone can make 

any decision relevant to his or her work that is not “below 

the waterline”—that is, that would not sink a division or the 

company if it proved to be a bad one.

Research scientist Robert Henn’s experience shows the 

decision-making philosophy in action. Some years ago, Henn 

began to think about a $500,000 piece of testing equipment 

that he believed could aid his research. He discussed the idea 

with his colleagues. He was enthusiastic about the equipment, 

but half a million dollars was a lot of money.

One day, CEO Bill Gore came into his office and said, “I 

hear you’re thinking about spending $500,000 on a new piece 

of equipment.”

Henn admitted that he was.

“Tell me, Bob,” Gore went on, “if this device does everything 

you imagine it can do, will it give us results that can help us 

improve our products or develop new ones?”

Henn had obviously thought about that question and 

found it easy to answer: yes, he believed the device would have 

practical and profitable applications.

“If it fails,” Gore asked, “if it turns out to be a $500,000 

paperweight, will your division survive?”

Henn hadn’t asked himself exactly that question. Gore 

waited while he mulled it over. Eventually he said, “If it turns 

out to be useless, that would be personally embarrassing to me, 

but, yes, the division would survive.”

“Then why haven’t you ordered it?” Gore asked. So 

he did. ●

Here are two true stories about organizational effectiveness. We leave it to you to think about their 

relevance to NASA and knowledge.

60 | ASK MAGAZINE
ASK Bookshelf

Infotopia: How Many Minds Produce Knowledge, 

by Cass R. Sunstein (New York: Oxford University 

Press, 2006)

Infotopia is about the democratization of knowledge, a subject 

Thomas Davenport considers in this issue of ASK. The book’s 

insights into how people share knowledge and make decisions 

can contribute to the discussion of these important subjects at 

NASA. In Infotopia, Sunstein analyzes recent developments that 

he thinks have the potential to aggregate people’s knowledge 

in valuable ways: the prediction markets that James Surowiecki 

also discusses in The Wisdom of Crowds; wikis, those collectively 

written and edited documents and encyclopedias; and the blogs 

(or Web logs) that comment on everything from politics to 

business to the often boring, occasionally fascinating details of 

the bloggers’ personal lives.

Like Surowiecki, Sunstein offers examples of the amazing 

accuracy of prediction markets and similar mechanisms for 

averaging the judgments or guesses large numbers of people 

make about questions ranging from the number of jelly beans 

in a jar to the outcome of an election or the release date of a 

product under development. Companies including Google and 

Hewlett-Packard have successfully used prediction markets to 

help guide decisions. Sunstein explains why these markets are 

so accurate and usefully describes circumstances in which they 

do and do not work. But there is one flaw in his careful analysis 

that is worth noting. Sunstein talks about prediction markets 

aggregating knowledge when in fact they aggregate judgments. 

Those collective judgments may be informed by knowledge, but 

the knowledge itself is not collected and cannot be extracted 

from the markets’ conclusions.

Wikis do aggregate knowledge and information. Sunstein 

argues convincingly that the best of them—Wikipedia is the bestknown example—can be extraordinarily current, comprehensive, 

and accurate. Although some wikis have been ruined by 

maliciousness and ignorance, Wikipedia thrives on the good 

will and good sense of most contributors and an editorial process 

supported by “Wikiquette” that establishes rules for disputing 

content. Businesses including Disney, Yahoo, and Oxford 

University Press are beginning to use wikis internally. They have 

great and so far largely unrealized potential as a tool for collecting 

and organizing what people in organizations know.

Sunstein is appropriately skeptical about the ability of 

blogs and the multitude of Web sites on any subject you can 

think of to improve the quality of our collective knowledge 

and understanding. He points to two related problems. First, 

many blogs and sites offer up information that is misleading, 

biased, and just plain wrong. Second, people tend to seek 

only information that confirms what they already believe 

(constructing “informational cocoons” for themselves), so they 

are unlikely to read broadly enough to judge the reliability of a 

particular source. In other words, the truth may be out there, 

but it’s hard to distinguish from the lies.

Sunstein is highly critical of deliberation—people talking 

together to come to a decision or evaluate ideas. He offers 

an important corrective to uncritical praise of the collective 

knowledge of teams and communities. He notes that groups are 

likely to defer to the opinions of high-status members and that 

members are often afraid to express views that differ from what 

the majority believes. As a result, he says, “deliberating groups 

discourage novelty” and, because they reinforce the ideas of the 

powerful or the majority, they tend to strengthen commitment 

to decisions good or bad. Sunstein suggests ways of improving 

deliberation that include explicitly inviting varied views, using 

devil’s advocates, and seeking individuals’ opinions both before 

and after group deliberation. ●

Here is a description of a book that we believe will interest ASK readers.

ASK MAGAZINE | 61
The Knowledge Notebook

On Trust

BY LAURENCE PRUSAK

Sometimes a concept seems to be everywhere 

at once. It arrives on the scene seemingly from 

nowhere, and everybody is suddenly talking and 

writing about it. One such idea is trust.

Although philosophers and poets have focused 

on trust as far back as the Old Testament and in 

the writings of several of the Chinese sages, it had 

very little traction as an idea in and of itself until 

recently. Few books or articles focused specifically 

on the subject. Then, starting slowly in the 1980s 

and picking up steam in the nineties, the subject 

took off. Economists, sociologists, political 

scientists, and management theorists began to 

take a serious look at how trust works in people’s 

lives, in organizations, in nations, and in cultures. 

This attention to trust helped spur the parallel 

interest in social capital and is, indeed, a major 

component of that set of ideas about the value of 

the connections between people. By now the trust 

literature is huge. I personally own more than a 

dozen major books on trust and have a thick file of 

articles on the subject. That collection, which only 

reflects my amateur’s taste for the subject, is by no 

means comprehensive.

So, what’s going on here? Why is the subject so 

hot? The short answer is: in a complex, connected 

world where so much depends on cooperation and 

understanding, trust is essential to the success of 

organizations and societies.

Trust between individuals can be defined as 

anticipated reliable cooperation. I help you with 

the expectation that you will help me when I need 

it, and your cooperation will be freely offered, 

not compelled by enforcement mechanisms. 

People usually base their trust on direct personal 

experience. When they don’t yet know one 

another, they proceed with caution, testing the 

water, observing behaviors that show if this person 

or that one is trustworthy.

Although in one sense all organizational 

activity comes down to the actions of individuals, 

focusing on individual trust isn’t always the most 

fruitful path to understanding how it works in 

organizations. How trust develops (or fails to 

develop) depends on the organizational context. 

We all know of organizations where trust is in short 

supply, between people and between employees and 

their management. Sometimes employees trust their 

colleagues while distrusting their managers with 

varying degrees of intensity, but often distrust at one 

level discourages trust at others. An organization’s 

trust “climate” can promote or destroy trust in 

many ways and many places.

Social scientists talk about “generalized trust” 

in organizations and in societies. When trust and 

trustworthiness in institutions, leaderships, and 

individuals are the norm, people are more likely 

to trust one another readily—they will assume 

trustworthiness until individuals or groups show they 

are not worthy of it rather than demand extensive 

proof before they are willing to trust anyone.

What is the importance of trust in 

organizations? For one thing, trust or the lack of 

it has a real economic impact. All organizations 

spend a lot of money and time (up to 40 percent 

of their total expenditures) on transaction costs. 

Transaction costs are the costs of doing work 

together—negotiating, bargaining, exchanging, 

and interpreting information and monitoring 

activities, among others. These activities are 

especially extensive and important in large, complex 

organizations. Generalized trust is a great way to 

62 | ASK MAGAZINE
cut transaction costs. When trust is the norm, people in the 

organization do not have to look constantly over their shoulders 

or nail down every detail of every agreement or monitor and 

measure compliance with requirements large and small. The 

organization and the individuals in it are relieved of an onerous 

and expensive burden. This can mean not only very significant 

financial savings, but savings of the enthusiasm, commitment, 

and energy that distrust erodes. 

Trust also encourages—in fact, makes possible—the free 

exchange of knowledge. People tend to share what they know 

when they are confident they will be credited for it and the 

knowledge they offer will be well and responsibly used. We 

have seen many organizations where trust is the great engine 

of knowledge sharing and people freely and actively offer their 

expertise to others who need it. This happens whether or not 

the organization has elaborate and expensive knowledgesharing systems. It is much more about attitudes, examples, and 

experiences than technology.

 Trust is asymmetrical. As Rod Kramer, a Stanford 

researcher on this subject, says, it is “hard won and easily lost.” 

One breach of trust can outweigh years of trustworthy actions. 

It is incumbent on managers and executives to do what they 

can to build and maintain trust in their own areas of influence. 

Research and common sense suggest that some good ways of 

doing this are to act transparently (that is, be trustworthy); 

reward and promote people who are trustworthy and get 

rid of those who aren’t; talk up the subject and recognize its 

importance; and, to quote a bumper sticker, be the change you 

wish to see. Trust me, it really is worth doing. ●

PEOPLE TEND TO SHARE WHAT THEY 

KNOW WHEN THEY ARE CONFIDENT 

THEY WILL BE CREDITED FOR IT AND 

THE KNOWLEDGE THEY OFFER WILL BE 

WELL AND RESPONSIBLY USED.

ASK MAGAZINE | 63
ASKinteractive

For More on 

Our Stories

Additional information 

pertaining to articles 

featured in this issue 

can be found by visiting 

the following Web sites:

• Deep Impact: 

http://www.nasa.

gov/mission_pages/

deepimpact/main/

index.html 

• Viking: http://www.

nasa.gov/mission_

pages/viking/

• Space Mission 

Excellence Program: 

http://www.nasa.

gov/centers/glenn/

news/AF/2006/nov06_

training.html

feedback

We welcome your comments on what you’ve read in this issue of ASK and your suggestions for articles you 

would like to see in future issues. Share your thoughts with us at http://appel.nasa.gov/ask/about/write.php.

Learning and Development

Check out these upcoming opportunities for increasing knowledge. For more information, please 

e-mail APPELcourses@asrcms.com.

Foundations of Aerospace at NASA Part A, July 16–27, Ames Research Center

This course is designed for new hires within their first year of employment at NASA or employees 

that began work within the past five years. The goal of this course is to immerse new hires in what 

it means to work at NASA and the principles of technical excellence. It will provide participants with 

a “big picture” of NASA, its governance model, and Agency operations, as well as communication 

and team participation skills and basic concepts of aeronautics and astronautics. 

Project Management and Systems Engineering Part B, September 10–14, Wallops Flight Facility

This course is designed for NASA project practitioners and systems engineers prior to or in the first 

year of entry into project, systems engineering, or supervisory positions. This course is intended 

to enhance proficiency in applying PM and SE processes/practices over the project life cycle. It 

will focus on defining and implementing system projects and providing the tools necessary for 

managing and leading project and technical teams. 

Web of Knowledge

NASA has created a knowledge network to promote learning and sharing among NASA’s 

engineers. Through NASA Lessons Learned, an agency-wide searchable database, an expertise 

locator, and discipline-specific communities of practice portals, the NASA Engineering Network, 

or NEN, connects engineers to NASA’s vast engineering resources to help them solve problems 

and design solutions more effectively and efficiently. Find out more about the Network online: 

http://nen.nasa.gov (NASA only). 

NASA in the News

U.S. News & World Report, in conjunction with the Center for Public Leadership at Harvard’s 

John F. Kennedy School of Government, named Charles Elachi of the Jet Propulsion Laboratory 

(JPL) as one of “America’s Best Leaders” for 2006. Other honorees include Warren Buffet, 

Sandra Day O’Connor, Wynton Marsalis, and Michael Bloomberg. Elachi was chosen for his bold 

leadership in turning around NASA’s Mars projects after the mission failures of the Mars Climate 

Orbiter and the Mars Polar Lander in the 1990s. His efforts led to the successful Mars Exploration 

Rover (MER) program, which included the Spirit and Opportunity rovers. The honorees were 

selected by a committee of government, community, and private-sector leaders convened by the 

Center for Public Leadership at Harvard University’s Kennedy School of Government. Read the 

Courtesy of 

U.S. News & World Report article online at http://www.usnews.com/usnews/news/leaders.

ASK OCE: http://appel.nasa.gov/askoce

64 | ASK MAGAZINE
Not yet receiving your own copy of ASK?

To subscribe, send your full name and preferred mailing address 

(including mail stop, if applicable) to ASKmagazine@asrcms.com.
National Aeronautics and Space Administration

NASA Headquarters

300 E Street SW

Washington, DC 20546

www.nasa.gov

NP-2007-06-472-HQ