Academy Sharing Knowledge

The NASA Source for Project Management and Engineering Excellence | APPEL SPRING | 2012

National Aeronautics and Space Administration

Inside

GALEX: MAnAGinG 

thE UnEXpEctEd

thE MiLLion-MiLE REscUE

BUiLdinG thE WAtson tEAM

S p e c i al Not i ce to O u r Sub s c ri b e rs —Pa g e 1
hcetlaC-LJP/ASA N:tide CrothoP
Contents

15

Departments

3

In This Issue 

By Don Cohen

4

From the Academy Director

NASA’s Knowledge Imperative

By eD hoffman

52

ASK Bookshelf

54

The Knowledge Notebook

The Greeks Had Many Words for It

By LaurenCe Prusak

56

ASK Interactive

InsIghts

15

The Million-Mile Rescue

By the nasa safety Center Procedural 

errors made while modifying software 

threatened a solar-observatory mission.

19

Efficiency Through Document 

Automation

By roBert DeLwooD Careful observation 

of work practices helps automation 

specialists simplify document creation.

26

Interview with Lisa May

By Don Cohen The program exec for 

MAVEN talks about how science missions 

are chosen and managed.

37

Managing Multicultural Teams

By ConraDo morLan For this IT project, 

cultural competence was as important as 

technical know-how.

5 11

To Our Subscribers 

ASK Magazine is updating its print subscription list. 

If you wish to continue receiving ASK in the mail after the Summer 

2012 issue, you MUST notify us at ASKmagazine@inuteqllc.com. 

Please put “Continue ASK” in the subject line and include your 

name and organization (if any) in the text.

ASK MAGAZINE | 1
Issue no. 46

Staff

acaDemy DIrector anD publIsher

Dr. Edward Hoffman

ehoffman@nasa.gov

eDItor-In-chIef

Laurence Prusak

larryprusak@gmail.com

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 real-life 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.

If you wish to continue receiving ASK in the mail after the Summer 2012 issue, you 

MUST notify us at ASKmagazine@inuteqllc.com. Please put “Continue ASK” in 

the subject line and include your name and organization (if any) in the text. 

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

Hanta Ralay

hanta.ralay-1@nasa.gov
In his “From the Academy Director” column, Ed Hoffman 

says, “Knowledge is the coin of the realm at NASA,” and 

discusses the challenges of “identifying, capturing, and 

sharing” the wealth of valuable knowledge the agency 

possesses. These are the goals of knowledge management, 

which is about making essential knowledge available and 

usable where and when it is needed in an organization.

When we consider knowledge and NASA, we probably 

think first about technical knowledge—the countless 

insights the agency has gained over the decades into how 

to engineer spacecraft and launch vehicles, and its wealth 

of accumulated scientific findings. As Laurence Prusak 

points out in “The Knowledge Notebook,” though, there 

are many kinds of knowledge. Purely technical knowledge 

(say the behavior of a particular material in the vacuum of 

space) is near one end of a spectrum that extends to much 

less explicit expertise—for instance, knowledge of how 

to meld disparate groups into a collaborative team. The 

difficulties of communicating technical knowledge effectively 

are real but may be ultimately less challenging than teaching 

the subtler lessons of how to get the work done (among 

many other skills, how to guide and inspire people, how to 

recognize problems before it’s too late, how to adapt to the 

unexpected events that are inevitable in complex projects).

Several of the articles in this issue of ASK illustrate the 

critical importance of those so-called “soft” skills (which 

include, by the way, understanding when you need new

or better technical knowledge—one source of problems 

and failures on technical projects is thinking you know 

everything you need to know). In most of these cases, 

the most important contribution to solving both technical 

and organizational difficulties was to gather people in one 

place to work and talk together. So, for instance, much of 

the team that built IBM’s Watson computer (“Building the 

Watson Team”) spent their days in a single large room 

without cubicles or closed offices. That proximity supported 

the exchange of technical information and helped create a 

shared sense of mission.

Similarly, David Young’s discussion of planning for an 

important climate mission (“CLARREO: Bringing Disciplines 

Together”) describes how gathering scientists, engineers, 

and managers together as early as possible in the process 

can avoid later wasteful conflicts between what scientists 

want and what engineers (and budgets) can provide. And in 

the interview, Lisa May talks about how program execs in the 

Science Mission Directorate meet to share knowledge from 

the programs they help manage. And James Fanson offers a 

negative example of what can happen when you don’t bring 

people together in “GALEX: Managing the Unexpected,” 

telling how leaving an engineer alone to design a key 

component led to an unusable unit and the need to scramble 

for a replacement.

The articles here that focus on international collaborations 

add a further element to the kinds of knowledge needed 

to carry out projects successfully: cultural knowledge. “An 

Argentine Partnership with NASA,” “Managing Multicultural 

Teams,” and “International Collaboration on BepiColombo” 

all emphasize the importance of taking time—and spending 

time together—to learn the values and perspectives of 

team members from other cultures. The time together and 

the understanding it helps generate contribute to another 

essential element of project success: mutual trust.

Don Cohen

Managing Editor

In This Issue

ASK MAGAZINE | 3
Like all large, knowledge-intensive organizations, 

NASA faces continuous challenges identifying, 

capturing, and sharing what it knows effectively.

Knowledge is the coin of the realm at NASA. 

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.

At the same time, (to paraphrase sciencefiction writer William Gibson’s remark about 

the future) NASA’s knowledge is not evenly 

distributed. Sometimes the people who know 

something and the people who need to know it 

don’t connect. And valuable knowledge is at risk 

of walking out the door as NASA approaches a 

significant demographic shift: more than half the 

workforce is eligible for retirement. There’s a high 

likelihood that many senior employees will leave 

within five years.

The knowledge challenge extends to NASA’s 

failures. Our mishaps, accidents, and anomalies 

yield critical, hard-won lessons. We use rigorous 

investigation methodologies such as root-cause 

analysis to ensure that we discover why we made 

mistakes. Our track record of learning from these 

incidents has also been unevenly distributed; we’ve 

done better in some instances than others.

Developing more consistent knowledge capability 

across the agency was part of what motivated the

Aerospace Safety Advisory Panel (ASAP), an advisory

group established by Congress, to recommend that

NASA “establish a single focal point (a Chief 

Knowledge Officer [CKO]) within the agency to

develop the policy and requirements necessary 

to integrate knowledge capture across programs, 

projects, and centers.” ASAP acknowledged good

work in this area at Johnson Space Center and

Goddard Space Flight Center, and also recommended 

that all centers and mission directorates consider 

establishing CKOs to “ensure standardization.”

In response to the recommendation, I was 

appointed NASA’s CKO. In late February, I 

convened a meeting of the agency’s knowledge 

community, and we took inventory of knowledge 

services and activities at various centers and mission 

directorates. Frankly, I had not been fully aware of 

the quantity or quality of knowledge work going 

on across the agency before that meeting. In the 

weeks and months ahead, after our data-collection 

effort has been fully vetted, I will be writing more 

about the current state of knowledge services at 

NASA. It is an impressive story that I look forward 

to sharing. Both ASK Magazine and the online 

ASK the Academy, in a new regular feature called 

CKO Corner, will also begin highlighting efforts 

at different NASA centers and mission directorates.

I will remain the director of the Academy 

of Program/Project and Engineering Leadership 

as I assume the responsibilities of serving as 

NASA’s first CKO. This is a logical extension 

of the knowledge services the Academy began 

providing over a decade ago. I look forward to 

engaging deeply with the community of dedicated 

professionals that gathered in February to ensure 

that our technical workforce has the knowledge it 

needs to achieve mission success. As always, please 

feel free to contact me if you would like to share 

thoughts or ideas. ●

From the Academy Director

NASA’s Knowledge Imperative

By ED HOFFMAN 

4 | ASK MAGAZINE
They say that good things come in small packages, and this has 

certainly been true for NASA’s Explorer Program. Explorers are 

among the lowest-cost missions flown by NASA, but they can 

pack a big scientific punch. Such is the case with the Galaxy 

Evolution Explorer, or GALEX, a mission designed to map the 

history of star formation over 80 percent of the age of the universe. 

Since its launch nearly nine years ago, GALEX has transformed 

our understanding of how and when galaxies formed over time. 

Along the way, as the team anticipated, several unexpected and 

intriguing scientific discoveries have been made. What we did 

not anticipate was the gauntlet of technical and programmatic 

challenges that had to be overcome to get GALEX into orbit. 

XLEAG 

The Andromeda Galaxy, or M31, is our 

Milky Way’s largest galactic neighbor. 

The entire galaxy spans 260,000 lightyears across—a distance so large, 

it took ten GALEX images stitched 

together to produce this view of 

the galaxy next door.

Photo Credit: NASA/JPL-Caltech
There’s a widely held belief that smaller projects are easier 

projects. In reality, the difficulty of a project is measured by 

the ratio of available resources to the challenges being faced. 

Explorer missions by necessity have small budgets, so it’s 

critically important to assemble the strongest possible team 

and ruthlessly constrain the magnitude of the challenges. This 

is easier said than done. Take staffing for example. Smaller 

missions have fewer team members, so each is more crucial. One 

needs the sharpest individuals with unusually broad skills. It 

can be difficult to recruit such people in organizations where 

importance is measured by the size of the budget managed or 

the number of direct reports.

Similarly, smaller missions have fewer instruments and 

components, but each element therefore tends to be mission 

critical. GALEX is a single-string, single-instrument design with 

very limited redundancy. This has two immediate implications: 

each element must have high reliability, and virtually no 

component can be eliminated. One of the most important tools 

available to the manager is the ability to “descope” items in 

order to contain cost. When each element is mission critical, the 

descope tool is limited to accepting lower performance from an 

element rather than eliminating it outright.

Recognizing these facts, GALEX’s principal investigator, 

Chris Martin of Caltech, proposed a mission that was simple 

in concept and built around a team of experienced individuals 

and institutions. NASA selected the mission for implementation 

in late 1997. Thus set sail a hardy band of explorers into what 

would turn out to be an unusually stormy sea.

Keeping It Simple

The idea for GALEX was to fly a 0.5-meter-aperture telescope 

with a wide field of view together with two photon-counting 

detectors, one optimized for the near ultraviolet and one for 

the far ultraviolet. The detectors would simultaneously image 

a region of the heavens 1.5° in diameter via a dichroic beam 

splitter. A filter wheel would enable a grism—a combination of 

a prism and grating—to be rotated into the beam to produce 

spectra that could also be imaged on the detectors. The 

spacecraft would point the telescope at the desired location 

during the night side of each orbit and orient the solar panels 

to recharge the battery during the day side. Over a period of 

twenty-eight months, virtually the entire sky would be imaged. 

In practice there were some complications, such as not imaging 

stars bright enough to damage the detectors, but in general the 

mission design and architecture were quite simple.

We also felt that the mission required no new technology,

but we were to learn otherwise. To achieve the required 

ultraviolet sensitivity, we needed photon-counting microchannel 

plate detectors. These make use of specially prepared, thin, 

porous glass plates supported at their edges, stacked and held at 

IN REALITy, THE dIFFICuLTy OF A PROJECT IS MEASuREd By THE RATIO 

OF AVAILABLE RESOuRCES TO THE CHALLENGES BEING FACEd.

6 | ASK MAGAZINE
an electrical potential of several thousand volts. An individual

photon of light striking the front surface of the detector produces 

a shower of electrons at the back. The location of the electron

shower is measured by timing the arrival of electrical pulses

with an array of very high-speed electrical circuits. While these 

techniques had been used in earlier detectors, they had not been 

implemented individually or in combination on detectors of the 

size required for GALEX.

In the end the detectors proved very difficult to manufacture, 

even by the group at University of California–Berkeley,

considered the best in the business at this type of device. By the 

time we collectively recognized this fact, it was too late to reduce 

the size of the detectors, so we persevered and accepted delivery

many months behind schedule. We learned an important lesson: 

scaling technology is sometimes as difficult as maturing the basic 

technology in the first place. 

Paradigm Shift

GALEX began implementation during the height of NASA’s

faster-better-cheaper era, a period characterized by the desire to

find innovative approaches to reduce development cost, even

if it meant tolerating and managing increased risk. In keeping

with this paradigm, the GALEX implementation plan featured 

many cost-saving aspects, some of which involved cost and

schedule risk. Interestingly, GALEX was confirmed with what

today would be considered an absurdly low level of cost reserves: 

10 percent, or about $5 million in total.

What we did not see coming was the dramatic change in 

risk acceptance following the loss of the Mars ’98 and other 

smaller missions around this time. These mission failures sent 

a shock wave through NASA, which responded by overhauling 

the underlying implementation processes to be followed by every 

mission under development. By 2000, the paradigm had firmly 

shifted from “faster better cheaper” to “mission success first.” 

Many of the cost-cutting approaches taken by GALEX were 

no longer considered acceptable. The team came under major 

scrutiny by outside groups of reviewers trying to reduce mission 

risk. NASA attempted to compensate the team for the cost of 

these changes, but it was difficult to estimate what the budget 

ramifications of the new processes would be. In particular, we 

knew that buying risk down after the fact would be difficult, as 

key design decisions and part selection had already been made and 

implemented. It was an unpleasant transition for all concerned.

Manage What You Can

Since we did not have the resources to oversee the detailed design 

of every subsystem or component independently, we relied on 

the expertise of the team members to identify where difficulties 

required additional attention or assistance. This worked well 

in most instances, but we dropped the ball in one important )WICOt (rebie. SM/)hcetlaCn (itra. MC/hcetlaC-LPJ/ASA: Ntidero CtohP

An ultraviolet mosaic from NASA’s Galaxy Evolution Explorer shows a speeding 

star that is leaving an enormous, 13-light-year-long trail. The star, named Mira 

(pronounced my-rah), appears as a small white dot in the bulb-shaped structure 

at right, and is moving from left to right in this view.

ASK MAGAZINE | 7
area—the detector readout electronics. While the Berkeley 

team was busy solving how best to build the photon-counting 

detector assemblies, the detector readout electronics were being 

designed and prototyped by a single design engineer. There were 

clear indications that he was overloaded, so the Berkeley team’s 

solution was to isolate him from outside distractions. Being 

close to Silicon Valley during the dot-com boom, it was difficult 

for them to hire qualified electronics engineers at university 

pay scales, and they didn’t want to lose their one key designer. 

Efforts to carry out peer review of his work or bring in outside 

help were resisted on the grounds that they would slow down 

the effort. We left the engineer alone. It was a mistake. 

Close to the time the flight electronics were due to be 

delivered, the engineer suddenly resigned and left the university. 

When we looked at the state of the electronics, we discovered 

why: an important portion of the readout electronics didn’t 

work and contained serious design flaws. The designer had 

been misleading us and his management about the status of the 

development. It took a crash program working with Southwest 

Research Institute to develop a replacement element. Another 

important lesson was learned: when faced with the dilemma of 

shoring up a flagging effort with new help at the expense of an 

added delay to bring that help up to speed, the right answer is 

nearly always to bite the bullet and bring in the additional help.

Survive Bolts from the Blue

Every project faces unknown unknowns, things that can’t be 

anticipated. These events call upon the resilience and creativity of 

the team to overcome. GALEX faced an unusually large number 

of “bolts from the blue.” One event on our mission particularly 

illustrates how extensive the consequences can be.

Our ITAR-Baby

In order to reduce cost, the spacecraft bus supplier, Orbital Sciences 

Corporation, selected radio equipment manufactured by a company 

in Britain. The S-band receivers and transmitter were delivered 

successfully, but the X-band transmitter was more challenging 

and took a bit longer to complete. Within weeks of the scheduled 

delivery, Orbital received a phone call from the company stating 

that they had declared bankruptcy and were being liquidated. If 

we wanted the incomplete X-band transmitter, we should show up 

with a final payment and take delivery at their loading dock. 

We dispatched a contingent to pick up the hardware and 

as much design documentation as possible, and returned it 

to the United States. We approached the radio experts at the 

Jet Propulsion Laboratory, who explained that what remained 

to be completed was the staking and tuning of the circuitry, 

something that could only be done by someone intimately 

familiar with the design—in other words, they couldn’t do it 

without the engineer who had designed it.

By this time the design engineer was employed with another 

company in Britain. We explored shipping the unit over to him 

but discovered that our export license was only for the company 

that had gone bankrupt; we could bring the radio into the 

United States, but we couldn’t legally ship it back out. The next 

best thing was to bring the designer to the United States. 

This is when we discovered that the designer was a dual 

British/Iranian citizen. Export-control regulations prohibit 

providing technical assistance to non-U.S. persons. Orbital 

explored the possibility of obtaining a Technology Assistance 

Agreement from the State Department to work with the 

designer but given his Iranian citizenship, they were encouraged 

not even to apply. 

The last option was to bring the designer to the United

States, set him up in an empty lab with a soldering iron and 

oscilloscope, and let him complete the staking and tuning. At 

the end of this exercise, we inspected his workmanship and 

concluded that the unit had been rendered unusable.

Being very short on time to find a replacement X-band 

transmitter, Orbital identified a potential replacement unit on 

another NASA spacecraft in their clean room. Several weeks 

of negotiation produced permission for us to cannibalize 

ANOTHER IMPORTANT LESSON WAS LEARNEd: WHEN FACEd WITH THE 

dILEMMA OF SHORING uP A FLAGGING EFFORT WITH NEW HELP AT 

THE EXPENSE OF AN AddEd dELAy TO BRING THAT HELP uP TO SPEEd, 

THE RIGHT ANSWER IS NEARLy ALWAyS TO BITE THE BuLLET ANd BRING 

IN THE AddITIONAL HELP.

8 | ASK MAGAZINE
hectalC-LPJ/ASA N:tider CegamI

Artist’s concept of the Galaxy Evolution Explorer. Its mission is to study the 

shape, brightness, size, and distance of galaxies across 10 billion years of 

cosmic history. The 19.7-inch telescope onboard sweeps the skies in search 

of ultraviolet-light sources.

ASK MAGAZINE | 9
this hardware. The only problem was that it operated at a 

different frequency than our National Telecommunications 

and Information Administration license specified, and it used 

a different modulation scheme. One would think relicensing to 

another frequency would be straightforward, but it turned out 

that the new radio transmitted in a part of the X-band spectrum 

reserved for “downward”-looking vehicles (toward Earth) while 

GALEX was an “upward”-looking vehicle. We eventually got a 

special non-interference-based waiver approved. This left only 

the modulation problem—the way GALEX’s data was packaged 

for transmission—which was solved by a crash program to build 

new demodulators for the ground stations located in Australia 

and Hawaii so the data could be “unpackaged” correctly.

Make It Work

The team found creative ways to survive various other bolts 

from the blue during GALEX: a vacuum-chamber failure 

that back-streamed diffusion-pump oil and contaminated the 

spacecraft bus; another mission’s in-flight failure of the gyro we 

had selected, forcing the crash refurbishment of a replacement 

gyro we found; the sudden loss of liquid-nitrogen supplies on the 

eve of instrument thermal-vacuum testing because the Enrondriven electricity crisis in California shut down the liquid-air 

production plant. 

Once every development challenge had been successfully 

overcome, we launched GALEX in April 2003 aboard a 

Pegasus XL rocket. The scientific return has surpassed our 

expectations. Looking back on the experience, I appreciate the 

tremendous training value of the GALEX development; just 

about every type of problem that could arise did arise. It taught 

me many lessons I’ve applied to missions that followed, and gave 

me a true appreciation that small projects can be just as difficult 

as the big ones. ●

Note: This work was carried out at the Jet Propulsion Laboratory, 

California Institute of Technology, under a contract with the National 

Aeronautics and Space Administration. © 2012 California Institute 

of Technology. Government sponsorship acknowledged.

James Fanson’s twenty-five-year career at the Jet Propulsion 

Laboratory has spanned technology development, instrument 

development, and flight project implementation. He was part 

of the team that repaired the Hubble Space Telescope; led the 

team that produced the preliminary design of the Spitzer Space 

Telescope; and, as project manager, led two telescope missions 

(GALEX and Kepler) to launch and early science operations. 

L: JPtide CrothoP

The GALEX spacecraft before its launch in 2003.

10 | ASK MAGAZINE
Title

By 

Intro

By DaviD Ferrucci

Building the

On January 14, 2011, I was in the 

audience at IBM’s Watson Research 

Lab in Yorktown, New York, along 

with company executives, major 

clients, and my project team when 

our Watson computer soundly 

defeated two human champions in 

the third round of their Jeopardy!

competition. Publicly aired a month 

later, the quiz show made headlines 

around the world: a computer had 

been better at answering a broad 

range of natural-language questions 

than the human experts.
The event was the culmination of almost four years of intensive 

work by my team of artificial-intelligence researchers and

engineers. My own qualifications as project leader and principal 

investigator included a background in artificial intelligence,

automated reasoning, and UIMA (unstructured information 

management architecture), and the experience of working on an 

open-domain question-and-answer (Q&A) project. But there’s 

also the fact that I was the only one willing to take on the very 

public challenge of pushing Q&A technology well beyond the 

current state of the art and putting the result to the test on national 

television. The risk–reward trade-off was daunting. The project 

had been shopped around the company by senior executives for 

several years. Most people didn’t think it was possible.

The Challenge

Their skepticism wasn’t unreasonable; the difficulties were

enormous. Answering Jeopardy! questions is not like playing 

chess, which computers have done at the highest level for

years. Unlike that game, with its strict, unambiguous rules and 

numerous but finite potential moves, Jeopardy! questions have no 

formal logic; many of them are quirky and playful in ways that 

many humans understand but machines don’t. There is no way 

to map those clues to axioms; they are not regular enough. So 

we would have to teach Watson to “reason” from unstructured 

content—that is, large volumes of naturally occurring text.

The computer would also have to acquire knowledge from 

unstructured sources (for instance, encyclopedias, dictionaries, 

thesauruses, the works of Shakespeare, the Bible) in a form the 

system could evaluate and use to answer the questions.

And it would have to do it quickly. Over two years into 

the project, after we had made a lot of progress developing 

algorithms that could parse the clues and arrive at reasonable 

responses, it still took the system about two hours to answer a 

single question. We had to get that down to a few seconds.

Nevertheless, the feasibility study my group carried out at 

the end of 2006 concluded that it should be possible to reach 

the goal in three to five years. We based that assessment on the 

facts that mechanical reasoning had advanced in recent years, 

that sufficient computer power for inductive reasoning was now 

available, and that lots of semi-structured reasoning data existed.

Senior IBM executives gave their approval, but the technical 

people, who understood the magnitude of the problems, still 

had doubts. Many of those computer scientists were more 

comfortable working on their own small projects and publishing 

papers that announced their modest contributions to the field 

than devoting a chunk of their careers to a big, risky project.

Building the Team

There is no formula for winning people over and melding them 

into a team. It was all about personal relationships: meeting 

with people—often one on one—and repeating the argument 

that I believed so strongly in my heart. I talked to them about 

the potential sense of accomplishment of being part of one of 

the biggest achievements in the history of computer science. I 

reminded the scientists that they could write and publish five 

years’ worth of papers without answering or even grappling with 

any of the big questions. The Watson project would give us a 

chance to be real scientists, to achieve greater certainty about 

whether this goal could be reached. We would be able to say, 

“Here’s how we did it,” or, “Here’s why the current state of the 

art cannot accomplish this task.” Even failure would advance 

the field significantly.

My evangelizing attracted about a dozen scientists; the team 

eventually grew to twenty-five. Over time, the group developed 

a strong culture of cooperation and a shared determination to 

get something done. That practicality was partly inspired by the 

12 | ASK MAGAZINE
engineers on the team. They were I-want-to-make-stuff-work 

people; they didn’t care about publishing papers. They won the 

respect of the scientists, who adopted some of their can-do attitude.

One of the things that helped make the team cohesive 

and collaborative was putting the multidisciplinary algorithm 

group in a single room and doing away with the physical 

and psychological barriers to working together that exist in 

traditional offices. We did not even have cubicles in the room, 

just tables with monitors on them. People were in each other’s 

faces; everyone knew what everyone else was doing. At the 

beginning, some people had trouble focusing and preferred a 

private office, but most of them adjusted to the more public 

space. It became a lively hub of activity. Being away from the 

lab was a disadvantage—you could quickly lose track of what 

was happening.

The lab also provided one-stop shopping for other subteams. 

For example, the infrastructure team was focused on scale-out 

and reducing latency. They were not involved in algorithm 

development and were ordinarily not in the lab. But when they 

found a bottleneck and needed to discuss which algorithms 

were contributing to the slowdown, they would come to the lab. 

Everyone who needed to be involved in the discussion was there. 

The lab made for very efficient one-stop shopping.

The Watson team environment was a big change for scientists 

who were accustomed to working mainly alone, searching for that 

one formula or algorithm that can better the last publication. A 

few people who could not adjust left the team. That is usually 

part of how new cultures develop: most people adopt the new 

behaviors and those who can’t move on to something else.

Progress

A key was getting an extensible architecture in place that reflected 

our scientific hypothesis for how a Q&A system effective enough 

to win at Jeopardy! should work. It was a hypothesis based on 

the decades of collective experience represented by the team, 

synthesized and laid down in software designs and a framework 

implementation we called DeepQA. An essential assumption 

underlying this architecture was that there would be no silver 

bullet, no single algorithm, no one hero that would solve Q&A; 

rather, we would have to assemble and combine many algorithms 

that analyzed the content from different perspectives. 

These algorithms could be developed independently by 

different researchers; the architecture itself would allow for 

the automatic combination of their results based on statistical 

machine learning. This approach allowed us to move more 

rapidly, reducing the requirement to anticipate a perfectly 

integrated solution and wait for a completely specified topdown design. We had different members of the team work on 

competing algorithms—that is, algorithms that took different 

approaches to understanding and answering questions by, for 

instance, focusing on different parts of speech in the Jeopardy!

clues. The approaches would simultaneously generate their own 

reliability scores, and those scores would be weighted statistically 

to get an overall confidence level. Developing these competing 

algorithms gave us a big jump in capability.

As we progressed, the size of the incremental improvements 

got smaller and smaller because the problems remaining were the 

hardest ones. Consider this clue: “On hearing of the discovery 

of George Mallory’s body, he told reporters he still thinks he 

was first.” This is an example of what we called “missing link” 

questions. Watson had to discover some unmentioned entity 

that could lead to the right answer. In this case the missing link 

was Mount Everest. The answer is “Edmund Hillary.”

We did a great deal of rigorous testing using questions 

randomly selected from past Jeopardy! games. (The randomness 

was important to avoid the unconscious bias we might have 

ASK MAGAZINE | 13
introduced by selecting the kinds of questions we believed Watson 

could answer.) Some of Watson’s early answers were ludicrously 

wrong. Consider this clue: “NY Times Headlines: An exclamation 

point was warranted for the ‘end of’ this! in 1918.”

An early version of Watson answered with “a sentence.” 

The correct answer was “World War I.” You might assume 

Watson had all the headlines of every New York Times paper 

and knew to just look it up. But it was rarely so easy. Among 

many improvements that resulted from analyzing this error, one 

was focused on analyzing and weighing temporal information 

in a clue. A key here was “1918.” Watson had to understand that 

while an exclamation point may end a sentence, the relevant 

information here had to be unique to a particular point in time.

When one of our scientists got the idea of ordering the 

test questions chronologically, we discovered that Watson’s

performance decreased on questions written post 2002. That 

was when the game was changed to make the categories and 

questions more entertaining for viewers—that is, perhaps a bit 

quirkier and funnier. The game was a moving target and we had 

to keep working to make Watson more flexible.

That we succeeded became clear in early 2011, when Watson 

became a Jeopardy! champion. The system offered a very few 

ludicrously wrong answers and many astonishingly correct ones 

and beat its human competitors.

After Jeopardy!

Since then, I’ve worked hard to keep the team together in the 

face of pressure to chop it up by sending members to other 

project teams. Jeopardy! was only a step on the road to improving 

analytics and natural-language processing. There is still a lot of 

work to do.

We are currently working on a machine dedicated to medical 

diagnosis and treatment evaluation, one that can help make more 

reliable decisions and explain how it arrives at its recommendations 

based on analyzing the most current and reliable sources of 

information. Unlike Watson on Jeopardy!, this system will be 

interactive, cooperating with its human partners. So, for instance, 

it will be able to say, “I’ve come up with five possible answers 

based on the patient data and categorized the evidence based on 

symptoms, drug interactions, patient history, and demographics. 

If you can confirm the following, my confidence in the top-most 

recommendation will increase.” The system will also show the 

documents most relevant to its recommendation to humans who 

can evaluate their reliability based on their own knowledge and 

experience and ultimately make a decision.

After that, who knows? We are still at the very beginning 

of developing capabilities that will astound and serve us in the 

future. ●

A FEW PEOPLE WHO COuLd NOT AdJuST 

LEFT THE TEAM. THAT IS uSuALLy PART 

OF HOW NEW CuLTuRES dEVELOP: MOST 

PEOPLE AdOPT THE NEW BEHAVIORS 

ANd THOSE WHO CAN’T MOVE ON TO 

SOMETHING ELSE.

DaviD Ferrucci is a research staff member and leader of the 

Semantic Analysis and Integration Department at IBM’s T.J. Watson 

Research Center. His team of twenty-five researchers focuses

on developing technologies for discovering knowledge in natural 

language and leveraging those technologies in a variety of intelligent 

search, data analytics, and knowledge management solutions. 

14 | ASK MAGAZINE
The Million-Mile Rescue

BY THE NASA SAFETY CENTER 

The mission was designed to maintain an orbit around the First 

Lagrangian point, the area where the combined and balancing

gravity of Earth and the sun would keep SOHO’s orbit

anchored in the Earth–sun line. Once in this orbit, SOHO’s

attitude was generally stable and would use spinning reaction

wheels controlled by an attitude-control unit (ACU) computer 

to autonomously adjust for internal or external disturbances.

If the wheels reached a spin near their design limit, the ACU

would automatically despin the wheels, use thrusters to stabilize 

attitude, and then reactivate the wheels to resume attitude

control. During these maneuvers, the ACU would use one of

three gyroscopes (Gyro C) to sense roll. 

SOHO’s second gyro (Gyro B) was used solely for fault

detection—for example, to sense roll rates beyond some

predetermined tolerance. If an excessive roll rate was detected,

SOHO would enter a safe mode, where it ensured that its solar 

panels were facing the sun, temporarily suspended the ACU

computer, and then awaited the ground commands it needed

to restore normal operations. During one such recovery, ground 

controllers used the third gyro (Gyro A), instead of Gyro C, for 

roll-rate sensing. 

Gyroscope Misconfigurations

Each gyro onboard SOHO was designed to be used only for

its specific independent function. All three require periodic

calibrations to account for drift bias, which results from

mechanical wear, angular changes, or exposure to extreme

temperatures. When drift bias occurs, ground engineers uplink 

the correct coordinates for each gyro to the spacecraft’s onboard 

computer, allowing the spacecraft’s attitude-control functions to 

operate accurately. The same mechanical and thermal wear that 

causes drift bias eventually makes the gyros non-operational, 

which became a concern when the SOHO mission was extended.

In February 1997, the flight operations team modified gyro 

command sequences in an attempt to address this wear issue. 

A command was written to deactivate, or spin down, Gyro A 

when not in use, which is any time other than the safe mode. 

The code was supposed to include a function to respin Gyro A 

upon entering safe mode, but this function was erroneously 

omitted in the new sequence. 

The modification had been introduced with a mission 

operations change request in March 1997 but was not used in 

gyro calibrations until June 24, 1998. Therefore, even though 

the SOHO spacecraft had entered safe mode four times prior 

to June 24, the code modifications were not in use and did not 

affect successful recoveries by ground crews. 

A later review revealed that these modifications were never 

properly documented, communicated, reviewed, or approved by 

either ESA or NASA. The change request itself was an internal 

flight-operations document only distributed within the team. The 

only testing performed was by a NASA computer-based simulator 

that verified each change separately, but not all together.

The software modifications contained a second critical 

error. The fault-detection setting on Gyro B was twenty times 

The Solar Heliospheric Observatory (SOHO) is a major element of the joint International Solar 

Terrestrial Program between NASA and the European Space Agency (ESA). Originally a two-year 

mission to study the sun, from its deep core to the outer corona, and solar winds, the mission was 

later extended because of its spectacular success. This extension led to software code modifications 

meant to increase SOHO’s operational lifetime. Instead, multiple errors in the new command 

sequences repeatedly sent the spacecraft into an emergency safe mode. SOHO’s attitude progressively 

destabilized until all communication was lost in the early hours of June 25, 1998.

InsIght | ASK MAGAZINE | 15
ESA engineers work on 

the SOHO spacecraft.

ASA: Ntidero CtohP

16 | ASK MAGAZINE
more sensitive than it should have been. This error triggered a 

mishap and sent SOHO into its fifth safe mode at 7:16 p.m. on 

June 24, 1998.

The recovery effort began immediately but was

complicated by the aggressive scientific task schedule planned 

for June 24– 29. The core SOHO team was already working on 

a compressed timeline without the luxury of additional support 

or contingency time. Ground controllers quickly discovered and 

corrected the error in Gyro B but did not notice that Gyro A 

had not reactivated. Shortly thereafter, as a normal part of the 

recovery sequence, all three gyros were recalibrated, and the

ACU computer was activated to make any necessary adjustments 

using its thrusters. But when the computer attempted to correct 

for the drift bias on the spun-down Gyro A, it continuously

attempted to correct for a perceived (but non-existent) rollattitude error until the actual roll rate increased so significantly 

that Gyro B’s fault detection accurately triggered another safe 

mode at 10:35 p.m. Again, recovery efforts began immediately.

Critical Decision Mistake

The safe mode recovery period was designed to give flight

operations and engineering teams sufficient time to understand 

problematic anomalies before taking action. SOHO was

programmed to store telemetry prior to any safe mode so it

would be available for examination by ground crews. The

operations procedures specifically stated that before attempting 

a recovery, Gyro A should be confirmed to be spinning and the 

telemetry should be analyzed. The SOHO operations team did 

not take advantage of this design feature; instead they chose to 

initiate recovery sequences almost immediately after each safe 

mode was triggered without checking either Gyro A’s spin status 

or the telemetry data. 

The team observed that Gyro B’s readings of an excessive 

roll rate did not agree with Gyro A’s nominal roll-rate reading, 

but the flight operations crew still failed to notice that Gyro A 

was not spinning. In a quick decision, the flight operations

manager incorrectly concluded that it was Gyro B (and not 

Gyro A) that was faulty. 

Gyro B was shut down, which rendered the fault-detection 

capability inactive. When control was returned to the onboard 

computer for the recalibration sequence of recovery, roll thruster 

firing resumed and sun-pointing errors eventually resulted in 

pitch and yaw thruster firings. This produced unstable spinning 

of the spacecraft that exceeded allowed limits and triggered 

another safe mode at 12:38 a.m. on June 25. 

SEVERAL FACTORS CONTRIBuTEd TO 

SOHO’S MISHAP: CHANGE CONTROLS 

WERE LACKING, PROCEduRES WERE NOT 

FOLLOWEd AS WRITTEN, AGGRESSIVE 

SCHEduLING OVERTASKEd THE TEAM, ANd 

NOT ENOuGH STAFF WAS AVAILABLE TO 

HANdLE THE PLANNEd SCIENCE TASKS 

ANd SuBSEquENT RECOVERy MOdES.

The critical software errors in the modified gyro command 

sequence meant that SOHO’s gyros were configured incorrectly 

and caused the onboard computer to erroneously fire its thrusters 

until the spacecraft destabilized. This was exacerbated by the 

decision to shut down a gyro believed to be malfunctioning in 

favor of a gyro that was actually inactive.

Within minutes, SOHO’s attitude diverged beyond 

control. Power, communications, and telemetry were all lost. By 

12:43 a.m., SOHO was officially lost in space. 

Artist’s concept of the SOHO 

spacecraft exploring the center of 

the sun. In reality, the spacecraft 

does this indirectly, by analyzing 

ripples on the solar surface that 

come from the deep interior. 

ASAN/AS: Etidere CgamI

ASK MAGAZINE | 17
The Million-Mile Rescue

Within hours, investigation teams at both ESA and NASA 

had been assembled. On June 28 they convened at Goddard 

Space Flight Center to begin recovery efforts. Based on the 

last few minutes of telemetry, simulations predicting possible 

trajectories for SOHO indicated that the spacecraft would 

diverge and escape into a solar orbit if it was not recovered by 

mid-November. By a stroke of good fortune, calculations also 

indicated that, in roughly ninety days, the spin of the spacecraft 

would naturally align the solar arrays with the sun for about 

half a spin period, giving the recovery team an opportunity 

to regain control over SOHO. On July 23, using the Arecibo 

radio telescope in Puerto Rico in combination with NASA’s 

Deep Space Network in California, the team was able to locate 

the spacecraft’s radar echoes and confirm both its location and 

spin rate.

The flight operations team uplinked commands to 

SOHO for twelve hours a day, searching for any signs of return 

communication. On August 3, contact was established. Over the 

next two months, SOHO was progressively restored to normal 

operating mode. On September 25, about ninety days after contact 

was initially lost, SOHO was fully operational. Remarkably, 

all twelve scientific instruments remained in complete working 

condition despite having been subjected to temperatures from 

-120°C to 100°C during the three-month ordeal.

Lessons Learned for NASA 

Several factors contributed to SOHO’s mishap: change controls 

were lacking, procedures were not followed as written, aggressive 

scheduling overtasked the team, and not enough staff was 

available to handle the planned science tasks and subsequent 

recovery modes. As a result, key engineers were preparing for 

upcoming science tasks rather than assisting with safe-mode 

recoveries. Recovery efforts were rushed in order to return 

the spacecraft to its science operations as quickly as possible. 

Ironically, the prioritization of science over spacecraft safety 

contributed to the loss of science operations for three months 

and risked the total loss of SOHO.

It is important that modifications or updates to procedural 

scripts on future NASA missions have formal approval before 

implementation, and the entire script (not just the modification) 

should be revalidated. Operational timelines should also be 

planned and validated before implementation—not in parallel 

with implementation—with the proper attention and reserve 

given to contingency planning and safety. There should be 

sufficient time for coordinating tests and simulations so they 

do not conflict with management and operations of real-time, 

on-orbit events.

The health and safety of a spacecraft are critical in achieving 

any scientific or operational goals. To keep the spacecraft healthy, 

the team needs to be healthy. Reassess staffing levels periodically, 

strengthen staff as needed, and provide the capability for the 

extra support required by contingency operations. This can be 

difficult in extended operations on missions that have limited 

budget flexibility, but it is important. In any case, operations 

teams must be well trained on the systems they will be required 

to use and should practice responses to emergency situations. ●

This article is adapted from a NASA safety-awareness training 

document based on information available in the public domain. 

The findings, proximate causes, and contributing factors identified 

in this case study do not necessarily represent those of the agency. 

Sections of this case study were derived from multiple sources listed 

under References. Any misrepresentation or improper use of source 

material is unintentional.

REFERENCES

1. F.C. Vandenbussche, “SOHO’s Recovery: An unprecedented Success Story,” esa Bulletin 97, March 1999, 

sohowww.nascom.nasa.gov/operations/Recovery/vandenbu.pdf

2. SOHO Mission Interruption Joint NASA/ESA Investigation Board, final report, August 31, 1998, umbra.nascom.nasa.

gov/soho/SOHO_final_report

3. NASA Public Lesson Learned 0664, “SOHO Mission Interruption Joint NASA/ESA Investigation Board,” december 1, 

1999, www.nasa.gov/offices/oce/llis/0664.html

4. K athryn A. Weiss, Nancy Leveson, Kristina Lundqvist, Nida Farid, and Margaret Stringfellow, “An Analysis of Causation 

in Aerospace Accidents,” June 25, 2001, csel.eng.ohio-state.edu/woods/accident_reports/NASA/leveson_soho.pdf

retnet Chgile Fcapd SraddoA GSA: Ntidere CgamI

SOHO’s orbit is about 1 million miles 

toward the sun from Earth at the 

Lagrangian Point.

18 | ASK MAGAZINE
Efficiency Through Document 

Automation

BY ROBERT DELWOOD 

Today’s tight budgets and reduced staff mean we need ways to work more efficiently. For office 

and knowledge workers that should include document automation. Yet organizations overlook 

a powerful tool they use every day: Microsoft Office. Office automation offers a powerful set of 

capabilities, both out of the box and with programming, that can transform the way you create 

and manage documents.

Microsoft Office automation uses built-in features either to place, 

reconfigure, or format document passages, or to automatically 

run sequences of commands. The simpler end of the automation 

continuum includes built-in features such as copy and paste, 

the “repeat last” command, and document linking (reusing 

text among different documents), all examples of tasks that 

can run directly from the Office ribbon. Advanced users may 

record macros (linking a series of commands) or manage macro 

libraries to shorten tasks. At the other end of the continuum, 

programmers create custom applications that manipulate data 

in specific ways. The intent is the same: to be more efficient by 

increasing throughput and reducing opportunities for error.

ORBIT®

The advantages are clear, but implementation can be an issue. If 

it’s the job of individual contributors to improve their processes, 

why doesn’t it happen more often? For one thing, automation 

tools, though often not complex, do require users to change the 

way they think about their work. There is also often a mismatch 

of expertise: 

• Users understand their own procedures but may not know 

what can be automated.

• A utomation specialists know how to implement Office 

automation but may not know users’ tasks.

The solution is to get the two together. We assign an 

automation specialist, typically a programmer with Microsoft 

Office automation experience, to a team to learn users’ 

procedures. Both parties then brainstorm to come up with 

automation suggestions. We call the process ORBIT, an 

acronym of five steps:

Observe. Initial observation focuses on the most repetitious 

procedures to develop a list of candidate processes. In 

some cases, an automation audit has the team members 

explain their work step by step, down to the key stroke. 

The specialist then has the opportunity to ask questions 

and investigate options. Typically, an audit of no more than 

thirty minutes can yield several candidate processes for 

automation. At other times, the observer actually sits with 

the team and observes their work.

Reengineer. The automation specialist and users work on 

new procedures, adapting tasks to automation. This may be 

as simple as recording macros, but sometimes procedures 

may have to be changed to accommodate automation 

capabilities. This step also provides an opportunity to 

eliminate procedures that are no longer needed. 

Build. The specialist creates the application or macros to 

automate the clients’ needs. The solutions and user interface 

must fit their working environment. Builds may also include 

a prototype or progressive versions of the application to 

show its proposed look and feel.

 Implement and Test. Specialists test the application and 

interact with the clients. Some features might be reworked 

InsIght | ASK MAGAZINE | 19
or redesigned based on feedback. Once the clients’

requirements are met, the specialists release the application.

Transfer. We deliver the application to users. Some 

applications can be modified to accommodate more general 

requirements for other groups. We place these tools in a 

public download site and inform potential users and other 

contractors of their availability.

Sample Cases

Some NASA cases illustrate this approach. At the Johnson Space 

Center, our DQA (document quality assurance) team, charged 

with enforcing document quality and style consistency, had 

unrecognized outdated procedures. One procedure in particular 

caught the attention of an automation specialist. He noticed 

that a DQA team member was going through a lengthy printed 

document page by page. Repetitive actions like that should always 

be evaluated for automation. The team member was reviewing 

the manual placement of eighty pages of graphics. The graphics, 

up to 150 diagrams, were a parts manifest list for the space 

station in a read-only format. They were routinely and manually 

inserted into documents. Each diagram had to be printed from 

its source document, scanned, converted to a TIFF file (tagged 

image file format), then opened in Adobe Photoshop, where it 

was cropped and occasionally had text removed. Then it was 

inserted into the target document and its size possibly adjusted. 

A single document took twenty to fifty hours.

The process followed clear, repeatable guidelines, which 

made it ideal for automation. Scripting could print pages from 

within Word one at a time, create TIFF files by using Microsoft 

Office’s Document Imaging driver, and place them in the target 

document, resizing them with mathematical precision. We 

questioned the requirement to remove text and found it to be an 

old constraint, not needed any more. The resulting solution was 

a Microsoft Visual Basic 6 standalone Windows application (an 

executable or .exe file), since it would involve multiple documents, 

and the code wasn’t conducive to being in a document template.

This automation reduced processing time to less than ten 

minutes with a zero defect rate. Conventional, top-down process 

improvement would probably have overlooked this task, since it 

wasn’t considered broken. The user who spent so many hours 

doing the work didn’t know it could be automated; it took an 

experienced automation specialist to identify the opportunity.

Knowing that automation can help with the smallest 

details, DQA team members began suggesting processes 

themselves. One was to create tables. New tables have up to 

fourteen requirements, including multiple font styles, column 

and row widths, and header formatting. A macro was recorded 

to create them. The time and quality savings were clear, but 

that wasn’t the real draw of automation here. Of greater concern 

were existing tables. Having been modified by different authors 

over time, they were prone to inconsistencies and each had to be 

manually checked prior to release. This was a good automation 

candidate since the procedure was manual and repetitive with 

clear, objective requirements. 

We created a macro series to either check each criterion 

individually, or check all table criteria in the document at one 

time. The scope later expanded to address user-entry mistakes, 

replacing line returns with paragraph marks, removing double 

spaces between words, removing spaces used as line returns, 

GETTING STARTEd WITH AuTOMATION.

you choose your level of involvement with automation. If you want to record a macro in Microsoft Word 

A simple start is the “repeat last” command, or the for Windows 2007 or later, start by clicking View/

F4 key. This repeats the last command you invoked. Tools > Macros > Macros > Record Macro. 

For instance, if you need to make lots of text bold, Give it a name, press OK, then go through all 

save that operation until last. After bolding the first the steps needed to complete your task. Stop the 

text, highlight the next instance and press F4. you recording by clicking View/Tools > Macros > 

can go through an entire document quite quickly. Macros > Stop Recording. To play the macro, 

click View/Tools > Macros > Macros, select 

the macro’s name, and press Run.

20 | ASK MAGAZINE
bolding certain words, and removing empty table rows. The 

greatest benefit was not time savings, although they were 

significant, but the consistency and assurance that the tiniest of 

details were fixed.

Our last example is of a complex application, initiated 

by management to address a specific, long-standing problem: 

acronyms. Many NASA documents require a list of acronyms 

and their definitions. In some cases, spelling out the first use of 

acronyms is required. Acronym management had been a timeconsuming and often inaccurate manual process at the agency. 

Given the ambiguities and complexities of acronym usage, 

this became a formal information-technology development 

project. The key was using Word’s automation functions. With a 

combination of its wildcard find and replace, thesaurus, custom 

dictionaries, and other features, it was possible to reach nearly 

100 percent accuracy. A separate list maintains customized 

acronym terms. In addition, the application lists words that 

might be previously unidentified acronyms. Rounding out the 

application are systems to add or modify terms and definitions, 

selecting from multiple definitions for the same term, producing 

and saving terms lists, and generating a new acronym appendix 

ready to copy and paste into the target document.

The resulting tool had three benefits. The immediate one 

was that it reduced document processing time for that step from 

a high of twenty hours to about thirty minutes, along with a 

dramatically higher accuracy rate. Second, after studying the 

process in detail, we concluded that authors and editors who 

supplied documents to DQA could use the tool to catch mistakes 

earlier and correct those mistakes faster. Lastly, the tool was so 

effective that we modified it for use by other groups or other 

contracts and made it available as a free download. It’s now used 

routinely for contract proposals, white papers, and presentations. 

With two or three highly visible projects completed, the 

teams became more confident and started suggesting automation 

ideas on their own. To date, we have provided more than a dozen 

tools. Document turnaround time dropped from the required 

twenty days to just three days. In addition to saving time and 

money, these tools can reduce stress. Some of our teams found 

that reviewing document changes in Microsoft Word is awkward 

and doesn’t lend itself well to group meetings. We wrote a tool 

that cataloged all revisions in a document to a separate list along 

with user-requested information. One meeting organizer wrote, 

“This is the coolest tool ever and why everybody doesn’t use it is 

beyond me. I love this thing!” ●

WHAT MAKES FOR A POOR AuTOMATION PROJECT?

Not all document tasks are good candidates • P rojects that have too many rule exceptions

for automation. The following often reduce • I nconsistently formatted documents, often the automation benefits or prevent automation entirely. result of many authors modifying the document 

• Unclear or changing requirements and/or modification over a long period of time 

• Projects that include too many manual Finally, some processes just don’t convert well 

decision points, or interventions to automation steps, either by needing features 

not available or not supported by Microsoft • Subject-matter experts who “just know” what Office, or because automation isn’t practical in the right action is but who can’t or won’t a particular environment. explicitly describe the logic behind it

ASK MAGAZINE | 21
Title

By 

Intro

Conducting human missions beyond low-Earth orbit to destinations such as asteroids 

and Mars will require substantial work to ensure the well-being of the crew. These new 

operational conditions, which will include long periods in microgravity, will pose health 

risks that are currently not well understood and perhaps unanticipated. Developing and 

applying advanced tools to predict, assess, and mitigate potential hazards to astronaut 

health is critical. NASA’s Digital Astronaut Project (DAP) is working to build well-vetted 

computational models to help predict and assess spaceflight health and performance risks, 

and enhance countermeasure development. The DAP aims to accomplish these goals 

through the following:

BY LEALEM MULUGETA AND DEVON GRIFFIN

The 

22 | ASK MAGAZINE | story
• P artnering with subject-matter experts to address 

human health-risk knowledge gaps and countermeasure 

development decisions 

• Modeling, simulating, and analyzing physiological 

responses to exposure to reduced gravity and spaceflightanalog environments

• Providing timely information to contribute to mission 

architecture and operations decisions in areas where 

clinical data are lacking

To achieve these objectives, the DAP follows a systematic, 

rigorous process that begins by identifying human health-risk 

knowledge gaps that are amenable to computational modeling. 

Subsequently, we work with subject-matter experts within 

the Human Health Countermeasures element of the NASA 

Human Research Program to narrow modeling and simulation 

objectives to inform specific research questions or hypotheses. 

Then we conduct a thorough field survey to identify stateof-the-art modeling and simulation methodologies that can 

address the questions and hypotheses effectively. Subsequently, 

the models are developed, refined, verified, and validated to 

make them ready for research application.

Once the models have been sufficiently vetted (an effort 

currently in progress), we work with researchers or provide them 

models to simulate typical spaceflight-environment scenarios. 

The results of the simulations can then be interpreted by the 

subject-matter experts to inform research. Additionally, results 

from research and flight operations that the DAP informs 

can be used to further refine and enhance the fidelity of our 

models for future use. In addition to enhancing countermeasure 

development, our iterative and collaborative approach offers 

other benefits:

• Substantiates anecdotal evidence regarding spaceflight 

health risks

• R educes cost of flight and ground experiments by running 

complementary simulations to further substantiate or 

refine experiments for optimal results

• Provides insight on the effects of long-duration spaceflight 

scenarios for which data are lacking

To ensure high-quality, repeatable results, the models 

are rigorously vetted using NASA’s Standard for Models and 

Simulations (NASA-STD-7009). We do everything we can 

to validate the modeling and simulation against spaceflight 

or flight-analog data to establish the highest fidelity possible. 

For example, we are in the process of using on-orbit video 

data of crewmembers exercising to validate the kinematics of 

exercise models. We are also gathering muscle and bone data 

from past spaceflight missions and bed-rest experiments to 

validate the capability of our musculoskeletal models to predict 

the impact of exercise countermeasures on musculoskeletal 

fitness. Given that models and simulations have limitations, 

we clearly document the validation and application domains 

of our modeling and simulation to ensure they are not applied 

beyond their intended use.

A Multicenter and Multidisciplinary 

Collaborative Approach

The DAP is managed out of Glenn Research Center by 

DeVon Griffin; the science content of the project is directed 

by Lealem Mulugeta of the Universities Space Research 

Association (USRA) in Houston at Johnson Space Center. We 

work collaboratively to lead a tightly knit team of researchers, 

engineers, and computational modelers located at Glenn and 

Johnson to execute the project’s core mission. We conduct a 

weekly tag-up teleconference to discuss planned activities for 

the week and coordinate critical tasks that must be executed to 

meet milestones. Lealem also meets with the multidisciplinary 

technical team via a weekly teleconference to conduct highly 

focused technical discussions regarding the development and 

implementation of modeling and simulation. DeVon then closes 

out each week with a programmatic teleconference, during which 

the team members provide status updates on current activities ASA: Ntidere CgamI

Three biomechanical exercise modules that include joint and muscle modules.

ASK MAGAZINE | 23
and flag any programmatic risks that need to be addressed or 

tracked. If required, the team also holds face-to-face meetings 

to address high-priority issues. Finally, to keep the project 

and the team focused, we have established project and science 

management plans to communicate the overarching vision of the 

DAP and provide a road map that guides the team’s efforts.

Applying Models and Simulations

for Musculoskeletal Health Research

The DAP is assisting the Exercise Physiology Countermeasures 

Project (ExPC) at Johnson to model exercise countermeasures 

that use the Advanced Resistive Exercise Device (ARED) aboard 

the International Space Station. Given the complementary 

expertise of DAP and ExPC in computational modeling and 

exercise physiology, the teams established a cooperative approach 

to develop and implement three exercise modules of humans 

and an ARED device module. These model types are currently 

being integrated to provide data on forces transmitted to various 

anatomical locations as a result of the exercises. 

The ARED exercise models will be integrated with bone and 

muscle adaptation modules currently being developed. These 

models use both terrestrial analog data and subject-matterexpert knowledge of musculoskeletal and exercise physiology 

unique to spaceflight. Once integrated with the exercise models, 

the bone and muscle models will simulate the response of bone 

and muscle physiology to exercise countermeasures during 

spaceflight missions. This will enable researchers to conduct 

“what-if” analyses to gain insight into questions such as

• I s it possible to reduce the amount of exercise time and 

maintain musculoskeletal performance by increasing 

exercise intensity or eliminating some exercises?

• Which exercises play the greatest role in maintaining 

musculoskeletal performance?

• What is the impact of unanticipated failure of exercise 

equipment on musculoskeletal health, and can the exercise 

regimen be reformulated to minimize adverse effects?

• C an exercise efficacy be enhanced for individual astronauts 

based on their unique anthropometrics?

In general, the overarching objective of this collaboration is to 

develop and implement musculoskeletal modules and modeling 

capabilities to customize and optimize exercise regimens based 

on anthropometrics and gender. Another goal is to provide tools 

capable of answering unforeseen exercise-physiology questions as 

they arise, as well as scalable and extensible exercise-device modules 

and modeling capabilities or platforms to evaluate the influence of 

exercise devices on exercise performance and flight hardware.

Ultimately, these tools will be used to inform ground 

and flight studies aimed at addressing musculoskeletal-risk 

knowledge gaps regarding the minimum amount of exercise 

required to maintain musculoskeletal health and performance, 

and the minimum set of exercise equipment needed to maintain 

musculoskeletal health and performance.

The joint teams developed the ARED model in 

progressive stages to gradually increase the module fidelity. 

The first product was a beta version, used as a development 

and checkout tool for the integration process with the 

biomechanics exercise modules. The teams maintain the beta 

release as a development platform throughout the project 

because it offers a simplified environment for checking and 

ASA: Ntidere CgamI

Joint- and muscle-driven versions of the squat-exercise biomechanics modules 

integrated with the ARED/VIS module.

24 | ASK MAGAZINE
ASA: Ntidere CgamI

The latest version of the wil

ARED/VIS module.

troubleshooting the integrated modules. Follow-on versions 

provide increased fidelity, including accurate characterization 

of mass, inertial and friction properties of the device, and the 

vibration isolation system.

Work in Progress

In addition to modeling and simulating exercise countermeasures, 

DAP is currently collaborating with the NASA Bone Discipline 

lead within the Human Adaptation and Countermeasures 

Division to apply modeling and simulation to augment a new 

bone-strength standard that NASA is currently developing. 

DAP team members are developing a unique capability that 

will provide the first simulations of the effects of microgravity 

on bone turnover. This work focuses on bone-strength

changes due to demineralization and architectural changes. 

It will also be combined with biomechanical modeling to 

predict the loads experienced at specific bone sites that are at 

greatest risk for fracture during post-flight activities astronauts 

might perform, such as jumping. Based on the outcomes of 

these simulations, it may be possible for clinicians to guide the 

activities of astronauts in order to minimize risk of fracture 

after they return from a mission.

The DAP is working with the Exercise Countermeasures 

Project Advanced Exercise Concept (AEC) device-development 

team at Glenn to model advanced-concept devices with the 

following goals:

• Gaining insight into the efficacy of AEC devices for 

exercise countermeasures 

• P roviding timely input for design, development, and 

refinement of AEC devices

• Reducing the time and cost to develop the exercise devices

• Reducing the time and cost to clinically test new exercise 

devices

Given that many of the AEC component prototypes 

will share some common architecture, DAP is developing a 

generalized modeling toolbox that will make it possible to rapidly 

benchmark the capabilities of proposed devices for common 

loading profiles. This builds on DAP’s goal to develop scalable, 

extensible exercise device-simulation modules and capabilities 

to rapidly and inexpensively evaluate exercise hardware efficacy 

during exploration missions. As part of that goal, the models 

l be able to simulate changes in exercise protocol as well, 

allowing exercise physiologists to conduct what-if analyses of 

various exercise prescriptions for microgravity conditions.

Finally, DAP is working with the Visual Impairment 

and Intracranial Pressure project to address recent findings 

of anatomical changes of the eye and visual performance 

diminution in many long-duration space station crewmembers. 

Although these changes have varied in severity, they have 

occurred at a much higher rate than expected. This project 

is currently in the field-survey phase to identify modeling 

and simulation resources that can be extended to answer key 

questions and test hypotheses in this area. ●

Devon griFFin has a background in optical instrumentation 

development for bioscience, microgravity combustion, and

microgravity fluid physics. He has been a co-investigator, facility 

scientist, and project manager for shuttle and station flight 

projects. He has managed projects for NASA’s Human Research 

Program since 2004.

ASK MAGAZINE | 25
that process to go on to a competitive 

Phase A, which is the very first step of 

mission formulation. Out of that, we get 

a funded concept-study report, which is a 

substantial document. The proposals have 

already been selected as having excellent 

science. We look at science feasibility: Will 

the instruments and operations proposed 

in this much more technical document 

actually support doing the excellent science 

that we want to select and fly? Step two 

also includes detailed evaluation of the 

budget and resources required as well as 

the management approach.

cohen: Who makes the final decision?

may: In the case of MAVEN, that’s an 

interesting story. Our brand new SMD 

associate administrator at the time, 

Dr. Stern, had been the PI [principal 

investigator] on one of the two proposals 

Lisa May is the program executive for MAVEN, the Mars 

Atmosphere and Volatile EvolutioN mission, in NASA’s 

Science Mission Directorate (SMD). In her spare time, she 

acts as the female voice of NASA’s ScienceCasts. Don Cohen 

spoke with her at NASA Headquarters.

 INTERVIEW WITH

Lisa

May

 BY DON COHEN

26 | ASK MAGAZINE | InsIght
selected. There was a lot of discussion 

with legal about what his role could 

be. What it came down to was that he 

could not be involved in anything that 

had to be approved about the conceptstudy reports, guidelines, and selection 

process. Chris Scolese, the agency associate 

administrator, became the selection official. 

When Dr. Stern left, Dr. Weiler came back. 

He had been center director at Goddard 

and had signed the concept-study report 

for MAVEN, which was proposed from 

Goddard. So he also had a conflict. For 

probably the first time, the Science Mission 

Directorate AA [associate administrator] 

could not be involved in the decision 

making. The NASA AA, Chris Scolese, 

made the selection.

Cohen: So there was an unusual amount 

of potential conflict of interest to work 

around.

May: There was a different issue of 

potential conflict of interest having to 

do with the initial concept-study report. 

We had to develop an entire new review 

panel, which took time. So we decided we 

would slip the mission launch from 2011 

to 2013. Mars missions are difficult. They 

generally have an aggressive development 

schedule; PI-led missions are cost capped. 

Adding risk by cutting a good chunk out 

of their development schedule was just 

not acceptable. Interestingly, the universe 

decided to cooperate. The science goal 

of both missions in the competition 

was to understand the effects of solar 

events—winds, ions—on the Mars upper 

atmosphere. The last solar cycle actually 

dawdled along and the new solar cycle 

did not ramp up for almost two years, 

which is about the length of the delay. 

The fact that the solar cycle happened 

to be delayed by almost two years was a 

fortunate coincidence.

Cohen: What role do you play in MAVEN 

as program executive?

May: The way I frequently describe my 

job to people is this: When you have a 

moving vehicle, you’ve got an engine 

that drives things and you’ve got the 

rubber that meets the road. In the case 

of space missions, the engine is the 

administration and Congress. They give 

us direction and funding. The rubber 

meets the road at the universities and 

industry partners and NASA centers 

that build and deliver the hardware 

and do the science. In between, you 

need something to keep the gears from 

grinding. That’s the program executive.

Cohen: So what would be a typical 

situation where the gears threatened 

to grind?

May: One of the interesting facets of being 

an agency that builds and delivers things 

as part of a broader federal government 

is that oversight, reporting, and data 

requirements constantly shift as the 

government expands and contracts, as it 

looks inward and reports outward. People 

in various organizations and within NASA 

want to know more and more about how a 

project is doing. There is an endless search 

for tools that enable us to understand and 

predict how a mission is going to do and 

where you might need funding later. It’s 

good, responsible management to want to 

be able to more accurately predict where 

you want to apply your funding. But 

saying, “NASA has new tools for figuring 

out how to do that,” is a real hardship 

for the lean team of a cost-capped and 

schedule-constrained mission. One of the 

jobs I do on a semi-regular basis is push 

back and ask these organizations, “What 

are you going to do with this tool? How 

do you use this data? Can I give you the 

data? Is there existing data you can use?” 

I try to protect the MAVEN management 

team from things they had not been asked 

to plan for. And from requirements creep. 

ASK MAGAZINE | 27
I FOR THE PROJECT AND FOR THE PEOPLE 

WHO NEED INFORMATION TO get it WITHOUT DERAILING SOME 

significant activity, AND I TRY TO maintain the integrity OF 

WHAT we selected ON BEHALF OF THE TAXPAYERS AND THE 

SCIENCE INVESTIGATION WE signed up TO GET. 

stand up find ways

I stand up for the project and find ways 

for the people who need information to 

get it without derailing some significant 

activity, and I try to maintain the 

integrity of what we selected on behalf of 

the taxpayers and the science investigation 

we signed up to get.

cohen: The requests for information 

come to you?

may: In general they do. I try to make sure 

that either I or the Mars Program Office 

can handle as many of them as possible. 

Sometimes organizations want to talk to 

the project without having a Headquarters 

filter. That’s understandable, though I 

have a very good relationship with the 

project and what they’ll hear from the 

project is what they’ll hear from me and 

what they’ll hear from the program office. 

We have a collaborative relationship and 

a really good flow of information back 

and forth.

cohen: I know there’s a tremendous 

amount of documentation associated 

with a project like this.

28 | ASK MAGAZINE
be ready. The last thing I wanted was 

to have a bow wave of things that I had 

to push uphill here at Headquarters a 

month before confirmation. That is not 

a strategy for success. Understanding

the requirements of review and approval 

enabled us to have every piece of that 

done well in advance. We knew that we 

were going to hit the marks and that the 

people who had reviewed documents

had not just signed them because it was 

urgent; they signed them because they 

agreed with them. Headquarters can be 

a famous bottleneck. Busy, high-level

people are not going to sign just because 

you say so.

cohen: Do you regularly attend MAVEN 

project meetings?

may: There are regular meetings I attend. 

Despite our collegial relationship and 

the fact that I came from Goddard

and have known many of these people 

for a long time, when Headquarters

shows up in the room, it affects how a 

meeting goes. I absolutely understand 

that they need to do their work, so we 

pick and choose when and how I get 

my information. I have tag-ups with

their management team weekly; there 

are quarterly meetings I attend. When 

they have their monthly meetings at

Goddard, I sit down with them and talk 

about things in their monthly report

and things we need for reviews coming 

up. They are a refreshingly transparent 

project, but I respect their need to get 

their work done without Headquarters 

in the room.

cohen: So how are things going?

to deliver on the last project; is your project 

planning around that?”

cohen: So the communication goes in 

many directions.

may: There are formal reporting systems in 

NASA for problems, but having our own 

community here in the Science Mission 

Directorate helps. And the PEs help each 

other with process issues, too. As I’ve said, 

there is a lot of documentation, paperwork, 

things that have to be done at a particular 

point in the life cycle. We sit down with 

each other and say, “How did you handle 

this particular requirement?” Then you 

can go back to the project and say, “This 

is a successful way for you to approach 

this” or “This other project that is a little 

further on in its development handled it 

this way and I think this is going to work 

for you. Let’s get it sorted out now early 

so that it doesn’t plague you at your major 

reviews or other milestones.”

cohen: A lot of knowledge sharing.

may: We have a Mars Program Office 

at JPL [Jet Propulsion Laboratory], and 

my mission manager there is much more 

involved in day-to-day tag-ups with the 

project and project details than I am. His 

JPL expertise—those folks have done 

Mars mission after Mars mission—helps 

Goddard with their first Mars mission, 

helping them as needed to understand 

specific issues as they crop up.

cohen: How long have you been at NASA?

may: In September, it will be twelve 

years—ten at Headquarters.

ASK MAGAZINE | 29
long time, but being fluent in it, being

able to grasp an issue someone raises

about the wrong resistor being on a

board or the way they’re going to solve

a problem, is essential—knowing what

they’re talking about, whether they have 

an adequate solution or whether I need

to ask more questions. To understand the 

technical problems being brought to me 

at a high level, it’s important to have the 

background to understand the low level 

if I needed to. All program executives are 

technical. It’s a given that you have an

engineering or a physics degree. 

cohen: Did you know when you were 

studying that you would use your skills 

in these ways, rather than for hands-on 

tech work?

may: Not at all. When I went into

engineering, it felt like a total break from 

what I had done in my undergraduate

career. Looking back—my thirtieth college 

reunion will be this summer—I realize that 

my technical background and my ability to 

communicate have factored into every job 

I’ve had. Those things have all merged into 

one career. I suspect if you could walk up 

and down this hall and ask anybody how 

they ended up here, they would give you 

a similar story: anything but a straight

line or “I always knew I wanted to ....” 

Headquarters requires a broad mix of skills. 

We do things that are policy- and budgetoriented, technically oriented things 

driven by the laws of physics, and all of the 

management and communication tasks 

and activities that make all those work 

together. We’re not specialists here. People 

I work with are good communicators, 

good speakers, interesting people as well as 

technically competent.

cohen: Do the NASA engineers you 

work with have trouble communicating?

may: There’s no way to generalize. There 

are people who do basic research that 

doesn’t require a lot of writing. There 

are savvy technical engineers who write 

proposals, articles, or talks. It’s a varied 

population. The technical competence is 

consistent. There are people who don’t like 

writing and people who gravitate toward 

it. People who come to Headquarters on 

detail who like to focus on one thing at a 

time tend to self-select to go back to do 

what they call “real work.” This is real 

work, believe me, but it’s not the deeply 

technical work that some people prefer. ●

BEING able to talk TO THE helio people AND SAY, “WE HAVE 

a parts issue. HOW IS YOUR MISSION GOING?” is valuable.

30 | ASK MAGAZINE
muirtsS ADA: Etidere CgamI

Artist’s view of 

BepiColombo 

at Mercury.

BY ELSA MONTAGNON

BepiColombo is a collaborative mission 

to Mercury between the European Space 

Agency (ESA) and the Japanese Aerospace 

Exploration Agency (JAXA) due to launch 

in August 2015. The mission is named after 

Giuseppe (Bepi) Colombo (1920–1984), 

an Italian scientist who studied Mercury’s 

orbital motion in detail.

Col

Inte

l

rn

a

atIo

b

nal

or

on BepIC

a

olo

t

mB

i

o

on
The structural and thermal model of the BepiColombo Mercury 

Planetary Orbiter in the Large Space Simulator at ESA’s Test Centre 

in Noordwijk, the Netherlands, ready for a dry run in preparation for 

thermal-balance testing.

Dedicated to the detailed study of Mercury and its 

magnetosphere, the mission consists of two spacecraft, 

the Mercury Planetary Orbiter (MPO) and the Mercury 

Magnetospheric Orbiter (MMO). Both will be launched as 

a single composite spacecraft that also includes a dedicated 

propulsion module and a sunshield for the MMO. ESA is 

providing the MPO spacecraft, the MMO propulsion module 

and sunshield, the launch, the operation of the composite 

spacecraft until delivery of the MMO in its operational orbit 

around Mercury, and the operations of the MPO around 

Mercury. JAXA is providing the MMO spacecraft and its 

operations around Mercury. 

This is the first time that ESA and JAXA have collaborated 

to such a large extent. I will try to address the questions of how 

the collaboration has been established and how it is working 

(including the effects and management of cultural differences) 

from my perspective as the BepiColombo spacecraft operations 

manager. My team and I are located at ESA’s European Space 

Operations Centre (ESOC) in Darmstadt, Germany. It is 

from there that we will control the composite spacecraft from 

its separation from the launcher until the MPO completes its 

scientific mission at Mercury, about eight years later. 

The Mission

The scientific mission objectives of BepiColombo include 

exploration of Mercury’s unknown hemisphere, investigation 

of the geological evolution of the planet, analysis of the 

planet’s internal structure, investigation on the origin of 

Mercury’s magnetic field and its interaction with solar wind, 

and characterization of the composition of the planet’s surface. 

32 | ASK MAGAZINE
To accomplish these and other objectives, the MPO has a 

payload of eleven instrument packages, and the MMO payload 

complement includes five instrument packages designed to

study fields, waves, and particles.

Launch is planned for August 2015 by an Ariane 5 from 

Kourou, French Guiana. The long cruise phase will include a 

combination of electric propulsion and gravity-assist maneuvers 

(once by Earth, twice by Venus, and four times by Mercury). 

Arrival at Mercury is currently planned for January 2022. After 

delivery of the MMO to its operational orbit and jettisoning 

of its sunshield, the MPO will finally reach its target orbit and 

start its scientific mission, which will last one Earth year, and 

may be extended by another Earth year. 

My team and I are responsible for conducting composite 

spacecraft operations from the BepiColombo Mission Operations 

Centre (BMOC), located at ESOC. For communications with 

the spacecraft, we will use the ESA network of Deep Space 

Antennas and JAXA’s Usuda and Uchinoura ground stations. 

After delivery of the two scientific spacecraft to their final orbits, 

we will remain responsible for operations of the MPO. In Japan, 

an operations team located at Sagamihara will be responsible 

for MMO operations. This team will interface with us until 

separation of the MMO from the composite spacecraft. Science 

ground segments in Europe and Japan will support the operations 

centers in the planning of scientific operations and archiving of 

scientific data. Finally, instrument operations will be supported 

by teams typically located at an instrument’s home institution.

Defining the Collaboration

The collaborative mission was selected by ESA in 2000. Like all 

missions selected as part of ESA’s mandatory science program, 

it underwent studies, first within ESA, then supported by the 

two main industrial prime contractors in Europe. Finally, at the 

beginning of 2007, a contract was placed with Astrium Germany 

to implement the European space-segment contribution. 

The collaboration with JAXA on this mission was formalized 

in a memorandum of understanding signed in April 2007 

by the ESA director general and the JAXA president. A slim 

document of fourteen pages, it establishes the framework of this 

collaboration in terms of responsibilities, management, handling 

of reviews, transfer of goods and data, access to scientific data, 

intellectual property rights, and release of public information. It 

was complemented shortly after by a program plan working out 

the principles outlined in the memorandum in more detail. 

The First Meeting

Our first meeting with JAXA took place in October 2006 at 

ESOC. As the popular saying goes, “You never get two chances 

to make a good first impression.” This meeting was therefore very 

important, as it would set the tone for the entire collaboration. 

At ESA, we are used to handling international collaboration. 

We interact with colleagues from our nineteen member states 

as part of our daily work; our contractors may come from 

AS: Etidero CtohP

ASK MAGAZINE | 33
additional countries outside the member states. We work daily 

with industrial representatives and scientists from member

states, as well as from long-standing partners such as the United 

States or Russia. These culturally challenging interactions are 

facilitated by an important though easily forgotten fact: most 

of these partners are familiar with the ESA environment. They 

normally know how we are organized, who does what, and 

what stands behind the job titles. When we met with our JAXA 

colleagues for the first time, all this was new to most of them, 

as their ways were to us. 

We therefore took care when defining the meeting agenda 

to dedicate time to background information on our centers and 

organizations. On the ESOC side, the meeting was chaired by 

my boss, the BepiColombo ground segment manager. At the 

beginning of the meeting, his boss, the head of the Mission 

Operations Department, which is responsible for spacecraft and 

ground-station operations at ESOC, joined to introduce himself 

personally to our Japanese colleagues and present the ESA 

organization, top-down, as well as a comprehensive overview of 

the missions being operated at ESOC. 

We then spent some time explaining our operations

concepts to each other. We did not talk about how we would 

later work together, but focused on trying to understand each 

other’s ways of doing business. Then we took them on a tour of 

ESOC’s mission operations facilities. 

The rest of the meeting was dedicated to discussing in detail 

all aspects of our interactions.

For this first meeting, we felt strongly that it was important 

to make responsibilities clear. While during meetings among 

European colleagues we do not normally evaluate statements 

by who is delivering them, we felt it would be very important to 

have topics explicitly covered by the person in charge of them 

in this first meeting with JAXA. We were also aware that our 

meetings occasionally become quite lively, with participants 

bringing up their views or opinions spontaneously on the 

subjects being discussed, sometimes even interrupting the 

speakers. We realized that this could blur the picture we were 

trying to establish, and therefore agreed that we would try to 

avoid that in the meeting. 

The meeting took two full days. We had about ten ESA 

participants and eight from JAXA. On the evening of the first 

day, we arranged to have dinner together at a nearby restaurant. 

One of the cultural differences manifested in meetings 

with our JAXA colleagues is their approach to internal 

communications. The MMO project manager or the ground 

segment manager normally handles all interactions with other 

MMO team members, communicating with their team in 

Japanese and with us in English. This pattern remains the same 

whether the team is physically located with us, as was the case 

for the first meeting, or connected by phone or videoconference, 

as is now mostly the case. This has certainly contributed to 

removing the language barrier almost completely, since our 

interlocutors are fluent in English. On our side, there are now 

more spontaneous interventions from the team than in the 

first meeting, but JAXA’s way of communicating helps keep 

discipline on our side. 

Setting Up the Interfaces

We have been holding yearly operations interface meetings since 

2008. The initial meetings were aimed mainly at clarifying the 

WE dId NOT TALK ABOuT HOW WE 

WOuLd LATER WORK TOGETHER, 

BuT FOCuSEd ON TRyING TO 

uNdERSTANd EACH OTHER’S 

WAyS OF dOING BuSINESS.

34 | ASK MAGAZINE
AS: Etidero CtohP

The BepiColombo Mercury Planetary Orbiter 

structural and thermal model on its ground-handling 

trolley with the high-temperature thermal blankets 

(white) partially installed. The conventional thermal 

blankets (silver) are visible where the high-temperature 

insulation has yet to be fitted.

ASK MAGAZINE | 35
requirements each agency placed on the other, in preparation 

for the ground-segment requirements review, which took place 

in November 2009. Our Japanese colleagues adopted very 

easily the ground segment interfaces that we proposed, based 

on our experience with other external agencies. But crosssupport requirements needed to be consolidated in more detail. 

We have worked with JAXA to produce an implementation 

agreement, working out the responsibilities and services 

outlined in the program plan in detail, and as many interfacecontrol documents defining the technical details of the relevant 

interfaces as necessary. Some of these documents—for instance, 

regarding ground station cross-support—are specific to the 

JAXA interface; others are shared across all external partners. 

Some of the interface work has required considerable 

discussion, flexibility, and creativity. For instance, the MPO–

MMO onboard interface is such that we are blind to what 

JAXA is uplinking to the MMO. This raises a concern on 

the difficulty for the two centers to support near-real-time 

interactive MMO operations, as is typically the case during 

near-Earth commissioning. We raised this point in the very first 

meetings with JAXA, and JAXA came back with their own 

concerns on the matter in 2010. After analysis of the MMO 

database structure, we came up with some ideas on how to 

improve the visibility by extra nonstandard processing of the 

data blocks by our systems. Requirements have been placed and 

are being implemented. 

Another specific aspect of this collaboration is the 

availability of technical documentation. JAXA only produces 

a subset of their documentation in English. We specified and 

justified very early on in the project the information to be shared 

with ESA. It is being provided either in a document in English, 

or translated in English within a document in Japanese. Instead 

of full documents, there have been cases—for instance, for joint 

reviews—where JAXA has summarized the review-relevant 

information in the form of viewgraphs. Though the amount of 

information we get access to is limited compared with what is 

normally available on a space program, it has until now been 

compatible with our needs. 

Outlook 

We are now moving into the ground segment implementation 

and operations preparation phase. A lot remains to be done, 

but we are benefiting from having established personal and 

formal interfaces with our JAXA colleagues early. Thanks to 

the preparatory work, the scope of the activities lying ahead of 

us is well-defined. 

Any joint decisions with JAXA take a long time to prepare. 

Our Japanese colleagues do not normally make decisions 

during the interface meetings. The meetings are used to collect 

information, discuss issues, and endorse prepared decisions. So 

far, this has not been a problem, but it requires careful attention 

in the preparation and timing of the meetings. 

I have taken Japanese lessons regularly between 2004 and 

2011, and have been to Japan twice, in 2005 and 2009. Neither 

trip was related to BepiColombo. When I started learning 

Japanese, I was mostly interested in getting exposure to a nonWestern culture. At that time, BepiColombo was very much 

in the background and did not enter into my decision to study 

the language. I will never speak nor read Japanese fluently—I 

study too little for that—but I have developed a keen sensibility 

for the Japanese culture. This experience has changed me, and 

certainly influences the way I handle the interaction with our 

JAXA colleagues. 

The collaboration with JAXA is an aspect of the mission 

that I enjoy a lot. It is undoubtedly one of the challenges of 

the BepiColombo mission: we carry the huge responsibility of 

delivering the MMO spacecraft safely into its orbit. We have 

managed to establish a relationship based on mutual trust and 

respect. Though not sufficient, it is a necessary condition to 

overcome the difficulties expected on the way. ●

Since 2007, elsa montagnon has been leading the flight 

control team for BepiColombo, the ESA–JAXA cornerstone 

mission to Mercury. Her responsibilities include the specification, 

acceptance, and validation of the ground segment preparation; 

validation of flight operations plans and procedures; and build-up 

and training of the flight control team.

uaerra. CC/AS: Etidere CgamI

This artist’s view shows the two BepiColombo orbiters 

mounted on top of their transfer module, forming a 

single composite spacecraft.

36 | ASK MAGAZINE
Having the opportunity to work for a company that operates in more than two hundred countries 

and territories and is a global leader in logistics has given me the opportunity to lead large global 

and regional information-technology projects. While technology made the work complex, the 

element of culture, both national and organizational, amplified the complexity.

Managing Multicultural Teams

 BY CONRADO MORLAN 

InsIght | ASK MAGAZINE | 37
A Global Project

The objectives of my first assignment were to lead the convergence 

of existing invoicing applications hosted and managed by 

country IT teams to a centrally managed single platform hosted 

in one of the regional data centers, and to standardize operations 

and processes. The new invoicing platform would be used by 

all countries in the Americas region; changes would follow a 

formal change-request process.

Although the existing invoicing applications shared core 

functionality, IT departments in individual companies had 

customized them by adding nonstandard functions that often 

did not comply with regional guidelines. This uncontrolled 

behavior led to new functions and processes that disrupted the 

standard operations at country and regional levels.

The technical team supporting the countries was challenged 

by reported incidents that often related to the customized 

functions, not core functionality. This was a source of conflict 

between the country IT teams and the technical support team, 

which many times was unable to address the issue. Business users 

did not produce invoices on time and their level of satisfaction 

was low. All this affected country and regional cash flow.

The Americas management board sponsored the project 

and mandated that all countries stop using any feature or 

function not aligned with the regional invoicing standards.

The Project Team

The project team consisted of stakeholders, the deployment 

team, and a technical support team. Stakeholders were the 

permanent regional management board and rotating country 

officials, including general manager, finance officer, and IT 

officer, who joined when the new platform was deployed in their 

particular country. The core deployment team was the same 

from project inception through completion and consisted of a 

project manager, technical-support team lead, and subject-matter 

experts in technology and invoicing. The rotating team members 

included country resources, both technical and end users. The 

technical support team, remotely located in Asia, supported dayto-day operation during the Americas business hours. 

During team formation, team management became 

complex as some stakeholders and members of the deployment 

team changed when a new deployment started. New members 

came on board and others departed as the deployment in their 

countries was completed. I had to understand how to integrate 

new members into the team smoothly, convincing them to 

accept change and promptly collaborate with the project.

I learned that I needed to develop cultural competencies 

to manage the project team effectively and establish 

connections with team members when they came on board. 

A kick-off meeting to explain the purpose and benefits of 

the project helped establish the bond between new team 

members and the project. The most important part of 

connecting was stressing the importance of their roles and 

how their local experience would enrich the project, as this 

created a sense of belonging that translated into engagement. 

But the connection was strengthened by understanding 

and respecting the different communication styles and 

preferences of the national cultures involved.

There are many books about national cultures, but few 

resources explain how to deal with national cultures in project 

teams. While attending project management congresses, I was 

able to connect with other project management professionals 

who had faced similar challenges and learn from their 

experiences. I also learned from my own mistakes. During my 

first visit to Asia, I met with the technical-support team lead 

and his team and inadvertently broke the local meeting protocol 

when I started asking direct questions of team members. After 

catching the nonverbal cues of team members that showed they 

were asking the team lead for permission to answer, I switched 

to directing questions to the lead. He then selected the person to 

answer the question. At the end of the meeting, I apologized to 

the team lead and team members for my oversight and made it 

clear that my intention was not to make them uncomfortable or 

38 | ASK MAGAZINE
violate local meeting standards. I quickly shared what I learned 

with the rest of the deployment team.

Speaking foreign languages is a must in a global project

environment, but language skill alone does not make a crosscultural expert. It is necessary to understand other cultures’

values, beliefs, and communication preferences. Knowing how

they manage and resolve conflict is essential, for obvious reasons.

duRING My FIRST VISIT TO ASIA, I MET 

WITH THE TECHNICAL-SuPPORT TEAM 

LEAd ANd HIS TEAM ANd INAdVERTENTLy 

BROKE THE LOCAL MEETING PROTOCOL 

WHEN I STARTEd ASKING dIRECT 

quESTIONS OF TEAM MEMBERS.

It is also important to understand your own culture’s norms 

and behaviors. That knowledge helps guard against interpreting

other cultures’ behaviors in terms of your own unexamined

expectations. Reflecting on your own culture helps you understand 

and interpret why people from other cultures act the way they do.

With those recommendations in mind, I looked for ways

to improve my cultural awareness in order to better understand 

my team members. As the project progressed and my cultural

awareness improved, my connection with international team

members became closer and more robust. When I had to

spend more than two weeks in a country, I usually spent my

weekends visiting popular spots where locals met: restaurants,

farmers’ markets, coffee shops, and occasional sporting events 

where I observed people’s customs, traditions, and behaviors. 

My observations in those settings helped answer my questions 

about culture. When in doubt, I asked questions either of the 

locals or my colleagues.

Intracompany Networking 

I often met with country management boards during the course of 

the project; these meetings offered good opportunities to establish 

long-lasting business relationships. I learned the importance of 

doing “my homework,” gathering all the relevant information 

prior to any meeting and knowing the audience in advance. 

Having established strong relationships in the initial phase of the 

project helped me get insight into country officials from people 

who had already dealt with them. Knowing the preferences and 

sometimes the opinions of a country’s management board about 

the project helped me to build the right deployment strategy and 

know what to expect from meetings.

In every meeting with country management boards, my 

team and I wore business attire and arrived on time. Board 

members arrived gradually and the general manager usually 

arrived late, demonstrating his status. The meeting started with 

preliminary discussions that helped build rapport. Deployment 

discussions occurred only after rapport was established. Usually, 

the first meeting exceeded the original allotted time and a 

second meeting was required to make the final decisions.

In this kind of project, it is important to have a well-defined 

circle of people who can influence the outcome. It can be like 

having “invisible” team members who support important 

functions and contribute to project performance.

Relationships should span all levels of the organization 

and not be limited to the higher ranks. Establishing a good 

relationship with users gives you feedback regarding the 

operation of the application and how it can be enhanced. For 

instance, Costa Rican users helped solve a common problem: 

end-of-day activities that involved several steps that required 

ASK MAGAZINE | 39
constant attention and, often, work after regular business

hours. They suggested assessing the feasibility of automating 

these tasks. The assessment was positive and the tasks were 

automated, enabling Costa Rica and the other countries to 

avoid overtime payment.

A New Project Manager’s Role

In an environment where organizations depend on global

projects for benefits that contribute to strategic objectives, the 

project management professional needs to explore new ways 

to lead, execute, and deliver projects supported by dispersed 

and diverse teams. Technical expertise is not enough. Project 

managers must adopt a business-oriented approach and cultural 

awareness and other soft skills. The most important knowledge 

and skills include the following:

• Strategic Management. Understanding an organization’s 

strategy will provide the backdrop for future assignments 

and an understanding of project selection criteria. Only 

projects that help the organization fulfill its intended

purpose should be selected.

• Mindful Communication. Communication is crucial to 

project success. Communication needs to be customized 

to the specific cultures involved in a diverse project team. 

Good communication influences and inspires project

teams and helps build strong relationships across the

organization.

 • Adaptability. New leadership styles that fit the global 

project are required when working with diverse and

dispersed teams located across time zones.

 • Resilience. Realigning or repairing projects facing

unexpected hardship because of miscommunication and 

problematic behaviors as well as cross-cultural issues and 

conflicts will be a regular part of the project manager’s task. 

• Transparency. Adherence to an organization’s values and 

culture as well as professional codes of ethics is mandatory 

in global projects. The state of the global project needs 

to be shared promptly with relevant parties whether the 

project is in good shape or facing hardships.

In this new role, the project manager will turn into a perennial 

learner striving toward excellence, a great communicator, and 

a business partner who ensures that projects will produce the 

benefits the organization is seeking.

Key Questions

If you manage or are thinking of managing a global project, 

here are some basic questions you should ask yourself:

• As a global project manager, how do you deal with cultural 

issues in your project team?

• What is your strategy to deal with conflict in a crosscultural team?

• D o you enjoy the challenge of being a global project 

manager? ●

40 | ASK MAGAZINE
An ArgenTine

PArTnerShiP

wiTh nAS

BY MAT

A

THEW KOHUT

When the Aquarius mission launched from Vandenberg Air Force Base in June 2011, 

few Americans outside the Earth-science and space communities probably knew 

that the satellite itself came from Argentina. 

tenmnervo Geniteng: Artedir CotohP

Argentine President 

Cristina Fernandez 

de Kirchner 

(center in blue) was

briefed on Aquraius 

January 20, 2010. 

From left, Aquarius 

instrument manager 

Simon Collins, JPL; 

Aquarius instrument 

systems engineer 

Dalia McWatters, JPL; 

President Kirchner; 

Alejandro Ibanez, 

INVAP; and Juan 

Carlos Miazzi, INVAP.

The Aquarius instrument is integrated to the service platform at INVAP (Bariloche)

Photo courtesy of INVAP/Luis Genovese

just before its shipment to Brazil for environmental testing.
Schematic visualizations of circulation 

in the North Atlantic, South Atlantic, and 

Indian Ocean basins. White arrows depict 

wind-driven surface currents. Blue arrows 

depict density-driven deep currents. 

The Aquarius/SAC-D mission (SAC is the acronym for Satélite 

de Aplicaciones Científicas—Scientific Applications Satellite) is 

the fourth in a series of satellites developed by the Comisión

Nacional de Actividades Espaciales (CONAE), Argentina’s

space agency, in collaboration with NASA. CONAE’s industry 

partner, INVAP, was responsible for building the spacecraft and 

conducting all integration and testing activities. 

For Luis Genovese, INVAP’s project manager for the

Aquarius/SAC-D observatory, this project reflected the

maturation of a collaborative relationship with NASA that

began in the early 1990s. By the time of the Aquarius proposal 

in 2002, he had worked with his partners at the Jet Propulsion 

Laboratory (JPL) for years. “This was the first time we were

participating in a project where the mission itself was a NASA

mission,” he said, noting that Aquarius was selected by NASA

through a competitive process. 

Since NASA’s Aquarius instrument would be flying on

a CONAE–INVAP spacecraft bus, NASA implemented a

rigorous insight program to ensure alignment with the agency’s 

standards and requirements. “We provided a high level of

visibility into the methodology and the processes that we

follow in our space missions, and this went very well, as many

of the processes were already qualified from the previous SAC 

projects,” said Genovese, citing electronics manufacturing and 

software engineering as competencies that already met NASA 

standards or certification requirements. 

Genovese also had other stakeholders to manage. In addition 

to the Aquarius instrument, the spacecraft carried seven other 

instruments—five developed in Argentina, one from France’s 

Centre National d’Etudes Spatiales, and one from the Italian 

Space Agency. “Everyone had configuration requirements that 

required the right implementation, and at the same time we 

had to ensure full system compatibility,” he said. With such 

diverse partners, the challenge extended beyond technical 

compatibility. “Our cultures are different so it was kind of a 

challenge for many, many people being able to communicate to 

different NASA centers with different ways of operations.” 

As with any spaceflight project, Genovese and his team 

encountered unanticipated hurdles along the way. The original 

mission design called for using a nickel-hydrogen battery from a 

U.S. vendor to power the spacecraft. As the design progressed and 

requirements changed, the cost of the original battery technology 

became prohibitive. After assembling a tiger team that included 

experts from Goddard Space Flight Center, CONAE and 

EyE ON THE 

OCEANS

Aquarius will allow scientists to see 

how freshwater moves between the 

ocean and the atmosphere as a result 

of rainfall, evaporation, ice melt, 

and river runoff, and will supply new 

insights on ocean circulation and 

climate. Aquarius’s measurements of 

sea-surface salinity will provide a new 

perspective on the ocean and its links 

to climate, greatly expanding upon 

extremely limited past measurements. 

During its first few months in space, 

the mission will acquire as many 

measurements of sea-surface salinity 

as had been collected from ships and 

buoys during the previous 125 years. 

42 | ASK MAGAZINE
NASA approved a decision to switch to a lithium-ion battery, 

which would offer greater efficiency and performance. The new 

battery technology had never been subjected to as many cycles 

as Aquarius demanded, so significant work had to be done once 

a vendor was selected to ensure the new battery would meet the 

mission’s requirements. 

Another problem emerged relatively late in the spacecraft 

integration process. A test of the propulsion subsystem revealed 

a leakage problem with the thrusters. At this point, a worst-case 

scenario might have been a delay of a year or more. Fortunately, 

INVAP’s partners at JPL were able to procure a qualified 

replacement thruster from a U.S. vendor with minimum trouble. 

“Working as a team with JPL, CONAE, and the vendor, and 

having the luck to have all the expertise, we had to be sure that 

everything was implemented correctly because our technicians 

had to reconnect the thrusters and test the overall system from 

mechanical, electrical, and propulsion points of view,” said 

Genovese. Much of the repair work was performed in Brazil, 

where the observatory environmental testing took place, adding 

another level of complexity in terms of project management.

SAC-D also posed an infrastructure challenge to INVAP: 

at the time the project was awarded, the spacecraft’s dimensions 

were significantly larger than their existing facilities could 

accommodate for integration and testing. The company made a 

strategic decision to invest in a new 60,000-square-foot facility 

in Bariloche, Argentina, to meet the needs of the project. “When 

we started to assemble the service platform, it was the first time 

we used this new assembly and integration facility,” Genovese 

said. “We were very proud of having the Aquarius instrument 

being delivered to Bariloche for system-level integration and 

testing at our own facilities.”

Reflecting on how Aquarius demanded a deeper 

level of international collaboration than the earlier SAC 

projects, Genovese emphasized the role of trust and constant 

communication. “We especially took care to provide a high level 

of visibility of our work to NASA. We worked really as a team, 

and we were not hiding anything in any aspect,” he said. “This 

project took eight years of work here. More than two hundred 

people were involved, and more than 650,000 engineering 

hours were devoted to this project, so I would say that trust and 

communications were the most important considerations.” ●

Image Credit: NASA/Scientific Visualization Studio ASK MAGAZINE | 43
BY BO SCHWERIN

HMA’s NASA-enhanced, ultra-high-pressure 

fire-suppression systems can extinguish a 

range of fire situations in significantly less time 

and using less suppressant than traditional 

low-pressure, high-volume systems.

Photo courtesy of NASA’s Spinoff

44 | ASK MAGAZINE | story
Marshall Space Flight Center has been at the heart of the agency’s 

rocketry and spacecraft-propulsion efforts since its founding 

in 1960. Located at the Redstone Arsenal near Huntsville, 

Alabama, the center has a legacy of success stretching back to 

the Saturn rockets that carried the Apollo astronauts into space. 

Even before Marshall was established, Redstone was the site of 

significant advances in American rocketry under the guidance 

of famous rocket engineer Wernher von Braun; these included 

the Juno I rocket that successfully carried the United States’ 

first satellite, Explorer 1, into orbit in 1958. And from the first 

orbital test flight of the Space Shuttle Columbia through the 

final flights of the shuttle program last year, these vehicles have 

been enabled by the solid rocket boosters, external tank, and 

orbiter main engines created at Marshall.

Today, Marshall continues to host innovation in rocket and 

spacecraft propulsion at state-of-the-art facilities such as the 

Propulsion Research Laboratory. Like many of its past successes, 

some of the center’s current advancements are being made with 

the help of private industry partners. The efforts have led not 

only to new propulsion technologies but to terrestrial benefits in 

a seemingly unrelated field—in this case, firefighting. 

Partnership

Orbital Technologies Corporation (ORBITEC) of Madison, 

Wisconsin, has been a longtime NASA partner, working with 

the agency on numerous projects—many through the Small 

Business Innovation Research (SBIR) program—on a range of 

space-exploration needs, from growing crops in space (Spinoff

2010) to advancing rocket engines. 

Through the SBIR program, ORBITEC has collaborated 

with several NASA centers, including Marshall, to develop 

products such as a cool-wall vortex combustion chamber that 

represents a new way in rocket engine design. By feeding a 

liquid or gas oxidizer into the combustion chamber in a manner 

that generates a swirling vortex flow, the design confines

the mixing and burning of the propellant to the core of the 

chamber, keeping the walls free from volatile thermal stresses. 

This process increases the durability and lifespan of the engine 

while allowing for smaller, cost-effective, and even reusable 

engine designs. Through further SBIR contracts with Marshall, 

ORBITEC applied this innovation to an advanced vortex hybrid 

rocket engine that combines solid and liquid fuel to power a 

low-cost, highly reliable, and versatile propulsion option. 

Rory Groonwald, chief engineer for ORBITEC subsidiary 

HMA Fire, saw potential in much of ORBITEC’s propulsion 

technologies beyond space exploration. Through extensive work 

with the U.S. Air Force Fire Rescue Research Group to develop 

means for more effectively extinguishing hydrocarbon-based 

fuel fires, HMA developed fire-suppression systems that used 

ultra-high pressure (UHP) for firefighting. Groonwald was 

exploring ways to improve the efficiency of fire-suppression 

systems by reducing the time and amount of water needed to 

extinguish a fire. 

“We were trying to make something more effective and 

safer for firefighters to use,” Groonwald said. 

The idea of management of high-pressure flows, as 

ORBITEC does with rocket engine design, repeatedly came to 

mind. Working with its partners, HMA incorporated elements 

derived from ORBITEC’s propulsion work into its design for fire 

suppression, and the improvements significantly enhanced the 

performance of HMA’s UHP systems. For example, the company 

studied how to better manage the flow of a liquid to create an 

energetic blanket of fine water droplets. Through iterative design 

and testing, they optimized a method for providing a continuous 

and effective stream that uses much less suppressant. 

Benefits

HMA’s propulsion-inspired design is only one of the benefits 

the company’s UHP suppression systems provide to firefighters. 

The systems introduce an approach to fire suppression that is 

complementary to—and in a number of cases superior to—

traditional firefighting methods.

“The fire industry still has a mentality of ‘surround and 

drown’—the more water you put around a fire, the faster the fire 

will go out,” Groonwald said. “But that is not necessarily true.”

One series of tests using empty houses at Vandenberg Air 

Force Base compared an HMA system with a 20-gallon-perminute, 1,400-pound-per-square-inch (psi) discharge capability 

(at the pump) versus a standard 100-gallon-per-minute, 125-psi 

standard hand line—the kind that typically takes a few firemen 

to control. The standard line extinguished a set fire in a living 

room in 1 minute and 45 seconds using 220 gallons of water. The 

Much deserved attention is given to the feats of innovation that allow humans to live in space and 

robotic explorers to beam never-before-seen images back to Earth. In the background of these 

accomplishments is a technology that makes it all possible—the rockets that propel NASA’s spaceexploration efforts skyward. 

ASK MAGAZINE | 45
fofnipSs ’ASAf Ny osetruoo ctohP

HMA’s fire-suppression 

technology is ideal for a host 

of firefighting applications, 

including combating wildfires in 

areas unreachable by standard 

fire trucks. Here, HMA’s L3 

(light, lean, and lethal) vehicle 

demonstrates these capabilities.

fofnipSs ’ASAf Ny osetruoo ctohP

Through NASA’s Small Business 

Innovation Research program, 

ORBITEC developed vortex 

combustion technology, 

representing a new approach to 

rocket engine design. ORBITEC’s 

NASA work led to advancements 

in fire-suppression systems by the 

company’s subsidiary, HMA Fire.

46 | ASK MAGAZINE
HMA system extinguished an identical fire in 17.3 seconds using 

13.6 gallons—with a hose requiring only one person to manage.

“[The HMA system] sucked the life out of the fire and did it 

faster than anything I’ve ever seen before,” said Devin Misiewicz, 

captain of the Vandenberg Air Force Base Fire Department. 

The key to the HMA system is the pressure of its discharge, 

which results in smaller droplets dispersed on the fire. The 

smaller droplets create a greater total surface area contacting 

the flames—four times the total surface area of the larger 

droplets from standard, low-pressure systems. In addition to 

helping rapidly extinguish a fire, HMA’s UHP approach also 

quickly reduces the temperature around a blaze—in the case 

of the Vandenberg test from 1,400°F to below 250°F within 

60 seconds, about 2 minutes and 30 seconds faster than the 

standard equipment—and results in less smoke. 

“What this does is create a safer environment for the 

firefighters to conduct an offensive suppression attack on the 

fire,” says Groonwald. Using less water also reduces one of the 

major sources of damage from a fire situation: the water itself. 

HMA’s Hydrus systems are commercially available in a 

range of platforms. The T4 and T6 First Responder Emergency 

Systems incorporate the system into easily maneuverable, allterrain vehicles. Along with the company’s Proteus Series Brush 

Trucks and skid-mounted mobile units that can be loaded 

onto any number of vehicles, HMA’s systems provide a quickresponse firefighting tool for a range of fire situations. Carrying 

their own water sources, these systems are ideal for fighting 

wildfires in areas unreachable by standard fire trucks. The 

systems’ high-pressure discharge can also penetrate 7 inches 

into the ground if desired, cooling lingering embers and heat 

sources that can reignite a wildland-type fire. The UHP 

systems are also highly effective against hydrocarbon fuel–

based car fires and have been repeatedly proven to extinguish 

fully engulfed cars in 9 seconds.

While Groonwald says that HMA’s systems are not intended 

to replace standard firefighting technology in all cases, they can 

be installed on fire trucks as a first-attack tool complementing 

raditional low-pressure, high-volume systems. 

“Our systems become a force multiplier,” said Groonwald. 

You can do more safely with the same amount of people.” 

Government partnerships like those between HMA and 

RBITEC, NASA, and the air force have supported the 

esearch and development leading to the creation of these gamehanging firefighting tools, said Marty Gustafson, ORBITEC 

ngineer and applications research manager.

“This is where the government–industry partnerships 

ake a difference,” she said. “They allow you to prove out a 

echnology in a way that gives you instant credibility.” 

The experts are buying in: the U.S. military employs 

our UHP units at the forward operating base near Kabul in 

fghanistan to help combat fuel fires and firebomb attacks. 

he navy uses the systems in the Middle East, and twelve air 

orce bases in the United States employ the technology. Alaska is 

lso examining the systems for remote towns, where they can be 

sed by operators without firefighting training, and the Mojave 

ir and Space Port in California features the technology on a 

pecially designed rapid-response rescue truck. Plus, municipal 

ire departments are interested in the technology’s NASAnhanced capabilities, meaning cities and towns nationwide 

ould soon benefit from another example of space-exploration 

echnology improving daily life. ●

ydrusTM, T4TM, T6TM, and ProteusTM are trademarks of Orbital 

echnologies Corporation.

his article was originally published in NASA’s Spinoff 2011.

t

“

O

r

c

e

m

t

f

A

T

f

a

u

A

s

f

e

c

t

H

T

T

THE STANdARd LINE EXTINGuISHEd A SET FIRE IN A LIVING ROOM IN 1 MINuTE ANd

45 SECONdS uSING 220 GALLONS OF WATER. THE HMA SySTEM EXTINGuISHEd 

AN IdENTICAL FIRE IN 17.3 SECONdS uSING 13.6 GALLONS—WITH A HOSE 

REquIRING ONLy ONE PERSON TO MANAGE.

ASK MAGAZINE | 47
48 | ASK MAGAZINE | story

brIngIng DIscIplInes together

BY DAVID YOUNG
Photo Credit: NASA

CLARREO, the Climate Absolute Radiance 

and Refractivity Observatory, is an Earthscience satellite mission in pre-Phase A 

(conceptual study) that is being designed to 

capture critical climate-change data much more 

precisely than has been possible with existing 

instruments. Its spectrometers, sensitive to the 

full range of infrared and visible radiation, will 

improve the accuracy of measurements of all 

the radiation leaving Earth by a factor of two 

to ten. That accuracy and the mission’s ability 

to measure trends over a decade or more could 

help scientists know whether climate change 

will be less or more severe than expected as 

much as two decades earlier than current data 

allow. This could be a key determinant for 

decisions concerning our nation’s response to 

changes in climate.

So it’s not surprising that the 2007 decadal survey of “Earth 

Science and Applications from Space” considered CLARREO 

one of four high-priority Earth-science missions. In response 

to the survey, a small team of scientists was formed at Langley 

Research Center to define the mission. In early 2009, we gathered 

a full-fledged preformulation team including scientists, systems 

analysts, discipline engineers, and business analysts at Langley 

along with smaller teams at Goddard Space Flight Center and the 

Jet Propulsion Laboratory and about ten external organizations 

with the goal of developing a feasible concept for CLARREO.

Bringing the Team Together

Having worked on other NASA science missions, including 

CERES (Clouds and the Earth’s Radiant Energy System) 

and CALIPSO (Cloud-Aerosol Lidar and Infrared Pathfinder 

Satellite Observations), mission scientist Bruce Wielicki, mission 

formulation manager Steve Sandford, and I were well aware of 

a familiar pitfall—that the CLARREO scientists would want 

only the best possible data regardless of the practical difficulties 

involved in getting it. That would lead to time-consuming and 

potentially acrimonious trade talks when scientific desires came 

up against engineering and budget realities. To avoid that kind 

of problem, we were determined to bring the team together 

CLARREO hopes to capture critical climatechange data much more precisely than has 

been possible with existing instruments.

ASK MAGAZINE | 49
early and make the science and engineering decisions part of 

one discussion, not two. From the outset, the management 

team had a vision of forming a truly interdisciplinary team that 

involved systems thinking at all levels.

We began by holding a two-day off-site retreat, facilitated 

by 4-D team-assessment experts. The 4-D Systems approach 

focuses on critical “soft skills” for scientists, engineers, and 

project leaders. The retreat included some typical team-building 

activities, such as people talking about their backgrounds to get 

to know one another, but most of the team building came from 

doing actual project work: establishing a clear shared vision of 

the mission, defining roles and responsibilities, and dealing 

with bottlenecks that had already become evident by diffusing 

authority that was concentrated in one overworked individual. 

The 4-D facilitators also provided the team with training that 

helped us appreciate the benefits of continual engagement across 

the diverse skills of the team.

Back at Langley, the entire team was collocated in an open 

area that had once been a cafeteria. There were no closed offices, 

only cubicles and multiple meeting areas, so everyone was aware 

of what his or her colleagues were doing. The project leaders 

worked in cubicles, too, and were always accessible. We had 

not only an open-door policy, we had a no-door policy. This 

resulted in a dynamic, collaborative environment that furthered 

the bonding process that started at the retreat. 

Although at times noisy and a bit chaotic, this arrangement 

made it easy to join in conversations and address issues as they 

arose. On multiple occasions, I was able to quickly provide 

clarification of technical aspects of the science in response to 

conversations in our break room. We encouraged systems 

thinking by including science and engineering representatives 

at almost every technical meeting. Communication was further 

enhanced through daily, early-morning, stand-up meetings to 

share late-breaking news and set daily priorities. 

Our integration initiatives went beyond the Langley team. 

Internal and external science team members participated in 

weekly telecons in the first year as scientific goals and priorities 

were clarified. We also worked actively to bridge the common 

gap between scientist-observationalists, who focused on how to 

gather data, and the data users, who wanted the best possible 

data and didn’t give much thought to issues related to the 

instruments that would gather it. We brought several teams of 

global climate modelers who would be the primary CLARREO 

data users into our requirements planning from day one. That 

has led to the development and use of innovative climateobserving system-simulation experiments that have not only 

demonstrated the utility of CLARREO data for improving 

climate predictions, but have been essential in setting rigorous 

accuracy requirements for the measurements. 

The Science-Value Matrix 

The most significant result of our integrated approach has been 

the development of the science-value matrix (SVM). This tool 

has helped clarify our trade discussions and weigh scientific 

value against cost, risk, and reliability as fully and objectively 

as possible. Like other work on CLARREO, developing the 

science-value matrix was a cooperative team effort.

The relative merits of competing goals are difficult to 

quantify for a complex mission with multiple science objectives. 

This is particularly true for a mission like CLARREO, where 

the measurements are applicable to a wide range of climate 

objectives. Without an objective means of calculating science 

benefit, our team could not effectively evaluate the relative 

costs and benefits of multiple engineering approaches. We met 

this challenge by developing the SVM: an innovative approach 

to quantitatively defining science value for key aspects of the 

mission, including measurement accuracy, orbit type, and record 

length. Benefits were measured based on the specific advances 

that CLARREO would provide in reducing uncertainties in the 

climate observations as defined by the Intergovernmental Panel 

for Climate Change. By rigorously defining relative science value 

across the broad climate objectives of CLARREO, the team 

A mural painted by summer student Amanda Cichoracki to represent CLARREO’s mission.

Photo Credit: NASA Langley Research Center/David Beals

50 | ASK MAGAZINE
provided a mechanism for optimizing science value relative to 

cost for a broad range of potential mission architectures.

The SVM was also designed to be a management tool to 

be used over the project’s life cycle. The matrix grounded and 

shaped discussions in objective fact and helped avoid what could 

otherwise easily have become formless, inconclusive debates. 

It definitely helped us guard against mission creep—the

temptation to add just one more capability that could quickly 

lead to losing control of budget and schedule.

For instance, members of our external science team

advocated the addition of a polarimeter that would use the 

polarization of light to analyze aerosols (particles suspended in 

the atmosphere) to CLARREO’s instruments. They wrote a 

peer-reviewed paper arguing for the instrument. In fact, it would 

have been a potentially great addition, since aerosols influence 

the amounts of absorbed and reflected radiation. The question 

was, how would that added value compare to the added cost? 

The SVM allowed us to determine that a polarimeter would give 

us 30 percent added value but would raise the cost by 30 percent 

as well. Headquarters agreed that the instrument was a great 

idea but decided it was a great idea we couldn’t afford within the 

CLARREO project.

The Future of CLARREO

The CLARREO team successfully passed its mission concept 

review in November 2010. The effectiveness of team integration 

was confirmed by the review panel’s board chair, who cited 

the exceptional working relationship among science, project 

management, and engineering as a major strength of the project, 

leading to a mission concept that was extremely mature for 

that project stage. Due to budget considerations, CLARREO 

remains in an extended pre-Phase A. 

NASA continues to fund efforts to refine the mission 

design and to look for cost-effective alternative ways to carry it 

out. For instance, we are examining the possibility of putting 

the instruments on the International Space Station instead of 

DaviD young is the project scientist for CLARREO at Langley 

Research Center, where he has been working for more than thirty 

years to help understand Earth’s climate. He currently serves as 

the deputy for programs in the Langley Engineering Directorate.

This global map shows temperature anomalies for July 4–11, 2010, compared 

with temperatures for the same dates from 2000 to 2008. CLARREO’s ability 

to measure trends over a decade or more could help scientists know whether 

climate change will be less or more severe than expected as much as two 

decades earlier than current data allow.

Image Credit: Jesse Allen, based on MODIS land-surface temperature data available through the 

NASA Earth Observations web site

on their own satellite observatories. We have also been working 

on a study with a group in the United Kingdom, exploring 

possibilities for international partnering. And we are using the 

science-value matrix to search for a less expensive way to achieve 

the mission’s science goals, perhaps with less capable but still 

adequate instruments.

The budget constraints are challenging, but we remain 

committed to this critical climate mission. This team experience 

has been one of the most rewarding of my career, and I believe 

that the trust and cooperative spirit the CLARREO team has 

developed in our years together will help us succeed despite 

these challenges. ●

WE HAd NOT ONLy AN OPEN-dOOR POLICy, WE HAd A NO-dOOR POLICy. 

THIS RESuLTEd IN A dyNAMIC, COLLABORATIVE ENVIRONMENT THAT 

FuRTHEREd THE BONdING PROCESS THAT STARTEd AT THE RETREAT.

ASK MAGAZINE | 51
An Engineer’s Alphabet, by Henry Petroski 

(Cambridge University Press, 2011)

Author of The Evolution of Useful Things and The Pencil: 

A History of Design and Circumstance among other books, 

Henry Petroski has long been an astute and eloquent 

explainer of how engineering works and why it matters. 

His An Engineer’s Alphabet is an entertaining and thoughtprovoking collection of anecdotes, facts, quotations, and brief 

essays on subjects ranging from abbreviations and acronyms 

in engineering to Zen and the Art of Motorcycle Maintenance. 

Along the way, Petroski writes about calculators, peer reviews, 

pocket protectors, skunk works, the Tacoma Narrows Bridge 

disaster, useless things, and hundreds of other topics of interest 

to engineers.

The many entries represent, as Petroski says, “the distillation 

of decades of writing, talking, and thinking about engineers 

and engineering.” There is trivia here—for instance, a list of 

universities whose sports teams are nicknamed “engineers”—but 

also serious food for thought. Under “Hubris in engineering,” 

Petroski writes:

I t took Galileo, who opened his treatise on two new 

sciences with stories of well-considered things that 

did not work, to explain how physical considerations 

that may be ignored on a small scale can dominate the 

behavior of a larger but geometrically similar design. 

Unfortunately, what Galileo knew in the Renaissance 

was not always remembered in subsequent centuries.

Discussing the commercial failure of supersonic airliners 

later in the same little essay, he offers this wisdom: “The designs 

of engineers must be more than just strong enough and fast 

enough; they must also be compatible with the existing physical, 

social, and political infrastructure.”

And what engineer would disagree with this, from 

“Scientists vs. engineers”:

 It is a common lament among engineers that all too 

Here are descriptions of some books that we believe will interest ASK readers.

ASK Bookshelf

52 | ASK MAGAZINE
ASK MAGAZINE | 53

functions effectively in the context of leadership dealing with 

issues that are literally unmanageable.

These stories provide examples of project leaders challenging 

the status quo with courage and creativity. The U.S. Air Force 

project leader who changed the government’s relationship with 

contractors from adversarial oversight to trusting partnership 

and the manager of a large construction project who motivated 

procrastinating designers by beginning construction before 

their plans were complete faced strong opposition and incurred 

a lot of personal risk, but they believed that radical action was 

the only way to succeed. They were very much rebels with a 

cause: Laufer emphasizes the importance of fighting the status 

quo only when and where it is necessary.

Many of the stories—the air force story mentioned above 

is one—are partly about culture change: developing new ways 

of working and new ways of thinking about work. Although 

the exact nature of that change varies from story to story, in all 

cases its foundation is trust. And trust is developed by working 

together—by demonstrating trustworthiness—and through 

constant, honest communication. The fact that leadership and 

project success depends on good communication in all available 

forms (and especially traditional person-to-person conversation) 

is an underlying theme of all these stories.

Note: Ed Hoffman, Larry Prusak, and Don Cohen (all of us 

currently associated with ASK) have contributed in various ways 

to this book, but it is very much Laufer’s accomplishment.

The View from Here: Optimize Your Engineering 

Career from the Start, by Reece Lumsden 

(Illumina Publishing, 2011)

Reece Lumsden, an experienced aerospace engineer, has 

written a book primarily for young engineers and students 

considering a career in engineering. The topics he covers range 

from the qualities that make a good engineer to the value of 

co-op programs and mentoring to the importance of systems 

thinking and good communication skills. He also offers some 

sound advice on job hunting and what to expect—and how to 

succeed—once you find an engineering job.

The View from Here offers engineering students some of the 

benefits of mentorship, providing down-to-earth advice from an 

older, experienced professional about many of the possibilities 

and pitfalls of their chosen profession. Managers of young 

engineers will find value in the book, too, as a guide to their role 

in helping those new hires develop and flourish. ●
The Greeks Had Many Words for It

BY LAURENCE PRUSAK

The Knowledge Notebook

At the end of February, the Office of the Chief

Engineer at NASA convened a meeting at Kennedy 

Space Center to discuss a variety of practices and

policy issues regarding knowledge management at

the agency. The meeting included representatives

from NASA centers and some guests who talked

about knowledge management work being done at

the FBI and the World Bank. For two and a half

days, we shared experiences and thoughts about

how best to share and use knowledge at NASA.

One aspect of the meeting stood out for me,

however. While we were all there to talk about

knowledge, the word itself clearly had diverse

meanings for the assembled practitioners. In fact, if 

we had gone around the room asking people what

knowledge is, there would be far less overlap in

meanings than anyone would have guessed going

into the meeting. 

 That fundamental disparity has been my

experience in many such meetings for the past two 

decades or so. Unlike our shared understanding

of almost any other term used in organizations

technology, systems, information, data, markets,

processes—we seem to lack a common idea of

what knowledge is. This makes working with

knowledge quite problematic. 

 Whenever I mention that I study and consult

on the subject of knowledge, this absence of

shared understanding of the meaning of the word

“knowledge” is conveyed to me in starkest terms.

Some people ask me if I can help them fix their PC 

(absolutely not); others want to know if I can help

their kids write a philosophy term paper (I probably 

could, but I’m not a philosopher); one person

asked me to explain the Myers-Briggs personality

test (my explanation would be no better than

—

most people’s). When a large, diverse organization 

undertakes to develop some innovative knowledge 

practices, think of the semantic confusion that is 

likely to ensue—and get in the way of effective 

cooperative work. 

Part of the problem is a linguistic issue. We really 

have just one word—knowledge—for what is in 

fact a very broad set of meanings or understandings. 

Many other languages have at least two words for 

knowledge; some Asian languages have three. The 

classical Greeks had at least seven words they used 

to describe different varieties or aspects of what we 

are forced to call “knowledge.”

Let me give you an example of how wide are 

the parameters of what we think of as knowledge. 

On one end of a continuum of meanings of 

“knowledge,” we might have the example of the 

Pythagorean theorem beloved (or hated) by 

high-school geometry students. It can easily be 

considered as a “piece” of knowledge. It surely is 

a part of the whole we call geometrical knowledge. 

The Pythagorean theorem is complete in itself. 

It needs no context or further documentation to 

make its meaning clear. It can be readily and fully 

explained by a geometry teacher and understood 

by her students.

Now let’s move to the other end of the spectrum 

of meanings of “knowledge.” A few months ago, I 

gave a talk to a group of Irish executives visiting 

Boston. When I was discussing knowledge and 

knowledge management, one of them told us that 

his brother was a well-known horse trainer in rural 

Ireland. The brother was famous for his skills but 

practically inarticulate when it came to describing 

how he does what he does. Even though a clear 

explanation of his work might bring him added 

54 | ASK MAGAZINE
business or repute, he can’t describe it except in the most banal 

and meaningless way. And this is a person in a country where 

people are known for their expressive skills! But his knowledge 

is almost all tacit—subtle, contextual, and very hard to represent 

or make understandable except, perhaps, by showing rather

than telling. Yet we would likely use the same English word to 

describe the Pythagorean theorem and the expertise of the horse 

trainer. How can one devise acceptable practices and policies for 

knowledge when the word can mean such different things? 

Well, some organizations do it. How they do it is by devising 

a consensus definition that meets the needs of the organization 

and is clear to everyone in the organization. It’s that simple. No 

language police are called for, no attacking others’ meanings

and pet ideas—just a negotiated truce that makes clear what we 

are talking about when we talk about knowledge. ●

ASK MAGAZINE | 55
ASKinteractive

For More on 

Our Stories

Additional information 

pertaining to articles 

featured in this issue can 

be found by visiting the 

following web sites:

• galex:

www.nasa.gov/galex

• clarreo:

clarreo.larc.nasa.gov

• aquarius:

aquarius.nasa.gov

NASA in the News

Focusing on a space program that is built to last, NASA’s FY2013 

budget details plans for the agency’s endeavors in Earth and planetary 

science, astrophysics, heliophysics, aeronautics, technology, and 

exploration. NASA Administrator Charles Bolden remarked that the 

budget “moves the agency forward strongly on a path that will maintain 

America’s preeminence in space exploration. ... embarking upon an 

ambitious exploration program that will build on new technologies as 

well as proven capabilities as we expand our reach out into the solar system.” The proposed budget seeks 

$17.7 billion for NASA to continue implementing its major elements and advance developing technologies. 

Read about the budgetary plan in detail at www.nasa.gov/news/budget/index.html.

Future of Human Spaceflight

NASA is embarking on a new era of space exploration in which humans will travel 

deeper into the solar system than ever before. The International Space Station will 

be the centerpiece for exploration and will serve as a test bed for research and new 

technologies, and as a stepping-stone to future destinations. While partnering with 

commercial industry to transport cargo and eventually crew to the space station, 

NASA will continue to focus on developing advanced exploration systems. To learn 

more about where NASA is going, explore the agency’s latest interactive feature at 

www.nasa.gov/externalflash/human_space.

NASA TV in HD

Want to know what life looks like in space? Watch live video from the International 

Space Station in high definition on UStream at www.nasa.gov/multimedia/nasatv/iss_

ustream.html. When the crew is scheduled for onboard tasks, look for internal views 

of the station. The rest of the time, expect to see stunning views of Earth. Since the 

station orbits Earth once every 90 minutes, it experiences a sunrise or a sunset about 

every 45 minutes. When the station is in darkness, the external camera video may 

appear black but can sometimes provide spectacular views of lightning or city lights below. 

feedback

We welcome your comments on what you’ve read in this issue of ASK and your suggestions for articles you 

would like to see in future issues. Share your thoughts with us here: askmagazine.nasa.gov/about/write.html.

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

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

ASK online, 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.

Scan this code with 

your mobile device 

to read ASK online.
National Aeronautics and Space Administration

NaSa Headquarters 

300 E Street SW 

Washington, DC 20546

www.nasa.gov

NP-2012-03-853-HQ