Academy Sharing Knowledge

The NASA Source for Project Management and Engineering Excellence | APPEL FALL | 2010

National Aeronautics and Space Administration

Inside

NASA and SpaceX Work Together

Shaping the Shuttle

Peer Assist: Learning Before Doing
ON THE COVER

Contrails are seen as workers leave the Launch Control Center at Kennedy Space 

Center after the launch of Space Shuttle Discovery and the start of the STS-131 

mission. After its nearly thirty-year history of human spaceflight achievements, the 

Space Shuttle is nearing its final planned launch. Photo Credit: NASA/Bill Ingalls
Contents

29

DEPARTMENTS

3 

In This Issue

By Don Cohen

4 

From the Academy Director

Change Management and 

Adaptive Challenges

By Ed Hoffman

58 

The Knowledge Notebook

What’s Right About Being Wrong

By Laurence Prusak

60 

ASK Interactive

INSIGHTS

25 

Interview with Wayne Hale

By Matthew Kohut The former shuttle 

program manager talks about career-long 

learning and what the Columbia accident 

taught the agency.

33 

Case Study: Making Compliance 

Comprehensible

By Joseph A. Horvath A pharmaceutical 

company finds ways to turn required 

documentation into tools for improving 

how work gets done.

42 

Peer Assist: Learning Before Doing

By Kent A. Greenes Faced with challenging 

projects, teams call on colleagues with 

relevant experience.

52 

The Impact of Energy on Projects

By Christie Dowling, Alexandra Gerbasi, 

and Vic Gulas The energy of outstanding 

performers can be measured.

55 

NASA Knowledge Forum 2: 

Knowledge in Projects

By Haley Stephenson Panelists at the 

forum discuss informal and formal ways 

of giving project teams the knowledge 

they need.

STORIES

5

NASA and SpaceX Work Together

By Andrew Chambers and Dan Rasky 

The shared goal of future spaceflight builds 

a bridge between organizational cultures.

9

The Freedom to Learn

By Jack Boyd Looking back at a long NASA 

career, Boyd shows the value of learning by 

doing and being open to new ideas.

15 

X-15: Pushing the Envelope

By Kerry Ellis The experimental rocket 

plane blazed a trail for the space program.

20 

From Sketch Pad to Launchpad

By Haley Stephenson A committed 

team helped make the shuttle a reality.

29 

Shaping the Shuttle

By Jim Hodges Langley’s wind-tunnel 

tests provided data essential to designing 

the shuttle.

37 

A Carrier Team One Risk Management 

Success Story

By Dan Fontaine A navy risk management 

program improves aircraft carrier maintenance.

46 

MIDAS: Keys to Software Success

By Jeff Cline Clearly defined requirements 

and extensive testing are essential to 

successful development of a software tool.

5 42

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

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

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

providing performance enhancement services and tools, supporting career development 

programs, and creating opportunities for project management and engineering 

collaboration with universities, professional associations, industry partners, and other 

government agencies.

ASK Magazine grew out of the 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 APPEL Knowledge Sharing programs and products, please contact 

Yvonne Massaquoi, ASRC Management Services, 6303 Ivy Lane, Suite 130, Greenbelt, 

MD 20770; yvonne.massaquoi@asrcms.com; 301-837-9127. 

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

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

Issue No. 40

Staff

Academy Director and Publisher

Dr. Edward Hoffman

ehoffman@nasa.gov

Editor-in-Chief

Laurence Prusak

larryprusak@gmail.com

Managing Editor

Don Cohen

doncohen@rcn.com

Editor

Kerry Ellis

kerry.ellis@asrcms.com

Contributing Editors

Matt Kohut

mattkohut@infactcommunications.com

Haley Stephenson

haley.stephenson@valador.com

Senior Knowledge Sharing

Consultant

Jon Boyle

jon.boyle@asrcms.com

Knowledge Sharing Analysts

Ben Bruneau

ben.bruneau@asrcms.com

Mai Ebert

mai.ebert@asrcms.com

academy program Manager

Yvonne Massaquoi

yvonne.massaquoi@asrcms.com

Design

Hirshorn Zuckerman Design Group, Inc.

www.hzdg.com

Printing Specialist

Hanta Ralay

hanta.ralay-1@nasa.gov

Printing

Peake DeLancey
Spaceflight is hard, Wayne Hale reminds us in the interview 

in this issue of ASK. His discussion of a long career devoted 

to the Space Shuttle touches on the sources of the shuttle 

program’s many successes and its few painful failures. 

A couple of other articles here (“From Sketch Pad to 

Launchpad” and “Shaping the Shuttle”) look back at the 

beginning of the thirty-year program, detailing the knowledge, 

flexibility, and commitment that went into designing the 

world’s first (and still only) reusable spacecraft.

Some of that knowledge came from imaginative and 

often daring earlier work. The X-15 program, which began 

in the fifties, provided essential understanding of thermal 

protection during high-speed reentry and proved that an 

aircraft-like spacecraft could glide safely to an unpowered 

landing. (See Kerry Ellis’s “X-15: Pushing the Envelope.”) 

The data generated by wind-tunnel experiments that began 

at Ames Research Center before NASA was established, 

described in Jack Boyd’s “The Freedom to Learn,” has 

served the space program from Mercury to Apollo to shuttle 

and remains relevant to future flights to other planets.

Technical challenges make spaceflight hard, but what 

Ed Hoffman describes as “adaptive challenges” (in “From 

the Academy Director”) are at least as important and are 

tougher in some ways. Technical problems can be clearly 

defined; potential solutions can be designed and tested. 

Adaptive challenges are harder to pin down and responses 

to them involve difficult social, organizational, and political 

change. The Challenger and Columbia accidents may have 

been partly due to what we might call “mis-adaptation”—a 

cultural shift toward arrogance and complacency that failed 

to take technical problems seriously enough.

Today’s adaptive challenges at NASA call for new 

ways of working toward new goals. One early example of 

success in achieving one of those goals—collaborating 

with entrepreneurial private industry on future spacetransportation technology—is described in “NASA and 

SpaceX Work Together.” A shared passion for space 

exploration underlies the cooperation between two very 

different organizations.

In some cases, adaptation may mean a return to past 

practices. Both the X-15 article and “Freedom to Learn” 

describe a time when it was more possible to take risks, 

to explore radical ideas, to try and fail than has been the 

case at NASA in recent decades. As Laurence Prusak says 

in “The Knowledge Notebook,” being allowed and even 

encouraged to fail is one of the keys to innovation—the kind 

of innovation the agency is being asked to achieve in the 

coming years.

Of course, achieving these ambitious goals also 

depends on maintaining and improving fundamental 

practices for managing and carrying out projects. Jeff 

Cline’s MIDAS article attributes the success of that software 

development program to clarity about requirements and 

extensive communication. Haley Stephenson’s report 

on the Academy’s second Knowledge Forum and Kent 

Greenes’s description of peer assists deal with the issue 

of giving project teams the knowledge they need to 

carry out their tasks. And Joseph Horvath (“Case Study: 

Making Compliance Comprehensible”) shows how even 

documentation required by regulatory agencies can be 

used to improve how work is done.

Don Cohen

Managing Editor

In This Issue

ASK MAGAZINE | 3
What do we mean when we talk about change 

management?

Change is an inevitable part of the life of an 

organization. Regardless of why it happens, it is 

always difficult and painful for many people.

One metaphor that’s helpful for understanding 

change in an organizational context comes from 

evolutionary biology. In The Practice of Adaptive 

Leadership, Ronald Heifetz, Marty Linsky, and 

Alexander Grashow recall that humans have been 

practicing adaptation for millennia: 

Our early ancestors’ process of adaptation to new 

possibilities and challenges has continued over 

the course of written history with the growth and 

variation in scope, structure, governance, strategy, 

and coordination of political and commercial 

enterprise. So has the evolution in understanding 

the practice of managing those processes, including 

in our lifetimes what we call adaptive leadership.

They go on to define adaptive leadership as 

“the practice of mobilizing people to tackle tough 

challenges and thrive,” noting that they use the 

term “thrive” as an evolutionary biologist would 

when describing the three characteristics of a 

successful adaptation:

1. It preserves the DNA essential for the 

species’ continued survival; 

2. It discards (re-regulates or rearranges) the 

DNA that no longer serves the species’ 

current needs; and 

3. It creates new DNA arrangements that give 

species the ability to flourish in new ways 

and in more challenging environments.

This concept of thriving is the essence of 

change management in organizations. Core values 

and practices remain intact, while the organization 

modifies or closes out activities that no longer 

match current needs and develops new ones to 

meet current and anticipated future needs.

Heifetz, Linsky, and Grashow suggest that 

organizations typically encounter one of two types 

of issues: technical problems and adaptive challenges. 

When a technical problem arises, the problem 

definition is clear, the solution arrived at is clear, and 

the process of solving the problem takes place through 

established lines of authority. Adaptive challenges are 

altogether different. Both the problem definition 

and the solution require learning, and the primary 

decision-making needed to meet the challenge takes 

place at the stakeholder level.

NASA currently faces an adaptive challenge. It 

has faced them before, and it has thrived. Doing so 

again will require learning across the enterprise.

Like the transition from Apollo to shuttle, the 

current adaptive challenge is the result of changes 

in the political, social, economic, and technological 

context in which the agency operates. As a government 

organization, the agency’s mission has always been 

shaped by stakeholders in the White House and 

Congress in response to the world around us. This 

is as true now as it was in the age of the “space race” 

between the Soviet Union and the United States. As 

the new national space policy notes, the space age 

began as a race between two superpowers for security 

and prestige. Today, the benefits of space activities 

are ubiquitous in everyday life, and the space 

community includes increasing numbers of nations 

and organizations around the globe.

A new challenge is here. It’s time to thrive. ●

From the Academy Director

 Change Management and Adaptive Challenges

By ED HOFFMAN 

4 | ASK MAGAZINE
Title

By 

Intro

A sample of PICA-X heat-shield material subjected to temperatures of 

up to 1,850°C (3,360°F) at the Arc Jet Complex at NASA Ames Research 

Center, Moffett Field, California. The NASA-originated PICA material 

holds the record for high-speed reentry into the earth’s atmosphere. The 

SpaceX-developed and -manufactured PICA-X variants meet or exceed 

the performance of the original material, and will protect the Dragon 

spacecraft on its return to Earth.

Photo Credit: SpaceX

N+S

 SpaceX

NASA

Work Together

By Andrew Chambers and Dan Rasky

STORY | ASK MAGAZINE | 5
The PICA Heat Shield

The NASA 2007 Government Invention of the Year, a lightweight 

heat-shield material developed at Ames Research Center, was 

the basis of the Phenolic Impregnated Carbon Ablator (PICA) 

heat shield that protected Stardust from temperatures as high as 

2,500 ̊C as the spacecraft reentered Earth’s atmosphere at more 

than 28,000 mph—faster than any previous manmade object. 

PICA was the ideal choice for the Stardust mission to collect 

samples from comets; other thermal-protection materials able to 

withstand those temperatures would have been too heavy.

The Stardust success led to serious consideration of PICA 

for other NASA programs. The designers of the Orion crew 

capsule tested the material extensively, designing and building 

a full-scale engineering prototype heat shield for Orion. 

Uncertainties about the potential risks of a multi-tile PICA heat 

shield (the much smaller Stardust shield was a single piece) led 

the Orion team to select the Apollo heritage Avcoat thermalprotection system for Orion. But their thorough research on 

PICA proved a valuable resource for other programs.

One is Mars Science Laboratory (MSL). The size of the 

science lab lander and the speed of Mars entry and descent mean 

that thermal-protection material used on earlier, smaller landers 

would not work for MSL. Christine Szalai and her colleagues at 

Jet Propulsion Laboratory, Ames, and Lockheed Martin have 

successfully designed, fabricated, and flight certified a multi-tile 

PICA heat shield for the science lab that is currently waiting for 

its 2011 flight to Mars.

Given PICA’s light weight and high performance, and the 

potential to benefit from knowledge gained on Orion and MSL, 

SpaceX chose PICA for its Dragon spacecraft, a pressurized 

capsule designed to carry cargo and eventually astronauts to 

and from low-Earth orbit. The company asked experts at Ames 

to provide support for the development of a 3.6-meter PICA 

shield for Dragon, and NASA made its expertise and specialized 

facilities available to SpaceX. SpaceX undertook the design and 

manufacture of the reentry heat shield; it brought speed and 

efficiency that allowed the heat shield to be designed, developed, 

and qualified in less than four years.

NASA is committed to working with private industry to develop the next generation of spacetransportation technologies. The agency’s Commercial Crew and Cargo program manages 

Commercial Orbital Transportation Services (COTS) partnership agreements that provide 

financial and technical resources to organizations committed to developing reliable and economical 

new launch vehicles and spacecraft. SpaceX is one of these partners. Successful NASA–SpaceX 

collaboration has created the heat shield for the firm’s Dragon spacecraft.

Inspecting the carbon-composite carrier structure for 

the first Dragon spacecraft heat shield, fresh from its 

mold. At nearly 4 m (13 ft.) in diameter, the structure 

supports the PICA-X tiles that protect the spacecraft 

during reentry. 

N+S

Photo Credit: SpaceX/Roger Gilbertson

6 | ASK MAGAZINE
Two Cultures, One Goal

This is where we met. Andrew Chambers was SpaceX project 

lead for the heat shield. NASA sent Dan Rasky, one of the 

original developers of the material, to spend most of 2008 

working half time at SpaceX’s Los Angeles facility. With his own 

desk, phone, and SpaceX badge, he was very much a member 

of the firm’s thermal-protection system team. Having started 

his career at a small, entrepreneurial aerospace company, Rasky 

found working at SpaceX to be like coming home, but he still 

experienced some culture shock after twenty years at NASA.

The speed of decision making was the most dramatic 

difference. At one meeting of the dozen team members and 

SpaceX Chief Executive Officer and Chief Technical Officer 

Elon Musk, Musk turned to Rasky during the discussion of 

options for producing PICA and asked, “Dan, what do you 

think?” When Rasky described his preference and the reasons 

for it, Musk said, “OK. That’s what we’re going to do.”

At NASA, his proposed solution would have led to a series 

of studies and additional meetings before a decision was made. 

But on-the-spot executive decisions that would be difficult at 

a government agency or large corporation readily happen at a 

small private company. Rasky found that kind of decisiveness 

exhilarating and a little alarming—what if he was wrong? 

Chambers had seen that sort of initial reaction before, from 

colleagues who joined SpaceX from other, traditional aerospace 

companies. But his team’s ability to make these decisions and 

execute them efficiently is the key to rapid development. At 

SpaceX, most processes are developed and performed in house, 

making design iteration highly efficient. In the time others take 

to determine the scope of their trade studies, the SpaceX team 

will build and test the required prototypes. Additionally, an 

integrated thermal-protection system team that brought together 

the required specialist areas, including aerodynamic predictions, 

structural analysis, and materials performance, allowed smart 

choices to be made and a “sparse matrix engineering” approach 

(not filling in all the blanks before proceeding) to be taken when 

developing prototypes. It’s the prototype that tells you whether 

your decisions were sound. If it fails to meet expectations, it 

provides data needed to make a better choice next time. 

The speed of the process was enhanced by having many of 

NASA’s technical experts only a phone call away. Additionally, an 

efficient procurement system allowed even exotic materials to be 

Photo Credit: SpaceX/Roger Gilbertson

N+S

Test placement of the PICA-X tiles on the first Dragon 

flight’s heat-shield carrier structure. During reentry 

the lightweight tiles withstand temperatures as high as 

2,000°C (3,620°F). 

ASK MAGAZINE | 7
delivered in just a couple of days and used for the next prototype.

The small size of the SpaceX PICA team—five engineers 

and six or seven technicians—also contributed to speed. Group 

members all worked at the same site and could easily meet to 

hash out problems, exchange information, and make decisions.

SpaceX has the advantage of speed and the freedom to 

innovate; NASA brings a breadth of experience and technical 

expertise to the table. It was NASA, after all, that carried out the 

research to develop the phenolic impregnated carbon material 

in the first place. NASA has unmatched experience in how 

materials and spacecraft actually behave in flight. And NASA 

has special facilities that small entrepreneurial companies could 

not readily afford. So, for instance, SpaceX makes use of the arcjet facilities at Ames that offer the only way to test the Dragon 

shield material at the requisite high temperatures.

When different organizations try to work together—and 

especially organizations with different cultures—they sometimes 

run into trouble. Failure to understand one another’s values and 

ways of working can get in the way. A sense of ownership of a 

project or a technology can interfere with knowledge sharing 

and cooperation. NASA and SpaceX have not experienced any of 

those problems in the PICA heat-shield work. Part of the success 

of the collaboration is due to the two organizations’ shared 

engineering language and shared enthusiasm for the virtues and 

potential of PICA. Part of it is undoubtedly due to the shared 

greater goal of new capabilities for successful spaceflight—the 

ultimate aim of the COTS partnerships. 

Mutual Benefits

The benefits SpaceX has derived from this collaboration are 

clear. They were able to take advantage of the extraordinary 

capabilities of PICA and the knowledge developed about it in 

the course of several NASA programs. And they got access to 

NASA’s testing facilities. 

But NASA benefited, too. For one thing, the knowledge 

flow goes both ways. What SpaceX has learned about designing, 

testing, and manufacturing large PICA heat shields is also available 

for NASA to apply to current and future programs. In addition, 

NASA can learn from SpaceX’s work practices. Although the 

agency will never operate like a small, entrepreneurial firm, its 

own innovative work could benefit from a version of SpaceX’s 

sparse matrix engineering and rapid prototyping.

The ultimate mutual benefit will emerge when the Dragon 

spacecraft delivers cargo and crews to the International Space Station 

and returns safely to Earth, protected by its PICA heat shield. ●

Dan Rasky is the director for the Emerging Commercial 

Space Office at Ames Research Center and a senior scientist 

with NASA. He is a co-founder and director of the Space Portal, 

whose mission is to “be a friendly front door for emerging and 

nontraditional space companies.”

Andrew Chambers started his career in the propulsion department of SpaceX in 2004. 

He initially worked on the development of various liquid rocket engines, including those that 

will lift the Dragon spacecraft. Over the past four years, he has developed the reentry heat 

shield for this capsule.

N+S

Protected by a PICA-X heat shield in this artist’s 

rendition, the Dragon spacecraft reenters the earth’s 

atmosphere at around 7 kilometers per second 

(15,660 mph), heating the exterior of the spacecraft 

as high as 2,000°C (3,620°F). 

Image Credit: SpaceX

8 | ASK MAGAZINE
In 1944, I went to Virginia Tech to get my bachelor’s degree in aeronautical engineering. 

In those days, we finished college in three years because the war was on, which was nice 

because you got in and out pretty fast. Langley Field sent interviewers out to our campus 

to talk to people, but I had been in Virginia all my life, and I wanted to see California. 

I told the recruiter I didn’t want to go to Langley; I wanted to go to Ames. A few weeks 

later I got a telegram from Langley that said, we’ve talked to Ames, and here’s your offer: 

$2,644 per year, take it or leave it. I took it.

Jack Boyd explains the efficiencies of conical camber in 1957.

The Freedom

to Learn BY Jack Boyd

Photo Credit: NASA

STORY | ASK MAGAZINE | 9
Ames sent me an offer but they didn’t say where I was going 

to work. The lady who talked to me said, “I see you have one 

course in college in compressible flow aerodynamics [which 

is like high-speed aeronautics] and we have a little supersonic 

wind tunnel, so we’re going to assign you to this 1-foot-by-3-

foot supersonic wind tunnel.”

There were fantastic people in that facility, people like R.T. 

Jones, who developed the sweptback wing; Harvey Allen, who 

developed the blunt-body concept; Walter Vincente, a really 

outstanding high-speed aero man; Milt Van Dyke; and Dean 

Chapman. I didn’t realize it at the time, but I worked with eight 

or ten of the best-known aerodynamicists in the world. As the 

years wore on, they became the leaders of the aerospace world.

They told me they were going to let me do a bit of research on 

sweptback wings, which were kind of new in 1947. At the time, 

we had to design our models, decide what we wanted them to 

look like, take the result to the machine shop to get them built, 

take them to the wind tunnel to test them, and then write a report 

on the results. You did the whole thing from start to finish. 

Learning the Job

I felt intimidated when I started, but everyone encouraged me. 

It was a very open-minded society in those days, an innovative 

society. If you had an idea and it had relevance to anything at 

all, they’d let you pursue it as far as you wanted to take it. 

R.T. Jones told me to start reading everything I could find 

about aerodynamics. For the first three or four months, I just read 

and talked to people. They didn’t really give me a job. Then one 

day they told me I’d been around long enough and knew enough 

about aerodynamics, so I should design a sweptback wing, put 

pressure taps in it, and test it to obtain detailed pressure forces 

on the wing. They threw me in to the middle of it, but all the 

experts around me could answer almost any question. The group 

I was in had only ten or twelve engineers, so it wasn’t hard to 

know who to go to, especially with R.T. Jones and Harvey Allen 

there to help. And I was one of only two or three new employees 

that year, so they focused on us new employees. 

The team in the little wind tunnel was only about twenty 

people in total: the branch chief and a number of researchers and 

mechanics. And we had maybe four to six “computers”—the 

computers were young ladies who sat in a room with a calculator 

and reduced the data for you. A lot of the engineers in those 

days literally married their computers. I did not. During all this 

exciting activity, I had time to meet and marry a beautiful lady, 

Winnie, and we have five children and nine grandchildren.

The center directors were very close friends of each other 

and frequently gave each other advice. I remember a visit from 

the Langley center director who advised us, “If you’ve got a 

good idea, go try it. If it fails, so it fails; just try another one.” 

Innovation was really the name of the game. 

Photo Credit: NACA

10 | ASK MAGAZINE
The bright people at Ames kept us from failing very often. 

Being among those folks was probably the thing that got me a 

really good start. Every day six or eight of us would go to lunch 

together and talk about our work. Harvey Allen had dinner 

functions and cocktail parties at his home in Palo Alto, and 

he’d invite the younger engineers to mix with the older ones. 

The girlfriends some of us had didn’t want to go. They found 

out the first time that all we talked about was work.

Sharing What We Learned

We were part of a very open society at Ames, with many open 

discussions, and all the data we obtained was free to the aerospace 

industry. They would use the data we got out of the supersonic 

and subsonic wind tunnels to help design their own aircraft. 

We also held National Advisory Committee for Aeronautics 

(NACA) conferences. Each year there was a conference at one of 

the centers: Langley, Ames, or Lewis. People from academia and 

the aerospace industry, both military and civil, would attend, 

and we would present our results from the past year. People 

including Theodore von Karman, Jimmy Doolittle, Hugh 

Dryden, Allen, and Jones would come to these meetings—all 

the bigwigs of the aerospace world. Those conferences, held 

every year, were key to transmitting NACA information to the 

industry, as were the NACA reports.

When NACA became NASA, the way we shared things 

changed some, and I don’t think deliberately. In the days up 

until 1958, NACA developed technical and aerospace data 

Interior view of Schlieren setup in the 

1-foot-by-3-foot supersonic wind tunnel at 

the NACA Ames Aeronautical Laboratory, 

Moffett Field, California.

Photo Credit: NACA

H. Julian Allen stands beside the observation 

window of the 8-foot-by-7-foot test section of 

the NACA Ames Unitary Plan Wind Tunnel. Allen 

is best known for his “blunt-body theory” of 

aerodynamics, a design technique for alleviating 

severe reentry heating problems.

ASK MAGAZINE | 11
for industry, and industry was the user of the data. When we 

became NASA, we became the users of some of the technology 

ourselves and managers of big projects like Mercury, Gemini, 

Apollo, and so on. It changed a little bit in how we transmitted 

the information out.

Innovation from Aeronautics to Astronautics

The air speeds at which we were working in those days were 

Mach numbers of 0.2 to 2.0, twice the speed of sound. We were 

making wings more slender and in sharper shapes to go faster 

more efficiently. In the fifties we at Ames began to think about 

space thanks to Harvey Allen, who started us thinking this way. 

He told us that if we were really going to go into space, we’d be 

orbiting the earth, for example, at 17,000 miles an hour, so we 

would need to make a blunt body shape to slow down a vehicle 

when it comes in so it wouldn’t burn up. 

That got us thinking about other kinds of things that would 

be interesting to work on. For example, if we went to Mars and 

Venus, where the atmospheric gases are different, certainly the 

aerodynamics would be different, too. 

I came across a guy called Zdenek Kopal, who was a famous 

astronomer who worked at an observatory in the Pyrenees 

mountains in Spain. We invited him to Ames for a lecture, 

and he began talking to us about planetary astronomy and gas 

mixtures on other planets. We were aerodynamicists; we knew 

nothing about planets. But Kopal and Carl Sagan said carbon 

dioxide and nitrogen were probably prevalent gases on Mars and 

Venus. We had a facility here called a free-flight range, which 

allows you to fire a model into a mixture and take data from 

it; unlike a wind tunnel, it could be filled with a variety of gas 

mixtures. We thought we’d fill one of these ranges with a variety 

of carbon dioxide and nitrogen mixtures and fly different shapes 

into them to see what the aerodynamics looked like. We got 

some interesting results. There were differences, not only in the 

aerodynamics but also in the heating. That got us started down 

that path of being interested in planetary entry vehicles. 

Had we not started doing this work at NACA before 1958 

because we were curious, I think we would never have gotten to 

the moon when we did. We had a jump-start on the technology 

we were going to need. Langley, Lewis, and Ames people 

were working on the technology that led to the application 

of the lifting-body studies—which looked at the feasibility of 

maneuvering and landing an aerodynamic craft designed for 

reentry from space—to Gemini, Mercury, Apollo, and, later, the 

Space Shuttle. We were not only curious, we had the freedom 

to pursue that curiosity. In order to fill one of the ranges with 

gas mixtures, we just asked the guy at the range and he said, 

“Hey, that sounds like a great idea, go do it.” Our center director 

was very safety conscious and he made sure it was safe. Many 

other people did much more detailed research after that; we just 

started it here. 

Simply starting somewhere and sharing what you learn 

from the experience allows others to take what you learned and 

keep expanding on it. You never know where things can end up, 

Photo Credit: NACA

12 | ASK MAGAZINE
The NACA credo.

Schlieren photograph of the flow 

around airplane models showing the 

effect of sweptback wings on shock 

waves at Mach 1.2.

Photo Credit: NACA

like landing on the moon. Curiosity can lead to innovation, and 

continuous learning, even unconventionally, can help keep that 

curiosity strong. 

Continuing Education and Future Innovation

I left NASA in ’85 and went to the University of Texas as assistant 

to the chancellor for research and was able to teach as an adjunct 

professor at the Austin, El Paso, and Pan American campuses. 

I came back to Ames in ’93, and that’s when we started the 

Aerospace Encounter, an educational program designed to 

inspire students in fourth through sixth grades about science, 

technology, engineering, and math. It is still operating today.

The kids cannot run the wind tunnel we use to house the 

program, but they can use computer workstations to operate a 

model wind tunnel and see what a big wind tunnel really looks 

like. We also have a computer program that lets them design 

their own airplanes. They pick an engine, a body shape, wing 

type, and a destination—like flying from San Francisco to 

London—and try to optimize how to do it. If they don’t have 

the right thrust or number of engines, their design can’t make 

it, of course, from San Francisco to London. So they have to 

redesign it. When they create a design that works, the computer 

alerts them to their success, and they can print out their design 

and take it away with them. 

The kids taught us something we knew early on: they 

were unconstrained in their thinking. For example, they would 

design an aircraft that looked like a blimp with little wings on it. 

ASK MAGAZINE | 13
It wouldn’t go anywhere at high speeds because the drag was too 

high, but their minds were open to almost anything. 

I talk to students a lot. I’ve got an arrow chart explaining 

that it’s going to be up to them what we do in the next fifty years. 

That chart says we’re going to explore the moon, we’re going to 

explore Mars, we’re going to explore the solar system. And then 

there’s the end of the arrow. My grandson asked, “What are you 

going to put in that arrow, sir?” 

I said, “I don’t know. What do you think?” 

He said, “Why don’t you put the words ‘quantum gravity 

machine?’ I think Einstein was wrong. We can go faster than 

the speed of light, and I’m going to prove it, and that’s what I’m 

going to call it: quantum gravity machine.” 

It’s been two years now, and so far I’ve seen no sign of the 

machine, but he’s still working at it. If we’re going to pursue 

human exploration of Mars using current chemical propulsion, it 

would take nine months to get there and nine months to get back. 

That’s just unacceptable. With my grandson’s quantum gravity 

machine, it would take about 4.5 minutes to get to Mars.

I like to talk to children because they’re open to almost 

anything. They don’t care what kind of questions they ask you. 

They aren’t inhibited. They’ve taught me to keep my mind 

more open. The mind closes as you get older; you get your own 

set of ideas and believe you must be right. You’re not quite as 

open to learning new things. With Aerospace Encounter, you’re 

constantly surprised by the questions kids ask, which is part of 

why it’s so great.

The average age at Ames was about 27 years old when 

I started. Now it’s around 50 years old. So we really need to 

get the young blood flowing here. But we need to do it while 

preserving the history that has come before. 

Preserving and communicating NASA history keeps us 

from making the same mistakes twice, hopefully. It also sets 

a shining example of what this country can do when it puts its 

mind to it. I don’t mean just landing on the moon; I mean the 

whole spectrum of things we’ve done. Look at what NASA has 

accomplished and think about how the first airplane flew in 

1903. Just over one hundred years later, look what we’ve done. 

We’ve gone to the moon, we’ve gone to Mars robotically, we’ve 

flown out of the solar system, beyond planets, over to Pluto. 

These are remarkable things. We need to pass on what we’ve 

learned from it all so we can keep doing remarkable things 

in the future. The kids are our future. They will develop the 

innovative technology that will permit us to further explore our 

solar system and beyond. ●

JACK Boyd serves as senior advisor to the Ames Research 

Center director and as the senior advisor for history and the 

center ombuds. He first reported to work at Moffett Field, the 

home of Ames, sixty-three years ago.

These four shadowgraph 

images represent early 

reentry vehicle concepts.

Photo Credit: NACA

14 | ASK MAGAZINE
Breaking the sound barrier took guts, curiosity, optimism, and some serious risk taking. Equipped 

with slide rules and other fifties technology, the army, navy, and North American Aviation teamed 

up with the National Advisory Committee for Aeronautics (NACA) to create an aircraft that 

could outfly all others. Through a series of experimental aircraft, NACA—later NASA—pursued 

supersonic and hypersonic flight with record-breaking results. The lessons learned during this 

ambitious research program contributed to many other NASA programs.

By Kerry Ellis

X-15:

PUSHING THE ENVELOPE

Photo Credit: NASA

The view from the cockpit 

of the B-52 carrier aircraft. 

STORY | ASK MAGAZINE | 15
During 199 flights between 1959 and 1968, the X-15 achieved 

many firsts and set a slew of world records, some of which still 

stand. Those achievements required a high level of risk and 

included failures along the way. But the program’s ability to 

build, test, fly, and repeat in quick succession made every new 

plane better than the one before. With the freedom to rapidly 

churn through data and rebuild when necessary, the team 

achieved more than anyone imagined possible.

Building a Rocket Plane

The X-15 was created to explore hypersonic (generally defined 

as five times the speed of sound) aerodynamic performance, 

research structural behavior during high temperatures and 

pressure, study stability and control during exit from and 

reentry of the atmosphere, and examine pilot performance and 

physiology. What the program discovered directly contributed 

to Mercury, Gemini, Apollo, and the Space Shuttle. 

Its immediate predecessor, the X-2, had been designed to 

achieve Mach 3. Pilot Milburn “Mel” Apt managed to push the 

plane to Mach 3.196 before turning back to Edwards Air Force 

Base to land; the roll he initiated to make the turn caused an 

adverse yaw problem previously experienced by Chuck Yeager in 

the X-1. The plane tumbled out of control, and Mel died in the 

accident. Making the leap from the tragic final flight of the X-2 

to a plane intended to double the X-2’s design speed was risky. But 

the tragedy made the X-15 team work hard to ensure pilot safety. 

To solve the yaw problem, the team developed a wedgeshaped tail: narrow at the front and wide at the back. This 

helped keep the air streams apart longer at hypersonic speeds, 

which gave the plane exceptional directional stability. The 

wedge tail is now a commonly accepted shape for hypersonic 

control surfaces, but the X-15 was the first to employ it on a 

manned aircraft.

To barrel through the air at six times the speed of sound and 

reenter the atmosphere from the edge of space, the X-15 body needed 

to survive extreme stress and heat. Engineers used Inconel-X, a 

heat-resistant nickel-chrome alloy, and titanium for the structure—

achieving the first use of a reusable superalloy structure capable of 

withstanding hypersonic reentry. In the process, the team developed 

new fabrication techniques for machining, forming, welding, and 

heat-treating Inconel-X and titanium. 

Heating at hypersonic speeds presented other design 

challenges as well. Since metal expands at high temperatures, 

slots were built into the sides of the plane to accommodate a few 

inches of expansion. “It expanded just like an oilcan,” pilot Maj. 

Gen. Joe Engle said. “It sounded like someone banging on the 

side of a plane with a sledgehammer, and the old guys wouldn’t 

warn you about it.” 

Early inertial systems affected how the X-15 was eventually 

flown. The systems relied on gyros, whose axes would be thrown 

Photo Credit: U.S. Air Force

The X-15 mockup as it was 

inspected in December 1956.

16 | ASK MAGAZINE
off kilter during hypersonic acceleration. This effect prevented 

pilots from knowing how high or how fast they were flying. To 

accurately measure thrust energy, the team decided to time how 

long the engine burned. A stopwatch in the cockpit told pilots 

when to shut off the engines in order to complete a planned 

flight path with precision. Burning the engine for one second too 

long could mean an extra 280 mph and 35,000 ft. of altitude, 

something pilot Maj. Gen. Bob White experienced firsthand.

Piloting Through Near Space

Engle described the X-15 team as one that worked together in 

perfect harmony: “If I didn’t look at badges, I would not know 

who anybody worked for on that program; it was that kind of 

operation.” The pilots who undertook the flight risks were key 

members of that team.

To keep pilots safe from the immense heat and pressure 

experienced during flight, engineers developed nitrogen cabin 

air-conditioning for the cockpit. This also helped counteract 

potential flammability should the engine malfunction. While 

filling the cockpit with oxygen was an option, the potential for an 

explosion if it interacted with the engine’s flammable propellant 

was too high a risk. To prevent blackouts from high g-forces 

and ensure the pilots could breathe within the nitrogen-filled 

environment, the X-15 team developed an early pressure suit, 

also pressurized and cooled with nitrogen. The only breathable 

oxygen available was in the suit’s faceplate. 

Each flight lasted about eight to ten minutes. Around eighty 

seconds after the X-15 was launched from under the wing of a 

B-52, pilots would shut down the engines. The rest of the flight 

was unpowered, and the pilot was essentially guiding a highspeed glider. Precision piloting was critical. If the engine was 

cut one second too late, or if the pitch was off by one degree, 

pilots could end up thousands of miles off track. With the only 

navigation available being line of sight from the X-15’s two small 

windows, a few ground stations, and non-hypersonic chase planes, 

overshooting the course meant emergency landing decisions had 

to be made and communicated quickly. And if one of the windows 

glazed or cracked from the heat of flight—a problem that often 

occurred—pilots were reduced to tracking on only one side of the 

plane. This made the stopwatch in the cockpit very important for 

accurate energy management and flight-path positioning. 

Eight pilots were given the title of astronaut for flying more 

than 50 miles above the earth’s surface. One, Captain Joe Walker, 

set an aircraft altitude record of 67 miles above Earth. When they 

were flying in near space, “Airplane attitude didn’t make much 

difference,” Engle said. “You could fly sideways or backwards over 

the top. But it was very important once you started back down 

and got into sensible atmosphere to be lined up both in pitch and 

yaw for reentry.” At the wrong angle, the plane could skip up 

during reentry, which happened to pilot Neil Armstrong during 

ASK MAGAZINE | 17
Photo Credit: Boeing

Scott Crossfield sits in a 

thermal-vacuum chamber 

during tests of a prototype 

XMC-2 pressure suit. 

Production versions of this 

suit were used for thirty-six 

early X-15 flights.

a heart-pounding

experience

A major concern when NASA began to explore 

human spaceflight further was the physiological 

responses of those chosen to fly the missions. 

Heart rates for pilots were very high, and data from 

X-15 pilots directly influenced the decision to fly men 

into space. Below is Walter C. Williams’ account of 

how the heart-rate issue was finally resolved.

We were working hard on Project Mercury. We 

were getting ready to fire Alan Shepard on the 

first ballistic flight. Prior to that, we had a little 

hearing before the President’s Scientific Advisory 

Committee. It had two types of members: 

engineering types and aeromedical types. 

We had a terrible time with the doctors; that’s the 

only way to describe it. They thought we ought 

to fly seventy-five more chimps before we flew a 

man. I’m serious! We had the data from this one 

chimpanzee, which showed very high pulse rates, 

and they were concerned that this might kill a 

man or you’d pass out or what have you. And so 

we had quite a go-around on that. 

Meanwhile, the X-15 was flying out here and the 

pilots were being monitored and, yes indeed, they 

had high pulse rates due to stress; their highest 

rates were usually before launch or landing. So I 

sent out for that data and brought it in and for a 

while I thought they were going to cancel the X-15 

instead of clearing us to fly Project Mercury! 

So Don Flickinger, the senior research aeromedical 

doctor, and one who had been closely following 

the X-15 program, got one of the doctors on 

the committee and Joe Walker in a three-way 

conversation (the data we had involved Joe 

Walker). The doctor began questioning Joe about 

this and that, then saying, “These pulse rates are 

pretty high—over 150. How did you feel?” 

Joe responded, “Oh, I felt all right. Now wait a 

gosh-damn minute. Are you trying to ask me 

whether or not I fainted?” 

The doctor said, “Well, yes. Did you faint?” 

Joe replied, “Hell, no! I didn’t faint!” 

The doctor continued, “Well, I don’t know ... 

people can pass out and not realize it.” 

Joe retorted, “Look, what I did one second 

depended on what I had done the second before, 

and I’m here talking to you!” 

18 | ASK MAGAZINE
Joe Engle during the X-15 program.

Photo Credit: NASA

one flight. “He ended up getting down to Burbank, turning 

around, and barely made it in to the dry lake bed, landing south 

to north instead of north to south like usual,” described Engle. “It 

was the longest flight in duration we had in the X-15.”

Training was key. Laying a foundation for later space 

programs, the X-15 program relied on a ground simulator to 

help pilots grow familiar with the minute controls and precise 

timing required for hypersonic flight. 

Paving the Way for Human Spaceflight

The pilots and engineers on X-15 worked together to discover 

the magic altitude where flying with reaction controls—rocket 

thrusters on the nose and wings—would work best. “Engineers 

asked us to find out where that magic altitude was,” said Engle. 

“We made some errors coming back in—sometimes getting a 

bit of roll. We learned that a blended, adapted flight-control 

system, using both reaction controls and aerodynamic surfaces, 

is necessary for an entry from space back into the atmosphere. 

The same flight-control system developed on X-15 was used 

on Space Shuttle.”

The way the Space Shuttle lands was directly influenced 

by the X-15’s unpowered landings. “Early in the design phase of 

shuttle, there was a very strong feeling that we really shouldn’t be 

landing something with as low a lift-to-drag ratio as the Space 

Shuttle unpowered,” explained Engle. “In fact, one of the early 

design proposals had air-breathing engines that would fit into the 

aft end of the payload bay. They would have taken up a quarter 

to a third of the payload bay in volume, not to say how much 

it was going to weigh, for the engines to be on a mechanism to 

fold out after you went supersonic, start up the engines, then 

fly it in like a conventional airliner. That plus the fuel.” Being 

able to demonstrate safe, accurate, unpowered landings with the 

X-15 proved to shuttle developers that a conventional powered 

landing was unnecessary.

Pressure suits developed for the X-15 provided insight 

into how full-pressure suits restricted the reach and energy 

envelope—how much and with what effort suited pilots could 

move—which paid off later in the design of spacesuits. “There 

was considerable discussion with Wright Field concerning use 

of a partial-pressure suit, which was developed, versus a fullpressure suit, which had to be developed,” said Walter C. 

Williams, chairman of the X-15 Flight Test Steering Committee. 

“It was felt important to develop a full-pressure suit. ... This suit 

became the foundation on which suit technology was built for 

use in the space programs.”

The X-15 program also demonstrated the first application 

of hypersonic theory and wind-tunnel testing to an actual flight 

vehicle, which helped provide confidence in the wind-tunnel 

studies later done for the shuttle.

Pushing the Envelope

The X-15 program, and its team, achieved so much in so little 

time due in large part to their skill and willingness in taking 

measured risks, pushing the envelope of what could be done 

with high-speed flight. The results of their collaboration paved 

the way for human deep-space exploration, influencing Mercury, 

Gemini, Apollo, and the Space Shuttle. Risk-taking was vital for 

the team’s leaps in innovation.

“There is a very fine line between stopping progress and 

being reckless,” said Harrison Storms, chief engineer at North 

American Aviation during the X-15 program. “The necessary 

ingredient in ... solving a sticky problem is attitude and 

approach. [It’s] what I refer to as ‘thoughtful courage.’ If you 

don’t have that, you will very easily fall into the habit of fearful 

safety and end up with a very long and tedious-type solution at 

the hands of some committee. This can very well end up giving 

a test program a disease commonly referred to as ‘cancelitis,’ 

which results in little or no progress and only creates another 

‘Hangar Queen.’” ●

Photo Credit: NASA

The X-15 research aircraft during its first powered flight on Sept. 17, 1959.

ASK MAGAZINE | 19
By Haley Stephenson

From

Sketch Pad

to

LaunchPad

Shuttle design evolution, 1972–1974.

Image Credit: NASA

20 | ASK MAGAZINE | STORY
STS-1 launches April 12, 1981.

Photo Credit: NASA

ASK MAGAZINE | 21
In the summer of 1980, the Space Shuttle program was in 

trouble. Technical challenges, especially those with the thermal 

protection system, were causing the program schedule to slip. 

Deputy Administrator Alan Lovelace held a meeting to address 

the problem. Moser, the engineering manager responsible for the 

tiles at Johnson Space Center at the time, was one of thirty-three 

engineers at the meeting. “Tell me what the schedule is, and I’ll 

want a firm commitment that you will make that schedule,” 

Lovelace said. He was very serious, Moser remembers, but 

Lovelace lightened the mood by telling a story: 

A pig and a chicken were having a talk in the barnyard one 

day. The pig asked the chicken, “Are you involved in the big 

dinner our master is planning for next week?” 

“Of course I’m involved,” replied the chicken. “I’m 

furnishing the eggs.” 

“Aw, that’s nothing,” the pig snorted. “You’re just involved. 

I’m supplying the ham. I’m committed.” 

“I want all of you to be like that pig,” Lovelace said, “I want 

you to be committed.”

The story added levity to a serious situation and served as 

inspiration for a group that later became known as the “Space 

Shuttle Ham and Eggs Society.” “We made that commitment 

and did what we said we were going to do,” Moser said. The 

group agreed to launch in April 1981. 

A Beginning 

Even before Apollo 11 made history with the first manned moon 

landing, the space community was looking for the next big thing. 

Shuttle studies and design efforts started to emerge during the 

mid-sixties and picked up momentum in January 1969. Input from 

the commercial and government sectors resulted in requirements 

ranging from delivering payloads to orbit to conducting Earth 

observations. “It was going to be a truck to carry goods to lowEarth orbit,” said Moser. “Everybody had a need.” 

NASA initiated several studies to come up with a design 

that would facilitate a cost-effective, quick-turnaround, fully 

reusable space transportation system. The studies produced 

several concepts, including lifting-body designs. Max Faget, then 

director of engineering at Johnson Space Center, acknowledged 

the merits of lifting bodies. According to Faget, “You avoid wing–

body interference,” which brings problems of aerodynamics. “You 

have a simple structure. And you avoid the weight of wings.” He 

saw difficulties, however, that effectively ruled them out for a 

practical shuttle design. They had low lift and high drag, which 

meant a dangerously high landing speed. As he put it, “I don’t 

think it’s charming to come in at 250 knots.”1

 

Faget had something else in mind. Influenced by the X-15 

rocket plane, he envisioned a winged vehicle that would glide 

back to Earth, its nose tipped upwards. He formed a “skunk 

This “cutaway” artist’s 

concept reveals systems 

of the major components 

of a Space Shuttle vehicle.

Photo Credit: NASA

Every decision—for instance, 

between a titanium or aluminum

structure, hot structures or

tiles for thermal protection, and 

straight wings or delta wings—

had complex implications for the

overall system design.

For Tom Moser, getting the first shuttle off the ground took more than technical know-how. 

22 | ASK MAGAZINE
Photo Credit: NASA Dryden Flight Research Center

works” team at Johnson to develop that concept. A network 

of support teams in communications, aerodynamics, and 

heat transfer contributed to analysis done by the core team. 

During that time, Moser was part of the structural design 

engineering group, which he would later lead. “We had all of 

the requirements, and we looked at almost a configuration a 

day,” Moser recalled. Each concept was analyzed in terms of 

weight, manufacturability, cost, schedule, risk, and technology 

readiness. “This is where really good engineering, leadership, 

and management was necessary,” said Moser. 

Every decision—for instance, between a titanium or 

aluminum structure, hot structures or tiles for thermal 

protection, and straight wings or delta wings—had complex 

implications for the overall system design. The material for the 

thermal-protection system, for instance, depended on whether 

the structure was titanium or aluminum. “Any time there was 

a decision to be made there was a set of requirements associated 

with that decision,” said Moser.

By the end of 1969, engineers had agreed upon a basic 

configuration for the shuttle, though it wasn’t exactly what they 

initially imagined. To balance development and operational 

costs, the shuttle could only be partially reusable. The expense of 

developing a fully reusable design encroached upon operational 

spending later on, Moser explained. NASA got the green light 

to proceed with shuttle development three years later. 

Decision and Change 

The detailed development of the shuttle began in 1972. 

This phase of the program was characterized by challenging 

discussions and their outcomes. “One thing that didn’t 

change from Apollo to shuttle is the way we made decisions,” 

said Moser. “Somebody was in charge, but everybody got to 

say what they thought needed to be said at that meeting.” 

Representatives from all engineering disciplines had a seat at 

the table. “All of the facts were laid on the table, and everybody 

got to argue and debate and present their views of what they 

thought the right answer would be,” said Moser. “Quite often 

it was a heated discussion.” 

Once a decision was made, changes were rare. He recalls that 

there were always people who wanted to make changes during 

the shuttle development. Unless testing showed otherwise, “we 

did our work well enough to where we didn’t have to make 

changes,” said Moser. They lived by the philosophy of “better is 

the enemy of good.” Quite simply, Moser said, “We closed the 

door on changes.” 

In It from Start to Finish

Over nine years of development, the individuals who started 

work on the shuttle saw it through to the finish. “I think that’s 

something that a lot of people don’t realize,” said Moser. “The 

team stayed together the whole time.” Moser believes this was 

a huge part of the success of getting the shuttle off the ground. 

Shuttle arrived in the wake of the Mercury, Gemini, Skylab, 

and Apollo–Soyuz programs, giving it a deep bench of seasoned 

engineers who had already worked on multiple programs. “We 

had that experience that is very, very difficult to obtain,” said 

Moser. This experience, combined with the team’s determination 

to see the shuttle succeed, proved a winning combination. 

“You’ve got to commit on the requirements and the mission, but 

you’ve got to commit to the team, too,” said Moser. 

The team had both good managers and good leaders, 

according to Moser. Managers control the implementation of a 

program, explained Moser, but leaders set the path and establish 

a rapport. During shuttle development, he looked up to people 

such as John Yardley, Chris Kraft, Bob Thompson, and Aaron 

Cohen. Their personalities differed, but all those leaders had the 

ability to make tough decisions. 

The team wasn’t always perfect. Screw-ups happened, said 

Moser, but the permission to learn from them made the team 

stronger because they stayed together. “People make mistakes,” 

he said, “but when you have a team and you believe in them and 

support them, then that’s what’ll work.”

The Space Shuttle prototype Enterprise

smoothly atop NASA’s first shuttle carrier 

 rides 

aircraft, NASA 905, during the first of the 

shuttle program’s approach and landing tests 

at Dryden Flight Research Center in 1977.

ASK MAGAZINE | 23
1. T.A. Heppenheimer, The Space Shuttle Decision: NASA's Search for a Reusable Space Vehicle (Washington, D.C.: 

NASA History Office), 1999, p. 207.

Sell It. Then Keep It Sold. 

Wernher von Braun once wrote that Apollo “had the beauty 

of simplicity. Everybody knows what the moon is, everybody 

knows what this decade is, and everybody can tell a live astronaut 

who returned from the moon from one who didn’t.” Shuttle had 

challenges of complexity. While the technical challenges were 

substantial, the political challenges were monumental. 

While NASA initially managed to make the case for the 

shuttle to the White House, Congress, and the public, it was 

difficult to fend off a developing sense of buyer’s remorse. The 

program never received the budget it requested, which caused 

continuous changes to planning and scheduling. The constant 

change and delay resulted in the program nearly being cut, 

though renewed enthusiasm emerged with the first approachand-landing tests of the Space Shuttle Enterprise mated to the top 

of a Boeing 747 in 1977. The stakeholders saw their investment, 

and it was quite a sight. 

“Keeping it sold is difficult,” said Moser, who encourages 

engineers to understand how to operate within the political 

system. “It doesn’t sound like engineering, but if you don’t do 

it, [the work] doesn’t get done.” You have to define the political 

environment and structure an approach consistent with it, he 

said. Keeping the program sold means communicating with 

stakeholders, writing letters, opening lines of communication 

with people in government, and creating effective public 

relations strategies to communicate to the public the importance 

of their investment. 

Liftoff 

The commitment came to fruition on April 12, 1981. Moser, 

who had been up since the early morning hours to support the 

launch, remembers standing in Launch Control at the Cape with 

minutes left in the countdown as STS-1 sat waiting on Launch 

Pad 39A. Moser realized he couldn’t see the vehicle from his 

location. “I couldn’t stand it, so I had to go outside,” he recalled. 

“I walked outside and looked across the open water to where the 

vehicle was and all I could see was just the nose of the external 

tank sticking above the launch complex.” 

Space Shuttle Columbia’s engines started, the smoke came 

up, the fire was bright, “and then the vehicle just rose,” Moser 

remembers. “It was like something coming to life.” 

After the launch, the members of the newly dubbed “Space 

Shuttle Ham and Eggs Society” were recognized for their 

significant contributions to getting the shuttle off the ground. 

Each member of the group received a personalized, laminated 

membership card with a picture of two fried eggs and a slice of 

ham with the words “Are you involved—or committed?” ●

Shuttle arrived in the wake of the Mercury, Gemini, Skylab, and 

Apollo–Soyuz programs, giving it a deep bench of seasoned engineers 

who had already worked on multiple programs.

Possible configurations considered for the Space Shuttle as of 1970. Image Credit: NASA

24 | ASK MAGAZINE
Kohut: Throughout your career you 

worked in the shuttle program at just 

about every conceivable level. Which jobs 

presented the steepest learning curves, 

and what did you do to get up to speed? 

Hale: The first job that I had coming in as 

a “fresh-out” from college—trying to learn 

how to be a flight controller, trying to learn 

about the Space Shuttle and its systems, 

particularly its propulsion system—was a 

big challenge to me because it was unlike 

anything I’d ever done academically or 

in any other part of my career. NASA is 

a special culture, with a special mind-set. 

You have your engineering background, 

but you have to put it to use in ways that 

are completely different in operation than 

what they teach you in the university.

Fortunately, I was mentored quite a bit 

by some of the Apollo veterans who were 

still there in the early days before shuttle. 

They helped teach us not just the facts, 

figures, and technical items, but how to 

Former Space Shuttle Program Manager Wayne Hale’s career 

roughly paralleled the life cycle of the Space Shuttle program. 

Hale began his career with NASA in 1978 as a propulsion officer 

at the Johnson Space Center and later became a flight director in 

Mission Control for forty-one Space Shuttle missions. He went 

on to hold numerous positions in the shuttle program, including 

launch integration manager, deputy program manager, and 

program manager. For the last two years and four months of his 

NASA career, he served as the deputy associate administrator for 

strategic partnerships, responsible for coordinating interagency and 

intergovernmental partnerships for the Space Mission Operations 

Directorate at NASA Headquarters. Matthew Kohut spoke with 

him two weeks before his retirement at the end of July 2010.

 I nter v iew W ith

 Wayne 

 Hale

 By Matthew Kohut

INSIGHT | ASK MAGAZINE | 25
think, how to make decisions, and how 

to communicate those decisions. 

Going from being a person in Mission 

Control sitting at one of the consoles 

being responsible for one discipline to 

being a flight director, where you have 

to understand all twenty-three different 

disciplines that are present in the Shuttle 

Flight Control Room, was also a big 

step. It was like going back to school 

again. There was so much technical 

[knowledge], so much rationale behind 

why things are done the way they’re done. 

It’s a huge amount of knowledge you have 

to amass to be able just to ask the right 

questions to lead the team toward having 

a safe and successful shuttle flight.

Then when I made the transition to 

the Space Shuttle Program Office, first 

as launch integration manager, then 

deputy program manager, and finally 

program manager, I found out that there 

were gaping holes in my knowledge and 

background, in particular regarding 

contracts, law, business, accounting, 

budgeting. All of these were things that I 

had never had to deal with during twenty 

or so years of working for NASA. I had 

to learn about all of those things in very 

short order. 

So each one of those jobs presented a 

different challenge, and the only way I 

know to get through any of those is the 

same thing that I’ve done every step of the 

way, which is to buckle down. You talk to 

people who know how to do what you’re 

attempting to do. You get a list of subject 

matter that you need to study, and you 

just roll up your sleeves and get after it. 

And of course you watch the people who 

are doing it, who are experts, and you ask 

a lot of questions. At some point you get 

to spread your wings and see how you can 

do. Sometimes you soar with the eagles 

and sometimes you crash. That’s part of 

the learning experience, too. 

Kohut: You mentioned that you had 

mentors early on. Who were your 

mentors? Did you have different mentors 

at different stages of your career? 

Hale: I absolutely had different mentors 

at different stages. At the end game when 

They [Apollo veterans] helped teach us not just

the facts, figures, and technical items, but how to 

think, how to make decisions, and how to communicate 

those decisions.

26 | ASK MAGAZINE
I was in the program office, having never 

been in a program office before, Bill 

Parsons was a great mentor to me. He was 

the program manager. He taught me a 

tremendous amount about running a big 

program, about the things I didn’t know, 

the things that I needed to learn. I also 

learned a lot from Lucy Kranz, who was 

our procurement/business office manager. 

She helped fill in all those parts of my 

education that were blanks. A large part 

of what I know about federal acquisition 

regulations, contracts, procurement, and 

how to do budgets comes from Lucy 

Kranz, who continues to do great work 

on different programs for the agency. 

 When I worked in the Flight Directors 

Office, the boss was Tommy Holloway, 

who was a master flight director. I also 

learned from some of those who had 

preceded me, like Chuck Shaw and Ron 

Dittemore. They were all great mentors 

to me. Going back to right when I walked 

in the door, there were several Apollo 

veterans who were ready, willing, and 

able to teach young graduates what it 

meant to work in Mission Control, and 

what sort of things you needed to prepare 

yourself for. And of course Gene Kranz 

was in charge of the organization in those 

days, and you learned a lot at what we 

used to call the Gene Kranz School for 

Boys. He taught us in no uncertain terms 

what was expected.

Kohut: Nearly a year after the Columbia

accident, when you were serving as 

shuttle deputy program manager, 

you wrote your team an e-mail (which 

you reprinted in your blog) that said, 

“... we dropped the torch through 

our complacency, our arrogance, 

self-assurance, sheer stupidity, and 

through continuing attempts to please 

everyone.” Do you have any thoughts 

on how large organizations can keep 

their edge and continue to improve even 

when they succeed?

Hale: The best advice I ever got—Tommy 

Holloway told us over and over—is, 

“You’re never as smart as you think you 

are.” If you ever get to the point where 

you think you’ve got it under control, 

you really don’t, and you need to be 

always hungry and looking out for the 

indications that things aren’t going well. 

It’s a difficult thing in a big organization 

to keep that edge, and it’s particularly 

difficult when things are going well. The 

shuttle had had a long run of success. I 

think we flew eighty-seven flights in a 

row that were all successful. 

In particular, the political leadership 

in charge expected us to do more with 

less. They kept telling us that spaceflight 

was routine and mature, and that we had 

solved all the major problems and just 

needed to not slip up on little things, and 

that it ought to be easier and faster and 

less expensive. 

The truth of the matter is that, with 

the current state of the art, spaceflight 

is extremely difficult. It is fraught with 

danger because of the high speeds and 

extreme environments involved. It requires 

extraordinarily close calculations on the 

amount of material and the physical 

structure of the space ship, because mass 

is at a premium in everything we do. 

After a while of getting, “This is not 

as hard as you think it is. This is mature 

technology and a mature vehicle with 

large margins. We know what we’re 

doing,” drummed into your head, you 

begin to fall into that trap, even though 

deep down in your heart you know 

that’s not true. I’ve seen that happen in 

other industries and other organizations 

that have had a long run of success. The 

fact of the matter is that, particularly in 

spaceflight, you cannot let yourself get 

arrogant. You cannot think that you’ve 

got everything under control. You’ve 

got to be vigilant. I think that’s true for 

any kind of high-risk, high-technology 

endeavor, though it may be true in other 

fields as well. 

A lot of us wish spaceflight were easier. 

I do. I wish it were easier and less costly. 

I wish it were like getting in your car and 

driving to the grocery store. But it’s not 

there. Many people in the media profess 

that it is easy, that it should be simple and 

cheap, and that somehow those folks who 

are currently in the field have not done 

a good job, and therefore it’s costly and 

looks hard. I just don’t believe that to be 

true. I believe it’s a very difficult thing to 

do that requires a great deal of dedication 

and precision. And unfortunately it’s not 

inexpensive at this point in history. 

Kohut: What are you most proud of from 

your tenure as shuttle program manager? 

Hale: The thing that I am most proud 

of is building a team that has been as 

successful as it has been in the five years 

after we returned the shuttle to flight. 

Things have been going very well. Being 

basically a worrier, I worry about things 

when they’re going well, but the team is 

doing very well because I think they are 

paying attention to the fundamentals 

and looking very hard at the symptoms 

ASK MAGAZINE | 27
of things that are not going as well as one 

might wish. So I’m very proud of the team 

and the culture change that we brought 

about. You would think that returning 

the shuttle to flight would be at the top 

of the list, and it is in some ways, but the 

thing I’m most proud of is building the 

team that has been able to carry on and 

be so successful.

Kohut: You mentioned the culture 

change. I’d like to get your perspective 

on what it was and what it became.

Hale: Again, the culture change had to do 

with the arrogant mind-set that basically 

said, “We have been doing this for so long 

so well that we know what we’re doing. We 

have got this difficult subject, this difficult 

environment under control, and we know 

we can get by with cutting corners because 

we know there’s a lot of margin in the 

system.” The culture change was to take 

a step back and say, “No, we really don’t 

know.” To go back to what Mr. Holloway 

taught me, we’re not as smart as we think 

we are. This is a very difficult thing to do. 

The margins everywhere are very small. 

It’s not ordinary, routine, or mature. And, 

therefore, we have to take great care with 

what we do. 

And, oh, by the way, our political 

overseers had kept cutting our budget to 

where we had emaciated our safety and 

engineering systems. We had to go back 

and tell them that that just would not do 

if we intended to fly this vehicle safely. It 

was going to take the resources to provide 

the proper oversight and insight. We were 

able to convince them of that. And so 

it goes. I think that was a huge culture 

change, both for those of us that worked 

in the program and for those who were 

outside the program and in positions to 

make decisions about national resources. 

Kohut: In your blog, you’ve shared 

a lot of “stories from the trenches” 

of the shuttle program that had not 

previously seen the light of day. In your 

first post, you said you wanted to start 

a conversation. Did the purpose of the 

blog change over time for you? 

Hale: The purpose of the blog was 

outreach, to tell people a little bit about 

what it takes to fly human beings in space 

and run a big program, and [share] a little 

bit of what goes on “behind the curtain” 

inside NASA, because I think people are 

interested. So much of what we at NASA 

put out is what somebody once termed 

“tight-lipped and technical.” Not very 

interesting, very arcane. This is a human 

endeavor, and there are people involved 

in it. The things that happen show us 

to be frail and mistaken at times, but 

strong, resolute, and innovative at other 

times, which is the way it is with people. 

I’ve enjoyed sharing some of these stories. 

Trust me, there are more out there, some 

of which I may never share [laughs] and 

some of which I have in mind to share, 

because it’s not just about spaceflight. It’s 

about people, and how people can rise to 

the occasion, react under pressure, and do 

something that is very difficult, with great 

élan and great pride in what they do. 

It’s been a lot of fun. We get feedback. 

People get to make comments and post 

them. I get to review those comments 

before they go out, which is an interesting 

process. I originally thought I’d just approve 

them all. Then you find out that there are 

certain features of the Internet—people 

perhaps are trying to do some things that 

are not appropriate. You really do have to 

read them and evaluate whether or not 

they’re appropriate to post. Those that are 

appropriate have been thoughtful in many 

cases, and frequently they have brought to 

mind another topic that I need to discuss. 

So it has been a conversation. ●

The fact of the matter isthat, particularly in spaceflight, 

you cannot let yourself get arrogant. You cannot

think that you’ve got everything under control.

S

28 | ASK MAGAZINE
Title

By 

Intro

A Space Shuttle model undergoes a wind-tunnel test 

in 1975. This test simulated the ionized gasses that 

Photo Credit: NASA Langley Research Center

surround a shuttle as it reenters the atmosphere.

On April 12, 1981, they sat in the Reid 

Conference Center at Langley Research Center 

and watched the first Space Shuttle launch on 

television, just like everybody else.

Shaping

theShuttleBy Jim Hodges

STORY | ASK MAGAZINE | 29
No, not just like everybody else.

“You were thinking of all of the things you could still be 

doing to it if you had the time and money,” said Dick Powell, 

who worked on the shuttle’s flight-control system as an engineer 

fresh out of Virginia Tech and remembered that, with shuttle, 

“the first thing you learned was that everything you learned in 

school was about thirty years out of date.”

Powell and others in flight control had taken aerodynamic 

data provided by George Ware, Delma Freeman, and a team 

who tested a host of designs and derivatives in a dozen different 

Langley wind tunnels. With the shuttle on the launchpad at 

Kennedy Space Center that day, Ware was wondering about the 

tests and about a meeting with the data verification committee.

“There was a parameter that they were unsure of because it 

had some variation,” Ware said. “We got a Rockwell guy and me 

in the hall to hash it out, and we came back with an answer.

“Now, that’s not a big deal, but it shows you why you might 

wonder: Did we make a mistake? We took a straight edge and 

drew a line and figured out the slope and that was the number 

we gave Dick for the controls. Did I do it right? Is that number 

right?”

Paul Holloway, later to become Langley’s center director, 

wondered about a project he had worked on since its inception 

as a member of NASA’s Space Shuttle Task Force. And he 

considered the time Langley invested in the project. “At its 

peak, Langley had 350 people, 350 man-years of effort at the 

completion of Phase B, in ’76,” he said.

That effort began with the formation of the Space 

Directorate at Langley in 1970. A Vehicle Analysis Branch was 

spun up, with volunteers brought over from Langley’s full-scale 

wind tunnel. They were given concepts to test by Johnson Space 

Center, which was still running the Apollo program at the time, 

only a year after Neil Armstrong first walked on the moon.

“Essentially, we had four configurations using a straightwinged orbiter and a straight-winged booster,” Ware said.

The orbiter looked like a fighter airplane, and power was 

going to be used to land. Ware and the group tested to determine 

what they already suspected: a straight-winged configuration 

wouldn’t work.

“With a straight wing, flow doesn’t become attached to 

both wings at the same time,” Ware said. “One of the wings 

attaches first, and it flips over and will crash.”

More configurations were tried, with wings swept back. 

Then a contractor suggested that the orbiter be boosted into 

space with a solid-fuel rocket and become a glider during 

descent. Rockwell gave it a try with a model that approached 

today’s 81-degree sweep, tapering to 50 degrees.

“They had estimated aerodynamic data, and it was our job 

to validate that data,” Ware said. “In a month, we ran a full set 

of data across a wide speed range and got the information to 

Headquarters. We said, yes, with a few caveats, it will work.”

Along the way, several adjustments had to be made in the 

thought process. “Changing directions with a program this big 

was like trying to steer an elephant,” Ware said.

One adjustment required the engineers to consider just 

what they were building: a flying truck.

“The shuttle’s job was to carry a payload into orbit,” Ware 

said. “It wasn’t designed to fly anything like an airplane. It was 

to survive the return to Earth and land.”

It was to become the first craft to do so under digital control 

from hypersonic speeds in space.

“There were a number of things we could have done to 

improve the flyability, but this was what they wanted,” Ware 

said. “The clock was running and the dollars were flying out.”

Once the shape of the shuttle orbiter was determined, the tests 

accelerated. Every flight-control configuration demanded testing.

“Shuttle had to rewrite a lot of textbooks,” Powell said. 

“It was the first digitally controlled aircraft ... and it was 

directionally unstable.”

Where airplanes had ailerons on their wings and elevators 

on their tails, shuttle had “elevons”—combinations of the two 

on the single big wing.

“You were using elevons for yaw control, and that was 

absolutely unheard of,” Powell said. “The vertical tail was 

unstable. We were using yaw off the elevons to trim hypersonically 

while the vertical tail was shielded [from airflow by the wing].

“It had never been done before, so we had to design a control 

system to do that.”

Then, too, there was a body flap to deflect gasses from the 

engines used to help the orbiter in its ascent. In reality, the shuttle 

has fewer control mechanisms than any airplane. But what was 

asked of the controls made the process more complex.

“The issue there is that the center of pressure, where the 

forces are acting, moves from hypersonic to subsonic,” Powell 

said. “So the trick is to design a vehicle to be controlled through 

all of these readings. Hence the flight mechanics issues.”

Each of those control ideas was tested by Ware and the 

wind-tunnel engineers. They also inherited another problem 

when it was found that tiles attached to the shuttle for heat 

protection were falling off.

“They were testing in the 8-foot pressure tunnel, using the 

bonding system they had for shuttle,” Holloway said. “They 

were testing to see how strong the bond was. If a tile got loose 

and several tiles came off behind it, it was called the zipper 

effect, and it terrified everybody associated with the program.”

There also were problems to work out with expansion of the 

aluminum skin of the shuttle orbiter during the heat of reentry. 

There was fear that that expansion would cause tiles to pop off 

the vehicle. That, and problems with the engines, deflected 

scrutiny from other issues.

30 | ASK MAGAZINE
A 5.5-foot-long wind-tunnel model of the Space 

Shuttle orbiter is tested inside Langley Research 

Center’s 16-foot Transonic Wind Tunnel. 

Photo Credit: NASA Langley Research Center

Imagine going to the director of spaceflight, who was John Young, and 

telling him we wanted to drill holes in the carbon-carbon nose ... But we

did prove analytically and through tests that you could do it, and we did it.

ASK MAGAZINE | 31
“Flight mechanics was having troubles, too,” said Powell. 

“But the other two took the brunt of the arrows.”

Though Johnson Space Center oversaw the shuttle 

project and developed flight-mechanics algorithms, Powell 

and Larry Rowell built a simulator at Langley at the behest of 

aerothermodynamics chief Gene Love.

“We found an old airplane cockpit and refitted it with an 

old Apollo hand stick and some CRT displays,” Powell said. “It 

was like an old golf cart, and we could roll it up to a computer 

console to run tests.

“It helped that we were single,” he added. “Computer time 

was scarce then, but computer time at night wasn’t scarce. We 

would work nights, weekends, whatever.”

And with their cobbled-together machinery, they uncovered 

a problem with the shuttle’s rudder aerodynamics that called for 

the flight-control system to be redone.

As aerodynamic questions were answered, more were posed. 

When Langley’s Jim Donovan wanted to put a camera in the tail 

of Columbia to shoot infrared video over the wing, it took more 

tests to determine that it wouldn’t affect the shuttle’s handling.

“The camera showed that part of the shuttle was overengineered,” Holloway said. “That was weight, and weight was 

payload.”

When Langley’s Paul Siemers wanted to install pressure 

caps in the nose of the shuttle to determine the flow field, there 

was more consternation.

“Imagine going to the director of spaceflight, who was John 

Young, and telling him we wanted to drill holes in the carboncarbon nose,” Holloway said, laughing. “You can imagine what 

the welcome was. But we did prove analytically and through 

tests that you could do it, and we did it.”

Data still comes from those sensors.

Each change generated more tests. From 1970 to 1982, 

52,900 hours of wind-tunnel time were used on shuttle at 

Langley. On that April day in 1981, Ware, Powell, and others sat 

in the Reid Center and wondered if it was enough. The shuttle 

went aloft and came back safely in the first of what would be 

four test flights. But it was hardly routine. Nothing about shuttle 

has ever been routine.

“This was nothing like anything we’d ever done before,” 

said Freeman. “It wasn’t like an airplane. An airplane, you’d 

send it out to a boundary, get it back, then send it out again at a 

different boundary. We had to get this right the first time.”

They got most of it right—enough to get the shuttle back 

safely. But before it could go out again, lessons learned from the 

first flight had to be applied.

“I think George Ware had wind-tunnel models ready to 

go,” said Powell of the moments after the shuttle landed safely, 

much to everyone’s relief. Data was quickly disseminated, and 

everyone learned how serious some of the problems were.

“You could see that every discipline had something to work 

on,” Powell said.

Flight control had misjudged the effect firing the thrusters 

on the aero Reaction Control System had on the orbiter’s 

aerodynamic flow field. The effect of the body flap on reentry 

demanded another look. The shuttle didn’t fly the predicted 

ascent profile.

“If you look at the shuttle, with all of the work on it, we had 

at least four things that could have led to the loss of the vehicle 

in that first flight,” Powell said.

Seven months later, the shuttle flew safely again. It was the 

beginning, but not of the operational life that had been proposed 

for shuttle.

“What you should understand was that, in 1969, this vehicle 

[was projected to] have a lifetime of ten years,” Holloway said. 

“It was designed for fifty flights a year ... and the cost was going 

to be $10 million a flight.”

The Space Shuttle flew nine times in 1985, the year of its 

greatest use. Each flight now costs about $500 million.

“While we were using it, we would be developing the 

technology base to move on and make it significantly cheaper 

to come up with a replacement system,” Holloway said. “And 

none of that happened.”

It’s why he isn’t sad that the shuttle program is ending. “It 

was never supposed to last this long,” Holloway said.

His sadness comes from knowing that there is nothing 

ready to take its place. ●

Former Los Angeles Times reporter Jim Hodges is managing 

editor/senior writer of the Researcher News at NASA’s Langley 

Research Center.

The high temperatures that were to be encountered by the Space 

Shuttle were simulated in the tunnels at Langley in this 1975 test of 

the thermal insulation materials that were used on the orbiter.

Photo Credit: NASA Langley Research Center

32 | ASK MAGAZINE
 Case Study: 

Making Compliance Comprehensible

 By Joseph A. Horvath

Because of their potential to affect human health, biopharmaceutical companies are highly regulated. 

Among the regulations with which they must comply are those that set standards for conducting 

laboratory studies, clinical trials, manufacturing, and associated processes. These regulations are 

often referred to as good practices. 

INSIGHT | ASK MAGAZINE | 33
A hallmark of compliance, in any field, is control. By 

demonstrating control of its good-practice operations, a company 

shows that it is able to comply with applicable regulations in a 

systematic way. This requires that they document their processes 

and standards, train qualified people to carry them out, monitor 

performance continuously, and take corrective action when 

needed. It also requires that a company document that all these 

things took place. These dual imperatives are captured in two, 

oft-quoted maxims:

• Say what you do, then do what you say.

• If it wasn’t documented, it didn’t happen.

In response to these imperatives, biopharmaceutical companies 

have created information bureaucracies to ensure that the creation, 

revision, and dissemination of good-practice information is tightly 

controlled. New procedures are reviewed, approved, published, 

incorporated into training, periodically re-reviewed, expired, 

and archived. When those procedures are revised—as they 

frequently are—the process repeats. New employees are trained 

in the procedures in which they will participate, assessed on their 

knowledge of those procedures, and retrained at set intervals or 

for cause. When their responsibilities change—as they frequently 

do—the process repeats. Everything is documented and “inspection 

ready.” Paper records are signed, dated, versioned, and stored in 

access-controlled archives. Electronic records are stored in validated 

software systems that capture electronic signatures and maintain 

“audit trails” of every addition, deletion, or change. With respect to 

control of compliance information, the biopharmaceutical industry 

has truly built a better mousetrap. 

In principle, the mechanisms that confer control and 

demonstrate compliance should also help workers perform their 

jobs correctly and efficiently. Well-documented processes carried 

out by well-trained workers should ensure high performance. In 

practice, however, the manner in which compliance information 

is controlled can interfere with its effective access and use, a 

paradoxical and potentially dangerous situation. Managing 

procedures in highly controlled document repositories can 

discourage workers from consulting them frequently. Writing 

procedures in a way that addresses all possible regulatory 

objections can make them complex and difficult to read. 

Holding workers accountable to train (and retrain) in a large 

and frequently changing list of procedures can engender a “boxchecking” mentality in which learning is subordinated to simply 

staying caught up.

At Millennium: The Takeda Oncology Company, we 

believe that well-controlled information will not ensure product 

quality if it is not readily understood and used by employees. We 

are not satisfied with building a better mousetrap—we insist on 

actually catching mice (figuratively speaking, of course). To this 

end, we have undertaken a series of projects to simplify access to 

compliance information, to make that information clearer and 

more useful to workers, and to improve the quality of compliance 

training so our workers’ training time is well spent. 

Making Documents Accessible

As any quality-assurance professional will attest, it can be 

challenging to get employees (particularly experienced ones) to 

consult documented procedures regularly. As humans, we are 

prone to cognitive biases and may overestimate our own level 

of comprehension or fail to notice shortcuts and errors as they 

creep into our well-worn routines. These biases are at play in the 

workplace and can lead workers to neglect written procedures in 

favor of their own memories or memory aids. A classic example 

is the manufacturing operator who writes machine settings on 

his or her glove instead of walking across the suite to consult the 

standard operating procedures. 

The challenge of getting workers to consult procedures is 

compounded by the loss of accessibility that can accompany 

strict document control. This loss of accessibility is subtle but 

cumulative in its effects. Controlled documents are more likely 

to be managed by a central group in a central repository, so paper 

documents are not as close at hand. Electronic documents are 

likely to be embedded in a more complex directory structure and 

within software systems that require separate user authentication. 

The printing and distribution of documents may be discouraged 

in order to minimize the availability of non-current versions. 

These impediments to access, when combined with employees’ 

34 | ASK MAGAZINE
natural disinclination to consult procedures, can form a recipe 

for error.

At Millennium, we have moved aggressively to ease access 

to controlled documents while maintaining a high standard of 

control and compliance. We pressed our document management 

software vendor to make significant improvements to the user 

interface and have served as early adopters of the resulting 

product. This product features familiar and intuitive screen 

conventions, a Google-like search function, and a list of 

“Recent” and “Favorites” documents to allow users to quickly 

and directly access their documents of interest. With respect 

to paper documents managed in file rooms, we have enhanced 

our document-scanning capability so more documents can be 

accessed online. We are in the process of streamlining file-room 

records management. And we are actively looking at how the 

organization of information in our central, controlled document 

repository can be optimized to better suit the needs of multiple 

departments. 

These changes to our document-control program have been 

well received but are really just the beginning. The potential 

of currently available technologies to deliver information at 

precisely the moment of need is largely untapped within the 

compliance space. 

Making Documents Useful

Being able to access documents more easily will hold little value if 

those documents are not themselves helpful—both for learning 

and for ongoing reference. Unfortunately, many compliance 

documents fail to meet this standard, owing in part to the goals 

that led them to be created in the first place:

• To instruct employees on how to perform their work

• To demonstrate to regulatory agencies that a process is 

well thought out, under control, and compliant

In practice, the latter of these purposes often tends to 

dominate; controlled documents are written more for inspectors 

than for those who will be required to use them. Documents 

are often written in a formal style that values explicitness and 

exhaustive description over clarity and readability. They may be 

structured and formatted in ways that are not conducive to firstpass comprehension or rapid visual search. And they are often 

written by subject-matter experts who lack technical writing 

skills and are prone to overestimating the appropriate level of 

detail. In this light, it is somewhat vexing to hear the common 

lament that “people don’t consult the standard operating 

procedures” as it seems to beg an obvious question: were they 

even written for them?

In 2009, we conducted an evaluation of our own 

documentation practices, focusing on their usefulness for 

purposes of learning and performance support. We reviewed 

research and best practices in the area of document design and 

readability. We conducted a close-reading and critical review 

of a sample of our controlled documents. And we interviewed 

employees regarding their experience with controlled documents 

and solicited suggestions for improvement. Our evaluation 

identified a number of opportunities for improvement that we 

are currently addressing:

• Improvements to our document templates to de-clutter, 

enhance readability, and provide embedded guidance for 

authors

• Establishment of a style guide along with writing-center 

support for document authors

• Allowance of employees to rate the value and readability 

of controlled documents via the company’s learning 

management system

These improvements are still in progress, but feedback on 

prototypes has been very positive and has reinforced our commitment 

to reconciling the dual purpose of our documentation: to record 

how we do things and to actually do them that way.

Making Training Meaningful

Access to useful documents is not enough, of course. Employees 

need to understand them and, often, to acquire new concepts 

and skills. This is the realm of training, and its objective, from 

a compliance standpoint, is clear. Training must be sufficient to 

The challenge of getting workers to consult procedures is compounded 

by the loss of accessibility that can accompany strict document control. 

ASK MAGAZINE | 35
ensure all employees are qualified for the work they do.

Because employees in our industry work in a highly 

complex and interdisciplinary environment, there is a lot of 

training. Employees must be trained on companywide policies 

and on the use of enterprise systems. They must be kept 

abreast of regulatory expectations and current good practices 

in their areas of specialization. And they must be trained on 

the particular systems, procedures, specifications, and other 

concerns to which their jobs expose them. 

To these are added several other drivers of training volume. 

Procedures are created and revised frequently, and each new 

or revised procedure must be incorporated in training. Healthauthority regulations require sufficient training to ensure 

ongoing qualification. This has conventionally been interpreted 

as a requirement for periodic retraining on all procedures 

(typically, every two years). Finally, it can be difficult to 

effectively target training below the department or group level, 

so training is sometimes assigned very broadly.

Given the sheer volume of training to be produced, 

companies struggle to deliver high-quality, meaningful training 

at the required rate. In the worst-case scenario, high training 

volume results in low training quality, and something has to 

give. Unfortunately, that something is learning. Employees 

may plow through a mountain of assigned training that delivers 

little value, and training becomes an exercise in “signing them 

off” on the relevant documents. The literature on good-practice 

training includes numerous examples—usually uncovered 

during inspection or audit—of employees who were trained 

on thirty or more standard operating procedures in a single 

day. Such cases demonstrate that learning has failed and that 

training has degenerated into a documentation exercise—a 

troubling and unacceptable state of affairs.

At Millennium, we place a high priority on training 

effectiveness and are working along multiple lines to both 

improve the value and lessen the burden of required training 

for our employees. We have developed a process of ongoing 

curriculum review to ensure that employees are assigned the 

training their role requires—neither more nor less. We have 

implemented a risk-based model to ensure the design of training 

materials and assessments is appropriate to the difficulty and 

risk inherent in a given procedure or subject matter. We are 

moving away from training employees on individual standard 

operating procedures and toward qualification-based training 

in which the procedures relevant to a given competency are 

taught via a single, tailored course. And we are increasing our 

use of job aids and other adjuncts to training. In interviews, 

our employees have expressed a strong preference for accessing 

information at the moment of need—rather than training on 

every detail then being expected to recall it months later. 

These and other initiatives have begun to enable us 

to simultaneously reduce the volume of training and improve 

its effectiveness. 

Beyond the Better Mousetrap

With the safety of their patients at stake, biopharmaceutical 

companies cannot be satisfied with building a better mousetrap. 

Validated repositories, process controls, and inspection readiness 

are not ends in themselves. Rather, they are means of ensuring 

that employees perform well: that they follow procedures, 

report problems, make good decisions. To do this, they must

• Truly understand the company’s procedures and their 

quality-related obligations 

• Have ready access to the information they need at the 

moment they need it

• Find that information to be useful to their purpose

The particular requirements of the compliance arena 

can make this a challenging standard to meet, but they 

certainly do not make it impossible. Unless we do so, as an 

industry, we will fail to satisfy the true intent of the regulations 

and, more important, we will fail to satisfy our obligations to 

the patient. ●

Joseph A. Horvath is the senior director of training and 

documentation at Millennium: The Takeda Oncology Company.

36 | ASK MAGAZINE
Title

By 

Intro

An aircraft carrier is a floating city with power plants, satellite telecommunications, convenience 

stores, and medical, dental, and hotel facilities. Maintaining and modernizing these ships can involve 

up to fifty different organizations simultaneously conducting all sorts of work, from painting to 

structural repair to electronic, electrical, and mechanical system upgrades. As an added project 

management challenge, the ship’s crew typically lives onboard during a major overhaul, which means 

that work cannot be conducted day and night, and services such as telecommunications, heating, 

ventilation, air conditioning, electricity, sanitation, and fresh water supply must remain intact as 

much as possible. With up to 500,000 man-days of work scheduled during an eleven-month drydocking period, you can imagine the tremendous amount of activity that must be carried out in a 

confined space and on a tight schedule. 

 By Dan Fontaine 

A Carrier Team One 

Risk Management 

Success Story

STORY | ASK MAGAZINE | 37
The Naval Sea Systems Command (NAVSEA) established 

Carrier Team One (CT1) in 1997 to define, champion, and 

improve cross-organizational processes for planning and 

executing these complex aircraft carrier overhauls, known as 

“availabilities.” CT1 provides the structure for managing and 

systematically improving cost, schedule, and quality performance 

by focusing on key planning and execution processes. They also 

integrate the efforts of numerous contributing organizations 

into an effective total-maintenance process.

CT1 took notice when two aircraft carrier availabilities

were completed a number of weeks late in 2006. The team 

identified many factors that contributed to the delays, including 

large work packages with a number of high-risk items, criticalpath work with minimal margin, significant new and expanded 

work, and project team inexperience and turnover. All these 

issues affected both projects, yet project managers lacked 

an effective means of identifying, assessing, mitigating, and 

communicating the risks they posed to their project’s timely 

completion. As a result, the carrier maintenance community 

was unaware that help was needed until it was too late to take 

steps to avoid or limit delays. 

In response to the problems encountered on those 

projects, CT1’s Executive Steering Committee formed a Risk 

Management Working Group (RMWG) and tasked them to 

(1) develop a standard process for comprehensive availability 

risk management that could be applied consistently across all 

aircraft carrier shipyards and (2) support and monitor a risk 

management pilot project to be implemented on nine carrier 

availabilities at five different locations. CT1 used the existing 

Northrop Grumman Shipbuilding Newport News Operations 

(NGSB-NN) Risk Management Program (already in 

compliance with Department of Defense guidance) to develop 

a formal process for all aircraft carrier availabilities.

NGSB-NN based their 1998 risk program on a NASA-proven 

practice. NASA’s Goddard Space Flight Center conducted a 

number of risk management training sessions at NGSB-NN and 

provided copies of their risk management procedures. Building on 

USS Theodore Roosevelt (CVN 71) is drydocked during a Refueling and Complex Overhaul.

Photo Credit: U.S. Navy

Early in the project, team leaders

wanted to see value before

engaging, but the best way to see

risk management’s value for their

project team was to engage in it.

38 | ASK MAGAZINE
this knowledge transfer from NASA, NGSB-NN developed a risk 

management process designed specifically for ship construction 

and repair. This process included developing a risk management 

strategy; developing and conducting risk management training; 

identifying program risks; analyzing potential technical, quality, 

cost, schedule, and human-capital impacts; determining 

likelihood of problem occurrence; developing plans to mitigate 

risks; developing and maintaining a risk tool for capturing and 

updating project and shipyard risks; capturing risk management 

lessons learned; and continually improving the process to reflect 

customer feedback. To indicate the probability and impact of 

risks, the process uses the red/yellow/green risk cube described in 

the Defense Acquisition University Risk Management Guide for 

Department of Defense Acquisition. It adds environmental and 

safety risks to cost, schedule, and technical/quality risks. Proving 

its value over time, NGSB-NN’s risk management program is 

now used companywide.

 The CT1 risk management pilot project focused on the 

cultural journey required to convince naval shipyard aircraft 

carrier project teams of the value of a formal risk management 

process and to actively engage in it. That journey included the 

following essential elements.

Catalyst: As in any cultural journey, a catalyst for change 

is essential. In this case, the catalyst was the late completion of 

the two 2006 aircraft carrier overhauls in an environment that 

lacked a formal risk management process. 

Infrastructure: The Executive Steering Committee formed 

the RMWG to establish a formal risk management program 

and associated training tools. 

Initial Buy-In: Once the infrastructure was in place, 

the RMWG leader met with key stakeholders to share risk 

management background and procedures and develop their 

implementation plan and customer expectations.

Launch: As Executive Steering Committee chairman, 

Captain Daniel Seigenthaler, USN (assistant chief of staff for 

carrier maintenance at Commander, Naval Air Forces Pacific 

Fleet), signed a letter directing the implementation of a risk 

management pilot program for nine aircraft carrier availabilities 

over a one-year period. This was followed by the RMWG leader 

meeting with project leaders at the headquarters of all three 

aircraft carrier shipyards to discuss ideas for implementation. 

During the pilot project, the RMWG leader provided peer 

assistance and training for each project’s assigned risk manager 

to support skills development and team acceptance. 

Integration into the Organization’s Culture: From the 

outset, each project team’s leadership needed to perceive the 

value of risk management to encourage their engagement. The 

initial direction and expectations set by CT1 provided the 

“push;” the challenge was to create a “pull” from the project 

teams. This was done by integrating risk management into 

command briefings, progress briefings, meeting agendas, team 

training, awards and recognition, newsletter articles, project 

A Hornet launches at sunset aboard USS John C. Stennis (CVN 74).

Photo Credit: U.S. Navy

ASK MAGAZINE | 39
strategies, retrospects, and the “hot wash” meeting at project 

completion. (“Hot wash” is a military term for a meeting 

used to capture learning and develop related recommendations 

at the end of a major activity or engagement.) CT1 thinks of 

a hot wash as a carrier-overhaul project team’s “gift” to future 

project teams. 

Establishing a cross-project risk manager community of 

practice for knowledge sharing and comparison was the key 

to the pilot’s accelerated adoption. This community provides a 

peer-assist environment for the risk managers to communicate 

and collaborate. It is also a forum for risk managers to discuss 

their challenges and share experiences and learning.

Retrospect and Process Maturity: The one-year pilot 

involved eight different overhaul projects that were either 

planned and less than a year from starting or in the process 

of executing four- to six-month-long repair projects. The pilot 

work proved to be process easy, implementation hard. Early in 

the project, team leaders wanted to see value before engaging, 

but the best way to see risk management’s value for their project 

team was to engage in it. 

At the conclusion of the risk management pilot, projectleadership interviews captured what went well and what could 

be improved. A risk management process retrospect was held 

to capture lessons learned and recommendations from the one 

carrier project whose risk implementation extended from the 

start of planning to availability completion. 

Resistance occurred on all projects, but the quickest 

adoption came from the one that was furthest from their start 

date (ten months of planning remaining). As one would expect, 

the team that was a month into their six-month overhaul and 

focused on executing the work that was already under way saw 

the least value in the risk program. Data gathered during the 

pilot showed that project teams who embraced the formal risk 

management process quickly achieved risk-exposure reductions 

similar to those NGSB-NN teams that had been using it for 

years. These metrics helped convince other project teams of the 

value of the process and encouraged their engagement. 

Captured risks were shared via CT1’s portal. The 

commonality of risks gave valuable insights to shipyard and 

program leadership personnel. Some examples of frequent risk 

categories were material availability, work package size and 

changes, constraints from shipyards or naval bases, planning 

performance, key event management, unidentified work and 

weather impacts, scheduling conflicts, worker availability, 

funding, ship’s crew readiness, and project team turnover.

Following the pilot project, feedback from leadership 

showed that they were all fully engaged and appreciative of 

this tool’s ability to help communicate and mitigate their 

biggest concerns. Matt Durkin, Norfolk Naval Shipyard’s 

project superintendent for USS Harry S. Truman’s (CVN 75) 

2009 overhaul, commented, “Risk management provided me 

with more visibility of our project’s key issues. I’m not sure we 

Shipyard workers depart the USS Harry S. Truman (CVN 75).

Photo Credit: U.S. Navy

40 | ASK MAGAZINE
Dan Fontaine of Northrop Grumman Shipbuilding is team 

leader of Carrier Team One’s Risk Management Working Group.

would have completed our last availability on time without the 

RM process.” 

And Tim Ferguson, Puget Sound Naval Shipyard and 

Intermediate Maintenance Facility’s project superintendent for 

USS Abraham Lincoln’s (CVN 72) 2009 overhaul, said, “Our 

project team leveraged the risk management program to support 

open and honest discussion of issues that could have impacted 

delivering the ship on time.”

Pilot participant suggestions for taking the risk management 

program to the next level included

• Adapting the process to address potential problems that 

were beyond the program manager’s scope of influence

• Using the risk management process to identify and 

communicate potential shipyard and ship’s crew workdistribution conflicts

• Integrating risk management into a work package’s 

development process during planning

Captain Kevin Terry, USN, CT1’s chairman, summed up the 

work so far: “The Risk Management Working Group has been 

a true success story. The pilot project was a home run. Aircraft 

carrier public and private shipyards are using the same language 

and risk cube to mitigate and communicate their issues.” 

The U.S. Navy’s Ship Maintenance Enterprise is currently 

building on the success of CT1’s risk management pilot project. 

A NAVSEA instruction is being issued to formalize the process 

for all the U.S. Navy’s ship and submarine overhauls. Over 

the next few years, NAVSEA will expand from individual 

project teams to the entire shipyard enterprise. As Cleve Butts, 

NAVSEA’s director for Carrier Support, notes, “It is absolutely 

essential that we complete our maintenance periods on time and 

within cost, not only for aircraft carriers but for all our ships. Risk 

management is a great communication and management tool 

for ensuring that the right actions are being applied effectively 

and early. The RM [risk management] process has now been 

successfully implemented at all aircraft carrier shipyards.” ●

To learn more about Carrier Team One’s risk management 

experience, contact their working group’s leader, Dan Fontaine, 

at Daniel.Fontaine@ngc.com.

At the conclusion of the risk management pilot, project-leadership

interviews captured what went well and what could be improved. 

A risk management process retrospect was held to capture

lessons learned and recommendations from the one carrier

project whose risk implementation extended from the start of

planning to availability completion. 

ASK MAGAZINE | 41
It’s not always easy to admit we don’t know everything, but once 

we do and ask for help, the process of gaining new knowledge 

has already begun. It takes time and effort, though, to get 

the right knowledge to flow and transfer when and where it’s 

needed. Fortunately, there is a proven knowledge management 

technique that can help. Called a peer assist, it accelerates the 

transfer of knowledge from those who have it to those who need 

it in many organizations.

The Peer Assist

A peer assist is a facilitated work-session, held face to face or 

virtually, where peers from different teams and organizations 

share their experiences and knowledge with a team that has 

requested help in meeting an upcoming challenge. Knowledge 

in the form of good practices, lessons learned, and insights is 

typically shared through relevant stories told by the people who 

experienced them. A peer assist does three things: 

• Targets a specific technical, mission, or business challenge

• Acquires assistance and insight from people outside the 

team and identifies possible approaches and new lines of 

inquiry

• Promotes sharing of learning and develops strong, and 

often new, connections among staff, partners, suppliers, 

and customers

I recently facilitated a peer assist for a health care provider 

in Alaska whose aim was to develop a capital business plan that 

would gain approval from budget holders outside Alaska to 

renew aging facilities and grow capability for long-term health 

care. A preliminary version of the plan had met resistance from 

these decision makers; the Alaska team was told to go back to the 

drawing board and develop a plan that required significantly less 

investment. The team had been working for months at reducing 

the cost and had gotten to a point where they exhausted what 

they knew and the knowledge they were able to get their hands 

on. They called me in to plan and facilitate a peer assist.

After calls with potential peers from the provider’s 

operations in Washington and Oregon, we held the peer assist 

in Anchorage with the home team and eight visiting peers. The 

peers openly shared the lessons they learned from developing 

capital plans for long-term-care facilities in their regions. It was 

clear by early afternoon on the first day of the peer assist that 

their advice to the Alaska team was to reduce their capital plan 

by remodeling and repairing existing facilities. 

The Alaska team insisted that their environment and 

customer needs were different from those in the northwestern 

United States and remodeling wouldn’t provide the long-term 

care needed to attract, serve, and retain potential Alaskan 

customers. Later that afternoon (and planned as part of the 

session) the peers visited several long-term-care facilities. The 

experience made all the difference in the world. The visitors now 

understood the Alaskan context for long-term care and changed 

their advice. They felt new facilities were warranted in Alaska and 

spent the second day of the session developing new options and 

approaches for capital-plan submission with the home peers. 

One of their recommendations was to perform a new 

survey of the aging population in the region. The peer from 

the Oregon provider operations had recently done something 

similar and offered a set of questions and a survey approach that 

Knowledge workers in NASA work on the edge, carrying out complex projects that have never 

before been attempted. It shouldn’t be a surprise to discover that teams working on these projects 

cannot possibly know everything they need to know to perform to the highest standards. In many 

cases, they haven’t had the opportunity to learn from previous experience, or they haven’t had ready 

access to those who have “done it before.”

Peer Assist: 

Learning Before Doing

 By Kent A. Greenes

42 | ASK MAGAZINE | INSIGHT
were geared to providing design input for the development of 

long-term-care facilities. On the spot, the peers modified the 

design of the survey to address the Alaskan environment, native 

Alaskan culture, and other unique aspects of the aging customer 

base in that region.

The session led to a breakthrough in the Alaska team’s 

thinking and capital plan. Not only was their plan approved, 

but the visiting peers benefited from the experience as well. 

An e-mail received by the Alaska team leader reinforced this: 

“Thank you again for the wonderful opportunity to work 

together last week. I really applaud your willingness to hear 

new ideas and your dedicated commitment to the people you 

serve. Kent, you taught us a new appreciation for the power of 

coming together to harness our collective knowledge to fulfill 

our mission. It was an enlightening two days for me, and I am 

very grateful for the experience.”

Many of the peers who came together for those two days 

continue to communicate and collaborate on a routine basis.

Why It Works

A peer assist works because peers more readily share their knowledge 

with each other—and accept knowledge from each other—than 

through hierarchies or official channels, where politics and other 

issues often hamper free exchange. And they are more likely to tell 

the truth about problems they have encountered.

When the peer assist occurs is critical. People are more open 

and inclined to use knowledge they gain from others if they 

get it before they commit to a specific plan of action. Once we 

start down a certain path, it’s hard to get ourselves to think 

differently. So the key to a successful peer assist is to convene 

the session after a team has exhausted what it already knows and 

created its plan, but before the start of actual work. 

Peer assists are most successful when the participants have 

time to socialize and get to know and understand each other. 

This helps people open up and share their hard-earned expertise, 

especially the wisdom gained from painful experience. 

When I was with British Petroleum (BP), our retail business 

wanted to enter the Japanese market. The international team 

responsible for creating the business in Japan hosted a peer assist to 

learn from other BP retailers before they implemented their plan to 

enter this new market. Peers came from all over the world to share 

their experience. The hosting team didn’t want to spend much time 

on the process, but we convinced the leader that the session should 

take two days. On the first day, the home team showed the peers 

their proposed station sites, visited competitor sites, and shared 

their building plans and challenges. When they asked for the peers’ 

input, the quality and amount of contributions were very low. 

In side conversations and in private, however, they all said Japan 

had too mature a retail market for our typical new-entry approach. 

Plus, there was a “gas war” going on in that region. But nobody 

ASK MAGAZINE | 43
dared say openly that they thought the Japan team’s approach was 

seriously flawed. After dinner that night, we went to karaoke bars 

then to a Japanese bath, where we all had to get naked, as is the 

tradition in Japan. The next morning, the feedback, storytelling, 

and sharing differed phenomenally from the day before. The peers 

honestly and openly shared their skepticism and their own tough 

experiences. As a result, the Japan team modified their plan in a 

matter of days and went on to an accelerated, successful entry into 

the market. I have no doubt that taking time to build relationships 

and trust during the peer assist enabled the participants to open up 

and share their knowledge truthfully.

Who Can Help You Learn?

It’s surprisingly easy to find people with relevant knowledge. One 

of the easiest and most effective methods is to tap your personal 

network to find who might have experience in the particular 

challenges you are facing. Even if the people you contact don’t have 

relevant experience themselves, they will likely know “someone 

who knows” and may offer to connect you to them.

The other obvious approach is to search your company 

intranet for people with relevant skills and relevant experience. 

Better yet, if your organization has internal social networking sites, 

blogs, and wikis, these can be quickly and conveniently searched 

for potential peers. Similarly, you can contact people in relevant 

communities of practice, professional forums, and networks to ask 

for help or contacts. Sometimes it is helpful to involve people with 

diverse experience who can push boundaries and lead to innovative 

thinking in the session. In some organizations, teams announce 

their intent to do a peer assist by posting the subject and associated 

challenge on their company’s intranet or electronic news facility. 

This enables people with relevant expertise to offer their help.

Engineering for Success

Based on my experience facilitating hundreds of peer assists, here 

are some critical things to do to ensure a successful outcome:

• Define the problem or opportunity that you are facing, and 

decide whether a peer assist is the most appropriate process. 

• Write and disseminate a brief description of your need to 

peers, giving them the chance to self-select for participation.

• Look for diversity, that is, people who will help your team 

confront the problem from different perspectives. 

• As soon as possible, identify people who can participate on 

your selected dates—fitting into their schedules is critical.

• Identify an experienced facilitator who understands the 

learning process.

• Design the event to ensure plenty of time to reflect.

• Allow the peer-assist team members time as a group during 

the session to analyze their findings. 

• Ensure the key lessons and good practices shared during 

44 | ASK MAGAZINE
the session are captured. This may require some followup work to gather sufficient detail for those who did not 

participate.

• Agree to a set of actions.

• Make your findings accessible to others outside the group.

Peer Assists in a Virtual World

One of the things that limits the application and impact of the peer 

assist is a team’s ability to hold the session in a timely manner. Virtual 

meeting technologies can really make a difference. I have facilitated 

many virtual peer assists online using standard web-conferencing 

tools. Yes, it’s tougher to socialize and build the respect and trust 

needed for open sharing and transfer. But what you lose by lack of 

face-to-face interaction you gain by making it feasible for peers to 

participate. More often than not, you are likely to get the right peers 

to participate because they don’t have to travel. 

Virtual peer assists are most effective when the challenge 

is specific and bounded. A good example is one I facilitated 

for an international oil company that was drilling their first 

high-pressure, high-temperature well in thirty years off the 

coast of Norway. The Norwegian government had set very 

high standards and extensive requirements for drilling in this 

deepwater environment, which included how the well was cased 

in cement to prevent gas blowouts and other operational risks. 

The team was two months away from setting casing 

when they realized their plan for cementing the well was way 

beyond budget. To make up for their lack of local experience 

and knowledge about procuring and setting casing in such an 

extreme environment, they had over-engineered a solution that 

required a greater amount of cement to minimize risk. I was 

brought in to facilitate a peer assist targeted at optimizing the 

cement-casing job. After eight hours of phone calls and personal 

networking, the Norway engineers were able to identify seven 

engineers across their global operations who had relevant 

experience and could spend a few hours on short notice in a 

virtual peer-assist session.

They reviewed well schematics online and in downloaded 

form, and asked lots of questions. Although most of them never 

met or knew each other, in a two-hour session the peers shared 

enough cementing knowledge to significantly change the 

Norway plan, reducing costs by $2 million. 

Not a Silver Bullet 

The effectiveness of a peer-assist technique in transferring 

knowledge in real time from those who have it to those who 

need it has been demonstrated over and over again. But that 

doesn’t mean it will always lead to improvements in performance. 

There are times when a peer assist is not really needed or the cost 

outweighs the benefits. 

Also, transferring knowledge is one thing, and getting 

people to use it is another. Knowledge doesn’t matter until 

the receivers apply it to make a difference. This is something 

I learned early on in my years applying this technique in BP. 

Recently, a lot of people have asked me, “If BP had such great 

knowledge-exchange techniques, how come they’ve screwed up 

so badly?” My simple answer is peer assists work, but they can’t 

force people to use the knowledge they make available.

One thing I do to address this issue is try to get the home 

peers to agree in advance to allow me to do some follow-up 

facilitation to complete the knowledge-transfer process. Basically, 

this involves tracking their work after the peer assist is over and 

prompting and provoking them to apply the knowledge they 

gained from the visiting peers. ●

This article is based on the work and experiences of the author and 

the knowledge management team at BP from 1995 to 1999. 

Kent A. Greenes is founder of Greenes Consulting (www.

greenesconsulting.com). Previously, he was head of knowledge 

management for British Petroleum and chief knowledge officer 

of SAIC.

Also, transferring knowledge is one thing, and getting people to use

it is another. Knowledge doesn’t matter until the receivers apply it

to make a difference. This is something I learned early on in my years

applying this technique in BP. 

ASK MAGAZINE | 45
By Jeff Cline

Keys to Software Success

A 1995 Standish Group survey of 365 respondents spanning 8,380 software 

applications showed that only 16 percent of software development projects 

finished on time and on budget; 31 percent were canceled; and the remaining 

53 percent overran costs by an average of 189 percent. Similar surveys predict 

that information technology projects are more likely to fail than succeed. 

46 | ASK MAGAZINE | STORY
An unpiloted ISS Progress resupply vehicle approaches the 

space station, bringing almost two tons of food, fuel, oxygen, 

propellant, and supplies for the Expedition 24 crew members.

ASK MAGAZINE | 47

Photo Credit: NASA
Photographed by an STS-131 crew member on Space Shuttle 

Discovery, the International Space Station is featured with Earth’s 

Photo Credit: NASA

horizon and the blackness of space as a backdrop.

For the past decade, a team led and managed by Barrios 

Technology, Ltd., at the Johnson Space Center has avoided 

the pitfalls associated with software development. In addition 

to launching the Mission Integration Database Applications 

System (MIDAS), a successful, large software application that 

supports the International Space Station (ISS) program, the 

team has a productive customer relationship, properly utilizes 

personnel, and empowers its employees, resulting in a highly 

functional software team. 

What Is MIDAS?

MIDAS supports approximately twenty organizations that 

use the system to develop and manage a wide array of ISS 

products, including flight manifests, imagery plans, hazards 

and toxicity analyses, cargo packing plans, cargo certification, 

and consumables planning. The application consists of 

approximately 24 subsystems, 160 user-interface modules, and 

more than 330 database tables. It integrates the subsystems to 

allow each customer organization to use active, current data 

from other customers to help develop its products and make 

data about its own products available to others. This high level 

of data integration allows organizations to develop timely, highquality products, increases cooperation among ISS organizations 

and partners, and provides a cost avoidance of approximately 

$3 million annually for the ISS program.

The NASA application owner and driving force for 

MIDAS, Tim Brown, has said, “Not only do we have a system 

in place that benefits almost every corner of the ISS program, 

but that software has also acted as a ‘glue’ for the various areas 

within ISS. It is my firm belief that MIDAS has been a major 

contribution to the increased coordination and cooperation ISS 

now has among the various individual areas.”

Task Origin and Initial Release

In August 1999, Tim approached our company with several 

pages of high-level requirements for a flight-manifesting tool 

and asked us to consider bidding for the development of the 

application with a target release in fall of 2000. After reviewing 

the requirements with NASA and internally, we decided that 

the task came with a high probability of failure, given immature 

requirements coupled with the task complexity and aggressive 

schedule. Recognizing the risk, but also the potential reward, we 

agreed to take on the work only if we could create a process that 

would give us the best opportunity for success. 

We explained to NASA that we would prefer to estimate 

the cost of developing detailed requirements before submitting 

a build bid. We proposed that a select team of senior developers 

from another Barrios project meet a few hours a day for several 

months with NASA to develop a more detailed requirements 

document. We could then deliver a requirements document and 

a realistic build bid based on more mature data. To support this 

requirements-definition effort, we asked NASA to provide a 

dedicated MIDAS application owner who would have authority 

to make decisions and provide guidance. 

NASA accepted our plan in November and identified Tim 

as our dedicated MIDAS application owner. In December we 

provided a schedule for the requirements-definition phase, 

which identified project tasks, external dependencies such as 

customer reviews and feedback, and milestones that would be 

necessary to produce a requirements document that would later 

inform our build bid. 

In January 2000 our team began meeting with NASA to 

identify software requirements, evaluate target technologies, 

and demonstrate prototype designs. In mid-April we provided 

a draft requirements document for review. When the review 

comments came in later than the schedule allowed, we 

explained the importance of commitments being made and 

kept by both parties. The review comments were incorporated 

and the requirements document and build bid were delivered on 

time, but only after a few tense days as both sides defended their 

positions. This first speed bump was an unpleasant necessity 

that ultimately provided a good foundation for mutual trust and 

a very strong working relationship.

That painful event showed NASA that our schedules were 

real and that both parties were responsible for the success 

and on-time delivery of the project. This doesn’t mean the 

schedule rules all else, but commitments and dependencies 

are often related and need to be coordinated. After this event 

48 | ASK MAGAZINE
both parties have always provided extremely timely support 

to the project.

NASA reviewed our build bid and authorized us to proceed. 

We developed a detailed schedule for design, development, 

testing, and deployment. The content was determined by 

collecting estimates from each software developer for the 

desired capabilities; integrating those inputs; adding time for 

integration testing, holidays, and vacation plans; and letting 

work management software predict the end date. When that 

date did not align with the customer’s desired delivery date, we 

negotiated with NASA to remove content from the release and 

then updated the task list until the work management software 

predicted an October 27, 2000, release date. 

This approach to schedule development has proven to be 

extremely valuable in several ways and provides key lessons:

• Software developers are best equipped to understand the 

effort required to develop and test software.

• When schedules are developed from the bottom up (by 

the executers of the tasks) instead of from the top down 

(by management), the development team takes ownership 

of the schedule. Because the team is committed to the 

schedule, members are invested in the project’s success and 

willing to work extra hours if necessary. Conversely, when 

an unrealistic schedule is dictated from above, schedule 

risks can be viewed as “not my problem” by development 

staff, fostering resentment and adversely affecting team 

unity and performance.

• Resource loading the tasks in work management software 

and including vacations and holidays allows the program 

to provide an objective, realistic schedule prediction for 

the software delivery date. 

• Investing the effort to develop a schedule this way creates a 

structured plan by which to communicate project progress 

and potential risk to both internal and external customers.

• Successfully executing a software release in accordance 

with an approved schedule creates additional trust 

between NASA and the contractor, demonstrating that 

our approved schedule is effectively a commitment, not a 

plan. Repeated successful execution of these schedules over 

time increases customer confidence in the contractor.

• Following this approach, MIDAS enjoys a 100-percent 

on-time delivery rate for approximately 33 major software 

releases and 112 maintenance releases while running 

under budget.

In May of 2000 we began design and development of the 

manifesting tool, conducting numerous reviews to demonstrate 

progress and identify course corrections in our approach. 

We included key users in integration testing. This not only 

confirmed the tool was performing up to their expectations but 

also trained them in the new system. After substantial internal 

and external test support, MIDAS was delivered on November 3,

2000—one week later than the work management–software 

plan. Although MIDAS was ready for delivery on the original 

date of October 27, an unexpected flight freeze restricted 

software changes. The first release of MIDAS is considered an 

on-time delivery because the delivery date was altered by an 

external, unexpected event.

Extending MIDAS 

We began to look up- and downstream of the manifest process 

itself to automate preceding and succeeding steps. For example, 

all manifest changes must be approved through a request process. 

By automating this step and previous steps, as well as those 

steps that follow flight manifesting (cargo packing, hazards 

analysis, cargo/transfer priorities, etc.), we have developed a 

fully integrated system of twenty-four subsystems that provides 

comprehensive traceability for hardware. 

Organizations are often apprehensive of change, particularly 

when they comfortably work with internally developed tools 

such as a spreadsheet or database, but local tools isolate the data 

from other customers. By explaining the benefits of integrated 

data and committing to develop any MIDAS software upgrades 

without cost to candidate organizations, we were able to attract 

many organizations to our requirements table. We promised 

to provide them software funded by a specific NASA budget 

in exchange for their data and support of MIDAS. Integrating 

When schedules are developed from the bottom up

(by the executers of the tasks) instead of from the

top down (by management), the development team

takes ownership of the schedule.

ASK MAGAZINE | 49
After an aborted docking on July 2, 

Progress 38 successfully docked to the 

aft end of the Zvezda Service Module on 

July 4, 2010. The docking was executed 

flawlessly by Progress’s Kurs automated 

Photo Credit: NASA

rendezvous system.

data from these organizations promotes stronger working 

relationships and contributes to job satisfaction for those 

involved in the product development. 

While this level of growth and success has been wonderful 

for our users, team, and company, it has also created challenges. 

The development team in place in May 2000, still intact today, 

has fewer than five full-time people, who are now responsible 

for twenty-four subsystems and more than 900,000 source lines 

of code. Each person must have knowledge of five subsystems, 

on average, in order to ensure the system can be effectively 

sustained, and yet requirements for new features are identified 

every month and added to the queue for MIDAS releases. A 

typical software developer can maintain only about 50,000 

source lines of code,1

 which suggests we should have eighteen 

software developers on staff.

Our small team is able to support so much complex software 

due to the successful development and implementation of many 

key lessons.

General Lessons

We’ve implemented several key elements into our structured 

processes that have proven to be very helpful in ensuring highquality products, maintaining developer interest, and protecting 

our customer from single-point failures.

Employee Respect and Growth 

The personnel we hire are highly trained adults, and we treat 

them as such. Our management approach is built upon trust 

and empowerment, not oversight or checkpoints. Once work 

is assigned to a developer, that developer is responsible for 

creating and meeting schedule estimates, performing testing, 

and managing requirements and user interaction. 

If a customer’s prioritized requirements cannot be 

accommodated by our team in the time requested, we negotiate 

a reduction in content or move the release date so our team 

can accommodate both content and schedule. This shows our 

employees that we value their professional and personal time. 

We want them to see this job as an enjoyable, satisfying career, 

not a twenty-four-hour-a-day obligation. As a result, our team 

members have never failed to step up when schedule challenges 

occasionally arise. 

When software anomalies are identified, we focus on 

understanding the root cause of the problem and develop process 

changes to reduce or eliminate the potential for repeating the 

error rather than assessing blame. When necessary, we work 

with employees to improve a skill or revisit a process.

We demonstrate to our NASA customer that our people are 

the reason for our success and balancing their needs is just as 

important as the needs of the customer. People tend to experience 

stress over family, finances, and their job. If I can eliminate the 

A written requirement can

be interpreted in many ways, 

so the key is whether or not

the software does what the

users thought they were

asking for, not what we, the

development staff, understood 

the requirements to be.

50 | ASK MAGAZINE
job stress from their life, we’ve given our team members more 

energy to focus on their more critical life concerns.

We also use rotational task assignments to provide new 

opportunities for staff development. Rotating personnel gives 

them new skills and a deeper and broader knowledge of our 

system design. A side benefit is our expanded ability to handle 

surges in requirements. Rotations also give staff expanded 

opportunities to learn from their coworkers. 

Trusted Partnership with NASA

A strong working relationship with NASA allows our team to 

excel. We established early on that our word was our bond. 

By empowering our developers to own schedule estimates, 

consolidating those estimates into a scheduling tool to produce 

realistic schedules, working hard to honor those commitments, 

and admitting when we’ve made mistakes, we have created a 

working environment of mutual trust between NASA and 

Barrios. NASA trusts our schedule estimates are realistic. If we 

determine a new requirement is too complex for our technology, 

or not a fair effort–benefit trade, NASA trusts our assessment 

instead of assuming we are avoiding work.

As a result, NASA empowers us to identify and recommend 

ways to make the software better, trusts our opinion on 

which changes make the most sense, and often comes to the 

development team to discuss ideas before taking them to our 

user community. 

Quality 

We work hard to ensure that the software we deliver is of the 

highest quality. While we’ve been successful during the ten-year 

(and counting) delivery history of MIDAS, our philosophy is “our 

users will remember software was delivered on time and wrong 

long after they’ve forgotten it was delivered late but right.” 

Delivering what users need takes precedence over delivering 

on time. As users test our software, they often realize they really 

need something other than what they requested. We work with 

them to identify the difference between where we are and where 

we need to be, and develop a plan to respond. This may mean 

an update to the software prior to delivery, or we may deliver 

as is and on time if the software is usable but not optimal. In 

this latter case, we schedule a follow-up release to add features 

identified during testing. 

Delivering “what they asked for” on time just because they 

agreed to that requirement three or four months ago doesn’t 

mean that requirement is still accurate or appropriate. We don’t 

want to deliver software if it isn’t ready. We deliver only after 

our users have tested the software and agreed that it meets 

their expectations and appears to be bug free, or meets their 

expectations except for minor acceptable discrepancies. We 

ensure high quality through a four-phase integration-testing 

approach that includes testing by the developer; testing by two 

other developers on the MIDAS team, one of whom is not 

familiar with the software; and testing by our customer-support 

group. Finally, key users test the software to ensure it meets 

their expectations. A written requirement can be interpreted 

in many ways, so the key is whether or not the software does 

what the users thought they were asking for, not what we, the 

development staff, understood the requirements to be. 

A Good Team Is Like a Good Marriage

After ten years, I’ve found that our MIDAS team operates much 

like a good marriage. The keys to a successful relationship 

among our MIDAS team members include identifying each 

other’s strengths and utilizing them, identifying each other’s 

weaknesses and strengthening them, and identifying each 

other’s hot buttons and avoiding them. Treating each person 

with respect and empowerment while providing a stable, 

interesting, and nurturing working environment promotes 

team unity and stability. 

By working with such a high-caliber team of software 

developers and NASA for a decade, we’ve learned a tremendous 

amount about successful team development, customer 

relationships, and the importance of teamwork. The team’s 

dedication allows our developers to sustain almost four times as 

much code as a typical developer. To replace this team of “almost 

five” would require more than twice as many new people of a 

similar skill level in order to barely get by. That is a testament to 

the power of positive team dynamics. ●

Jeff Cline is an information technology manager and 

certified Project Management Professional for Barrios 

Technology. Supporting the ISS program for more than twentytwo years, he has served in various software-related capacities, 

including software architect, developer, and trainer, and he has 

led teams for the past fifteen years.

1. Tom Love, “10 Must Knows for CIOs About Software Development,” November 16, 2006, www.itmpi.org/assets/

base/images/itmpi/privaterooms/tomlove/MustKnows.pdf.

ASK MAGAZINE | 51
We’ve all seen teams that succeed beyond anyone’s wildest dreams. 

They seem to be driven by more than great processes, good 

communication, and individual heroics. They exude an infectious 

energy, outwardly and among their members. Talk of energy in 

teams is often relegated to the list of “intangibles” that may find 

their way into promotional documents or performance reviews 

but do not trump the “numbers.” But we all have people in our 

work lives that we gravitate toward to get a “boost” and others we 

avoid because they “suck the life out of you.” The effects of energy 

are real and important. Furthermore, energy in organizations can 

be studied and the results used to improve performance.

Over a six-year period, we measured the impact of energy 

on large and small teams of a large engineering/construction 

company. The results of the studies verified our intuition about 

the importance of energy. We have found that it has direct 

impact on leadership, performance, engagement, and project 

delivery. We measured the energy within a global informationtechnology (IT) team of 160 people. Using organizational 

network analysis, we created network diagrams that map the 

connections among individuals in an organization. Specifically, 

we focused on energy networks. Energy was measured by asking 

a simple, powerful question: When you interact with this person, 

how does it affect your energy level? The responses ranged from 

“strongly de-energizing” to “strongly energizing.” The patterns 

that emerged from the energy maps were then used to develop 

and grow teams within a changing organization. 

Work by Rob Cross and others identifies behaviors that create 

energy. They include creating a compelling vision, having the 

opportunity to contribute meaningfully, being fully engaged in 

an interaction, seeing progress through interactions, and believing 

in a worthy and attainable objective. These conditions create an 

infectious can-do mentality among individuals and teams. 

An Example: Energy and Leadership

Colleen began her career as a trainer providing information 

to civil engineers on new software applications. Her ability to 

deliver this information effectively engaged even the stodgiest 

engineers. Thanks to her skill, she was given an opportunity to 

begin managing small IT projects. She was adept at this task, 

too, and began to excel under the tutelage of her supervisor; 

pursuing a project management career path was exciting to her. 

When her company merged with another engineering 

company, the regional IT functions were merged. Her project 

management abilities were quickly recognized by the new 

company. Informal comments circulated about her abilities 

and the “energy” she brought to projects. She was positive, 

yet doggedly persistent in meeting objectives on time. When 

the IT function in the company transitioned from regional to 

global, Colleen became part of a newly formed global Project 

Management Office (PMO) under the guidance of her longtime supervisor. With her strong training background, she 

was primarily responsible for communicating and teaching the 

global IT community about the new PMO practices; the rapid 

adoption of those practices showed how effective she was. She 

was sought after to manage the most difficult and challenging 

IT projects. Recently, an opportunity to direct the services for 

The Impact of Energy on Projects

By Christie Dowling, Alexandra Gerbasi, and Vic Gulas

It’s no surprise that success in project-based organizations is driven by how well project teams 

perform. The quality of performance depends not only on the demands of the project but on the 

team makeup and dynamics. In fact, those human factors can have a much greater impact on 

results than the challenges of complexity and scope. Collaboration, communication, leadership, and 

effective knowledge sharing are vital to success, and the “spirit” of teams matters at least as much as 

their technical skill. 

52 | ASK MAGAZINE | INSIGHT
the Americas portion of the IT unit came along and she was 

selected to fill this role, moving her from leadership in project 

management to leadership of a regional service function—one 

step below the chief information officer (CIO). 

Her success was driven, in large part, by how she engaged 

with her teams and coworkers. The energy measurements over 

these six years indicate that Colleen was rated as energizing by 

95 percent of her network ties, compared with the group average 

of 75 percent. 

Colleen is one example of the relationship between energy 

and effectiveness (and success). Of those receiving the highest 

evaluations over time, one rose to be CIO, another became 

a division director reporting to the CIO, and another rose 

three levels to global functional director. Like Colleen, these 

individuals were rated as energizing by more than 90 percent 

of their contacts. Highly placed individuals who, on the other 

hand, received more “de-energizing” scores either left the 

company over time or were asked to leave. 

Energy and Performance

The importance of energy is not limited to leaders. Cross and 

his colleagues note that energizers are “more likely to have 

their ideas considered and put to action, ... get more from 

those around them, ... attract the commitment of other high 

performers, ... [and] impact what individuals and networks as 

a whole learn over time.”

Collecting both performance and energy data, we found high 

performers in the IT team were consistently rated as energizing 

by 77 percent of their connections. Average performers were 

rated as energizing by only 59 percent of their connections. The 

energy difference between average and low performers was only 

7 percent. Energy appears to make the difference between high 

and average performance in this IT team. The individuals who 

have high energy scores were more likely to be in leadership roles 

in the organization or move into them over time. 

Energy makes a difference in team performance as well. 

In 2007, an important project to migrate the existing company 

to a new e-mail system began. The project languished for 

almost twelve months, not getting past the planning phase. 

Then team leadership and a few other core team players were 

changed to jump-start progress. The project was completed 

in six months. The energy data revealed that the original core 

team members were viewed as “energizing” by only 43 percent 

of their connections; the second core leadership team energized 

87 percent of their connections. An even starker contrast 

between these teams was the energy scores of the sponsor and 

project manager. The sponsor and project manager of the 

original team energized only 26 percent and 30 percent of their 

connections; the replacement sponsor and project manager 

energized 90 percent and 64 percent, respectively. Based on these 

observations, we strongly believe that energy and performance 

at the individual and team level are closely linked. 

Energy and Retention

Jack was a member of the IT team dating back to globalization 

in 2003. Between 2003 and 2007, other team members 
indicated that he had high relative energy. Between 2003 and 

2008, though, the percentage of people working with Jack who 

found him energizing dropped from a high of 94 percent to 56 

percent. Shortly thereafter, Jack left the organization. 

In Jack’s case, the number of energizing ties was an indicator 

that his job satisfaction and level of engagement had changed. 

We found the same trend with other individuals who voluntarily 

left the organization—the year before their departure, energy 

scores dropped by an average of 10 percent. So energy can be 

an indicator of employee engagement, and analysis can help 

management identify employees at risk of leaving. 

Individuals with higher “energizing” scores exhibited a lower 

turnover rate in the six years than those that were identified 

as “de-energizing.” On average, those who left the firm were 

rated as de-energizing by 45 percent of their contacts, compared 

with those who stayed with the firm, who were rated as 

de-energizing by only 16 percent of their contacts. Such results can 

help identify key team members as targets for retention efforts. 

Creating Energy

While a focused network survey will provide the clearest 

analysis, you can get insight into the energy level in your 

group by asking and answering these questions:

Is there a compelling vision and mission for the 

team? A well-articulated, clear, and meaningful 

vision differentiates energizers from de-energizers. 

Energized teams look to future possibilities rather 

than past problems.

Are deadlines met? People tend to follow through 

on commitments when they are energized by 

the activities.

Are ideas freely offered and discussed? People are 

energized when they feel they contribute to the team. 

When an idea is rejected, does the individual who 

proposed it still feel they have been heard and given 

a fair chance?

It is also possible to identify energizers within groups. They are 

the people who

 • Subscribe to principles and goals that go beyond their 

personal benefit

 • Engage others in meaningful and realistic conversations 

that capture their hearts and imaginations

 • Create an environment where teammates meaningfully 

engage in important conversations and make them feel 

that their ideas are valued

 • Balance the need for progress and welcome new ideas

 • Effectively disagree with others in a way that makes 

their contribution valued even if it is not followed

 • Consistently follow through on commitments to the 

individuals and the team

Individuals with these characteristics are likely to be 

the main energy sources on their teams. As you plan for the 

future, make the most of those energizers by placing them in 

visible leadership roles. Modeling energizing behaviors yourself 

also helps to propagate energy. When leaders energize others, 

energy has a tendency to pass down through the organization. 

Developing energizing behaviors may require shifts in behavior, 

leadership philosophy, or maybe even core values, but the great 

positive impact of energy on performance makes the effort 

worthwhile. ●

Vic Gulas (vic@k-leadership.com) is the former chief people 

and knowledge officer at MWH, where he led the knowledge 

management, IT, and human resources strategies along with key 

global implementations. Recently retired from MWH, he helps 

nonprofit and for-profit companies leverage their knowledge 

for business.

Alexandra Gerbasi (agerbasi@csun.edu) is an assistant professor of sociology at 

California State University, Northridge. Her work focuses on social networks, trust, and social 

capital. Her book (with Dominika Latusek), Trust and Technology in a Ubiquitous Modern 

Environment: Theoretical and Methodological Perspectives, was recently published. 

Christie Dowling (christie.l.dowling@us.mwhglobal.com) is 

an environmental engineer at MWH with a passion for enhancing 

connections between people and groups to streamline work 

processes and increase reapplication of knowledge. 

References

Robert Cross, Wayne Baker, and Andrew Parker, “What Creates Energy in Organizations?” MIT Sloan Management 

Review, Vol. 44, No. 4, Summer 2003.

54 | ASK MAGAZINE
Title

By 

“The rubber meets the road in projects,” said Jean Tatalias, 

director of Knowledge Services at MITRE, at the beginning of the 

daylong discussion. “We have been working toward improving 

our knowledge sharing and knowledge management.” Tatalias 

pointed out that MITRE had been managing knowledge for 

fifty years. “You might think, ‘Well, fifty years, you must have 

it all done,’” she continued, “but we all know if you work in KM 

[knowledge management], it’s never really done.” 

Over the course of the day, attendees shared stories and ideas 

about knowledge in projects. As projects increase in complexity, 

they demand greater organizational attention to identify and 

transfer valuable knowledge effectively. In addition to NASA and 

MITRE, representatives from organizations including Petrobras, 

the International Centre for Complex Project Management, 

MWH Global, the University of Southern California Marshall 

School of Business, Greenes Consulting, Fluor, and Common 

Knowledge Associates gathered to explore staffing, knowledge 

preservation, and communication, as well as to exchange stories, 

research, ideas, and experiences. 

Defining “Community”

Paul Adler, professor at the Marshall School of Business at 

the University of Southern California, opened the forum 

by challenging the attendees to define what it means to be 

a community, asking, “What makes a group of people a 

community?” It is an important question in a discussion of 

project knowledge because so much organizational knowledge 

is developed and shared in communities. 

Communities share a vision, purpose, identity, or values, 

the group agreed. A community has a common language 

and shares time and information. Communities built around 

science, religion, art, military, politics, and hobbies are often 

characterized by different hallmarks. For instance, the arts place 

great value on individual contributions, whereas the military 

focuses more upon the whole. Religious communities tend to 

respect and preserve tradition, while scientific communities 

gravitate toward innovation. “What I’m struck by is that some of 

these communities ... need exactly the right context to stimulate 

innovation, and some of them are devoted to maintaining 

tradition,” said Adler. 

“Traditional forms of communities are antithetical to 

innovation,” he said. “There’s a very distinct type of community 

that encourages innovation.” Adler explained that innovative 

and traditional communities have different values, norms (that 

is, the behavior members expect of one another), rewards, and 

authority distribution (for instance, top-down or distributed).

Both types of communities have advantages and drawbacks, 

and Adler maintains that organizations need to understand 

the impact that each can have on performance. “If you want 

an organization in which innovation is a crucial performance 

outcome, you need to be looking carefully at the possibility that 

the traditionalistic community is hampering your progress.”

Staffing a Project with Knowledge and Talent

The first panel, comprising Vic Gulas, senior advisor and 

former chief people and knowledge officer for MWH Global; 

Ed Rogers, chief knowledge officer at Goddard Space Flight 

Center; and David Coomber, director of Operations at MITRE, 

addressed how organizations staff projects with the knowledge 

and talent they need. Knowing how to set up, design, and initiate 

The NASA Academy of Program/Project and Engineering Leadership, along with co-host 

MITRE, brought together knowledge experts from NASA centers and members of industry and 

academia for the Academy’s second NASA Knowledge Forum in April. MITRE hosted the event in 

San Diego, California. 

NASA Knowledge Forum 2: 

Knowledge in Projects

 By Haley Stephenson

INSIGHT | ASK MAGAZINE | 55
projects is half the battle, remarked Larry Prusak, editor-inchief of NASA’s ASK Magazine, who facilitated the panel. The 

other half is knowing what knowledge you need, and how that 

knowledge will fuel the project. “The project is becoming the 

unit of analysis within an organization,” said Prusak. Projects 

shape how organizations structure themselves and how they 

measure progress. 

Knowledge acquisition happens in one of two ways: through 

traditional methods of choosing people known to those leading 

the project, or through the more risky method of looking 

outside a known network and taking a chance on someone less 

familiar who has specific knowledge. Most organizations rely 

on the traditional method: going with someone they know or 

have worked with. “The majority is done by relationships,” said 

Gulas. “There may actually be a better person out there, but ... 

there’s this trust that [someone has] delivered and they’ll deliver 

again that is a huge bias.” 

This is common practice for staffing projects at Goddard, 

said Rogers. It’s not the knowledge that usually earns someone 

a spot on a project team. “It’s ‘I want Joe on my team’ or ‘I want 

Sally on my team,’” explained Rogers, but “it shouldn’t matter 

what engineer is matrixed to your group .... It’s not ‘You get 

Sally,’ [it should be] ‘You get the electrical engineering branch’s 

knowledge applied to your project.’”

MITRE has gone through a transition, said Coomber, and 

is now looking at more formal ways of organizing its people and 

knowledge. MITRE is structured to support knowledge staffing 

using web-based knowledge networks everyone can access, and 

integration directors who are responsible for talking to one 

another across disciplines identifying talent, best practices, and 

valuable knowledge. “If I know I need talent in a certain area, 

I’ll go to them,” said Coomber. 

“Expertise doesn’t necessarily come from people you know,” 

Coomber remarked. Looking outside known networks invites 

risk into a project, but taking this chance offers the possibility 

of a serendipitous outcome. For MWH, said Gulas, this means 

evaluating how their organization looks different from their 

competition. To stand out from the rest, they go in search of 

knowledge outside their typical network. “We have to go in 

search of that new knowledge,” said Gulas. After interviewing 

a candidate for a position, Gulas asks himself if he walked away 

feeling energized or de-energized by that person. 

NASA, a project-based organization, doesn’t offer a cookbook 

for individual success. Rather, opportunities are visible to those 

motivated to look for them, explained Ed Hoffman, director 

of the Academy. “This way you get a variety of answers ... the 

people that you want, the minds that you want.” 

Organizations expecting to thrive cannot insulate themselves 

from outside knowledge. “The world is too complex,” said 

Prusak. “No one can possibly know everything. The world will 

beat you in the end.” 

Preserving and Communicating Knowledge 

in Projects

Knowledge transfer is often treated as a simple task when it is 

actually quite complex, requiring time, money, and personnel. 

Most project knowledge is tacit, difficult to document in a 

standard way, and heavily reliant upon context. Often project 

teams aren’t even really sure what knowledge others will find 

valuable. What they consider a “no brainer” or too specialized 

for reuse may in fact be important to other project teams, 

explained Don Cohen, managing editor of ASK Magazine and 

moderator of the second panel, which included Kent Greenes, 

chief executive officer of Greenes Consulting; Hal Bell, director 

of NASA’s Advanced Planning and Analysis Division; and 

Nancy Dixon, founder and principal researcher of Common 

Knowledge Associates. 

Understanding the needs of the knowledge customer is of 

utmost importance, the panelists agreed. This process begins 

with a conversation. Watching when people in a group are sitting 

up, listening, and engaged in a topic indicates what knowledge 

customers are interested in, said Tatalias. Dixon refers to these 

“Expertise doesn’t necessarily come from people you know,” Coomber

remarked. Looking outside known networks invites risk into a project, 

but taking this chance offers the possibility of a serendipitous outcome.

56 | ASK MAGAZINE
group meetings as “sense-making” discussions, whereby people 

come together to understand their contribution to the larger 

puzzle of the project. “I might be able to tell you what I did and 

what actions came from it, but someone else in the room might 

be able to provide their outside perspective of their own actions 

in response,” said Dixon. 

Whenever Greenes goes into a knowledge-capture session, 

he requires that the customer for the knowledge is present, 

because the customer should have the greatest say in what the 

knowledge looks like in the end. Greenes consulted for British 

Petroleum (BP) when it was having problems with knowledge 

transfer between workers during shift hand-over, which was 

costing money and risking employee safety. Greenes observed 

the workplace in action, which allowed him to advise BP on 

how to tailor the knowledge and its transfer to their workers—

the knowledge customer. 

In addition to understanding the knowledge customer, 

understanding how to move or transfer knowledge appropriately 

is also essential. Many organizations use “wikis” to capture and 

post knowledge. These systems are usually search-based, however: 

a user goes in search of the knowledge they know they need, not 

the knowledge they don’t know they need. A wiki is a “pull” 

mechanism, explained Dixon—user initiative pulls knowledge 

from a source. “You can only learn from a pull mechanism if you 

know what you don’t know,” she cautioned. Designing a system 

to push needed knowledge is the other half of the battle. 

A push mechanism, similar to the one Amazon.com uses 

to suggest other books a reader might be interested in based 

on previous browsing and purchasing history, requires that the 

knowledge supplier understand the customer well enough to 

push the right information, said Dixon. Georg Siebes of NASA’s 

Jet Propulsion Laboratory pointed out that too much push can 

be counterproductive. “If the pond is full of bait and the fish are 

saturated,” Siebes said, “the knowledge transfer fails.” 

Effective knowledge transfer depends on the support of 

organizational leadership and resources for communications 

experts and knowledge-sharing events like storytelling over 

lunch. Withholding resources threatens the success of effective 

knowledge sharing, said Bell. He cited the example of the 

Phoenix lander mission to Mars in 2007. The successful project 

captured the attention of people working outside the project. Of 

particular interest was knowledge gained about the heat shield 

for the lander, which protected the spacecraft from damage as it 

entered the Martian atmosphere. The project team didn’t have 

the resources to share their story, however, and the data from the 

heat shield was on the verge of being eliminated. Bell’s group 

stepped in and provided the resources needed to prevent the 

data from being lost. “It’s not always money, it’s people,” said 

Bell. “It takes management and commitment to make these 

discussions happen. It’s all too easy to get caught up in the here, 

now, and today, and not five years down the road.”

Looking Ahead

Attendees suggested that future forums could feature more 

real-life stories from expert practitioners and focus more on the 

next generation of knowledge workers. One particular interest is 

gaining a better understanding of the way the younger generation 

communicates, networks, and learns. Today’s young professionals 

will be the future custodians of organizational knowledge, and 

current leaders must help prepare them to take ownership. 

The discussion reinforced the value of bringing people 

together and exchanging ideas. The forum is an example of a 

community founded upon an affinity for knowledge, looking to 

evolve and progress in order to support organizations, programs, 

and projects. “We’re coming together and sharing our stories 

and lessons,” said Hoffman, “learning from each other.” ●

ASK MAGAZINE | 57
What’s Right About Being Wrong

By Laurence Prusak

The Knowledge Notebook

A number of years ago I was asked by some 

clients to come up with a rapid-fire indicator to 

determine whether a specific organization was 

really a “learning organization.” Now, I have always 

believed that all organizations learn things in some 

ways, even if what they learn does not correspond 

well to reality or provide them with any useful new 

knowledge. After thinking about the request for 

a bit, though, I decided the best indicator would 

be to ask employees, “Can you make a mistake 

around here?” 

When people in various organizations tried 

this out in practice, asking groups of employees 

that key question, they were almost always given 

the same response: “Yes, you can make a mistake, 

but you will pay for it.” Some of these organizations 

were the very same ones that touted themselves as 

“learning organizations” in their annual reports 

and public-relations statements, but if they penalize 

their employees for making mistakes, not much 

learning will happen. 

Why? Well, if you pay a substantial price for 

being wrong, you are rarely going to risk doing 

anything new and different because novel ideas 

and practices have a good chance of failing, at least 

at first. So you will stick with the tried and true, 

avoid mistakes, and learn very little. I think this 

condition is still endemic in most organizations, 

whatever they say about learning and encouraging 

innovative thinking. It is one of the strongest 

constraints I know of to innovation, as well as to 

learning anything at all from inevitable mistakes—

one of the most powerful teachers there is. Some 

recent political memoirs by Tony Blair and George 

Bush also inadvertently communicate this same 

message by denying that any of their decisions 

were mistaken. If you think you have never made 

a mistake, there is no need to bother learning 

anything new.

The early history of NASA is partly a history 

of making mistakes—some of them very costly—

that helped develop the knowledge needed to land 

men on the moon and put rovers on Mars, among 

other triumphs. Some believe that NASA has 

become too mistake-averse over time and that an 

emphasis on avoiding mistakes limits the agency’s 

ability to innovate. (Take a look at the interview 

with Robert Braun in the summer 2010 issue of 

ASK, for instance.)

A recent book has a novel and appealing 

approach to this whole subject. Written by Kathryn 

Schultz, it is called Being Wrong. Ms. Schultz 

wants to establish an entirely new discipline called 

“wrongology” to study the causes, implications, 

and, most of all, the acceptance of being wrong. She 

presents a more populist version of the great book by 

Charles Perrow, Normal Accidents, but her take on 

the subject is more individually based and funnier. 

What would happen if we all accepted that 

being wrong is as much a part of being human as 

being right, and especially that errors are essential 

to learning and knowledge creation? What would 

our values and institutions look like under this 

new dispensation? I can easily summon up the 

grave image of Alan Greenspan testifying before 

Congress last year on the causes of the financial 

crisis. What was so very startling was seeing him 

admit that he was wrong! It was such an unusual 

event that it made headlines around the world. But 

why should it be so rare and so startling? Greenspan 

had a hugely complex job, one where many critical 

variables are either poorly understood or not known 

58 | ASK MAGAZINE
at all. Nevertheless, neither he, nor any other federal director I 

have heard about, has ever said anything vaguely like what he 

did that day before our elected officials and the public.

Perhaps Ms. Schultz’s book will at the very least cause us 

to reflect a bit more on this oft-buried subject. It was a favorite 

theme of philosophers, when philosophers still wrote for the 

masses, and in literature. Being too proud to admit you are 

wrong—or to admit it only when it is too late—is central to 

several of Shakespeare’s plays. King Lear comes to mind. It is the 

subject of more novels than I can begin to list here. If you are 

interested, try tackling War and Peace (and I highly recommend 

it; it’s a great read), and you will see how Tolstoy deals with 

the subject of Napoleon’s colossal mistakes and (Tolstoy being 

the great writer he is) the stubborn mistakes of some Russian 

generals, too.

While Alan Greenspan is not often thought of as a heroic 

figure, he has the laudable distinction of being one of the very 

few people to say directly and clearly that he made a mistake. 

In doing so, he at least opened the door to the possibility of 

learning to do things differently—and better—in the future. ●

... if you pay a substantial price for

being wrong, you are rarely going

to risk doing anything new and 

different because novel ideas and 

practices have a good chance of

failing, at least at first.

ASK MAGAZINE | 59
ASKinteractive

For More on 

Our Stories

Additional information 

pertaining to articles 

featured in this issue can 

be found by visiting the 

following web sites:

• Space Shuttle: 

www.nasa.gov/mission_

pages/shuttle/main/

index.html

• X-15: www.nasa.gov/

externalflash/x15_

interactive

• SpaceX: 

www.spacex.com

feedback

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

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

Reminder: PM Challenge 2011

The NASA PM Challenge is the agency’s annual forum for NASA stakeholders to learn 

about and discuss current trends in program management, project management, and 

related disciplines by sharing their knowledge, lessons learned, and new ideas that 

enhance mission success. PM Challenge 2011 will be held February 9–10, 2011, in 

Long Beach, California. Registration is open October 25, 2010, to January 18, 2011. 

For more information, and to register, visit pmchallenge.gsfc.nasa.gov.

Web of Knowledge

One of the first places scientists turn when volcanoes, wildfires, pollution plumes, 

dust storms, and other phenomena—both natural and manmade—make an 

appearance is NASA’s Aerosol Robotic Network (AERONET). A team of scientists 

at Goddard Space Flight Center along with numerous institutions around the world 

started setting up the network of portable instruments decades ago to validate 

and calibrate satellite measurements. That remains the network’s core function, 

but thousands of scientists have found ways to use AERONET data to gain insight 

into a variety of research areas ranging from air quality to cloud microphysics to 

precipitation dynamics. And one of the best things about the network is the data 

are free for all to use. To learn more about AERONET, visit aeronet.gsfc.nasa.gov.

NASA in the News

NASA’s Space Shuttle fleet began setting records with its first launch on 

April 12, 1981. The shuttle has carried people into orbit repeatedly; launched, 

recovered, and repaired satellites; conducted cutting-edge research; and played 

a major role in building the largest structure in space, the International Space 

Station. As humanity’s first reusable spacecraft, the Space Shuttle required 

not only advanced technologies but the tremendous effort of a vast workforce. 

As the program approaches its final planned launch, NASA is paying tribute with a collection of feature stories 

and videos documenting Space Shuttle operations. Learn more about what it takes to maintain and fly this 

technological marvel at www.nasa.gov/mission_pages/shuttle/flyout/index.html. NASA will continue to add 

stories and videos to this collection, so check regularly for new content.

60 | ASK MAGAZINE
Not yet receiving your own copy of ASK?

To subscribe, send your full name and preferred mailing address 

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

If you like ASK Magazine, 

check out ASK the Academy

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

and features about best practices, lessons learned, and professional 

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

NASA Headquarters 

300 E Street SW 

Washington, DC 20546

www.nasa.gov

NP-2010-09-683-HQ