Academy Sharing Knowledge

The NASA Source for Project Management and Engineering Excellence | APPEL SUMMER | 2013

National Aeronautics and Space Administration

Inside

The Knowledge

ManageMenT Journey

KSC SwaMp worKS

prediCTable 

proJeCT SurpriSeS
gnarta SuhsoJn amrir AoineS, ecroFr i. AS.: Utidero CtohP

ON THE COVER

Above Bear Lake, Alaska, the Northern Lights, or aurora borealis, are created by solar 

radiation entering the atmosphere at the magnetic poles. The appearance of these lights 

is just one way solar radiation affects us; it can also interfere with NASA missions in 

low-Earth orbit. To achieve long-duration human spaceflight missions in deeper space, 

several NASA centers are working to find better safety measures and solutions to 

protect humans from space radiation. 
Contents

21 5 9

DEPARTMENTS

3

In This Issue 

BY DON COHEN

4

From the NASA CKO 

Our Knowledge Legacy

BY ED HOFFMAN

42

The Knowledge Notebook

Big Data—The Latest Organizational 

Idea-Movement

BY LAURENCE PRUSAK

44

ASK Interactive 

INSIGHTS

9

Predictable Project Surprises: 

Bridging Risk-Perception Gaps 

BY PEDRO C. RIBEIRO Concerns about 

project-threatening risks are often ignored 

or unspoken.

21

The Knowledge Management Journey 

BY EDWARD W. ROGERS Goddard’s CKO 

reflects on what ten years on the job have 

taught him.

25

Creating NASA’s Knowledge Map 

BY MATTHEW KOHUT AND HALEY STEPHENSON 

A new online tool helps show who knows 

what at NASA.

29

Lessons on Leadership: The Evolution 

of the Radiation Protection Project 

BY KEITH L. WOODMAN AND DEBI TOMEK 

Thanks to wise leadership and open 

communication, an important project 

survives multiple challenges.

STORIES

5

Back to the Future: 

KSC Swamp Works 

BY KERRY ELLIS Kennedy’s new Swamp 

Works encourages innovation through 

experimentation and knowledge sharing.

13

University Capstone Projects: 

Small Investments, Big Rewards 

BY LAURIE STAUBER Glenn’s partnership

with universities generates first-rate 

space-medicine research.

17

One Person’s Mentoring Experience 

BY NATALIE HENRICH The author explains 

how she found and worked with her mentor.

33

The Road to New Flight Software 

BY CHRISTOPHER KRUPIARZ To develop new 

software, an Applied Physics Lab team 

collaborates with several NASA centers.

37

Tales from a Five-Sided Building 

BY STEPHEN GARBER Six months at the 

Pentagon gave Garber an opportunity 

to compare NASA and the Department 

of Defense.

ASK MAGAZINE | 1
Issue No. 51

Staff

aCaDEMy DIRECTOR aND pUblISHER

dr. edward hoffman

ehoffman@nasa.gov

EDITOR-IN-CHIEf

laurence prusak

larryprusak@gmail.com

MaNagINg EDITOR

don Cohen

doncohen@rcn.com

EDITOR

Kerry ellis

kerry.ellis@inuteqllc.com

CONTRIbUTINg EDITORS

Matt Kohut

mattkohut@infactcommunications.com

haley Stephenson

haley.stephenson@valador.com

SENIOR KNOwlEDgE SHaRINg 

CONSUlTaNT

Jon boyle

jon.boyle@inuteqllc.com

KNOwlEDgE SHaRINg aNalySTS

ben bruneau

ben.bruneau@inuteqllc.com

ramien pierre

ramien.pierre@inuteqllc.com

aCaDEMy pROgRaM MaNagER

yvonne Massaquoi

yvonne.massaquoi@inuteqllc.com

DESIgN

hirshorn Zuckerman design group, inc.

www.hzdg.com

pRINTINg SpECIalIST

Tun hla

tun.t.hla@nasa.gov

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 Academy and its Knowledge Sharing Initiative, 

designed for program/project managers and engineers to share expertise and lessons 

learned with fellow practitioners across the Agency. Reflecting the Academy’s 

responsibility for project management and engineering development and the 

challenges of NASA’s new mission, ASK includes articles about meeting the technical 

and managerial demands of complex projects, as well as insights into organizational 

knowledge, learning, collaboration, performance measurement and evaluation, and 

scheduling. We at APPEL Knowledge Sharing believe that stories recounting the reallife experiences of practitioners communicate important practical wisdom and best 

practices that readers can apply to their own projects and environments. 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 Academy Knowledge Sharing programs and products, please contact 

Yvonne Massaquoi, InuTeq LLC, 6303 Ivy Lane, Suite 130, Greenbelt, MD 20770; 

yvonne.massaquoi@inuteqllc.com; 301-837-9127.
In “Our Knowledge Legacy,” NASA Chief Knowledge Officer 

(CKO) Ed Hoffman describes his visit with elementaryschool children in Brooklyn, some of whom may become 

NASA engineers, scientists, or managers decades from now. 

Talking to those smart, enthusiastic students, he realized 

how important it is to preserve and transmit the agency’s rich 

store of knowledge so that future employees can build on it 

to advance aeronautics and space science and exploration. 

No NASA mission starts absolutely from scratch. They all 

depend on knowledge gained from the experience of earlier 

work. As several articles in this issue of ASK make clear, 

effectively fostering and sharing that knowledge demands 

thoughtfulness, skill, and creativity.

Edward Rogers, who has been Goddard’s CKO for 

more than a decade, shares lessons from “The Knowledge 

Management Journey,” including the importance of fitting 

knowledge activities to people’s specific needs and ways of 

working, rather than trying to impose pre-existing knowledge 

management techniques on them. Rogers has helped make 

“pause and learn” reflection and case-study discussion an 

integral part of work at Goddard.

In “Creating NASA’s Knowledge Map,” Matthew Kohut 

and Haley Stephenson discuss a new tool that shows 

the richness and diversity of knowledge work at NASA’s 

centers. As it continues to be enriched and refined, the 

map is likely to be a valuable way to locate essential 

knowledge anywhere in the agency. That matters because 

the knowledge required to solve a problem or avoid disaster 

almost always exists somewhere in the organization. But it 

is not always available to the people who need it to make 

sound decisions. Sometimes that knowledge is discounted 

or ignored, a point Pedro Ribeiro makes in “Predictable 

Surprises: Bridging Risk-Perception Gaps.” He outlines a 

technique for addressing that danger.

Of course NASA is also in the business of developing new 

expertise. In “Back to the Future: KSC Swamp Works,” Kerry 

Ellis describes labs at Kennedy Space Center designed to 

create knowledge by bringing together people with diverse 

backgrounds and by hands-on experimentation, building 

prototypes that teach the experimenters things they could 

never have learned from abstract planning or design. Aware 

of the importance of making what they discover available 

to others, the Swamp Works teams are also careful to 

document their work as they go along. 

Laurie Stauber’s “University Capstone Projects: Small 

Investments, Big Rewards” describes another way to 

acquire new knowledge. Glenn Research Center partners 

with several universities on student projects that explore 

space-medicine issues, providing valuable experience for 

the students and valuable learning to NASA.

The right knowledge is essential to project success 

but not sufficient to make it happen. A couple of articles 

in this issue demonstrate the importance of leadership 

and good communication. In “The Road to New Flight 

Software,” Christopher Krupiarz shows how the Applied 

Physics Laboratory at Johns Hopkins worked with several 

NASA centers to build complex new software. And Keith 

Woodman and Debi Tomek’s “Lessons on Leadership: The 

Evolution of the Radiation Protection Project” describes the 

skilled leadership that kept a project alive and well in spite of 

numerous changes that could have killed it.

Don Cohen

Managing Editor

In This Issue

ASK MAGAZINE | 3
Our Knowledge Legacy

By ED HOFFMAN 

From the NASA CKO

When we’re young, we are excited by our dreams. 

Our future possibilities seem endless and alluring. 

This spring, I had the opportunity to step back 

into that childhood world of possibilities when I 

returned to my elementary school in Brooklyn. Going 

back to P.S. 199 (Frederick Wachtel school) after 

forty years was a profoundly moving experience. I’d 

been invited to talk with students from kindergarten 

to grade six about my experience working for NASA. 

My purpose was to use the powerful connection 

between art and science to communicate to the 

students that “you can do anything in your life, as 

long as you dream big and work hard.” I wondered 

and worried: Would I be relevant?

Then the day unfolded, and every minute was 

something I treasured. The students were alert, 

energized, passionate, and smart. They wanted to 

know more about life onboard the International 

Space Station, the challenges of landing the Mars 

Curiosity rover, and the aircraft of the future. The 

teachers were welcoming and inspiring. The art 

activity that followed my talk was highly interactive 

and engaging for the students—the combination 

of science and art can unlock new realities and big 

dreams. Many asked about working as engineers, 

project managers, artists, and scientists, and more 

than a few indicated they would see me in a few 

years. (They promised to be good bosses.) I walked 

away believing they could make that dream a reality.

As I reflected on that day, it occurred to 

me that most of the programs that inspired the 

students in my talk will be history by the time they 

would be able to join NASA in a decade or more. 

There will be new programs by then, of course, 

but the people who carry them out—today’s 

students—will need the knowledge and expertise 

that has enabled us to complete the construction 

of the space station while manning it continuously 

for over a decade and to land a car-sized rover in a 

crater on Mars. That knowledge will only live on 

and be available to them in the people who worked 

on these programs and the systems we design to 

preserve and share it. 

NASA has come a long way since Apollo in 

its effort to capture knowledge from its flagship 

programs. The Shuttle Knowledge Console at 

Johnson Space Center is the go-to source for thirty 

years’ worth of knowledge about the Space Shuttle. 

Knowledge about the Ares I-X launch vehicle was 

captured very deliberately. The Mars program has 

made an intensive effort to document lessons from 

the innovative approach used to land Curiosity on 

the Martian surface. In the case of the International 

Space Station, the partner space agencies have 

developed a joint document of lessons learned 

based on their experience working collaboratively. 

This knowledge is our real legacy to the 

students of P.S. 199 and other schools if they are 

to continue the work of space exploration and 

aeronautics research. There’s no question that the 

passion remains alive. They are counting on us to 

share what we know. ●

4 | ASK MAGAZINE
to the

STORy | ASK MAGAZINE | 5

kacb

After the retirement of the Space Shuttle and completion of the International Space Station, 

NASA has been looking toward what’s next in human space exploration. Several centers have 

begun working on projects that could pave the way for the new ambitious goals of exploring 

asteroids and launching missions beyond low-Earth orbit. But such a shift in goals also requires 

a shift in culture. Taking a cue from NASA’s Apollo days, Kennedy Space Center (KSC) has 

taken steps toward changing the culture to one of hands-on, lean engineering and innovation 

development with the KSC Swamp Works.

KSC Swamp worKS

By KERRy ELLIS

future:
“KSC Swamp Works is what I call ‘Back to the Future,’” said 

Rob Mueller, senior technologist for the Systems Surface Office. 

“It’s an attempt to return to the early years of NASA when it was 

very hands-on, projects happened quickly, there were a lot of 

experiments, and sometimes failures happened, but we learned 

from the failures.”

KSC Swamp Works includes the Granular Mechanics and 

Regolith Operations Lab and the Electrostatics and Surface 

Physics Lab. Both have been around for a few years as part of 

the Surface Systems Office but were previously located in an 

off-site building. When the opportunity—and budget—

became available to move the labs back to Kennedy, the teams 

discussed their vision for an ideal environment in which to do 

new hands-on work.

“AND WhAT I’vE NOTICED IS INNOvATOrS 

frOM DIffErENT GrOuPS WILL hAvE 

GrEAT CONvErSATIONS ABOuT WhAT 

ThEy’rE WOrKING ON AND ASKING, 

‘hAvE yOu ThOuGhT Of ThIS? hAvE yOu 

ThOuGhT Of ThAT?’ IT’S WOrKED OuT 

vEry WELL.” 

“I asked the team, ‘What do you want?’” said Jack Fox, chief 

of the Systems Surface Office. “I made sure the requirements 

matched the building we wanted. It’s a huge building because 

we wanted to reinvent everything into being a Swamp Works 

environment—cost-effective, hands-on, rapid ideas—and have 

both labs in the same space.” The teams didn’t want different 

codes and buildings that would inhibit joint brainstorming. 

Another building requirement to support this goal was to 

include an “innovation space.”

With café seating and white boards, and walls and tables 

painted with whiteboard paint as well, the innovation space 

is located in a small, open loft. “It’s completely flexible, 

reconfigurable. The whole dynamic of the room can change,” 

said Mueller. “It’s not designed to be a room to have meetings. It’s 

designed to be a room where people can interact spontaneously 

and informally to come up with new ideas and innovative ways 

of working.” 

To further encourage openness and collaboration, the 

team also included a flexible work space as part of the building 

requirements. Meant to operate as a technology incubator, it 

allows anybody with a good idea to come in and have real estate 

available to try out a new technology. “They can’t stay there 

forever,” Mueller explained, “since it’s an incubator, but at least 

there’s a place for new ideas to get started.”

The labs have a mix of primarily engineers, physicists, 

and chemists—both senior and fresh-outs—to help encourage 

innovative thinking and problem solving. But that diversity is 

part of the challenge of running a Swamp Works operation. 

“How do you get people together from different disciplines?” 

asked Mueller. “Usually we do this by creating a multidisciplinary 

team for a project, but we don’t always have all the disciplines we 

need.” To fill the gaps, the Surface Systems Office takes advantage 

of Kennedy’s matrix organization and asks the Engineering and 

Technology Directorate for the help they need. 

Sometimes they find that expertise through more informal 

means. Every other week the teams have innovator get-togethers 

during lunch. “We talked about having after-work activities, but 

people kind of want to go home,” said Fox. “We learned that 

lunchtimes every other Friday work well. And what I’ve noticed 

is innovators from different groups will have great conversations 

about what they’re working on and asking, ‘Have you thought 

of this? Have you thought of that?’ It’s worked out very well.” 

With an abundance of knowledge and ideas flying about, 

KSC Swamp Works has taken steps to formally capture lessons 

learned in the midst of their fast-paced efforts.

Capturing lessons learned

Using a “make it, test it, and improve it” model of work, projects 

in the KSC Swamp Works labs often undergo several generations 

of builds, each an inexpensive attempt to improve on the one 

before. With so much excitement generated by doing hands-on 

work, it can be a challenge to get the teams to slow down and 

capture what they’ve learned from their efforts.

Mueller reminds his teams of the incentives for taking the 

time to document that knowledge. “We try to tie things together ASA: Ntidero CtohP

A panoramic view of the new KSC Swamp Works space.

6 | ASK MAGAZINE
with positive outcomes—like a conference or a new technology 

report or a patent application,” he explained. “In order to get 

credit for the work we’ve done, we write conference papers, 

which require us to document things well. We also write new 

technology reports, which could get published in NASA Tech 

Briefs and eventually lead to getting a patent on the work. We 

would like to protect intellectual property and license the new 

technology transfer to the public, and in order for the legal process 

of patenting to happen, you have to have documentation.”

"Why DON’T yOu uNDErSTAND WhAT’S 

BEEN DONE fIrST BEfOrE yOu STArT 

TryING TO CrEATE NEW WAyS TO DO IT?"

Since much of KSC Swamp Works’ focus is on openness 

and collaboration, the teams try to make their lessons learned as 

broadly available as possible. Currently, they use SharePoint to 

make formal knowledge-capture documents readily accessible. 

But they also use it to capture lessons in real time.

Projects traditionally complete the work, stop to document 

it, and then move on to the next phase. This process doesn’t 

work as well for the faster-paced work involved in leanengineering research and development. “We do have formal 

processes like design reviews, and we create documentation for 

those reviews, but we try to document as much as we can real 

time so the records are always available and you don’t have to 

stop to generate a report,” said Mueller.

The labs maintain continuity of knowledge between 

generations of designs by having the same team work on every 

successive generation together. 

The collaboration among scientists and engineers, seniors 

and fresh-outs, is open, allowing everyone to learn from each 

other and ask questions along the way. One recent graduate, 

Rachel Cox, said the knowledge she has gained by working with 

senior engineers on the Regolith Advanced Surface Systems 

Operations Robot (RASSOR) has been invaluable.

raSSor

The KSC Swamp Works labs currently focus on the engineering 

and science of dealing with regolith—or space dirt. The superfine 

substance has a habit of getting into places it shouldn’t. Sneaking 

into space suits, jamming mechanical gears, and sticking to 

everything with strong electrostatic charge, regolith is a known 

nuisance. But mined effectively, it could be a valuable resource 

for future long-duration missions beyond low-Earth orbit.

RASSOR is a robot designed to excavate regolith on an 

extraterrestrial surface with very low gravity, like the moon 

or an asteroid. The teams are currently working on the third 

generation of the robot, having learned a lot from their first 

two efforts.

One generation ended up being too heavy. That isn’t a big 

concern for a prototype, but weight matters to a flight-ready 

robot. The heavier the robot is, the larger the rocket needed to 

launch it, and the more expensive it becomes. A key contributor 

to the robot’s weight was its metal tracks. In the initial planning, 

the team debated using tracks versus wheels for RASSOR.

“The treads you use for a track give you more traction, 

letting you operate in more extreme environments, on steeper 

hills, and very dusty soil that is fluidized,” explained Mueller. 

“But wheels are much simpler and lighter. We did end up 

using tracks, but they caused a lot of problems, so now we’re 

looking at going back to wheels. Tracks versus wheels is one 

good example of a problem that was designed to be addressed 

by rapid prototyping.”

The first RASSOR used rubber-belt tracks because they’re 

cheap, easy to obtain, and don’t have to be heavily modified. 

But those tracks didn’t hold up well during testing. The team 

then moved on to using metal tracks. Cox, a recent mechanical 

engineering graduate, has been working on improving the tracks 

for the third-generation robot, a process she says has increased 

her knowledge exponentially. 

“I just graduated from college, so I thought I was pretty 

smart and could come up with new ideas,” Cox said, “but I 

don’t have the knowledge to back it up.” For a few weeks she 

struggled with the metal tracks, coming up with new designs 

that kept running into problems. “I’d fix one, and it would create ASA: Ntidero CtohP

With a pair of drums positioned on arms, RASSOR can take on a number of 

different shapes to accomplish its work. 

ASK MAGAZINE | 7
another,” she said. Then she went to one of the lead engineers 

for advice. He pointed out that tank tracks had been designed 

and created for years, and there was no need to reinvent the 

technology. “He said, ‘Why don’t you understand what’s been 

done first before you start trying to create new ways to do it?’”

Cox found a large military textbook about tank tracks and 

spent a couple of weeks reading it and figuring out what applied 

to RASSOR. “It set me straight,” she said. “I had a baseline to 

go off. Instead of trying to pull things out of my head, I had 

real-world examples and could see that this might not scale, but 

this is probably doable. 

“So going to that engineer and asking for help, it’s been 

really helpful. I wish I had done that sooner.”

Everyone involved on RASSOR has gained invaluable

knowledge by building the robot, seeing how it operates, and 

improving on the design. The process has allowed the team 

to learn not only what doesn’t work, but also what might

work much better than they had originally thought—or in

unexpected, but advantageous, ways.

For example, after building the first generation of the

robot, they learned through testing that it was capable of doing 

acrobatics. “We designed it so it could flip itself over again to 

avoid getting stuck,” Mueller explained, “but then we learned 

just by experimenting that there were several different ways

of driving it. You could drive it on its bucket drums, which 

it wasn’t designed to do. We could also stand it up and dump 

regolith into a bin. So we discovered many different modes of 

operation just by experimenting with it. You can’t get that from 

just white-boarding it. You need a physical prototype to try new 

things with.”

Currently, the team foresees building RASSOR through 

a fourth and possibly fifth generation, each time using what 

they’ve learned from the previous build to improve the design. 

KSC Swamp Works aims to have each new project go through 

this process, benefiting NASA as well as the scientists and

engineers with new knowledge and innovations.

Future plans and Collaborations

The knowledge gained doesn’t stay inside KSC Swamp Works. 

The labs collaborate with several NASA centers and projects, 

as well as commercial partners. They have worked with Project 

Morpheus, building the hazard field at the landing facility and 

building launch and landing pads for the vehicle. And they have 

been interacting with the Multi-Mission Space Exploration 

Vehicle team at Johnson Space Center and working with 

Desert Rats, as well as collaborating with Kennedy’s Spaceport 

Innovators. The labs hope to do much more in the future.

“We’re reinventing Kennedy to be a place where we 

do the high-risk, high-payoff work needed for future space 

exploration,” said Mueller. “It’s different from what we’ve done 

in the past, so there’s a big culture change. KSC Swamp Works 

is a pile of projects designed to show how Kennedy could be a 

different place in the future—still very successful, but probably 

a different way of doing business.”

“Our mission is to provide government and commercial 

space ventures with technologies they need for working and 

living on the surfaces of the moon, planets, and other bodies 

in our solar system,” added Fox. “We’re the provider of 

technologies. We’re laying the groundwork for future NASA 

programs and commercial ventures. We feel that’s the role of a 

government lab.” ●

Photo Credit: NASA/Jim Grossmann

ASA: Ntidere CgamI

KSC Swamp Works logo.

8 | ASK MAGAZINE

NASA Chief Knowledge Officer Ed Hoffman (left), Jack Fox (center), and Rob 

Mueller discuss KSC Swamp Works and techniques to enable innovation during 

a weeklong series called “Masters with Masters” at Kennedy Space Center. 
Photo Credit: Steve Garner “Unfortunately, my King ... here I am, unwilling and unwanted ... because I know that no one 

ever welcomes a bearer of bad news.” —Antigone by Sophocles, circa 442 BC

“It is pardonable to be defeated, but never to be surprised.” —Frederick, the Great

Predictable Project Surprises: 

Bridging Risk-Perception Gaps

BY PEDRO C RIBEIRO

INSIGHT | ASK MAGAZINE | 9
Many failed projects provide early warnings that they will run 

into trouble, but these signs are often ignored. They fly under 

the organization’s risk radar, evading even sophisticated risk 

management processes. Organizations end up not recognizing 

early signs of failure until nothing can be done other than trying 

to manage a crisis. 

The Good and Bad News About Project Failure

Projects may fail for many reasons. Common causes range from 

unrealistic expectations and unclear requirements to inadequate 

resources and lack of management support. Whatever the 

reason for a specific project failure, we should ask ourselves if 

it was a complete surprise for all involved, an outcome no one 

could possibly have imagined. Were 100 percent of the people 

involved in the project blind to the signs of an impending crisis? 

The good news is that failure is rarely a complete surprise. 

Almost invariably, some people perceive the danger and try 

to warn the organization. Sometimes warnings from outside 

the organization signal trouble ahead. In other instances, 

the grapevine—the organization’s informal communication 

network—talks about it in the cafeteria or by the water cooler. 

According to research (see the Silence Fails report of 2006), up 

to 90 percent of employees involved in a project may recognize 

far in advance when projects are headed for failure.

The bad news is that 71 percent try to speak up about 

their concerns to key decision makers but do not feel they are 

heard, and 19 percent don’t event attempt to speak because they 

already know they will not be heard. The result: important risks 

are unnoticed or ignored until it is too late. Then the project 

suddenly collapses, leaving management wondering what went 

wrong. When the project is a large one, they may first learn 

about the failure from the news media. 

Postmortem analyses, inquiries, and audits of failed projects 

often uncover streams of unheeded warnings in the form of 

letters, memos, e-mails, and even complete reports about risks 

that were ignored, past lessons not learned, and actions not 

taken—a failure of leadership that creates the conditions for a 

“perfect storm” of problems that could and should have been 

prevented, but nevertheless catch leaders by surprise.

Harvard Business School professors Max Bazerman and 

Michael Watkins apply the term “predictable surprise” to an 

event that takes leaders by surprise despite prior availability of 

the information necessary to anticipate the event and its possible 

consequences. I define “predictable project surprise” as an event 

characterized by sudden project status change or a discontinuity 

in a project’s expected or actual result that takes management 

by surprise when project team members or sources outside the 

organization tried to warn the organization about the danger. 

Predictable project surprises can result from unmanaged 

differences in project risk perceptions. 

Risk-Perception Gaps and 

Predictable Project Surprises

Risk perception is the subjective judgment we make about 

the characteristic, severity, and likelihood of a risk. It varies 

from individual to individual and from group to group. 

Education, experience, level of expertise on a specific subject, 

psychological traits, cultural context, and even the way risks 

are described all influence how we perceive the riskiness of 

a given situation. There has been a considerable amount of 

empirical research undertaken about why we perceive risks 

differently. Differences in risk perceptions are a fact of life 

and a strength in well-managed multidisciplinary teams, since 

they mean that some people will be aware of risks that others 

cannot see. 

Look at the photo above. Depending on previous knowledge 

of the context, information, perspective, training, and expertise 

about scuba diving with sharks, we may have different perceptions 

about the inherent risk of this situation and our ability to cope 

with it.

Even perception of so-called “black swans”—high-impact, 

low-probability events—depend on the observer. According to Photo Credit: Fiona Ayerst

10 | ASK MAGAZINE
Nassim Taleb, author of The Black Swan, what may be a blackswan surprise for one observer is not for another. A black swan is 

something not expected by a particular observer, and whether or 

not an event is considered a black swan depends on individual 

knowledge and experience.

Such differences in perception mean that at least some 

members of a diverse group are likely to identify risks that 

threaten project success. But their insights will not save the 

project if they are not effectively communicated.

Horizontal communication disconnects between department 

and division silos, as well as vertical communication disconnects 

between senior management, sponsors, and project managers 

on one hand and project managers and team members on the 

other, also contribute to the formation of isolated and ineffective 

clusters of risk perception.

Communication disconnects can be aggravated by attitudes 

toward risk. (In a previous ASK article, “Sinking the Unsinkable: 

Lessons for Leadership” [Issue 47, Fall 2012], I discussed some 

examples of the impacts of communication disconnects.)

Certain attitudes function as communication blockers, 

increasing the chances risks will be ignored. These include denial 

(“This cannot happen”), minimization (“You are stirring up a 

tempest in a teacup”), overconfidence and grandiosity (“We are 

the best organization in this field, we have the best systems in 

place”), idealization (“We are installing a new system or hiring a 

new manager that will solve all our problems”), and transference 

(“If this happens, department X or another entity is to blame”). 

Defense mechanisms, when ingrained in an organization’s 

culture and endorsed by leaders, are detrimental to teamwork 

and collaboration among departments. They encourage faulty 

rationales for decisions and complacency, and can lead to 

intimidation of those who question management.

In the absence of appropriate channels, good multidisciplinary 

team management, and a positive conflict culture for articulating 

concerns, team anxiety will flow through the grapevine, and 

important differences in risk perceptions will end up being 

discussed out of management awareness and control—in the 

cafeteria, by the water cooler, or outside the office. 

According to research, grapevine activity accelerates any 

time there is an ambiguous or uncertain situation and absence 

of sanctioned, open, and trusted channels for venting concerns, 

including office politics, hidden agendas, and pressure for results 

perceived as harmful to project objectives. Employees in any 

organization receive most of their information from informal 

networks and from a small number of people whose opinions 

are highly respected. The strength of the informal network 

will vary according to factors such as organization and country 

culture. With the Internet, interactions among people sharing 

and exchanging information in informal virtual communities 

and networks are accelerating, jumping over organizational, 

national, and geographical boundaries.

Mapping Risk-Perception Gaps 

Recognizing, discussing, and addressing risk-perception gaps 

are critical to project success, reducing the chances of projectrisk blind spots.

To address this need and complement and leverage other risk 

management information-gathering techniques and processes, I 

developed a tool for mapping and easily visualizing risk-perception 

gaps. The Risk-Perception Map (RPM) charts “perceived risk 

level” and “perceived risk-response capability” in a 2-by-2 matrix.

Perceived risk level represents an individual’s subjective 

assessment of risk level absent any action to alter the likelihood 

or impact of the risk. The perceived risk-response capability 

is an individual’s subjective assessment of her organization’s 

ability (using technology, processes, and people) to effectively 

formulate, plan, and execute responses to identified risks.

The two dimensions group risk perceptions into four 

categories: Mission Impossible or a Crisis Waiting to Happen; The 

Big Challenge; A Walk in the Park; and Just Another Day’s Work.

Mission Impossible or A Crisis Waiting to Happen: The 

observer perceives the project as high risk and does not feel the 

THE BAD NEWS IS THAT 71 PERCENT TRY TO SPEAK UP ABOUT THEIR CONCERNS TO KEY 

DECISION MAKERS BUT DO NOT FEEL THEY ARE HEARD, AND 19 PERCENT DON’T EVENT 

ATTEMPT TO SPEAK BECAUSE THEY ALREADY KNOW THEY WILL NOT BE HEARD.

ASK MAGAZINE | 11
organization has adequate capabilities and controls in place do 

deal with it effectively.

Say, for example, that the undersea photograph represents 

a project that involves scuba diving with sharks. If one judges 

that swimming with sharks is dangerous and believes that the 

organization does not have adequate scuba-diving training 

capabilities, depth of knowledge about shark habits, scubadiving equipment maintenance policies, practices of regularly 

feeding sharks, and explicit contingency plans in case something 

goes wrong, he may be inclined to think this to be a Mission 

Impossible or a Crisis Waiting to Happen project. 

The Big Challenge: The project is perceived by the observer 

as very risky, but the organization is perceived as having the right 

capabilities in place to effectively face and manage the risks. 

A Walk in the Park: The project is perceived as low risk (the 

observer perceives sharks or this situation as relatively harmless), 

and the organization is thought to excel in capabilities, policies, 

and preparedness to effectively deal with this type of project. 

Just Another Day’s Work: The observer perceives the 

project as low risk and does not believe the organization has 

adequate capabilities and level of preparedness to deal with it. 

The likelihood of the risks are small and the consequences, if 

they do happen, will be minor.

Different stakeholders of your project—project team 

members, auditors, management, quality, finance, compliance, 

and other units within and outside the organization—

are likely to have different risk perceptions, positioned in 

different quadrants. Multidisciplinary teams consisting of 

representatives from different departments and professional 

backgrounds bring different areas of expertise and provide 

multiple points of view, and potentially reduce risk blind 

spots. Some key members of your team may judge the project 

as Mission Impossible or a Crisis Waiting to Happen, while 

management may consider it a Walk in the Park or Just 

Another Day’s Work. If these differences in risk perceptions 

are ignored or not understood and addressed, the project may 

not only lack necessary support from key stakeholders but also 

be headed for a predictable project surprise.

Bridging Risk-Perception Gaps

The RPM helps to overcome communication gaps and defense 

mechanisms by providing a template and a visual tool for 

structured discussions about risk-perception differences. By 

making these differences visible, it makes it much harder to 

ignore or discount them. Evaluating risk-perception differences 

becomes an explicit part of project work.

By focusing on capturing, showing, and understanding 

diverging risk views, the RPM complements other risk 

management information-gathering techniques and processes. 

It is especially useful when an organization’s existing risk 

management processes do not provide adequate, sanctioned, 

open, and trusted channels and processes to capture and address 

differences in risk perceptions or when teams become biased or 

so concerned with reaching consensus and converging to a single 

“risk score” that they fail to evaluate important risk-perception 

gaps. It can also help reduce the chances of predictable project 

surprises and increase the chances of project success. ●

PEDRO C. RIBEIRO is the founder of Stratech/TheProjectOffice. 

A director of the Risk Management SIG and a former member of 

the board of PMI Educational Foundation, he is the author of the 

book Licoes do Titanic sobre Riscos e Crises (Lessons from the 

Titanic on Risk and Crises), the article “Sinking the Unsinkable: 

Lessons for Leadership” (ASK Magazine, Issue 47, Fall 2012), 

and has contributed to the PMI Practice Standard for Project Risk 

Management. E-mail: pedrocribeiro@stratech.com.br

Image Credit: Pedro C. Ribeiro

Figure 1. Risk-Perception Map.

LOW

LOW

HIGH

HIGH

MISSION IMPOSSIBLE

“A CRISIS WAITING TO HAPPEN”

THE BIG CHALLENGE

JUST ANOTHER DAY’S WORK A WALK IN THE PARK

PERCEIVED RISK-RESPONSE CAPABILITY

PERCEIVED RISK LEVEL

12 | ASK MAGAZINE
Capstone team from the 

University of Michigan.

By LAURIE STAUBER

Looking for solutions to vexing technical problems can sometimes yield 

serendipitous results. Here at Glenn Research Center, the search for new 

medical expertise that will be needed for long-duration spaceflight has led 

to an unexpected, mutually beneficial relationship with several universities.

reubat Seuri Laf oyesturo cotohP

STORy | ASK MAGAZINE | 13
Crews on long-duration exploration missions beyond lowEarth orbit will need medical capabilities to diagnose and treat 

disease as well as to maintain health. The Exploration Medical 

Capability element at Glenn develops medical technologies, 

medical informatics, and clinical capabilities for different levels 

of care during those space missions. About two years ago, the 

Human Research Program (HRP) and Exploration Medical 

Capability (ExMC) project management team asked me to 

develop a Technology Watch solution for ExMC gap needs. 

ExMC gaps are areas where the agency has limited expertise. 

Industry, other agencies, or academia may already have some of 

that expertise or be in a position to develop it, but—since little 

had been published about these particular knowledge needs—it 

was difficult to gauge where that expertise and those capabilities 

were likely to exist.

My initial task involved gathering information specific to 

each gap need, preparing documentation, and then publishing 

in a variety of venues, including the Federal Laboratory 

Consortium (FLC) technology locator, and then online in both 

their national and Midwest newsletters. We held discussions 

at FLC meetings, both national and Midwest; at Cleveland 

Engineering Society, Bioenterprise, Nortech, and Baldwin 

Wallace University’s Center for Innovation and Growth. An 

additional document was published in the February 2012 

issue of NASA Tech Briefs magazine to attract other potential 

knowledge sources. And we created an ExMC brochure for 

wide dissemination at conferences, to organizations with 

potential interest, and on technology web sites throughout the 

Midwest region, including the Autoharvest site, an automotive 

industry foundation based in Detroit. As a result, we received 

many valuable contacts.

We made additional contacts in person or via teleconferences 

with many more organizations, including the Cleveland Clinic 

Foundation, University Hospitals, Case Western Reserve

University, University of Akron, Ohio State University, Procter 

& Gamble, United States Air Force School of Aerospace 

Medicine, Battelle Memorial Institute, University of Cincinnati, 

Northwestern University, Carnegie Mellon University,

Cleveland Bioenterprise, Baldwin-Wallace University’s Center 

for Innovation and Growth, the Mayo Clinic, National Institutes 

of Health, U.S. Food and Drug Administration, the Research 

Institute of Chicago, the Wright Brothers Institute, and others.

That extensive list seemed promising, but we made little 

progress with our industry associates since the commercial appeal 

of this work is limited. We found, however, that universities 

are clamoring for meaningful senior engineering projects that 

require minimal funding. In addition, the turnaround time of 

student projects is relatively short; they begin in the fall semester, 

and results are presented to Glenn in May at the close of the 

school year. Most universities categorize these senior projects as 

“capstones”—student assignments often performed as a team 

effort and culminating in final reports that are a curriculum 

requirement for graduation. 

We contacted regional universities based on geographic 

location and areas of specialization, with Glenn covering 

the Midwest. Our focus centered on universities that have a 

biomedical or biomechanical engineering department. I worked 

with either a department head or capstone advisory group at each 

university to develop the project, visiting Ohio State University, 

University of Michigan, University of Akron, and Wright State 

University to explain HRP and ExMC goals. The ExMC gap 

list was circulated among the appropriate faculty to determine 

a proper fit. Two or three potential topics were agreed upon, 

and then department advisors asked student teams to indicate 

their areas of interest. Given the demand for capstone work 

at multiple universities and the limited availability of funding 

and mentors, the program typically supports one project per 

university per school year.

At the close of their senior year, student teams present their 

findings. The university team provides Glenn with a final report 

that gives ExMC a valuable start on gap closure. This successful 

outreach activity also provides a meaningful experience for 

Glenn employees to act as a mentor or gap manager.

Aaron Weaver, of Glenn’s Bioscience and Technology 

Branch, commented, “During the mentoring experience, I felt 

it important for the students to guide their own development. 

They were not just responsible for developing the product; they 

WE fOuND ... ThAT uNIvErSITIES ArE 

CLAMOrING fOr MEANINGfuL SENIOr 

ENGINEErING PrOJECTS ThAT rEquIrE 

MINIMAL fuNDING. IN ADDITION, ThE 

TurNArOuND TIME Of STuDENT 

PrOJECTS IS rELATIvELy ShOrT; 

ThEy BEGIN IN ThE fALL SEMESTEr, 

AND rESuLTS ArE PrESENTED TO 

GLENN IN MAy AT ThE CLOSE Of ThE 

SChOOL yEAr.

14 | ASK MAGAZINE
ASA: Ntidero CtohP

Crews on long-duration missions beyond low-Earth orbit will need medical 

capabilities to diagnose and treat disease as well as to maintain health. 

ASK MAGAZINE | 15
were responsible for the development of the requirements, how 

the requirements would be verified, product development, and 

testing. This gave the students a feel for the entire design process 

and led to a great learning experience and final product.”

The capstones provide an inexpensive mechanism to obtain 

first-rate research results. According to ExMC Project Manager 

DeVon Griffin, “The Exploration Medical Capabilities element 

originally conceived of capstones more as an education/outreach 

activity. Given the high-quality work produced by teams mentored 

by GRC [Glenn], the element is now working to provide targeted 

research options and archiving all results. This activity has become 

a key part of the element’s technical work.” Dr. Griffin mentored 

both of the University of Akron teams in 2012.

NASA Glenn’s Human Research Program/ExMC project 

sponsored three student-capstone projects that were completed 

in 2012, including bone stabilization in microgravity and threephase medical suction, filtration, and containment designed for 

a microgravity environment, both carried out at the University of 

Akron; and a wrist-fracture stabilization device for microgravity 

at the University of Michigan, mentored by Dr. Weaver.

The goal of the University of Akron team was to develop 

solutions addressing the agency need for a medical suction 

device for use in a microgravity environment. They built a 

proof-of-concept device that met the requirements of their labtesting protocol. While the students were not able to conduct 

microgravity testing, they did conduct extensive computationalfluid-dynamics simulations to verify performance. Additionally, 

they conducted 1 g testing for validation in a gravitational field.

The goal of the University of Michigan team was to create 

a device that would immobilize the wrist, protect a fracture 

from external perturbations, maintain hand function for 

daily work, and have low mass and volume. At the close of 

the semester, the students determined the device was on track 

to be validated and that it functioned as designed. Rachael 

Schmedlen, student advisor for biomedical engineering at the 

University of Michigan, noted, “This is the first opportunity 

students have had to work with a real client and design, build, 

and test a prototype that aims to solve a need. They receive an 

appreciation for the practical challenges with the development 

of a new device.”

Six additional student-capstone projects have been carried 

out in 2013, including diagnosing and treating radiation sickness, 

University of Akron, mentored by Debra Goodenow-Messman 

of the Diagnostics and Data Systems Branch; treatment of softtissue injuries during Exploration-class missions, University of 

Michigan, mentored by Dr. Griffin of the ISS and Human Health 

Office; medical-suction fluid containment for microgravity 

and partial-gravity environments, Northwestern University, 

mentored by John McQuillen of the Fluid Physics and Transport 

Branch; medical device sterilization, Ohio State University, 

mentored by Lauren Best of the Bioscience and Technology 

Branch; eyewash in microgravity, Wright State University, 

mentored by McQuillen; and medical suction in microgravity, 

University of Illinois–Chicago. (This last capstone uses a NASA 

topic but has no NASA oversight or financial support.) The cost 

associated with the ExMC capstone projects ranges from $0 to 

$2,000 per project, with funding provided by HRP.

Mark Ruegsegger is assistant professor of practice in the 

biomedical engineering department at Ohio State University. 

He remarked, “This has been a very rewarding experience for 

the students. They have been able to work on an open-ended, 

real-world problem that has application beyond medicine in 

space. The team has also gained valuable skills in working with 

NASA professionals as project consultants.”

The university student-capstone projects have the potential 

to be expanded to assist other core competency areas at Glenn 

Research Center. The obvious benefits to the agency are low 

cost, relatively quick results in the form of a final report, and a 

fresh perspective on a serious technical challenge. ●

Laurie Stauber is currently the Bioscience Collaboration and 

Partnership lead at Glenn Research Center and is responsible for 

business development focused on biomedical work with external 

partners. She is also the Exploration Medical Capabilities Tech Watch 

agent for the Human Research Program, formulating university 

capstone projects to solve long-term astronaut health issues.

ThE uNIvErSITy STuDENT-CAPSTONE PrOJECTS hAvE ThE POTENTIAL TO BE 

ExPANDED TO ASSIST OThEr COrE COMPETENCy ArEAS AT GLENN rESEArCh 

CENTEr. ThE OBvIOuS BENEfITS TO ThE AGENCy ArE LOW COST, rELATIvELy 

quICK rESuLTS IN ThE fOrM Of A fINAL rEPOrT, AND A frESh PErSPECTIvE 

ON A SErIOuS TEChNICAL ChALLENGE.

16 | ASK MAGAZINE
Robonaut and a spacesuit-gloved 

hand are extended toward each 

other to show collaboration.

ASA: Ntidero CtohP

STORy | ASK MAGAZINE | 17
That was the headline that grabbed my attention and 

ultimately led to my participation in a formal mentoring 

program. ACES is an acronym for Advancing Careers and 

Employee Success. The agency-supported program is designed 

to help employees achieve their potential, to help NASA meet 

the challenges of a changing workforce, and to contribute to 

making NASA a strong learning organization. The headline 

attracted my attention because I had been looking for a way 

to gain a greater understanding of NASA as a whole and reach 

beyond the circle of my day-to-day working network. When I 

think about where I want to be in five or ten years, I am not 

sure I still want to be in my current role. I thought a mentoring 

experience would be a good first step in exploring other areas 

of interest. 

Step One. Apply. This was a simple process of completing 

an application and getting supervisory approval to participate in 

the yearlong program.

Step Two. Mentor Match. That was not as straightforward 

as step one. There were two options: (1) specifically request 

a mentor or (2) opt for being matched with someone within 

a pool of available mentors. Not sure which option would 

be best, I focused on my goals. I wanted my mentor to have 

experience-based NASA knowledge in a field that aligned more 

specifically with my academic background in communication 

and knowledge management. I wanted someone who had an 

interesting job, who would readily tell stories about the work, 

and who would be willing to expose me to his professional 

world and network.

That was when I remembered the “From the Academy 

Director” articles from ASK Magazine by Edward Hoffman, 

NASA chief knowledge officer (CKO) and former director 

of the Academy of Program/Project and Engineering 

Leadership (APPEL). I remember being drawn in by the 

headings: “I Would Prefer Not,” “Saturdays with Sinatra,” 

“Don’t Trust Anyone Under Thirty,” “And the Band Played 

On.” In these brief essays, Ed communicates a pointed lesson 

while underscoring the important work of NASA ... all within 

a few paragraphs. I remember repeatedly shaking my head in 

agreement as I read them.

I thought, “Ed meets all my ’would likes’ in a mentor. He 

has significant experience-based NASA knowledge. He is a 

gifted storyteller. He has an interesting job that is outside my 

functional area and professional network.” I realized having 

Ed agree to be my mentor would be a big reach. He was the 

CKO of NASA. At the time, he was also the director of APPEL. 

He worked at NASA Headquarters in Washington, D.C. I 

worked at Glenn Research Center in Cleveland, Ohio, as the 

Scientific and Technical Information manager in the Logistics 

and Technical Information Division. Maybe even more of an 

obstacle, Ed had never heard of me and was not listed in the 

pool of available mentors. What made me think he would even 

consider mentoring me?

Calling all mentees and mentors for ACES class of 2012–2013.

18 | ASK MAGAZINE
The first thing I did was comb through the application 

materials to see if the fine print required a mentee and mentor 

to be located at the same center. I could not find any such 

requirement. I did find a line that read, “If you need more 

information, please contact the program manager.” When I 

asked her if a mentee could be matched with a mentor located at 

a different center, she responded, “Who do you have in mind?” 

I replied with hesitation and a wince, “Dr. Edward Hoffman 

at Headquarters.” 

To my surprise she did not scoff or chuckle, but replied, 

“I have known Ed for over twenty years. I will give him a call 

and let you know.” The rest, so to speak, is history. I sent Ed 

an e-mail describing myself and why I requested him as a 

mentor. He graciously agreed to the match without so much as 

a prescreening phone interview. 

I later asked him why he was willing to become my mentor. 

His answer: “You seemed genuine in your interest, smart about 

the work, and passionate about your motivations. That is an 

unbeatable combination, so I felt it was important to support 

you in your growth and journey.”

Step Three. Partnership Defined. The program kicked 

off with an orientation session. New mentees were joined by 

experienced mentors to meet and network—think “speed 

dating,” but in this case, it was “speed mentoring” to define 

the roles and responsibilities of both mentors and mentees 

and outline the organization of the program. My mentoring 

partnership officially began during a half-day mentoring 

workshop. Ed traveled to Glenn from Headquarters to

participate and to meet me for the first time in person. In one 

of the first e-mails I received from Ed, he wrote, “There are 

many things going on across the agency in terms of knowledge, 

so I will look to give you the opportunity to take part. I’ll 

start making a list of areas of potential interest for you and 

importance to NASA.” 

Our formal action plan identified agreed-upon developmental 

experiences that would be of the greatest benefit to me. The 

mentoring agreement clarified the goals for learning, determined 

the structure for meetings, and established norms for the 

partnership. The program also specified individual assessments 

and evaluations at various checkpoints to allow for proactive 

adjustments, if needed. These tools not only provided a road map 

for keeping the mentee–mentor partnership on track, they also 

defined expectations for both of us.

Step Four. The Experience. Ed introduced me to individuals 

in his professional network, included me in agency knowledge 

working groups and activities, invited me to the annual NASA 

Knowledge Community Forum at Kennedy Space Center, and 

introduced me to knowledge management scholars. He provided 

me not only with a peek through the window of his professional 

world, but also access to people and projects that I would have 

not otherwise been exposed to or known about. For example, 

in an e-mail sent to some of his colleagues, he wrote, “I want to 

introduce you to Natalie Henrich, who I am mentoring. Natalie 

is from Glenn and works Scientific and Technical Information 

activities, among other assignments. She will be involved in our 

knowledge work and I want you to know her.”

When I was asked to write this article for ASK Magazine, 

the editors urged me to be honest and paint an accurate picture 

of my mentoring experience, including Ed’s accessibility (or 

lack thereof). At that moment, I remember thinking that 

people enter mentoring relationships for different reasons. Some 

may want to gain experience outside their immediate working 

groups; senior professionals close to retirement may pair with 

junior employees to pass on knowledge; some may want to 

learn particular new skills from experts with unique expertise. 

There are many reasons to seek out a mentoring partnership. In 

my case, I wanted to hear the stories of an experienced NASA 

employee and be exposed to a new field. My goal was to watch 

Ed Hoffman talks about his 

transition into the role of 

NASA chief knowledge officer.

ykbyr HmaililW/ASA N:tide CrothoP

ThE MENTOrING AGrEEMENT CLArIfIED 

ThE GOALS fOr LEArNING, DETErMINED 

ThE STruCTurE fOr MEETINGS, AND 

ESTABLIShED NOrMS fOr ThE PArTNErShIP.

ASK MAGAZINE | 19
and learn. In truth, my expectations were in check from the 

moment I requested Ed as a mentor. 

I knew we were geographically separated, so weekly meetings 

or casual run-ins would not be part of the experience. I figured 

he was extremely busy and likely traveled a great deal, so there 

would probably be times when he would not be immediately 

available. All that was okay with me. In reality, I found Ed to 

be accessible via phone and e-mail. He shared great stories with 

me about his experiences at NASA over the years. He not only 

allowed me to “watch and learn,” but encouraged me to “ask 

and participate.” On more than one occasion, he prompted me 

to ask questions and let him know if I wanted to participate in 

an activity he was involved with or working on. My expectations 

were not only met, but exceeded.

Step Five. Lesson Learned. From this mentoring 

experience, I learned to “reach for it.” NASA is a place where 

“reaching for it” happens on a daily basis, whether it is reaching 

to launch a vehicle into space, land a rover on Mars, or become 

one of the best places to work in the federal government. My 

“reach” was to connect with Ed Hoffman and do all I could 

to listen and learn. Ed supported my reach and strengthened 

it by inviting me into his professional network, encouraging 

me to participate, and making time to be accessible to answer 

questions and offer suggestions for navigating the organization.

Step Six. Thanks. I would like to thank Ed for mentoring NataLie HeNriCH serves as the Scientific and Technical 

Information manager of the Logistics and Technical Information 

Division at Glenn Research Center. She earned her BA in 

communication from Denison University in Granville, Ohio; MA in 

communication and education from Columbia University; and MS in 

knowledge management from Kent State University in Kent, Ohio.

me this past year; my supervisors, Richard Flaisig and Seth

Harbaugh, for supporting my participation in the program; and

NASA for supporting employees with professional growth and

learning opportunities. Mentoring programs like this one make

me optimistic that NASA will continue to develop knowledge, 

which leads to innovations that help the agency realize its vision: 

To reach for new heights and reveal the unknown, so that what 

we do and learn will benefit all humankind. ●

Knowledge Forum participants draw 

out their knowledge networks.

ASA: Ntidero CtohP

20 | ASK MAGAZINE
The Knowledge Management Journey

By EDWARD W. ROGERS

On May 13, 2003, I reported to work at Goddard Space Flight Center as the center’s “knowledge 

management architect.” Looking back after ten years there, I will try to summarize why knowledge 

management was successfully adopted at Goddard. Of course, the process was not as neat and 

orderly as this retrospective analysis may suggest; it was more of a journey of discovery with a few 

basic guiding principles to help keep me on course.

nn GuisrCh/ASA N:tide CrothoP

NASA employees are busy working on complicated 

missions, so finding knowledge management 

strategies that fit within hectic schedules is key.

INSIgHT | ASK MAGAZINE | 21
Take Time to understand 

what Fits the organization

The first thing I realized was that knowledge management 

would come across as a fad or a waste of time to the competent 

and busy people at Goddard—more than three thousand 

government employees and six thousand contractors on site—

unless what I did clearly met the organization’s real needs and 

suited its way of working.

I began by thinking about what Goddard actually does 

repeatedly as a business. What we “produce” over and over again 

is not any particular mission but the assembly and execution of 

a project. Because each project team has a different assignment 

and a different mission, people tended to think, “We never do 

the same thing twice. Lessons don’t apply since the mission is 

always unique.” But what we do over and over is put together 

a team to accomplish a mission. So that suggested what the 

knowledge management focus should be. Many of the lessons 

we should be learning had to do with how we manage those 

teams as much or more than the technology or design of a 

specific mission. To be useful, knowledge management would 

have to address issues of how we manage our projects, not just 

pass along test and failure data at the technical level.

One fact of working life was immediately clear: Smart 

people make rational decisions about how they spend their 

time. They rarely see value in management meetings and events 

designed to extract knowledge from them. On the other hand, 

they see high value in the exchange of knowledge among peers. 

The critical difference is whether individuals leave the meeting 

knowing more than when they came. I knew I would have to 

design knowledge sharing and learning sessions as “exchanges” 

and not knowledge-extraction activities.

I modified the After Action Review (AAR) concept used 

by the U.S. Army into a NASA process we called Pause and 

Learn (PaL). Most NASA projects last years; some go on for 

a decade or more. An AAR at the end of a long project would 

be almost meaningless with respect to design decisions made 

years earlier by people who may have left months or years 

before. So I introduced the idea of pausing during development 

at appropriate points to reflect on what has been learned so far. 

I called it Pause and Learn to make it unique to NASA and 

to distinguish it from an AAR. It focuses on group reflection 

and learning that will be valuable for the participants first and 

foremost. Participants are encouraged to share their perceptions 

of what happened and process the insights together. Because the 

PaL is local and real, it is seen as valuable. After PaL sessions, 

participants often comment that this was a lessons-learned 

activity from which they actually learned something.

Building on the PaL success, I focused on two other 

learning activities at Goddard. I set out to write case studies to 

help people think about the project and management aspects of 

retnet Chgilfecapd SraddoA GSA: Ntidero CtohP

While NASA projects are one of 

a kind, each has valuable project 

management and engineering 

lessons that can be learned and 

applied universally.

22 | ASK MAGAZINE
our missions in addition to the technical lessons. I also started 

holding interactive discussion sessions often using these case 

studies to engage people in learning from prior missions.

use Terms That have Meaning for people

Rather than talk up the value of knowledge management to 

a skeptical audience, I used words the technical workforce 

understood and cared about, things like “cost,” “schedule,” 

“reliability,” and “decision making.”

I argued, for instance, that knowledge had to be better 

organized and shared at the working level so Goddard could 

assemble teams more reliably. The hook I used to explain this was 

asking whether it was important which engineer was assigned 

to a project. Many project managers were quick to admit they 

spent much time trying to get the “A team” of engineers onto 

their project. I had my opening. If the engineering branch as a 

group shared and organized their knowledge effectively, then 

it would matter less which engineer was assigned, because any 

engineer would bring the network of knowledge from the entire 

branch to the project.

Similarly, good decision making is a practice that all 

managers treasure. Using case studies, we focused on improving 

decision making, something managers could recognize as an 

immediate benefit to them and their team. Project managers 

who thought of their projects as unique could see that decisionmaking processes are similar across projects and they could 

learn from others. So we connected knowledge management to 

something considered a core cultural attribute at Goddard: the 

ability to make good decisions.

brand your Knowledge activities

As the previous section suggests, what you call your knowledge 

activities and aims matters. While “knowledge management” 

didn’t resonate with project teams, “reliability” did. The names 

of things should tell what they are about and what their value 

is to your specific organization. So, for instance, I coined the 

term Pause and Learn to describe exactly what those sessions 

were for and to indicate that they were designed specifically for 

Goddard—not just imported from other organizations. 

Start with Small Steps 

and use what’s already There

The PaL sessions and case-study-based workshops I’ve described 

were relatively small-scale and opportunistic knowledge 

activities. Based in particular projects and designed to create 

immediate benefits to participants, they justify themselves 

with clear practical results and encourage others to take part in 

similar activities. These relatively modest initiatives are much 

more likely to demonstrate their value and win converts than 

big systems that take months or years to set in motion and 

seem to promise big improvements at some unspecified future 

date. One of the many pitfalls of those large-scale efforts is they 

demand time and effort from participants long before they give 

any value in return. And the fact that they have large, general 

goals means they are much less likely to ever produce useful 

results than more focused modest efforts.

Other people at Goddard were already playing around with 

wikis and collaboration tools. The action I took was to not shut 

things down or assume a command and centralize approach, 

except in areas of IT commodities such as search capability. The 

more local efforts the better, and the more grassroots sharing 

and learning the better. Whenever possible, I encouraged and 

showcased good things others were doing. In the government, 

there is often an assumption that things need to be hidden or 

cost-cutting managers will whack whatever is not part of their 

own agenda. Clearly, that kind of approach would not work for 

knowledge management, which is supposed to be about sharing 

and openness. 

Create demand and encourage Knowledge 

Management Converts and evangelists

Participants in successful knowledge activities who tell their 

peers how those events helped make their projects successful 

are your greatest allies—their stories will do more to promote 

your knowledge management work than any arguments, 

presentations, and advertising you offer. Encouraging others to 

“sell” knowledge management for you helps make up for the 

fact that a chief knowledge officer only has so many hours in the 

day and can’t do it all alone.

On a similar note, the best way to ensure that valuable 

knowledge management activities become a robust and persistent 

part of how your organization does business is to “reproduce” 

yourself. Start investing in people who can take over significant 

parts of what you do as early as possible. You don’t want to be 

the sole source on knowledge management energy and therefore 

a single point of failure.

Taking time to share knowledge in the moment, such as 

with Pause and Learn sessions, provides an opportunity 

to learn and apply lessons before a project ends.

retnet Chgilfecapd SraddoG/tfihseulA BSA: Ntidero CtohP

ASK MAGAZINE | 23
Ten Myths about Knowledge Management

These positive lessons about making knowledge management 

work suggest why some of the commonly held beliefs about 

knowledge management don’t work. Here is my top-ten list of 

false assumptions about knowledge management. Think about 

them as recipes for failure that should be avoided.

10. Culture can be mandated from the top.

9. C ollaboration can be “purchased” or sharing can be 

rewarded.

8. K nowledge management can be outsourced.

7. A nybody (who isn’t busy) can do knowledge management.

6. K nowledge management can be done by buying the 

right software.

5. K nowledge management can be independent of the 

business process.

4. C ommunities of practice can be established by the top.

3. Knowledge management is about centralizing knowledge 

content to use it more efficiently.

2. K nowledge management is really about databases.

1. K nowledge management is an IT function and should 

be given to the chief information officer.

As simple as these errors are, they are repeated over and 

over by people who hope that those failed approaches will work 

this time. If anybody ought to learn these lessons, it should be 

the people whose job is sharing lessons learned, but that is sadly 

often not the case. A main source of these repeat failures is the 

assumption that myth number seven doesn’t apply. Over the 

years, I have met dozens of knowledge management managers 

in various government agencies with no relevant experience who 

were assigned to “go do knowledge management” and given 

budgets to do it. One scientist-turned-knowledge-managementexpert told me she had a $2 million budget and no idea what 

knowledge management was but was eager to find out. Another 

told me confidently, “I’ve got knowledge management all figured 

out. It’s just a matter of getting the right software systems in place.” 

Ten million dollars and five years later, this same person told a 

public meeting, “We now know that knowledge management 

is 80 percent people and only 20 percent software”—which he 

could and should have known at the outset. This is an expensive 

way to educate government leaders. 

The Knowledge Management Journey

At the outset, I described my ten years at Goddard as a journey 

of discovery. Some might say I haven’t accomplished much by 

their metrics. I am the first to admit I haven’t accomplished all 

I wanted to do. When people go on a journey they often notice 

different things. It depends what you’re looking for. What I’m 

looking for and what I see is NASA as a vibrant, dynamic, 

pulsating organization—almost a living organism that needs 

to stay healthy. Knowledge management is an ongoing effort. 

When you join a gym, it’s not buying a membership that gets 

you in shape—you actually have to go there to work out and 

keep doing it. I set out to create exercises that would help 

Goddard be a stronger and healthier knowledge organization 

over time. I feel confident that those exercises are paying off and 

improving Goddard’s knowledge fitness. ● 

... rELATIvELy MODEST INITIATIvES ArE MuCh MOrE LIKELy TO DEMONSTrATE ThEIr 

vALuE AND WIN CONvErTS ThAN BIG SySTEMS ThAT TAKE MONThS Or yEArS TO SET 

IN MOTION AND PrOMISE BIG IMPrOvEMENTS AT SOME uNSPECIfIED fuTurE DATE.

24 | ASK MAGAZINE
Creating NASA’s Knowledge Map

By MATTHEW KOHUT AND HALEy STEPHENSON

Need to understand something about engine cutoff sensors, the physiological impact of extended 

stays in low-Earth orbit, or how to drive a rover on Mars? That kind of specialized expertise exists 

at NASA, and often nowhere else. But where does that unique know-how live? How and where 

is it captured and shared? NASA’s interactive knowledge map serves as a springboard for helping 

practitioners find what they don’t know and share what they do.

INSIgHT | ASK MAGAZINE | 25
To paraphrase science-fiction writer William Gibson, NASA’s 

knowledge is not evenly distributed. Sometimes the people who 

know something and the people who need to know it don’t 

connect. NASA’s missions continue to increase in complexity, 

teams become more distributed, and technology advances. At 

the same time, Apollo and shuttle generations are disappearing. 

All these factors make knowledge-sharing connections critical 

to organizational success. 

While learning from its successes and failures is at the core of 

NASA’s work, its track record for doing so is also unevenly distributed; 

the agency has done better in some instances than others. 

Developing a more consistent knowledge capability across 

the agency was part of what motivated the Aerospace Safety 

Advisory Panel, a Congressionally established advisory group, 

to recommend that NASA “establish a single focal point (a chief 

knowledge officer) within the agency to develop the policy and 

requirements necessary to integrate knowledge capture across 

programs, projects, and centers.” 

In response, newly appointed NASA Chief Knowledge 

Officer Ed Hoffman convened the first meeting of NASA’s 

knowledge community—individuals identified by center 

directors and mission directorate associate administrators as 

chief knowledge officers or points of contact—in January 2012. 

Their discussions revealed an abundance of knowledge work 

happening across NASA’s centers, mission directorates, and 

cross-agency organizations: forums, lunches, case studies, 

databases, online expert-locator systems, and more. Some 

activities were well established and well known, while others 

were just getting started.

This big picture was an eye-opener. The knowledge 

community decided to develop a comprehensive index of the 

services available across the agency. And so began their initiative 

to create an interactive map—a knowledge map—that made 

NASA’s knowledge services findable to all. 

it Started with a Spreadsheet

After the inaugural meeting, Mike Lipka, the knowledge 

point of contact for NASA’s Safety Center, took the initiative 

to document the services community members had described 

at the initial meeting. He organized what he’d captured in a 

simple matrix that paired each NASA organization with the 

knowledge services provided, using an ad hoc taxonomy to 

categorize those services by type (for example, online portals 

versus publications).

Lipka’s initial exercise laid the groundwork for a more 

systematic data-gathering effort to create a dynamic, online tool 

for visualizing and engaging with NASA’s knowledge resources 

and services. 

Each knowledge organization subsequently participated in indepth interviews about the work within their organizations over 

the next several months. The resulting data set was impressive and 

large. The community needed a structured way to communicate 

about the great work going on across the agency. 

a Vocabulary for Knowledge at naSa

Unsurprisingly, the knowledge services described by the chief 

knowledge officers and knowledge points of contact in their 

interviews took many forms. Some activities were “self-service,” 

ThE KNOWLEDGE COMMuNITy DECIDED 

TO DEvELOP A COMPrEhENSIvE INDEx 

Of ThE SErvICES AvAILABLE ACrOSS 

ThE AGENCy.

26 | ASK MAGAZINE
ASK MAGAZINE | 27

such as typing a query into a search box or watching a video. 

These services work well for explicit knowledge that doesn’t 

require a lot of context or personal judgment. For instance, the 

fundamentals of earned value management can be codified, 

broken down, and expressed as a series of concepts without 

requiring a world-class subject-matter expert. 

At the other end of the spectrum, some activities 

emphasized tacit knowledge, which is dependent on context 

and personal judgment. This kind of sharing usually requires 

social interaction. A master practitioner’s knowledge about 

how to interpret ambiguous test data or make a go or no-go 

launch decision cannot be transferred through a Google search. 

Though technology can helpfully extend the reach of a personal 

story, it doesn’t provide the full experience of face-to-face 

communication or hands-on learning. 

The community agreed upon a set of categories to describe 

the range of knowledge activities taking place across NASA. 

Online Tools. Any online knowledge tools, including but 

not limited to portals, document repositories, collaboration 

and sharing sites, and video libraries.

Search/Tag/Taxonomy Tools. Dedicated search engine 

for knowledge (e.g., Google Search Appliance) and any 

initiatives related to meta-tagging or taxonomy.

Case Studies/Publications. Original documents or

multimedia case studies that capture project stories and 

associated lessons learned or best practices.

Lessons Learned/Knowledge Processes. Any defined 

process that an organization uses to identify or

capture knowledge, lessons learned, or best practices, 

including the Lessons Learned Information System 

vetting process, organization-specific lessons-learned

processes, benchmarking, use cases, knowledge-sharing 

recognition programs, knowledge product validation 

processes, and communications about expectations related 

to knowledge sharing.

Knowledge Networks. Any defined knowledge network, 

such as a community of practice, expert locator, mass 

collaboration activity, or workspace specifically designed to 

enable exchanges and collaboration. 

Social Exchanges. Any activities that bring people together 

in person to share knowledge (e.g., forums, workshops, 

Lunch and Learn/Pause and Learn). The reach of these 

activities can be multiplied through online tools such as 

videos and virtual dialogues.

The categories are not the only ones that could have 

been created, and they are not a perfect fit for every 

knowledge activity at NASA, but they provide a means for 

making useful distinctions among different activities. The 

knowledge community decided to adopt these categories in

January 2013, agreeing that this terminology could be improved 

in the future. 

This vocabulary provided the knowledge community 

with a foundation for talking about their services, tools, and 

activities with each other, the practitioners they serve, and the 

agency’s stakeholders. For instance, online tools such as the Jet 

Propulsion Laboratory’s Wired wiki or Marshall Space Flight 

Center’s ExplorNet satisfy different knowledge needs than the 

lessons learned and knowledge processes at Goddard Space 

Flight Center or the Human Exploration Operations Mission 

Directorate. The community wanted to do more than just talk 

about these services, however—they wanted to see them. 

Visualizing Knowledge at naSa

Seeing is believing, and visualizing a knowledge landscape can 

promote increased sharing. 

The data the knowledge community aggregated serves as 

a starting point: what is happening, who is doing it, and how 

can others access it? The community recognized that their data 

would change and grow over time. Creating a visualization that 

could accommodate that evolution meant thinking beyond 
what the word “map” usually brings to mind: subways, floor 

plans, theme parks, and possible buried treasure. 

Instead, the map needed to be a kind of Rubik’s cube, 

allowing the data to be sliced in multiple ways as the data set 

became richer and larger. This interactivity would allow users 

to browse the community’s data set as it currently existed—by 

knowledge category, center or organization, and knowledge 

point of contact—and as it could exist in the future—by 

discipline, topic, accessibility, or any other variable. 

Just as the community wanted its data openly displayed 

on the map, it also wanted the map itself to be broadly 

accessible online. This meant the map needed to be "platform 

independent": it shouldn’t matter if a user had an iPhone or an 

Android tablet. Their access to the data and experience with the 

map should be the same. To satisfy this requirement, the map 

development team decided to build the map using HTML5, 

a coding language that achieved the vision of making the 

map accessible across all platforms. If you have an Internet 

connection and a browser, you can browse the current map of 

NASA’s knowledge services at km.nasa.gov/knowledge-map.

where the Map leads next

The NASA knowledge map represents a step forward in 

NASA’s evolution as a learning organization. It is the first 

online tool of its kind that aggregates the knowledge work 

happening across NASA, making it a springboard for NASA 

practitioners and stakeholders to access resources to find 

answers and solve problems. 

It demonstrates a commitment and dedication to greater 

transparency about the knowledge services available across 

the agency. While some resources remain protected behind 

firewalls, the community has identified the services available 

within each organization and provided points of contact. 

The map does not resolve the challenge of making 

knowledge universally accessible across organizational lines, 

but it is a step toward building more resilience into NASA’s 

knowledge infrastructure. There’s plenty left to do. Half the 

NASA workforce is eligible for retirement and could walk out 

the door with critical knowledge that has not yet been passed 

on to others. Young professionals at the other end of the career 

path have had fewer opportunities than previous generations at 

NASA to get hands-on experience. 

In short, the 2013 NASA knowledge map is a beginning, 

not an ending. It will continue to grow as other organizations 

within NASA share their knowledge resources and as the 

knowledge needs of NASA practitioners evolve. ●

ThIS INTErACTIvITy WOuLD ALLOW uSErS TO BrOWSE ThE COMMuNITy’S 

DATA SET AS IT CurrENTLy ExISTED—By KNOWLEDGE CATEGOry, CENTEr Or 

OrGANIZATION, AND KNOWLEDGE POINT Of CONTACT—AND AS IT COuLD ExIST 

IN ThE fuTurE—By DISCIPLINE, TOPIC, ACCESSIBILITy, Or ANy OThEr vArIABLE.

28 | ASK MAGAZINE
Lessons on Leadership: The Evolution 

of the Radiation Protection Project

By KEITH L. WOODMAN AND DEBI TOMEK 

ll HieleeSt/ASA N:tdier CgeamI

Learning how to deal with radiation is crucial 

for long-duration human spaceflight.

Occasionally, you get the rare, pleasurable experience of watching a project flourish even when 

confronted with seemingly insurmountable challenges. The Radiation Protection Project started as 

a vague idea on how to address one of the largest inhibitors to maintaining long-duration human 

presence in space. This project survived multiple transitions, including having the work split 

between two organizations. In overcoming these odds, it has become an excellent example of how to 

formulate, stand up, and run a multicenter, mid-technology readiness level (TRL) project integrated 

across different organizations. 

INSIgHT | ASK MAGAZINE | 29
this white-paper call with a workshop held at Langley where the 

white-paper authors could present in an open forum. During 

this workshop, Tomek opened the proceedings by telling the 

audience that, given the complexity of this technical problem, 

no one center could solve it alone. Centers would have to find a 

way to work collectively to enhance NASA’s expertise. 

This face-to-face meeting was critical. Those who wanted 

to participate in the project were able to make their cases. 

At the same time, Tomek and the other project leaders were 

given enough information to start making informed choices 

on which technologies needed to be funded in order to meet 

agency and programmatic goals. The collaborative “kick-start” 

this workshop produced was evident when Tomek was pulled 

aside during one of the breaks by a well-known scientist familiar 

with the usually argumentative radiation community. This 

scientist pointed out two individuals speaking at the back of 

the room. He said, “Those two scientists have refused to talk 

to one another for ten years, and now they are discussing how 

to collaborate!” While this was a great start for the new project, 

encouraging the cultural shift needed to promote collaboration, 

a huge problem was just over the horizon. 

lesson Two: Fight for what’s right

In 2010, the human exploration program decided to shut down 

ETDP and create the Exploration Technology Development and 

Demonstration (ETDD) Program, a completely new program 

under new management. During the formulation of ETDD, 

the human exploration program also decided that Radiation 

Protection would not be its own project but a technical element 

under the Life Support and Habitation (LS&H) project. 

Many involved in the effort felt this was a major 

miscalculation. They knew that the enormity of the radiationprotection problems warranted a separate project. However, a 

new project could not be funded due to budgetary constraints, 

so the Radiation Protection Project transferred as a technical 

element under LS&H. This presented additional challenges in 

TOMEK’S INSISTENCE ThAT “EvEryONE hAvING A vOICE” NO MATTEr ThEIr rOLE 

Or CENTEr AND ThE TruST GAINED frOM TEAM MEMBErS ThrOuGh hEr 

INTErEST IN uNDErSTANDING IDEAS AND SOLuTIONS CrEATED AN ATMOSPhErE 

Of TrANSPArENCy AND TEAMING ThAT ENCOurAGED COLLABOrATION INSTEAD 

Of COMPETITIvENESS BETWEEN CENTErS.

30 | ASK MAGAZINE
trying to maintain the portfolio of radiation technologies that 

were under development within a project grouping that was not 

related to radiation protection. 

The umbrella project was understandably very concerned 

about maintaining the full complement of their portfolio and 

having to share funding with the now embedded radiation 

work. Considerable negotiation, persuasion, and soft skills were 

required to restore project funding to its original levels. This 

involved conversations with individuals at centers and NASA 

Headquarters and “telling the story” of radiation protection: how 

driving toward a solution in support of long-duration human 

spaceflight involved focused funding and collaboration across 

the agency. The project could not afford to lose the ground that 

had been gained. Even with reduced funding at the inception, 

then delayed funding because of the budget environment, the 

project team still managed to hit all their milestones and embark 

upon building the foundation for radiation protection. 

project addressing this vital technical area, and so programmatic 

AES managers pulled the radiation work out from under another 

project and stood Radiation Protection up as its own project. 

At the same time, a portion of the existing portfolio was moved 

to the STP Game Changing Office as the Advanced Radiation 

Project (ARP). Tomek was selected as the project manager of this 

newly emergent project, but now the original ETDP project had 

been split between two different mission directorates. 

Because of NASA programmatic and full-time employee 

constraints, the decision was made that the AES project would 

be led out of Johnson Space Center with Tomek as the deputy 

project manager. Johnson then selected a very experienced and 

talented project manager from the now canceled Constellation 

program, Bobbie Gail Swan, to serve as the project manager. 

While switching the project from Langley to Johnson 

could have created tension within the team, both Swan and 

Tomek strove to maintain continuity and synergy within 

the existing team. Swan met with, talked to, and, most 

importantly, listened to Tomek and the team members who 

had been working on the project the previous two years. They 

discussed at great length the project’s history and its way 

forward. These initial meetings helped the two leaders build 

a deep mutual understanding and respect. This concordance 

was evident to all team members during meetings, setting the 

tone of highly effective collaboration between centers. Team 

members saw the leaders exhibiting synergy and taking what 

could have been interpreted as a negative for the technical 

discipline into a positive. This, in turn, promoted a spirit of 

collaboration and freedom to share ideas among the whole 

team. The project now had two fine leaders who were working 

hand in hand. 

During this same period, Tomek, as ARP project manager, 

was able to develop a portfolio of work within this sister 

project that was complementary to the work being done in 

the AES project. The thought was that as these STP radiation 

technologies matured, they could potentially be infused into the gnarta Suhson Jamrir Aoine, Secror Fi. AS.: Utidero CtohP

Above Bear Lake, Alaska, the 

Northern Lights, or aurora borealis, 

are created by solar radiation 

entering the atmosphere at the 

magnetic poles. 

“ThOSE TWO SCIENTISTS hAvE rEfuSED 

TO TALK TO ONE ANOThEr fOr TEN 

yEArS, AND NOW ThEy ArE DISCuSSING 

hOW TO COLLABOrATE!”

ASK MAGAZINE | 31
AES project for further development and integration into flight 

vehicles and/or habitats. As project manager of the STP project 

and the deputy project manager of the AES project, Tomek was 

able to oversee a successful integration between the projects.

This good working relationship between the project 

managers seemed to permeate and influence the rest of the 

project. Langley’s primary responsibility is the design and 

development of various types of protection shields for solarparticle events. This team includes various research scientists, 

systems and vehicle analysts, developmental engineers, 

technicians, and resource analysts. It was amazing how quickly 

this diverse group came together and started producing. 

Tomek’s insistence that “everyone having a voice” no matter 

their role or center and the trust gained from team members 

through her interest in understanding ideas and solutions created 

an atmosphere of transparency and teaming that encouraged 

collaboration instead of competitiveness between centers. Tomek 

encouraged the team to think beyond traditional methods of 

radiation protection. As a result, they have made great strides in 

furthering protection technologies. The project will soon fly its 

radiation dose-measurement technology (dosimetry technology) 

on EFT-1. It has already flown to the International Space Station 

for ongoing crew testing. 

lesson Four: replace good leadership 

with good leadership

In 2012, Tomek was selected for NASA’s Mid-Level Leader 

Program (MLLP). As part of this program, she was also selected 

to serve a detail to NASA Headquarters, working with Associate 

Administrator Robert Lightfoot, that has resulted in her using 

her strong leadership skills to assist in a restructuring of technical 

capabilities across the whole agency. Swan, Tomek, and Langley 

management decided that David Moore, who was the systems 

engineer for the shielding work, would replace Tomek as the 

Radwork’s acting deputy manager and as the acting project 

manager for the Advanced Radiation Project. Although Moore’s 

background and experiences were different from Tomek’s, they 

shared a vision of the success of the radiation projects and what 

it would take to get there. The transition was seamless. 

With Moore taking on these leadership roles, the projects 

continued to meet or exceed their programs’ expectations with the 

development of new dosimetry and shielding technologies. Upon 

completion of the MLLP, Tomek was selected as technical advisor 

to Langley’s Center Director’s Office, so the position for the 

Radworks deputy manager and the Advanced Radiation Project 

manager was advertised. Moore competed and was selected. Now 

officially in the position, he is facing challenges because of budget 

cuts caused by the sequestration. As all good leaders do, he is 

adapting, rescoping, and focusing on mission success. ●

KeitH L. woodmaN is manager of the Exploration Research 

nd Development Office at Langley Research Center. He is also 

n adjunct professor for the American Public University system, 

eaching graduate-level courses for the department of space 

tudies. After taking his first APPEL course over ten years ago, 

e became a devotee of the subject of engineering management, 

arning a PhD from Old Dominion University in 2011. 

a

a

t

s

h

e

ASA: Ntidere CgamI

The sun emits radiation that can cause 

cellular damage to humans in space.

32 | ASK MAGAZINE
Title

By 

Intro

In 2004, my group in the Space Department 

of the Johns Hopkins University Applied 

Physics Laboratory (JHU/APL) was presented 

with a critical opportunity and challenge. 

We had successfully developed and deployed 

spacecraft flight software on a number of 

NASA missions over the previous decade. 

They included the Advanced Composition 

Explorer, a spacecraft at a point of Earth–

sun gravitational equilibrium almost a

million miles from Earth; an Earth orbiter 

(Thermosphere, Ionosphere, Mesosphere

Energetics, and Dynamics mission); the NearEarth Asteroid Rendezvous spacecraft; the 

twin Solar Terrestrial Relations Observatory 

probes; and missions destined for the inner 

t h e r oa d 

to the new

flight software

By CHRISTOPHER KRUPIARz

Cutaway model of the Earth’s Van Allen radiation belts with the two satellites from NASA’s Van Allen Probes, 

the first mission to fly the new Applied Physics Laboratory flight-software architecture.

ASA: Ntidere CgamI

and outer solar system (Mercury Surface, 

Space Environment, Geochemistry, and 

Ranging spacecraft and New Horizons). 

Over the course of that decade, our flight 

software had become tightly coupled, with 

changes in one application affecting others. 

We were able to reuse the software during this 

time, but doing so depended on reusing the 

same avionics and the same personnel. When 

teams or hardware changed, the software was 

difficult to apply to new missions without 

substantial modification. It was clearly time to 

revamp our core architecture, but we wanted 

to do it in a way that preserved many of our 

existing applications while modernizing the 

overall structure.

STORy | ASK MAGAZINE | 33
The Robotic Lunar Lander fires its onboard thrusters to carry it to a controlled landing using a pre-programmed descent profile. Guidance and control (G&C) 

development at the Applied Physics Laboratory is a collaborative effort between the flight-software group and the Marshall Space Flight Center G&C analysts’ group.

Bruce Savadkin, my group supervisor at the time, recognized 

this need. Through proposals to the JHU/APL Internal Research 

and Development board, he successfully acquired funds to work 

toward this goal. Our first step was to identify software that 

would decouple our software architecture and allow individual 

applications to operate independently. This study led us to select 

an architecture developed by NASA Goddard Space Flight 

Center, called the Core Flight Executive (cFE). 

integrating the Core Flight executive

CFE is a suite of software that provides multiple services 

to flight-software applications. A key to these services is a 

software communication bus, or transfer interface, that makes a 

modular, decoupled architecture possible. Instead of individual 

applications calling functions within other applications

and creating intractable dependencies among them, cFE 

communication occurs via message passing. An application 

publishes messages and subscribes to messages on a software 

bus, providing a single input source to the application. With a 

well-defined message dictionary that various applications can 

understand, this provides a straightforward way to plug and 

play new applications into a system. 

Once that middleware was selected, we began adapting 

our flight software to the cFE concept. Transitioning to a new 

architecture took a significant amount of rethinking. We had 

been working with our current architecture for years; we fully 

understood its idiosyncrasies, its advantages, and its limitations. 

The new architecture required a new way of thinking. 

Additionally, some in the group were reluctant to change. 

Their reluctance came with strong arguments, including, “We 

just launched a probe to Mercury. Why change a successful 

architecture?” and “Why not wipe the slate clean and rebuild 

from the bottom up?” (The answer to the first question was, “We 

need to improve our ability to reuse code to lower costs,” and to 

the second, “Too expensive.”) So our development process was 

not only technical. It included a necessary series of discussions 

to bring those who were reluctant to change onboard. 

As the initial lead on the project, it was my responsibility 

to handle these questions and to find a way forward for the 

design. Leading a team on a research effort this large was a new 

experience for me. Unfortunately, I quickly learned lessons on 

how not to do it. Whereas my previous efforts with large teams 

had specific requirements and goals, this research effort was 

much more open ended; we had to answer the question, “What 

is good?” before we could build the software. So my usual project 

management method of trying to reach an agreement on small 

issues while we all agreed on the larger purpose immediately 

ran into trouble. Not surprisingly in hindsight, when you ask 

a group of experienced flight-software engineers what a good 

architecture is, you get multiple answers. As a result, we had 

many false starts that resulted in slower progress than I had 

originally hoped.

To address the problem, we identified a couple of key 

personnel who had strong technical reputations within the group 

as well as extensive flight-software experience and asked them to 

define a path forward. While it would not meet the impossible 

goal of unanimous consent, we knew that their experience 

and the trust they inspired meant it would be well received. 

At the end of the effort, the team had encapsulated enough 

of our heritage code in cFE applications to demonstrate that 

we could have the best of both worlds: a modular architecture 

that leveraged our past success. We had shown that cFE was 

adaptable to our architecture. Now we just needed a mission to 

prove it.

mahtobniggid HivaD/retnet Chgile Fcapl SlahsraA MSA: Ntidero CtohP

34 | ASK MAGAZINE
As it happened, we had two: the Radiation Belt Storm 

Probes (now called the Van Allen Probes) and the Robotic 

Lunar Lander program. 

The Van allen probes

The Van Allen Probes are twin spacecraft studying the Van Allen 

radiation belts. They are also the first mission to fly the new

JHU/APL flight-software architecture based on cFE. Mark Reid, 

flight-software lead for the mission, was instrumental in advancing 

the architecture. He began his prototyping work in Phase A, 

working closely with the mission operations and integration and 

test teams—the ones who interact most with our software.

Naturally, they were accustomed to operating a spacecraft 

in a certain way. Familiarity with institutional procedures from 

mission to mission is a key to the success of our spacecraft. When 

introducing cFE, Mark focused on ensuring it would not disrupt 

those procedures. He avoided cFE features that fit Goddard’s 

operational model but would have been too disruptive of APL’s 

procedures. Mark also did early benchmark testing of cFE 

operations to understand their impact on resource utilization. 

We expected to see an increase in processor and memory usage, 

since we understood that cFE is more complex than directly 

coupling software. Mark’s team’s measurements showed that 

cFE would work within the computing constraints of the 

spacecraft. He also found that focusing on software that was not 

dependent upon external communication made it possible to 

reuse a significant amount of our code base while transitioning 

to the new architecture. 

On the whole, the cFE integration was a success. The 

primary difficulties the team encountered were not with the 

code itself. Auxiliary tasks that come with managing a large 

body of code—for instance, version control, bug fixes, and 

updates—caused the greatest difficulties. Because Goddard 

was developing its own spacecraft while also supporting cFE, 

it was understandably difficult for them to respond to requests 

from outside the organization. Fortunately, Mark and his 

team developed strong personal relationships with Goddard 

personnel, which ensured focused responses to our needs.

The robotic lunar lander

The Robotic Lunar Lander development article is a joint effort 

between JHU/APL and the Marshall Space Flight Center. To 

understand how cFE operated within the lander, I exchanged 

e-mails with Gail Oxton, who was the flight-software lead 

through a significant part of development. She and her team were 

responsible for developing the guidance and control algorithms 

that would fly on the test vehicles. Marshall developed the 

command and data-handling functionality and sensor interfaces.

Guidance and control (G&C) development at APL is a 

collaborative effort between the flight-software group and the 

G&C analysts’ group. The analysts develop G&C models via 

MATLAB to accommodate the constraints and requirements 

of a given mission. Once that work is complete, they turn to 

Simulink to auto-generate flight code that is then delivered 

to the flight-software group and integrated into our flight 

software. For the robotic lander, Gail devised an initial plan to 

deliver the auto-generated C code for the G&C models directly 

to Marshall. But as Gail remarked, “That can be a challenge 

when the G&C analysts and the software team are on different 

floors, let alone in different states.” 

She decided instead to implement G&C as an entire 

cFE application so the interface between Marshall and APL 

would be solely over the software bus. Needing to define only 

a small set of messages for communication removed potential 

AT ThE END Of ThE EffOrT, ThE TEAM hAD ENCAPSuLATED ENOuGh 

Of Our hErITAGE CODE IN CfE APPLICATIONS TO DEMONSTrATE 

ThAT WE COuLD hAvE ThE BEST Of BOTh WOrLDS: A MODuLAr 

ArChITECTurE ThAT LEvErAGED Our PAST SuCCESS. WE hAD 

ShOWN ThAT CfE WAS ADAPTABLE TO Our ArChITECTurE. NOW WE 

JuST NEEDED A MISSION TO PrOvE IT.

ASK MAGAZINE | 35
dependencies within the code. This was a step forward in both 

collaboration and software reusability; it would be the first time 

we delivered a cFE application externally.

To achieve this solution, Gail developed an interface control 

document that defined all software bus traffic. This involved a 

range of data including clock ticks, sensor input, and commands 

from Marshall’s command and data handling to APL’s guidance 

and control, and thruster fire commands, attitude data, and

other telemetry from G&C to command and data handling.

Over the next few months, each team separately developed

and tested their applications. When the APL G&C application 

was delivered to Marshall, the Marshall team successfully

integrated the G&C application in literally a few hours. Gail

had one brief, over-the-phone debug session to identify an

array indexing problem on day two, but after that the software 

worked flawlessly. Over time, Gail’s team delivered algorithm 

improvements to Marshall. Each delivery was similarly smooth. 

The Robotic Lunar Lander continues to have many successful 

test flights.

When asked about the experience, Gail summed it up this 

way: “We had no prayer of getting this to work in the timeframe 

and funding we had without cFE.”

Solar probe plus and the Future of cFe

As flight-software lead for the Solar Probe Plus project, I am

working with my team to further the architecture. We are

striving to make the software even more reusable and cost

effective through configuration values, parameters, and tables

that can reduce the amount of rework from mission to mission, 

relying instead on configuration variables to modify the

software. We are also working with the Van Allen team to avoid 

some procedural difficulties encountered on that project.

CFE and Goddard’s larger Core Flight System, of which 

cFE is a part, continue to achieve recognition outside Goddard. 

It is not only performing flawlessly on the Van Allen Probes 

and the Marshall lander, but it is also being used on projects 

such as Johnson Space Center’s Morpheus effort, the Ames 

Research Center’s Lunar Atmosphere and Dust Environment 

Explorer, and Goddard’s Lunar Reconnaissance Orbiter, Global 

Precipitation Measurement spacecraft, and the Magnetospheric 

Multiscale mission. CFE can work for an organization that 

has no existing flight-software experience or architecture; 

it can also work, as we showed, for an organization with an 

existing architecture. CFE and the Core Flight System have the 

potential to serve as a basis for other NASA missions, reducing 

costs and simplifying the process of developing software for the 

full fleet of NASA spacecraft. Currently, Goddard has to turn 

to individual missions to improve cFE on a mission-by-mission 

basis. What the Van Allen experience has shown us is that 

Goddard (and NASA in general) has a strong product available 

for use by the NASA community. As the user base grows, we 

hope institutional support will grow with it. ● 

CHriStoPHer kruPiarz is a member of the Johns Hopkins 

University Applied Physics Laboratory (JHU/APL) principal 

professional staff. He is currently the assistant group supervisor 

of the JHU/APL Embedded Applications Group and flight-software 

lead for the Solar Probe Plus mission.

NOT SurPrISINGLy IN 

hINDSIGhT, WhEN yOu ASK 

A GrOuP Of ExPErIENCED 

fLIGhT-SOfTWArE 

ENGINEErS WhAT A GOOD 

ArChITECTurE IS, yOu GET 

MuLTIPLE ANSWErS.

A simulated view of the sun illustrating the trajectory of Solar Probe Plus during 

its multiple near-sun passes. The Applied Physics Laboratory is flight-software 

lead for the project, working to further the Core Flight Executive architecture.

ASA: Ntidere CgamI

36 | ASK MAGAZINE
Ta l e s f r o m a 

Five-Sided 

Building

By STEPHEN GARBER

STORy | ASK MAGAZINE | 37

What is it like to work at the Pentagon? From November 2012 to April 2013, I 

was fortunate enough to do a six-month “detail” there. I worked in a policy office 

within the Office of the Secretary of Defense, which is roughly analogous to NASA 

Headquarters as an agency-level organization that oversees military services and 

numerous smaller agencies. It was a rewarding experience where I learned every 

day. Not only did I learn a great deal about the two main policy issues I had in my 

portfolio, I also observed the different organizational culture at the Department of 

Defense’s (DoD) headquarters. Although the atmosphere wasn’t much different from 

what one might expect, I found some details interesting and potentially relevant to 

other organizations, including NASA.
One stereotype that turned out to have validity is that military 

people follow directions well, as opposed to many civilians who 

often don’t follow directions, even when it’s in our best interest. 

One morning I dropped off a prescription at the commercial 

pharmacy in the Pentagon. The pharmacist said she’d check 

if it was in stock and notify me. She left a voice message that 

afternoon, saying the medicine was in stock and that I should 

print out a coupon for a discount. When I listened to the voice 

message, I didn’t really understand what she meant about 

the coupon. Most people might have given up there to save 

themselves some headache, but I Googled the medicine and 

found a web site for it with a coupon for first-time patients. 

When I gave the coupon to the pharmacist, she explained that 

it allowed me to receive the medicine for free, saving me about 

$70. The pharmacist told me that in other locations where 

she’d worked, patients typically wouldn’t print such coupons, 

even though it was in their best interest. DoD people (and not 

just those in military uniforms) take direction well. Perhaps 

this illustrates a common foible of human nature outside the 

military—we are often too proud to accept advice. 

Another well-known facet of military services is that 

service members rotate among assignments frequently. In 

addition, there is considerable turnover among civil servants 

and contractor staff. Perhaps that’s inevitable, since there are 

more than 20,000 people who work at the Pentagon. Not 

surprisingly, defined structures and work processes are key when 

personal institutional memory may be lacking. Cross-training 

government employees to do different kinds of work is usually 

mutually beneficial, allowing the organization to reduce single 

failure points and motivating and engaging employees. Given 

the constant churn of personnel at DoD, leaders there tend to 

view cross-training as more essential than at NASA. 

When I first arrived at the Pentagon, I had a couple of weeks 

with a military officer on our team who I knew would soon 

retire. After he gave me two neat, chronologically organized 

binders with materials on a policy issue I would soon take over 

for him, I asked him for copies of his relevant electronic files. He 

responded that all his work files, like those of others in the office, 

were stored on a shared drive with a file structure that turned out 

to be easy to understand. Before my detail, I had made sure to 

copy all my NASA work files to a shared drive, but many of my 

file folders were arbitrarily named. At least in the Office of the 

Secretary of Defense Space Policy, the electronic file structure 

was self-evident and thus fairly straightforward for employees 

to find needed documents. When I returned to NASA, one of 

the tasks my boss asked me to work on was pulling together 

documentation for our various contract history projects in a 

way that all members of our office could easily access. Because 

people often stay for long periods of time in their jobs at NASA 

and thus acquire substantial detailed subject-matter expertise, 

if a subject-matter expert is out of the office for any reason it 

sometimes becomes a single point of failure. We at NASA likely 

could do better in terms of “knowledge management” to avoid 

this problem. 

The fact that people move around so much at DoD, 

perhaps combined with respect for hierarchy, yielded another 

notable organizational culture facet: a strong implicit emphasis 

on teamwork. While working on various aspects of two 

space-policy issues, I interacted with people from a variety of 

organizations who brought different perspectives and expertise. 

Underlying our interactions was the notion that regardless of 

where we worked or our specific backgrounds, we each had 

something to contribute to the issues at hand. Thus everybody 

worked together cooperatively. I didn’t witness any bureaucratic 

“steamrolling” or people trying to pull rank, presumably because 

the hierarchy was clear. Also, people rarely asked for others’ 

personal perspectives; we all represented a particular office or 

institutional perspective. At NASA, I’ve seen more latitude for 

individual personalities and ways of doing business, which can 

be a pleasant form of teamwork or it can be dysfunctional. 

Relatedly, virtually everybody I encountered at DoD was 

respectful of other people. This is hardly a surprise, but the 

manners I saw exhibited on a daily basis were instructive. In 

an orientation class, one presenter cautioned that we should not 

refer to a superior by his or her first name in casual conversation 

unless we’d feel comfortable addressing that superior by first 

name to his or her face. Two colleagues refused to call me 

anything but “sir” even after I suggested a few times that we call 

ThE fACT ThAT PEOPLE MOvE ArOuND 

SO MuCh AT DOD, PErhAPS COMBINED 

WITh rESPECT fOr hIErArChy, yIELDED 

ANOThEr NOTABLE OrGANIZATIONAL 

CuLTurE fACET: A STrONG 

IMPLICIT EMPhASIS 

ON TEAMWOrK.

38 | ASK MAGAZINE
each other by our first names. (I suppose I technically outranked 

them, although I don’t think they knew that.) I began calling 

others at work “sir” or “ma’am” and found this encouraged me 

to be polite, especially when dealing with frustrating customerservice situations outside work. This was a change of pace 

from NASA, where the administrator, a retired general, asks 

employees to call him by his first name. Presumably long ago, 

NASA Administrator Charles Bolden wisely adapted to NASA’s 

more informal culture, but I’ve always addressed him as “sir” 

when I see him in the hallways. 

Although there was good-natured teasing among my team 

at DoD, people rarely talked disparagingly about a person 

who wasn’t in the room. Initially, I didn’t consciously realize 

this admirable aspect of DoD’s culture. Even at NASA, with a 

deserved reputation as a “can do” organization, sometimes we 

waste emotional energy and time complaining about people or 

things we don’t like. Not everything was or is perfect at DoD, 

but I find focusing on the positive to be a helpful tactic in many 

practical ways.

Another way in which mutual respect is demonstrated at 

DoD is people don’t check their phones during meetings. The 

reason for this is simple: such portable electronic devices are 

prohibited from almost all offices and meeting rooms in the 

Pentagon for security reasons; this has the added benefit of 

ensuring respectful attention to speakers.

DoD employees multitask in another way, however: using 

classified and unclassified systems almost simultaneously. 

Everybody has at least a secret clearance and uses at a minimum 

two separate computers: one classified and one unclassified. For 

security reasons, these computers connect to separate systems. 

Thus everybody has at least two e-mail addresses. Since most of 

my work was on the unclassified system, I could ask colleagues 

who sent me messages on the classified network to let me know 

via phone or unclassified e-mail to check my secure e-mail. 

Conversely, I asked my boss to give a specific colleague, who 

spent most of his time on a highly classified system to which I 

didn’t have access, a heads up when I’d sent him an unclassified 

e-mail. While a little cumbersome, this informal system 

sufficed to keep work flowing in separate channels. Because 

the vast majority of NASA employees, even those with security 

clearances, do not have such computer setups, this arrangement 

isn’t usually necessary at NASA. 

Another aspect of my experience that I keep coming 

back to is that policy has a significant footprint at DoD. 

The Undersecretary of Defense for Policy oversees perhaps 

one thousand people who are divided into various geographical 

and functional offices. The Space Policy Office, a group 

of about twenty people divided into three branches, has 

significant influence despite its relatively small size, and it 

is only one of several DoD players in space policy. There is 

The Pentagon, headquarters of the Department of Defense. 

ecror Fi. AS., Udnomman He. Ktgr SetsaM/esnefef Dt onemtrape: Dtidero CtohP

ASK MAGAZINE | 39
An illuminated American flag is 

displayed at the Pentagon near 

the spot where American Airlines 

Flight 77 crashed into the building 

on September 11.

yva. NS., Uezluhc. Sn Wadnars Bsalt Csr 1eciffy OtteP/esnefef Dt onemtrape: Dtidero CtohP

40 | ASK MAGAZINE
another office called the DoD Executive Agent for Space 

that also deals with space-policy issues. Then there are other 

people in a number of staff offices who work on space policy 

from various angles (e.g., various air force components, legal, 

and procurement). DoD is much larger than NASA, so it 

makes sense that there are more people working on spacepolicy issues at the Pentagon.

In practice, only a small number of people do policy 

analysis at NASA, and these people are forced to cover many 

issues. In fact, the term “policy analyst” seems to have different 

meanings at DoD and NASA. I was heartened to see the 

number and range of DoD people thinking about the complex 

space-policy issues that both civilian and national security (and 

often commercial as well) space communities face. Sometimes 

my head would spin a bit after sitting in on discussions about 

internal DoD directives or DoD perspectives on national 

space-policy issues, as it seemed people were debating how 

many angels would fit on the head of a pin. Yet people had 

time to think through the issues, and people in the field paid 

attention to the carefully crafted language in these policies. 

Simply put, words matter. Ideally it’d be nice if there were at 

least a few more NASA policy people at Headquarters to help 

think through similar various perspectives. 

Another facet of DoD’s organizational culture that was 

apparent is there seems to be more administrative support at 

the Pentagon than at NASA Headquarters, and most of these 

positions are filled by contractors. This may seem like a luxury 

to NASA people who are accustomed to more minimal support, 

yet these highly capable administrative professionals increased 

the efficiency of workflow. In particular, schedulers made 

arranging meetings vastly easier and freed the “principals” to do 

other things. More administrative support seems like a relatively 

small investment that’s worth it whenever possible because it 

yields great benefits in operational efficiency. 

As a sidelight, I was also impressed with one administrativesupport contractor who helped me numerous times and basically 

ran the office. He had a terrific “let’s get it done” attitude. 

Although he expressed interest in working at NASA, this former 

sailor was awarded with a fairly high-level civil-service job in 

another DoD office. He is truly a standout who typifies the best 

of enthusiastic, capable employees at both DoD and NASA. 

Of course, leadership and management are all about the 

people. Beyond the exciting, important missions that NASA 

and DoD have, an organizational culture focused on setting 

the conditions for employees to thrive makes all the difference. 

Reflecting on the different natures of the two organizations 

and missions, it is heartening to see that both DoD and NASA 

strive to take care of their people. We have much to learn from 

each other. ●

Of COurSE, LEADErShIP AND MANAGEMENT 

ArE ALL ABOuT ThE PEOPLE. BEyOND 

ThE ExCITING, IMPOrTANT MISSIONS ThAT 

NASA AND DOD hAvE, AN OrGANIZATIONAL 

CuLTurE fOCuSED ON SETTING ThE 

CONDITIONS fOr EMPLOyEES TO ThrIvE 

MAKES ALL ThE DIffErENCE. 

StePHeN garber has worked in the NASA History Program 

Office for a number of years and recently completed a sixmonth detail at the Department of Defense. Read more about 

his experiences at the Pentagon and during a six-month detail 

in NASA’s Office of Legislative and Intergovernmental Affairs in 

the 2013 third-quarter issue of NASA History News and Notes at 

history.nasa.gov/histnews.htm.

ASK MAGAZINE | 41
Big Data—The Latest Organizational Idea-Movement 

By LAURENCE PRUSAK 

The Knowledge Notebook

Since the Second World War, something like 

forty-five major idea-movements have swept

through both public and private organizations.

They include early time-and-motion studies,

the quality movement, reengineering, human

potential, and many, many others. Some of these 

movements promulgate genuinely new ideas;

some recycle old approaches under new names. I 

am quite certain every reader of this column who 

has spent more than a few years in an organization 

has been the beneficiary—or the victim—of at 

least one or two of them. 

What accounts for the often disruptive change 

that seems to erupt every few years (the new ideas 

then either becoming embedded in the way we 

work or forgotten forever)? Well, for one thing 

there is money to be made from selling new ways 

to make organizations more efficient, innovative, 

or profitable. Consultants, technology vendors,

motivational speakers, and the like all need new 

ideas to gain audiences and keep them interested. 

The same is true of the business press. It isn’t 

always possible to fill a journal with compelling 

stories every month or even every quarter unless 

there are new ideas to discuss or develop. 

Some other factors contribute to the phenomenon. 

The boredom experienced by many managers 

who yearn for something new to try is one that 

reinforces their genuine desire to actually produce 

useful results for their organizations. There is 

also the pure uncertainty faced by all who try to 

improve the performance in their work life—and 

increasingly their home life as well. There is little 

real science to guide organizational behaviors;

the “science” of organizations lacks the clarity and 

testability of engineering or biology. Therefore, one 

can make a substantial case for an organizational 

improvement idea on more specious grounds than 

the purer sciences allow. Cases, logic, and rhetoric 

all play their roles in persuading people to follow 

the latest idea. Because those things are easier and 

less costly to develop than the findings of real 

science, there are virtually no barriers to entry. 

Finally, the fact that so many of the movements 

that promise so much in principle deliver so little 

in practice (except disappointment) drives people 

to latch on to the next great new idea and hope that 

this one will live up to the hype.

Now we have big data, or “business analytics” 

as it is sometimes called. It addresses issues of 

capturing, storing, organizing, and interpreting 

large quantities of data and extols the benefits of 

those efforts. This movement is just about at the 

height of its influence, in my opinion. It is more 

global in scope than some of the others I have 

mentioned, due to the increasing globalization of 

the market for business ideas as well as the almost 

total dissemination of information technology 

know-how across the developed and most of the 

developing world. 

Like the quality movement, big data has much 

to recommend it. Analytic software has been used to 

do everything from studying baseball dynamics to 

predicting customer preferences. You can read and 

hear many stories of how those analyses uncovered 

new opportunities and supported good decisions. 

New applications for data combing, analytics, and 

gaming are being developed every day. 

There is still the question, though, of what 

one does with all this analyzed data. Some of the 

proponents of big data suggest that the software 

itself can tell you what to do, but in fact the 

42 | ASK MAGAZINE
results of these analyses are almost never self-evident. Human 

judgment and experience-based knowledge are still called for to 

understand and give meaning to the data and decide what to 

do with it.

If this were not the case, we would barely need human 

managers at all—just let the machines run our organizations. 

In fact, the plethora of data being produced by all the new 

monitoring and social-media usage require more—not less—

human intervention in running any organization. Without 

human reflection and interpretation, the data remain inert and 

ambiguous. Doing what the data itself “tells” you to do—or 

seems to tell you—can actually cause harm. 

The dream of self-running organizations, organizations 

where little human intervention is needed and so-called

objective data itself continuously optimizes performance, is a 

long-standing fantasy that should be limited to sci-fi literature 

but can be found in business magazines, books, and schools.

So, like some other movements, big data seems to have 

some real potential but also the potential to be misused and 

overpraised. Maybe it is not possible at this point to determine 

the proportion of good to bad. The one thing we do know for 

sure is that some other movement will come along to replace it 

within a few years. ● 

... ThE PLEThOrA Of DATA BEING 

PrODuCED By ALL ThE NEW MONITOrING 

AND SOCIAL-MEDIA uSAGE rEquIrE 

MOrE—NOT LESS—huMAN INTErvENTION 

IN ruNNING ANy OrGANIZATION. WIThOuT 

huMAN rEfLECTION AND INTErPrETATION, 

ThE DATA rEMAIN INErT AND AMBIGuOuS.

ASK MAGAZINE | 43
ASKinteractive

For More on 

Our Stories

Additional information pertaining 

to articles featured in this issue can 

be found by visiting the following 

web sites:

• KSC Swamp works: www.

facebook.com/pages/SWAMPWORKS-at-NASAKennedySpace-Center/536736493017273

• Applied Physics Laboratory:

www.jhuapl.edu

• NASA Knowledge Map: 

km.nasa.gov/knowledge-map

Mars 2020

NASA has announced plans for a new robotic science rover set to 

launch in 2020. Designed to advance high-priority science goals for 

Mars exploration, the mission would address key questions about the 

potential for life on Mars. The mission would also provide opportunities 

to gather knowledge and demonstrate technologies that address the 

challenges of future human expeditions to Mars. NASA’s plans include 

openly competing the opportunity for the mission’s specific payload 

and science instruments. Learn more about the 2020 plan and the 

current science definitions for the mission at mars.jpl.nasa.gov/m2020.

NASA Apps

If you’re looking for another way to keep up with NASA news on the 

go, the agency has a collection of apps tailored for general overviews 

and updates, photos, missions, on-demand video, International Space 

Station tracking, and more. Check out all the latest apps at www.nasa.

gov/connect/apps.html.

NASA in the News

NASA announced a Grand Challenge focused on finding all asteroid 

threats to human populations and knowing how to deal with them. Grand 

Challenges are ambitious goals on a national or global scale that capture 

the imagination and demand advances in innovation and breakthroughs in 

science and technology. The challenge is a large-scale effort that will use 

multidisciplinary collaborations and a variety of partnerships with other government agencies, international partners, 

industry, academia, and citizen scientists. It complements NASA’s recently announced mission to redirect an asteroid 

and send humans to study it. To read more about the challenge and respond to NASA’s request for information, visit 

www.nasa.gov/asteroidinitiative.

feedback

44 | ASK MAGAZINE
Did you know you can receive ASK digitally?

To subscribe for e-mail alerts or download issues and articles, 

visit askmagazine.nasa.gov.

If you like ASK Magazine, 

check out ASK the Academy. 

ASK the Academy is an e-newsletter that offers timely news, updates, 

and features about best practices, lessons learned, and professional 

development. Learn more at askacademy.nasa.gov.
National Aeronautics and Space Administration

NASA Headquarters

300 E Street SW 

Washington, DC 20546

www.nasa.gov