The NASA Source for Project Management and Engineering Excellence | APPEL SPRIN

Special 

MAKING THE VIS

POLICIES AND PRACTICE

NEW ERA OF SPACE EXP
ON THE COVER

This artist’s concept of the Ares V cargo launch vehicle illustrates the separation of its 

first and second stages in Earth orbit. The vehicle’s propulsion system will be able to 

lift heavy structures and hardware to orbit or fire its engines for trans-lunar injection, a 

trajectory designed to intersect with the Moon. Such lift capabilities will enable NASA to 

carry robust science and exploration payloads to space and could possibly take future 

crews to Mars and beyond. For a detailed map of the mission architecture, see the 

special pullout in this issue.

Image Credit: 
6 

50

DEPARTMENTS

3

In This Issue 

4 

From the Administrator

55

ASK Bookshelf

56

The Knowledge Notebook

58

ASK Interactive

POLICY

6 

Documented Experience: Re-Defi ning 

Project Management Processes

BY DON COHEN In defi ning requirements 

for future programs and projects, NASA’s 

7120.5D team has sought clarity, consistency, 

and the wisdom of experience.

15 

Developing Engineering Excellence for 

Programs and Projects at NASA

BY CHRIS SCOLESE Excellence in engineering 

depends on clear standards, good 

communication, effective training, and a 

commitment to organizational and personal 

responsibility.

23 

Safety and Mission Assurance: 

Independent Yet Engaged

BY BRYAN O’CONNOR S&MA tests 

assumptions not only to identify problems 

but to help solve them.

27 

Program Analysis and Evaluation: 

Clarity and Independence

BY SCOTT PACE PA&E provides independent 

assessments of NASA programs that include 

options for decision makers.

33 

A Look Under the Hood of NPR 7120.5D

BY MIKE BLYTHE The new NASA Procedural 

Requirements establish consistent key 

decision points, roles and responsibilities, 

and problem-resolution processes to support 

the Agency’s ambitious new mission.

36

A Common Language for Systems 

Engineering: NPR 7123.1

BY STEPHEN J. KAPURCH The document 

defi nes processes for managing interactions 

among the elements of complex projects 

and programs.

50 

Program and Project Management 

Improvement Initiatives

BY DR. C. HOWARD ROBINS, JR. The history 

of program and project management at 

NASA includes repeated attempts to improve 

resource control, risk management, and 

communication.

PRACTICE

9 

Lessons from COBE Ab

Processes and Procedu

BY DENNIS MCCARTHY The N

mission required groundbre

thorough testing, and teamw

12 

A Relentless Focus on t

BY REX GEVEDEN Accountab

disagreement, and mission 

essential to achieving NASA

17 

Interview with Rob Man

BY DON COHEN The chief en

Mars Exploration Program 

success of Mars Pathfi nder

Opportunity and the contrib

can make to future explora

Special Pullout

NASA’s Exploration Arc

A map detailing NASA’s pla

to the Moon.

29 

Low-Cost Innovation an

Vision for Space Explor

BY HOWARD E. McCURDY Fu

will include fi nding new way

work at low cost.

38 

Enabling Exploration

BY GARRY LYLES The Explo

Mission Directorate and Co

NASA’s new exploration pr

a reality check for procedu

requirements spelled out in 

41 

The Apollo Experience

BY ROGER D. LAUNIUS Durin

era, NASA learned lessons 

manage complex program

important today.

47

Professional Developm

for the Moon, Mars, and 

BY ED HOFFMAN Career-long 

give managers and systems 

skills they need to make the 

Exploration real.
The Academy of Program/Project and Engineering Leadership (APPE

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

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

providing performance enhancement services and tools, supporting career 

programs, and creating opportunities for project management and 

collaboration with universities, professional associations, industry partne

government agencies.

ASK Magazine grew out of the previous academy, the Academy of Pro

Leadership, and its Knowledge Sharing Initiative, designed for pro

managers to share best practices and lessons learned with fellow practit

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

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

achievements as well as insight into broader issues of organizational knowled

and collaboration. We at APPEL Knowledge Sharing believe that stories re

real-life experiences of practitioners communicate important practical wisdo

their stories, NASA managers, scientists, and engineers share valuable expe

knowledge and foster a community of reflective practitioners. The storie

in ASK are written by the “best of the best” project managers and enginee

from NASA, but also from other government agencies, academia, and in

better than a project manager or engineer to help a colleague address a cri

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 

what you think about what you read here and by sharing your own storie

stories or ask questions about editorial policy, contact Don Cohen, Mana

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

For inquiries about APPEL Knowledge Sharing programs and products, p

the Knowledge Sharing Project Manager, Tina Chindgren, ASRC Managem

6303 Ivy Lane, Suite 130, Greenbelt, MD 20770; tina.chindgren@

301-837-9069. 

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

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

EDITOR-IN-CHIEF

Laurence Prusak

lprusak@msn.com

MANAGING EDITOR

Don Cohen

doncohen@rcn.com

TECHNICAL EDITOR

Kerry Ellis

kerry.ellis@asrcms.com

SPECIAL ISSUE EDITOR

Matt Kohut

mattkohut@infactcommunications.com

SPECIAL ISSUE CONTRIBUTORS

Giny Cheong

giny.cheong@valador.com

Richard Faust

richard.k.faust@nasa.gov

KNOWLEDGE SHARING MANAGER

Tina Chindgren

tina.chindgren@asrcms.com

KNOWLEDGE SHARING ANALYSTS

Ben Bruneau

ben.bruneau@asrcms.com

Johanna Schultz

johanna.schultz@asrcms.com

APPEL PROGRAM MANAGER

Jon Boyle

jon.boyle@asrcms.com

DESIGN

Hirshorn Zuckerman 

Design Group, Inc.

www.hzdg.com

SENIOR PRINTING SPECIALIST

Jeffrey McLean

jmclean@hq.nasa.gov

PRINTING

GraphTec
A casual observer of NASA’s accomplishments from Mercury

and Apollo to the Space Shuttle, space telescopes, and 

interplanetary robotic missions would probably guess that 

those achievements depended on two things: technical 

knowledge and money. Those are essential, of course. But 

the ability to manage that complex, innovative work—to 

plan, guide, and evaluate efforts of many people in many 

places—has been equally important. Landing a man on 

the Moon required the combined knowledge and skills of 

several hundred thousand individuals working for tens of 

thousands of contractors and universities. It was as much 

an organizational triumph as a technical one.

The Agency’s new mission—to build an outpost on 

the Moon and fl y humans to Mars—is in many ways 

more ambitious than Apollo. It will demand decades of 

outstanding cooperative work from all ten NASA centers 

and many contractors. It too will be a managerial challenge 

of daunting complexity and scope. As NASA Administrator 

Michael Griffi n notes in his column on the role of 

governance, it “will require as much ingenuity, hard work, 

and sustained commitment as NASA has ever brought to 

bear.” This special issue of ASK is devoted to the Agency’s 

efforts to develop the organizational structures, policies, 

procedures, and practices needed to organize and support 

that work and commitment.

A number of articles focus directly on the new NASA 

Procedural Requirement documents that establish the 

consistent processes and clear roles and responsibilities 

needed to carry out and coordinate the programs and 

projects that will turn the Vision for Space Exploration 

into reality. Chief Engineer Chris Scolese and Associate 

Administrator Rex Geveden emphasize the importance of 

the clarity and consistency of the procedures, especially 

as they relate to decision making and the balance between 

project authority and engineering authority.

Geveden also talks about the importance of 

focus on the mission, and Ed Hoffman describe

of career-long training and education that the 

will require. The framers of the procedural 

have striven to make them practical tools that 

mission, not bureaucratic abstractions of how pr

projects should be carried out. “Documented 

and Garry Lyles’ “Enabling Exploration” descr

their efforts to incorporate knowledge develop

long experience in the requirements and to 

against the reality of actual work. Bryan O’Con

and Mission Assurance: Independent Yet Eng

Scott Pace (“Program Analysis and Evaluation: 

Independence for the New Mission”) describ

organizations identify potential risks and proble

programs but also look for solutions. Their aim, to

accomplish the mission, not put roadblocks in t

Real-life experience is always more varied an

than even the most sophisticated plans and 

can describe or predict. Rob Manning’s convers

the Mars programs he has worked on make tha

the historical perspectives provided by C. How

Jr., and Roger Launius point out some of the 

challenges of managing complex projects. Howa

argues that NASA must continue to innovate, 

creating its spacecraft and launch vehicles bu

new ways to work effi ciently and well. The art

issue show how much thoughtful work has be

ready NASA for the new era of space explorati

also make clear that we are only at the beginnin

demanding, and exciting journey.

Don Cohen

Managing Editor
We at NASA have the unique privilege of carrying out 

an enormously challenging program of exploration 

and discovery on behalf of the American people. 

The vision for Space Exploration, first announced 

by the president three years ago, has since become 

the law of the land with the passage of the NASA 

Authorization Act last year. The capabilities we 

are developing to satisfy the vision will enable us 

to explore new places, expand our understanding 

of the universe, and establish a human presence in 

other parts of the solar system.

The vision has given NASA its greatest 

mission statement since President Kennedy set the 

Apollo program in motion in 1961. Fulfilling our 

commitments to the International Space Station, 

retiring the Space Shuttle by 2010, and developing 

the Crew Exploration Vehicle and launch vehicles 

to carry out missions to the Moon, Mars, and 

beyond will require as much ingenuity, hard work, 

and sustained commitment as NASA has ever 

brought to bear.

The path ahead is difficult and risky to be 

sure. The next decade will present some of the 

greatest technical and management challenges 

NASA has ever known. Meeting them requires a 

solid organizational foundation that facilitates our 

ability to develop and successfully execute programs 

and projects. It is my responsibility to ensure that 

the Agency has a highly resilient management and 

governance framework, one that strikes a proper 

balance between flexibility and control, so we can 

thrive during this time of dynamic transition. 

 Governance in NASA refers to two things: 

oversight and approval of strategic, programmatic, 

and operational planning and the process for 

decision-making and appeals through the chain 

of command. The former manifests i

the Strategic Management Council, 

Management Council, and the 

Management Council. Governance b

reserved for matters in which decisions 

degrees of integration, visibility, and a

The latter is a natural feature of 

are organized, in which the progra

institutional chains of command are cl

and intentionally separated until they r

top of the organizational chart. Genera

decisions are the responsibility of line o

either programmatic or institutional. I

where there is substantial disagreeme

will be appealed by one side or the oth

A good recent example is the lau

for STS-121. In that case, programmat

made the decision to launch, and 

authorities appealed that decision 

concerns about ice-frost ramp foam 

the shuttle’s external tank. In that cas

came to the level of the Administr

agreement could not be found at lowe

my belief is that decisions of that magn

the attention of NASA’s top manage

governance process worked well in th

It is necessary to have independe

and programmatic lines of comman

because there will always be a hea

between the programmatic im

accomplish tasks within cost and s

the technical imperative to do thin

regardless of cost or schedule. W

organizational separation, one impe

other must dominate, always to the 

either the project or the institution. Th

The Role of Governance

BY DR. MICHAEL D. GRIFFIN 
preserves the valid viewpoints of both, to the benefit of the 

program and the institution. This approach restores our ability 

to provide independent technical review of programs.

A central organizing principle of our work is that the people 

of NASA must assume the primary responsibility for making the 

vision for Space Exploration come to fruition. We are undertaking 

a multigenerational program of sustained exploration, and our 

intellectual capital should remain in house, where we can sustain 

the program’s momentum and retain an institutional memory of 

the system, the cost trades that are made, and why the architecture 

is the way it is. Making our own engineers clearly responsible and 

accountable for our technical products at the system level will 

drive our team toward excellence.

Having decided this, we want to provide our engineers with 

sound requirements and processes that help them execute mission 

objectives with careful and sober attention to risk. First and 

foremost, we will continue to encourage our people to speak up 

whenever they have safety concerns. And through the governance 

framework we will listen to and respond to those concerns.

Since NASA is a highly decentralized organization that 

requires flawless integration of its complex systems, a uniform 

approach to program and project management is essential if we 

are to achieve the kind of technical excellence that is necessary 

to execute our long-term exploration program successfully. The 

same holds doubly true for systems engineering. I have said many 

times since joining NASA that we need to do better in this area. 

The requirements and processes spelled out in NPR 7120.5D and 

NPR 7123.1 are steps in the right direction for these disciplines. 

Through efforts to strengthen our governance model, 

policies, and processes, we are working to establish standards of 

technical excellence that will enable a program of the complexity 

and promise of deep space exploration to move forward over a 

period of decades. It is a personal priority of mine to work with 

the senior management team to make sure that our organization 

enables the workforce to excel as it undertakes the tremendous 

tasks before us. ●

WE ARE UNDERTAKING A 

MULTIGENERATIONAL PROGRAM O

SUSTAINED EXPLORATION, AND OU

INTELLECTUAL CAPITAL SHOULD 

REMAIN IN HOUSE, WHERE WE CAN 

SUSTAIN THE PROGRAM’S MOMEN

AND RETAIN AN INSTITUTIONAL 

MEMORY OF THE SYSTEM, THE CO

TRADES THAT ARE MADE, AND WHY 

THE ARCHITECTURE IS THE WAY IT 
BY DON COHEN

Tom Gavin of Jet Propulsion Laboratory (JPL) heads the team responsible for writing NPR 

the document that defi nes the policies and requirements that will govern the programs an

that will take NASA back to the Moon and on to Mars. Carrying out this complex, in

lengthy mission is as much an organizational challenge as a technical one. 
The work of NASA Centers and contractors, and what is likely 

to be more than one generation of engineers and scientists, 

needs to adhere to consistent, well-defined processes to 

guarantee quality and safety and make it possible to coordinate 

those thousands of local efforts into intricate, integrated 

systems—think of a gigantic puzzle whose pieces must fit 

together perfectly. At the same time, the processes need to 

flexibly accommodate different kinds of projects and leave 

room for the creativity that will solve the myriad problems 

this new work will present. Most of all, these processes cannot 

be a bureaucratic abstraction of how work should be done; they 

need to be grounded in experience and embody the best of 

how work happens in the real world.

The 7120.5D team pulls together broad and deep NASA 

expertise, including members from each center and mission 

directorate, from the Office of the Chief Engineer and the 

Office of Safety and Mission Assurance, from Program Analysis 

and Evaluation, and several mission support organizations that 

provide experience in human space flight and robotic projects. 

Gavin, currently associate director of Flight Projects and Mission 

Success at JPL, brings a wealth of experience in establishing 

consistent flight project practices at that center, but he is quick 

to point out that 7120.5D represents the interests and expertise 

of stakeholders throughout NASA.

Many organizations run into problems with coordination 

and collaboration because they assume that everyone understands 

basic terms in the same way when, in fact, they mean different 

things to different groups. Those differences often only surface 

when they try to work together but end up working at cross 

purposes. Some of the most critical work of the 7120.5D team 

involved developing a common understanding of the words that 

define important processes. For example, Gavin notes, “People 

had different views about the meaning of ‘independent.’ We 

had to resolve that.” NASA’s governance model includes the 

principle that programs and projects do not review their own 

work, but what, precisely, does that mean in practice? Gavin 

comments: “Does ‘independent’ mean that a pe

review board can’t be part of the project or fu

project? Yes. Does it mean they can’t work at the 

No. The technical knowledge you need is at the ce

Everything the team did was open to discussi

defines roles and responsibilities in part for the sa

defines key terms: to reduce ambiguity and elimina

generated by the assumption that “everyone knows” 

center, and headquarters roles and responsibilities 

fact ideas about them are likely to be vague or c

Orlando Figueroa, veteran of many projects an

and now director of Applied Engineering and Te

Goddard Space Flight Center, drafted a matrix 

responsibilities for 7120.5D and “everybody beat 

was out there” (according to a team member) to m

definitions were the right ones.

The document defines key decision points and 

what the minimum standard of accomplishmen

... THESE PROCESSES CANNOT BE 

BUREAUCRATIC ABSTRACTION OF 

WORK SHOULD BE DONE; THEY NE

TO BE GROUNDED IN EXPERIENCE 

EMBODY THE BEST OF HOW WORK 

HAPPENS IN THE REAL WORLD.
phase—what needs to be done before moving on to the next 

phase. So it mandates more project and program structure than 

in the past, when project approval was the main and sometimes 

the only formal decision point. But in keeping with the need for 

flexibility and in recognition of the professionalism of NASA 

employees and contractors, it focuses on what needs to be 

accomplished, not how a project team achieves those results.

The team’s goal was to define a single, consistent, 

unambiguous process for all NASA programs and projects, but 

they recognized the need to maintain some process elements 

that have value for some kinds of projects and not others. 

Gavin says,

 The general structure is the same across the board, but we 

wanted to keep the things that were good about existing 

processes. For robotics, we do a post-launch assessment 

review with the standing review board. For human space 

flight, they have a mission management team meeting every 

day. We wanted to preserve that function, so we wrote that 

exclusion into the document.

The extensive hands-on experience of the team members 

gave them the ability to test 7120.5D against the realities 

of project work. They continually asked, “Could I have 

been successful on my project if I had to work to these 

requirements?” 

The NASA community beyond the drafting group also had 

an opportunity to apply their experience and insight to the new 

policies and requirements. Team members distributed their draft 

document informally to program, project, and mission support 

practitioners at their centers or organizations, asking them to 

test the document’s provisions and definitions against their 

own experience. They received 1,300 comments in response. A 

subgroup of the team then “holed up for three days,” in Gavin’s 

words, “and went through every single one of those comments.” 

They decided collectively whether to accept or reject each 

criticism or suggestion and wrote down the ration

decisions. The comments helped clarify the life-

process. Among those adopted were a new flow 

Hill of the Space Shuttle Program Office and an ex

how a tightly coupled program like Constellation w

between program requirements for mission succes

standards of how to perform work. Gavin remarks, 

we said, ‘Yes, we blew it. You got it right.’” The d

rationales were discussed by a core team, which a

document revision. In several instances the core t

out to leading Agency experts for advice on a spe

such as new federal Earned Value Management r

Then the new version was put on NODIS, the N

Directive Information System, to get comments f

wider group of NASA practitioners. The posting d

370 comments. Those went through the same caref

process to produce the final document.

Randy Taylor, a member of the 7120.5D tea

worked on the earlier 5A and 5B versions, note

documents took years to complete. “We did this 

more aggressive schedule,” he says, “which has re

meant continuity of membership, and it kept the 

going.” Probably the most important part of the 

adds, is that “we did it in the sunshine.”

Gavin concurs that openness—developing 

“in the sunshine” and testing its provisions with 

community—was critical to the quality of the pro

document. He has nothing but praise for the group 

intense months of analysis and discussion to the tas

the new policies and guidelines. “The operative wo

he says. “They worked as a team. They were very 

Everybody brought their skills and their cultur

melded together into one document.” ●
BY DENNIS McCARTHY Image Credit: NASA

COBE was launched into an Earth orbit in 1989 to mak

of the microwave radiation left over fro
The COBE project was the most demanding o

because it had to be so precise. To achieve its goal o

diffuse infrared and microwave radiation from 

universe, it had to be essentially perfect. We h

almost impossibly stringent requirement by perfo

of analysis. We analyzed every circuit and did Fa

Effects Analyses (FMEAs) of all the things we th

possibly happen.

You could never have written a specification o

or a statement of work to have someone build 

was Nobel Prize science that depended on gro

technology. Nothing like the instruments we nee

been built before. We had a 100% failure rate al

when we put the instruments in test dewars and 

materials’ properties and electronics. You could

have a contractor do that.

Because COBE had cryogenic instruments with 

of liquid helium cooled to a temperature of 2 kelv

we had to be sure everything was right before 

down; otherwise, it would have taken six weeks to 

up and then cool it down again. So we were very 

developing plans and procedures to test the sate

instruments. Even though we didn’t have all the r

in the eighties that projects have today, we were ve

of all the analyses required to ensure the spacecra

free and would perform the way we predicted it w

COBE was designed to launch from Vandenb

Base on the Space Shuttle, which would insert it 

orbit. The Challenger accident forced us to compl

every aspect of the spacecraft’s design, including m

shuttle launch to a Delta rocket. We’d already bui

mock-up of the COBE spacecraft for a shuttle laun

accident, we had to do a lot of additional analyses to 

the spacecraft for an entirely new launch vehicle 

insertion. The mock-up was actually used to integ

all spacecraft subsystems while we continued to 

instruments in parallel.

The processes and procedures used to cond

program were extremely thorough. For exampl

Smoot were awarded the 2006 Nobel Prize in Physics for this research.

A close-up of COBE’s Far Infrared Absolute Spectrophotometer (FIRAS) horn 

antenna, which made a precise measurement of the spectrum of the cosmic 

microwave background radiation.

Photo Credit: NASA
finished the tests needed to qualify the complete satellite, we 

left it in a radio frequency clean room—a shielded environment 

that blocks extraneous electromagnetic signals—and let it run 

for two weeks. We were encouraged to do this to help scientists 

understand all the characteristics of the satellite. Because 

what they were trying to measure was so minute and the 

measurements had to be so accurate, they needed to be certain 

that their results reflected cosmic background radiation, not 

“noise” from the satellite. This two-week test gave the scientists 

the opportunity to learn the satellite’s idiosyncrasies.

We also had an open-door policy that worked remarkably 

well. The project management team was very sensitive to the 

fact that we wanted everyone in the program to come to us 

at any time if they found something they didn’t understand 

or if they didn’t agree with our decisions. People could come 

talk to me whenever they wanted, and they did. We relied on 

the technicians, engineers, and designers to be our eyes and 

ears, keeping tabs on what went on every day. They were all 

empowered to feel it was their spacecraft. When the workforce 

feels they own the spacecraft, they take care of it, they test it 

adequately, and they don’t take shortcuts. 

I gave our quality assurance (QA) personnel the authority 

to shut down work whenever they felt the need. Once or 

twice they called me from the clean room to say they were 

going to shut down work for a day because the pressure of 

the project was causing someone to want to move on and not 

finish something or skip steps instead of being thorough. The 

QA team did a marvelous job. They had a lot to do with the 

success of this program.

In-house development is critical to building the skill base 

of the NASA workforce. Goddard Deputy Director Mike 

Ryschkewitsch and Director of Engineering Orlando Figueroa 

were each responsible for a part of COBE. There’s no better 

proof of the value of hands-on work. The only way they could 

have developed their high level of engineering judgment was 

through work on an in-house program. In-house projects also 

make you a much smarter customer. You cannot go out and 

monitor prime contractors and distinguish what the problems 

are if you haven’t done the work yourself. 

COBE is a success because the satellite led 

discovery. Looking back, I can say it succeeded 

the team’s talent and dedication, despite disagre

misunderstandings caused by the absence of cl

out roles and responsibilities, such as those prov

new 7120.5D. There were people in the line o

who thought they had more responsibility for C

thought they should have, and as a result there 

conflicts. Clarity about who does what allows e

be more comfortable about expectations, which 

better working environment where the focus can 

accomplishing the mission. ●

DENNIS McCARTHY was deputy project manager for the Cosmic 

Background Explorer (COBE) at Goddard Space Flight Center from 

1983 to 1989. He remained at Goddard in 1990 as the associate 

director for the Space Sciences Directorate, moving in 1991 to 

NASA Headquarters to be the program manager for the Hubble 

Space Telescope. McCarthy was later vice president and director 

of Engineering Services and then director of Engineering at Swales 

Aerospace, where he was responsible for all engineering discipline 

support to NASA, universities, and industry until 2006. 

False-color image of the near-infrared sky as seen by the Diffuse 

Background Experiment (DIRBE), a COBE instrument that obtain

can be used to seek the cosmic infrared background radiation a

the structure of the Milky Way Galaxy and interstellar and interp
Artist’s concept showing a coronal mass 

ejection sweeping past STEREO, which is one 

of NASA’s many recent successful missions.
BY REX GEVEDEN

As someone who has worn a lot of hats within NASA, I would be the last person to 

policies and procedures don’t matter. They’re absolutely critical if we’re to do our jobs e

But it’s not an accomplishment to put out a procedure or to reorganize. In this agency, th

one kind of accomplishment that matters, and that is to carry out NASA’s mission. 

Of course the mission can take several forms—a space flight, a 

research activity, a wind tunnel test. The point is that these are 

all outcome-focused activities, the purpose of which is to satisfy 

NASA’s mission. They are the reason NASA exists, that Congress 

appropriates money to us, and that taxpayers support us. Our job 

is to execute the nation’s civilian aerospace program. Period.

If you’re not doing the mission or something that supports 

the mission, then stop what you’re doing and focus your 

energies on work that does support the mission. This applies to 

any organization. To take a non-NASA example, I used to get 

a utility bill that was a postcard in the mail with a perforation 

so I could mail back one half with my check and put the other 

half in my records. That was the system for years and years, 

and it worked fine. For the last several years, though, I’ve 

received a different kind of utility bill that comes in a bigger 

envelope. It still contains the card with the perforation, but 

it also has something else called the utility bill newsletter. I 

have never read the utility bill newsletter, and I never will. But 

I’m still paying three cents a month or so to contribute to the 

production and distribution of that newsletter. The mission 

of the utility company is to deliver kilowatts of power to my 

home, not a newsletter that I didn’t ask for and don’t want. In 

my view, the newsletter is just a distraction from the mission of 

the utility company.

One of the differences between the NASA of today and 

yesterday is that we have a much more focused and ambitious 

mission today than we’ve had in nearly forty years. We’ve been 

handed a vision with a scale that exceeds our budgets, so we 

have to use every penny we can possibly find, and 

partner with international entities, commercial co

others. To make all this happen, we can’t afford to s

resources on non-mission activities.

In the past couple of years, we’ve made sweepin

changes, organizational changes, and procedu

but those are just a means to an end. They are a

mission. If we have successful missions and we per

and schedule, then we’ll know that our governan

management, and organizational principles matter

What many of these changes have done is put th

back in the middle on the balance between project a

engineering authority. There was a time when the 

culture dominated the agency, and project manag

little real authority. Later, probably starting in the 

we developed a project management culture, w

very positive development except that it took th

balance. Today the project manager still has cle

and accountability all the way down a well-defin

command. At the same time, however, technical au

exists independent of that. If you’re an engineer i

think it’s easier to get a technical issue raised by the m

and I think that’s the way it should be. 

Based on what we’re seeing so far, those 

manifesting very positively in mission success. 

Readiness Reviews for Space Shuttle flights STS-1

and STS-115 were characterized by healthy deba

course became publicly known. I think we’re a bett
it. We worked harder, we thought more deeply about technical 

issues, and in the end we got the best decisions we could get. 

And they contributed to mission success.

It’s a sign of health, not illness, for an organization to 

institutionalize a process for constructive disagreement. 

Consensus-based management in which decision participants 

are pressed into agreement reflects, in my opinion, a state of 

poor health for an organization. If we don’t respect or care 

about one another enough to disagree honestly and openly, 

then we’re not healthy. In an unhealthy organization, 

disagreement creates discomfort, so at times of conflict you 

will hear things like, “Let’s take that offline.” Or, “We’ll take 

an action item.” In other words, disagreement is diverted and 

suppressed. Disagreement—civil, constructive disagreement, 

not destructive, personal disagreement—brings out the best in 

us. It causes us to think harder about our positions. It causes us 

to defend ourselves in a more comprehensive and professional 

way. And I think it leads to good decisions. 

I’m proud of the culture we’re creating within NASA. 

It’s about accountability, responsibility, and success. It’s a 

demanding culture, but it’s one in which I think NASA and 

its partners can thrive and are thriving. It’s a culture about 

truth, about being straight, about disagreeing when you need 

to, and about listening to disagreements and adjudicating them 

fairly. When we talk about technical authority and institutional 

independence, we’re not just talking about engineering. We’re 

also talking about a responsibility to be technically great in 

procurement, for example. If we’re doing something that’s 

risky or otherwise inadvisable, it’s a procurement responsibility 

to raise that concern up the chain and challenge the program 

or project on it. It’s a responsibility to be excellent in law, in 

accounting. Technical authority is not just about an engineering 

culture, though engineering is a big part of it. 

In the end, it is all about the mission, and none of the 

organizational or cultural changes will matter if we don’t 

fly successful missions. Just in the last year, we have flown a 

number of exceptionally difficult missions—the shuttle and 

station assembly flights, New Horizons, CloudSat

STEREO, the Mars Reconnaissance Orbiter, a

think we are doing well. We must maintain our m

because this is a hard and risky business, and it wi

best efforts we can offer. ●

REX GEVEDEN is NASA’s Associate Administrator. In this 

position, he is responsible for all technical operations of the 

Agency. He works directly with the Administrator to develop 

strategy and policy and has direct oversight of all NASA’s 

programs and fi eld centers.

STS-114 Mission Specialist Wendy Lawrence (right) learns about 

inside the orbiter Discovery from Reina Winters, an engineer wit

Space Center. The Flight Readiness Review for STS-114 involved 

which led to better decisions for the mission.
As a boy growing up, I was enthralled by all aspects of space exploration. I soon rea

the success of all space initiatives was the result of solid engineering. Today, while I se

NASA Chief Engineer, I am still in awe of our challenges and accomplishments. NASA 

organization. Our work is literally the stuff of dreams. Themes of wonder, challenge, te

and exploration are components of the work that we do. We sustain NASA’s ability 

through our commitment to solid engineering.

When Mike Griffin asked me to serve as the Agency’s Chief 

Engineer, it was clear that there was an overarching mission to 

create an organization that fostered excellence in engineering so our 

intellectual and mission products would be respected by our peers 

and the public. During the past two years, tremendous energy has 

been devoted to designing a governance model that will further 

promote mission excellence. Standards have been established that 

demand commitment to what we all know is the right way to 

succeed on complex engineering systems. These standards have 

been reinforced by increasing the power and responsibility of 

engineering and programmatic leaders working on our projects 

within the Agency. These increased authorities are further 

enhanced by an organizational commitment to new and improved 

training and development targeted for the individuals and teams 

working our missions. Taken together, these developments—the 

governance model, updated standards, clear lines of authority, 

open communication, and enhanced training—represent real steps 

forward in fostering engineering excellence.

This organizational transformation serves one purpose: to build 

our capacity for excellence. But engineering excellence goes beyond 

standards, communication, training, and structure. It comes down 

to personal responsibility for doing a job based on dedication and 

knowledge and speaking up about what is right and what is wrong. 

Such organizational and personal responsibility has always been a 

part of NASA, as it always is a part of great organizations.

I have been fortunate to work with great organizations and great 

people throughout my professional life. My career began in the navy 

nuclear submarine program, where I had the opportunity to work 

for Admiral Hyman 

Rickover, the father 

of the nuclear navy. 

Rickover understood 

better than anyone 

that people are the 

key to the success 

of any organization. 

“Human experience 

shows that people, 

not organizations or 

management systems, 

get things done,” he once said. These words cont

as a reminder to me that everything we do in the 

Chief Engineer is ultimately about people. I am 

providing the best possible leadership and guid

technical workforce—both civil servants and contr

designs, builds, and operates our space flight system

working with NASA knows that our missions rare

chances, and we have little margin for error. So wha

to achieve this consistent level of mission success

nothing less than excellence. The legendary Green 

coach Vince Lombardi once said, “The quality 

life is in direct proportion to their commitment t

regardless of their chosen field of endeavor.” On s

all know this and are motivated by the pursuit of e

With that in mind, how do we achieve 

excellence? I see it in terms of four guiding princ
Management Processes and Requirements) represents our best 

thinking—drawing on NASA’s nearly fifty years of experience in 

running space flight programs—about the essentials of program 

and project management and the engineering of complex systems. 

The existence of sound policies and procedures does not guarantee 

success, but their absence is a surefire recipe for disaster. As President 

Eisenhower, the crowning achievement of whose military career 

was commanding the Allied invasion of Normandy, once observed, 

“Plans are nothing; planning is everything.” 

Our policies, processes, and procedures must help us work 

collaboratively. That means allowing us to complete tasks 

effectively in a repeatable manner. This reduces costs and fosters 

designs that encourage collaborative problem solving, which is 

essential in an agency with ten field centers and thousands of 

private industry suppliers. 

We all know that space flight projects are inherently risky 

ventures. So at its core, NPR 7120.5D will help us minimize risks 

that can jeopardize mission success. When we practice smart 

strategies at key knowledge decision points in the project life cycle, 

we minimize project risk. When we maintain a clear division 

between technical and program authority, we minimize both 

technical risk and performance risk. When we assign clear roles 

and responsibilities and strengthen accountability, we minimize 

the risk that an organizational weakness will lead to failure. 

Engineering excellence is about more than risk reduction, 

though—again, it is about people. NASA is fortunate that the 

challenge and excitement of its mission allows it to attract and 

retain the most capable technical workforce in the world. After 

all, as President Kennedy said, “We do these things not because 

they are easy but because they are hard.” NASA, in turn, bears 

responsibility for providing this workforce with the training and 

development necessary to carry out its missions. The Academy of 

Program/Project and Engineering Leadership (APPEL), which 

operates within the Office of the Chief Engineer, is responsible 

for the development of program, project, and engineering leaders 

and teams within NASA. Its programs must draw on industry, 

academic, other space agency, and NASA best practices; cuttingedge research; and the most sophisticated tools available to give 

our people the best possible preparation for their work. Professional 

development is more than a series of benchmarks that must be met 

in order to progress up a career ladder; it is a philosophy of growth 

through continuous learning that becomes a habit of mind for 

On the institutional level, engineering rigor takes 

independent technical authority, the implementatio

spelled out in 7120.5D. We have learned the hard w

happen when an engineering organization does not h

independent voice. That independence cannot be 

schedules and budgets, just as programmatic con

be overlooked in the development of the technical 

a given program or project. 

Communication lies at the heart of all lea

management challenges. Every major failure in NA

has stemmed in part from poor communication. 

technical workforce, communication takes myriad 

meetings, discussion among peers, continuous risk m

knowledge management, knowledge sharing, diss

best practices and lessons learned, and continuo

to name but a few. The complexity of NASA’s p

projects demands an open, vigorous culture of 

communication that flourishes within the contex

and procedures while empowering individuals at all 

concerns without fear of adverse consequences. N

specifically addresses the importance of dissenti

ensuring there is an orderly process for airing all v

an environment of respect, integrity, and trust.

Engineering excellence is a goal, not an objec

be measured over a fixed period of time. Policies a

professional development, engineering rigor, 

communication are necessary means for achieving t

they should not be mistaken for ends that offer any 

Through the diligent practice of these principles, 

will develop a way of working that will bring us 

goal and shape us into an engineering organizat

successfully execute the programs and projects tha

closer to our vision of exploring the new frontier of 

As chief engineer, CHRIS SCOLESE is responsible directly to 

Administrator Michael Griffi n for the overall review and technical 

readiness of all NASA programs. The Offi ce of the Chief Engineer 

ensures that the development efforts and missions operations 

are being planned and conducted on a sound engineering basis 

with proper controls and management.
Rob Manning was chief engineer for the 1997 

Mars Pathfi nder project and is currently chief 

engineer for the Mars Exploration Program at Jet 

Propulsion Laboratory. He was one of the NASA 

practitioners asked to review and comment on a 

draft of the 7120.5D requirements and policies. 

COHEN: I want to talk about your 

take on the 7120.5D processes and 

requirements, but let’s start with the 

Mars program experience that has 

shown you how projects work. 

MANNING: In late ’92 or early ’93, Brian 

Muirhead, the flight systems spacecraft 

manager of Mars Pathfinder, said, “I need 

a chief engineer who can deal with the 

software and electronics of this mission, 

because we’re doing new things.” Brian 

and Tony Spear, the Pathfinder project 

manager, were able to pull together a 

very young and energetic team peppered 

with old, wise people. Mars Pathfinder 

was among the first of the faster, better, 

cheaper missions. We modified the old 

way of doing business, trying to streamline 

it to make it faster and cheaper. 

COHEN: It’s hard to do more than two of 

“faster, better, cheaper.” 

MANNING: The trouble is, you need all 

three. Brian tried to get people very 

disciplined not just about cost control but 

scope control. You just can’t make things 

cheaper by whipping people; you have to 

adjust scope, make things as simple as you 

can, but not too simple. For a while we 

were too simple. For instance, we didn’t 

have a radar to detect when we were 

getting close to the ground. We had a 50-

meter cable with a little touchdown sensor 

that sent a signal up to inflate the airbags, 

but the lander might land before the tether 

did, so we said that wasn’t going to work. 

We added a low-budget radar we found. 

We tried to use a lot of commercial stuff, 

which was a mixed story. Sometimes you 

Manning

BY DON COHEN
spend more money convincing yourself 

that the off-the-shelf instrument will 

work than you would have spent had you 

built a unit ten times more expensive. 

Mars Pathfinder landed the fourth of July 

1997, the first airbag lander, with its little 

Sojourner rover. For a while, Sojourner 

was treated like a parasite. 

COHEN: In what sense? 

MANNING: It was this funny thing bolted 

to the inside of the lander; we didn’t 

see where it would take us. The faster, 

better, cheaper mission paradigm was an 

experiment; the landing system was an 

experiment; the science that you could 

do with a rover was experimental. In the 

grand scheme of things, Mars Pathfinder 

will not be counted as the greatest scientific 

mission, but it broke a logjam. We hadn’t 

been to Mars since the very successful 

but very expensive Viking missions of 

the late seventies. The notion was that 

you couldn’t land on Mars without a 

substantial budget, maybe in the billions 

of dollars. So a $270 mill

which was what Pathfinder 

to be—including the launch 

operations, the science, th

and the rover—seemed unbe

The view that you could h

platform on the surface of M

rocks right up to your nose ha

tested or taken seriously by 

community. Likewise, airba

their right mind would land 

and have it bounce around o

of another planet? 

COHEN: So it was a proof of c

MANNING: It’s hard for hu

to accept new paradigm

experiencing them. In 1995

Wide Web was just starting. 

have dreamed that, a few ye

couldn’t do our work witho

have to have a little taste. 

COHEN: So faster, better, che

worked. 

I LEARNED ON PATHFINDER THAT WHEN YOU eng

something, YOU HAVE TO ENGINEER the whole 

... YOU MIGHT HAVE TO change the design OF THE SY

TO MATCH the capability OF THE PEOPLE WHO DO the 
MANNING: Yes, but after Mars Pathfinder, 

the faster, better, cheaper model led to 

the sad state of affairs in 1998, when the 

Mars Polar Lander and Mars Climate 

Orbiter failed. The notion was, if Mars 

Pathfinder can do this mission for $270 

million, we can do it again for half that. 

People overestimated what was possible. 

They didn’t see how close to the edge 

we were financially and technically. 

The combined budget of the Mars 

Polar Lander and the orbiter equaled 

the Pathfinder budget. My view was, 

that team was probably better than we 

were, but I don’t know if they’re twice 

as good. 

COHEN: Did they build on what you 

learned? 

MANNING: Some. Mars Pathfinder was the 

first planetary mission to use a singleboard computer with a commercial 

operating system. That’s since been 

repeated over and over. It was the first 

mission to use C programming constructs 

that have now been ubiquitous for more 

than a decade. Much of the software on 

Pathfinder went on to fly on Stardust, 

Genesis, and Odyssey. 

COHEN: Were there particular 

mechanisms for passing along 

what was learned? 

MANNING: We used the NASA lessonslearned process to put particular lessons 

in the lessons-learned database, but 

that doesn’t substitute for the people 

connection. You’ve got to connect with 

and talk to individuals who have gone 

through these experiences, either as 

review board members or team members 

or leaders of the follow-on mission. 

That’s the only method I know that 

really works. 

COHEN: Some companies use peer 

assist—conversations with people who 

have done similar work—to pass along 

project knowledge. 

MANNING: We do that. In the case of 

Pathfinder, we hadn’t landed on Mars 

in almost a quarter of a century, but the 

people who did it were still around. You 

go to Israel Taback, the chief engineer 

working for Jim Martin, and to Jim, the 

project manager of Viking. You go to Paul 

Siemers of the Viking project. They’re 

worth their weight in gold. They’ll say, 

“There’s a paper written by so-and-so. 

Call that person. That’s what I would do.” 

Imagine having Jim Martin, Iz Taback, 

Gentry Lee, Duncan MacPherson, and 

John Casani all in the same review board 

staring you down. Jim Martin saying, 

“If you can’t show me this entry-descentlanding system is going to work in the 

next four hours, this project is going to 

be over by noon. We shouldn’t be wasting 

taxpayers’ money if we don’t know how 

to pull this off.” The good news is that he 

and others had prepared us. 

COHEN: You convinced them. 

MANNING: We were the first in twenty-five 

years, and I think they wanted us to try. 

Convincing ourselves that it would work 

was touch and go. We had so many air 

bag failures, so many drop test failures, 

so many software problems. Literally two 

months before launch we were doing a 

fullup test of the entrydes

system with the spacecraft 

bed vehicle, and it crashed. W

knowing that the software o

a slim chance of working. W

get our software done by lau

never really done. That se

after launch has paid off m

on almost all our missions. 

COHEN: You couldn’t delay th

MANNING: You can launch 

planets with some regularity 

can fly by Venus and Earth 

But with Mars, you’re stuc

week launch window ever

months. 

COHEN: That will be true for m

missions to Mars. 

MANNING: The pressure 

phenomenal. When we deve

to go to Mars with people, 

to see the same two-we

All the launch pads are go

incredible use. One laun

disaster potentially knock

armada off. 

COHEN: Do you see the Mars 

failures of 1998 as reality ch

MANNING: In some respects, t

best things that could hav

They reminded us that we 

edge. Had they not occu

would have. You can dance 

on the edge of the cliff, but 

close, you’re going to fall. 

was encouraging us to do m
and saying, 

A failure or two wont hurt 

us,” but two failures within two months 

is painful. They reminded us what about 

faster, better, cheaper is good and what 

is bad. When you cut a project down, it 

acts almost like an incompressible fluid. 

The pressure goes up astronomically as 

you reduce the volume. We squished 

those missions down until the risk 

squeezed way up. 

COHEN: Do you think the experience 

taught both technical and management 

lessons? 

MANNING: They’re almost interchangeable 

in my mind. I learned on Pathfinder that 

when you engineer something, you have 

to engineer the whole story. You don’t 

only engineer what it’s going to look like 

and how it’s going to work; you have to 

engineer the person who’s going to design 

it and build it. You have to think about how 

they work with everybody else and make 

sure they have the tests, the resources, 

the space, the test time, the schedule. It 

all has to go together. You might have to 

change the design of the system to match 

the capability of the people who do the 

work. You think, the design’s got to be 

what the design’s got to be, but it turns 

out there’s a lot of variability. You want to 

select a design approach that best uses the 

skills you have at your disposal. 

COHEN: On Mars Pathfi nder you had a lot 

of uncertainty to deal with. 

MANNING: In the case of all landing 

systems on Mars so far, you don’t know 

as you’re designing it whether it’s going 

to work because there are so many 

unknowns in the Mars environment and 

in the system interactions. There’s just 

no way you can tell a review board, “I 

need 500 percent margin in my mass.” 

They’ll say, “You don’t know what the 

heck you’re doing.” That’s correct; we 

don’t know because no one has done this 

before. Project managers at NASA want 

to stay on the road. Entry, descent, and 

landing comes along and suddenly the 

road stops. The whole team is driving 

across a field or a river valley that wasn’t 

on the map. You end up taking the 

project off road because the road that 

you thought would take you from here 

to there has a big gap in it. 

COHEN: I assume the Pathfi nder 

experience laid the groundwork for the 

Mars Exploration Rover program. 

MANNING: The whole MER premise was to 

take the Mars Pathfinder entry-descentlanding system, make the minimum 

necessary modifications in that detailed 

design, and fly a rover that’s designed 

to fit. That lasted about three months 

as a paradigm. It’s June 2000 and the 

launch date is June 2003. Projects need 

four years: one to do preliminary design, 

another to do detailed design, another 

to do fabrication and assembly, and the 

fourth year to test and launch. Three 

years is not enough, if you design from 

scratch. Even before we started seeing 

these changes, we got a phone call from 

Dan Goldin’s office saying, “Why aren’t 

you doing two?” We said, “No one 

asked. We don’t know that we can’t, and 

it might help us.” It turned out that it 

did. We wouldn’t have launched any had 

we only done one. 

COHEN: How did it help to do 

MANNING: When you’re b

assembly line of aircraft, y

build one and put it through 

qualify that system design. 

do that same lengthy test pro

tenth aircraft you build? No

through an acceptance test 

certify that it matches the fir

two vehicles, we put one thr

of qualifications for its cruis

descent-landing phases and t

in parallel, through the su

qualification and split the 

testing. That knocked a co

off our schedule, which al

launch on time. 

COHEN: Is there a key lesson 

story teaches? 

MANNING: In the case of 

complicated systems, give 

test program that gets you 

you don’t want to hear ear

the team get into the te

soon as possible. Things th

often don’t work to specif

oftentimes the environm

operate to specification. 

requirements on Mars; she 

up to them. You have to b

accept new information, new 

from the scientific team t

instance, “Hey, Rob, wind

worse than you thought.

you know about a problem

remarkably easy to fix it if 

yourself the time. When 

“I’m doing my testing at the 

asking for trouble unless i
that they already know very well. There’s 

no crime in being wrong. The crime is 

not giving yourself elbow room to fix the 

problems. 

COHEN: Let’s talk about 7120.5D and how 

it refl ects some of your experience. 

MANNING: There are three legs of program 

management. Program-level management 

focuses on the program/project objectives 

and the resources needed to get the job 

done. Mission assurance provides an 

independent view of safety and quality 

assurance, and makes sure we follow the 

approved processes and get certification 

for the systems that we build. The third 

leg, which has always been there—we 

just haven’t made it official before—is 

the engineering leg. It’s the technical 

authority processes that start with the 

Office of the Chief Engineer and work all 

the way down to the projects and through 

the engineering line organizations at the 

NASA Centers. The line organizations 

and the lead engineers and project systems 

engineers have an independent technical 

say, almost a technical ombudsman role, 

going all the way up to the chief engineer 

in the event programs deviate from good 

engineering practice. We’ve been doing 

much of it unofficially for many years. 

7120.5D makes it official. It allows 

people—especially new people who come 

to work for NASA—to understand how 

the processes work and the right methods 

for talking about engineering quality. 

COHEN: Can 7120.5D do that without 

introducing a lot of bureaucratic 

paperwork? 

MANNING: We have developed a lot of 

checklists; there are new processes 

involved. But some of the older processes 

have been streamlined. In the past, who 

was on your review board an

different review boards yo

unclear. You might have a 

design review with one grou

month later an independent r

different group of people go

the same material. We 

combine them.” Many of t

and procedures we’ve been d

hoc way are now being cod

specifically what you need fo

you only need to do it once. 

terminology—for example, t

decision point” describes th

from one phase of the missio

That’s also been murky in t

new version attempts to clari

COHEN: Do you think it will be 

appropriate for different proj

MANNING: It’s tuned to diff

of projects. Constellation is 

IN THE CASE OF THESE supercomplicated systems

YOURSELF A test program THAT GETS YOU THE ans

YOU DON’T WANT TO HEAR EARLY AND HAVE THE TEAM 

INTO THE test mode AS SOON AS POSSIBLE. ... ONCE 

KNOW about a problem, IT BECOMES REMARKABLY ea

fi x it IF YOU’VE GIVEN YOURSELF the time.
of projects that are very closely coupled. 

There’s a certain review process for that 

kind of program versus the Mars program, 

which is a more continuous program that 

has projects that are somewhat coupled, 

but not as closely as Constellation. If 

we find a process is cumbersome, we’ll 

tune it. This is a work in progress. The 

first projects to use it will find holes in 

it. We’ll try to fix them in version E. 

Some people may argue that it’s great 

for big projects, but what about little 

projects? We’ll spend all our time doing 

documents and writing certification and 

flight readiness reports. We say, “Yes, you 

have to do it, but appropriately for your 

project.” That’s part of the balancing act 

that’s still to come. 

COHEN: You’ve mentioned new 

terminology. Tom Gavin has talked 

about 7120.5D helping to standardize 

shared vocabulary. 

MANNING: We still are not consistent 

about how we define terms and rules of 

engagement across the Agency. Having 

things written down really makes a 

difference. 

COHEN: Will 7120.5D require people to 

document project learnings? 

MANNING: I don’t think that’s its intent. 

It’s an attempt to define the minimum 

requirements of projects to ensure that 

the system being built will meet its 

objective on budget and schedule with 

the appropriate level of quality, mission 

assurance, and safety. Because budgets 

are tight, it’s still a problem to write down 

what you’ve done and why you did it. 

COHEN: Which could be a problem for 

future missions. 

MANNING: We have relied on Viking 

documentation to an extraordinary extent. 

Because there was a twenty-five-year hiatus 

between Mars missions, we could never 

have done Pathfinder and MER without 

the Viking documentation. The same 

thing is happening with Constellation 

and Apollo. The Apollo documentation 

has really helped people understand what 

happened in the 1960s. It’s helped them 

get a dose of experience they would not 

have gotten at this phase of the program 

otherwise. It has been healthy for the 

Agency to study the knowledge that was 

developed at that time. 

COHEN: What do you think is the best 

way to present new documents to make 

clear they’re not just a bureaucratic 

annoyance? 

MANNING: It would be useful for some body 

to create a presentation that explains 

where it came from and why it’s the way 

it is. We tried to put as much information 

in as small amount of space as possible. 

7120.5D has a long, rich history. Laying 

down rules and making a list of them is 

important, but when you first get them, 

you shouldn’t get them as rules, you 

should get them as stories so you can 

understand the context behind the rules. 

If you’re just following the rules without 

being aware of why you’re doing what 

you’re doing and why it’s important to 

your success, you’re being an automaton. 

Reading the document will probably 

confuse a lot of people unless they’re 

steeped in the stories behind it. There’s 

a logic behind the documen

deep and rich. If you read 

the context, it looks burea

it’s based on crisp and w

out project and program m

issues: How is money ass

does NASA avoid throwing 

after bad? How is progra

technical risk communicat

we make sure that our cost e

be close to being right? A lo

do with controlling the fu

is a notoriously difficult th

represents the best we’ve got 

For more of our conversation w

Manning, read the full interv

at http://appel.nasa.gov/ask.
When I was a test pilot at the Naval Air Test Center, I worked closely with the engineers 

the fi rst American version of the British Harrier, a vertical/short takeoff and landing (V

fi ghter, for two years before the fi rst fl ight of the prototype. The main aim of my involvem

on my own cockpit experience, was to keep the pilot’s workload at a manageable level, 

during takeoff and landing. I worked with the engineers on the design of the head-up displ

projects vital information into the pilot’s fi eld of view, and the design of the throttle an

minimize circumstances that required the pilot to let go of them.
As NASA’s Chief Safety and Mission Assurance Officer, 

I apply and promote a lot of the lessons I learned then as a 

test pilot and later as a Space Shuttle pilot and director of the 

Space Shuttle program. One of them is the value of drawing 

on different perspectives and types of expertise early on, as 

with the development of the American version of the Harrier. 

We have a history in the Agency of not involving the safety 

and mission assurance (SMA) community during the entire 

project life cycle. No one disagrees with the idea, but they 

tend to think of SMA as the “back-end folks.” An important 

element of the new 7120.5D 

practices and policies 

is that they give safety 

and mission assurance 

an explicit, active role 

from the beginning of 

every project.

“Can Do” vs. 

Caution 

Like good test pilots, 

members of the safety 

and mission assurance 

community spend a lot 

of time thinking about 

“what if” situations (what 

if the engine quits? what 

if one or another system 

fails?), trying to reduce 

the set of possible problems 

that no one has thought 

about yet and trying to 

make sure there is always a 

way out if something goes 

wrong. NASA’s culture 

is a famously optimistic, 

problem-solving, and goal-oriented one; the SMA 

is supposed to look for potential problems a

engineering and operational assumptions. In s

members can sometimes be seen as naysayers. Ov

perception can wear down a motivated SMA eng

seen people burned out by the stress of this negat

I think part of the responsibility for resolving 

between can-do optimism versus problem-seeking p

with the SMA team itself. “No, because” is a legitim

point for safety and missio

We need to take a realis

look at barriers and 

But “no” shouldn’t be t

“Yes, if” is an importan

organization like NAS

words, we need to b

knowledgeable enoug

when there is a safety 

problem but persist

to help the larger 

the solutions to the 

uncover. SMA engin

engaged from the b

part of the design te

out how to make thin

just explaining why 

not and then leaving 

A tension also ex

being fully and acti

in projects from th

as safety and missi

will be under 7120

the same time mai

independence of 

and action we 

our work well. O
challenge and test the assumptions of 

design engineers, providing the checks and balances needed 

to ensure safe, successful missions. So we need to look at project 

plans, analysis results, design options, and other project elements 

with independent eyes and ensure design engineers are not 

drinking their own bathwater. We at NASA can sometimes get 

carried away by an overabundance of confidence in ourselves, 

but I think of the advice Tommy Holloway gave me while we 

were working on the space station together: “Remember, you’re 

not as smart as you think you are.” No matter how good you 

are, you can’t think of everything, foresee every problem, or 

recognize all the potential weaknesses in your assumptions, so 

reach out for the independent look.

I remember a clear example of skilled professionals being 

led astray by an excessive belief in their competence in the late 

seventies. We arranged training dogfights between a dozen navy 

F-14 pilots and an equal number of marines flying the AV-8A, the 

first American version of the British V/STOL aircraft. The first 

F-14 pilot to face a Harrier unswept his aircraft’s wing to lower 

its speed and increase maneuverability, but he couldn’t match 

the Harrier, which had vectored thrust capability and could be 

almost stationary by comparison. The Harrier easily dropped 

behind the F-14 and “destroyed” it. Although the second and 

third F-14 pilots saw what happened, they tried the very same 

thing, with the same result: they also lost their dogfights. Why 

didn’t they learn? They assumed they were better pilots than the 

ones who had failed and ignored the possibility that the tactic 

itself was faulty.

Learning fr

Mishaps

A similar ov

factor may get 

of NASA’s abi

from mistakes. 

is required to in

occurrences of 

injury. Investig

calls is encouraged but not required, so they are o

In the past, when we experienced a close call, we ten

on the one thing that saved us (and our own skil

disaster) rather than the three that almost killed 

calls are a gift—an opportunity to learn impo

without scraping bodies from the floor. We are 

though. I recently sat in on a class B–level mishap 

final report briefing, not for a class B mishap, bu

call. A young worker was knocked down but not i

he cut through a “hot” electrical wire that had 22

electricity running through it. The focus of the 

was not on what saved his life—the fact that the 

dry, that he was wearing gloves, that he was yo

to tolerate the jolt—but on what caused the ac

procedures, out-of-date drawings, inadequate supe

center director, through the mishap board, made th

“gift” and allowed the center to take steps towar

similar, possibly fatal mishaps in the future.

Safety and Mission Assurance and 712

The safety and mission assurance community has 

involved in the process of rewriting 7120.5D, 

members spending almost all their time on the 

contribution helps ensure that SMA, one of the thr

check-and-balance “milk stool” that supports pr

projects, has as well-defined a role as program m
and engineering. The new processes make clear 

safety, reliability, maintainability, and quality assu

add-ons that come toward the end of projects but 

from the beginning. 

The Columbia Accident Investigation Board co

NASA lacked the discipline needed to avoid serio

they pointed to navy submarine requirements and 

a model. 7120.5D takes a step toward the necessa

without mandating processes that are too rigid. On

we have tried to keep from getting bogged down 

detail is to look for the optimal mix of processes s

7120.5D and references to other policy and process 

Finding the sweet spot between not enough pro

much is not easy. 7120.5D alone is not going to 

perfect balance—that’s where good people come in

important step in the right direction. ●

All images courtesy of NASA Glenn Research Center

BRYAN O’CONNOR is a former Marine Corps test pilot and 

aeronautical engineer. He served at NASA as a Space Shuttle 

commander and program director and is currently serving as the 

Agency’s Chief of Safety and Mission Assurance. 
PA&E consists of five divisions: studies and analysis, 

strategic investments (which focuses on budget planning 

and programming), cost analysis, an independent program 

assessment office, and mission support that administers 

resources for PA&E. We are not an auditing organization—that 

is, our aim is not to find fault or mistakes but to offer clear, 

objective analysis that includes alternative solutions to potential 

problems. For instance, if we have doubts about a program 

having sufficient reserves of money and time to achieve a critical 

technical objective, we may identify possible responses such as 

conducting tests to demonstrate technical readiness, adding 

reserves, or accepting the identified risks.

To do their jobs effectively, PA&E staffers need 

multidisciplinary expertise. They need to see the “big picture” 

and understand areas such as economics and statistics as well 

as engineering. They regularly supplement their own technical 

knowledge with the expertise of NASA and industry engineers, 

including those working on the programs being evaluated, since 

they are the ones likely to be closest to the problems. Throughout 

the analytical process, we have to manage the tension between 

independence and collaboration. We work closely with program 

teams to understand their work and help them succeed, but we 

must simultaneously maintain enough distance to avoid the blind 

spots and optimism that often accompany deep engagement. 

Optimism is good—it is one source of NASA’s success—but 

it can lead to a failure to recognize and adequately allocate 

resources to areas of risk. Cost and schedule seem especially 

susceptible to optimistic thinking, so it is importa

to provide reality checks wherever possible. As Mi

has said, “You shouldn’t grade your own homework

Recent Examples

Some recent decisions based on PA&E’s work have 

unnecessary expense and delay. The office studied 

of whether RS-68 rocket engines could be used 

exploration mission, or whether it would be pref

Space Shuttle Main Engines. At first, technical 

skeptical about using the RS-68, but careful ana

that, given some launch vehicle modifications, it w

to provide the necessary performance. The decisio

the RS-68 will save several billion dollars over seve

PA&E also examines infrastructure needs. 

developing the James Webb Space Telescope an

Exploration Vehicle were originally planning to u

thermal vacuum chamber at Johnson Space Cent

team, working with the centers and mission 

analyzed the potential impact of common needs 

testing facility and worked to develop new pla

conflicts that could have delayed or compromised 

performance of both programs.

PA&E, 7120.5D, and New Missions

Mark Saunders, the PA&E director of the Independ

Assessment Office, has been directly involved in de

BY SCOTT PACE

NASA Administrator Michael Griffi n established the Offi ce of Program Analysis and E

(PA&E) to supply independent studies and assessments of NASA programs for the 

the Administrator. To ensure its objectivity, the offi ce has no operational line authority 

responsibility for any mission areas—it is a staff function. We don’t say “go” or “no go;” 

up with observations and options that help those who do make decisions make them on th

the best available information and “full disclosure” of alternatives.
new 7120.5D guidance on program and project management. 

The new clarity the document provides regarding the review 

process, defining and standardizing when major reviews occur 

and what must be accomplished before a project or program can 

move on to the next stage, also clarifies when and how PA&E 

will carry out its analyses and make recommendations. But 

7120.5D leaves room for the flexibility that different kinds of 

programs require. A research program shouldn’t be treated the 

same way as a flight project, for example. The aim of 7120.5D is 

mission success, not making everything fit the same template.

The projects and programs that make up NASA’s new space 

exploration mission are extremely complex and interrelated, with 

each element building on the one before and laying the foundation 

for those that follow. Choices—some of them very difficult 

choices—will have to be made with the overarching challenges 

and aims of the mission in mind, so the level of analysis needed to 

make informed decisions will be especially great. Ma

possible decisions based on the best possible inform

doubly important as NASA prepares to send human 

from the Earth for long periods of time.

New missions of exploration to the Moon, Mars

will make great demands on all involved projects a

and will undoubtedly create tensions in the ma

requirements, resources, and schedules. We need 

decisions on clear, consistent priorities. Not ever

happy with every decision, but if the supporting 

and clearly evident, I believe those decisions will 

by the NASA community, our partners, and stak

are mindful that the Columbia Accident Investig

complained that NASA has been too much a 

culture;” the limitations of that tool sometim

information needed for decisions. PowerPoint h

uses, but it is no substitute for detailed analysis that 

only what was decided but why that choice was m

job is to contribute to mission success by helpin

leadership of the Agency make better decisions thro

and thereby enhance the credibility, trust, and co

need to explore new worlds. ●

SCOTT PACE is the Associate Administrator for Program 

Analysis and Evaluation at NASA. In this capacity, he is 

responsible for providing objective studies and analyses in 

support of policy, program, and budget decisions by the NASA 

Administrator.

WE NEED TO BASE OUR DECISIONS ON 

CLEAR, CONSISTENT PRIORITIES. NOT 

EVERYONE WILL BE HAPPY WITH EVERY 

DECISION, BUT IF THE SUPPORTING LOGIC 

IS FULLY AND CLEARLY EVIDENT, I BELIEVE 

THOSE DECISIONS WILL BE RESPECTED BY 

THE NASA COMMUNITY, OUR PARTNERS, 

AND STAKEHOLDERS. 
www.nasa.gov/mission_pages/constellation/main/index.html 

The cargo launch vehicle, Ares V, lifts off.

Solid Rocket Boosters (SRB) separate from Ares V.

Earth Departure Stage (EDS) performs Earth orbit insertion.

Payload shroud separates to expose the Lunar Surface Access Module (LSAM).

The crew launch vehicle, Ares I, lifts off.

First stage separates from Ares I.

Ares I upper stage performs Earth orbit insertion.

Crew exploration vehicle, Orion, docks with LSAM and EDS; EDS fi res for lunar destination.

Orion and LSAM separate from EDS.

Orion and LSAM enter lunar orbit.

LSAM lands on the lunar surface.

Astronauts perform lunar surface activities.

LSAM ascent stage lifts off from lunar surface.

LSAM ascent stage and Orion dock for crew transfer.

Orion burns for Trans Earth Injection (TEI).

Orion and surface module separate and re-enter Earth’s atmosphere.

Orion decelerates through Earth’s atmosphere.

Parachutes open for landing and recovery.

Mission

Profi le

1

2

3

4

1.

2.

3.

4.

1a.

2a.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

ASK Magazine would like to extend special thanks to Beth Dickey from the Offi ce of Public Affairs 

and Derek Wang from the Exploration Systems Mission Directorate for their assistance.
9

10

11

13 12 16 15 14

4

5

6

7

8

12

13

14

16

15

3

9

10

11

1 1a

2 2a

All images courtesy of NASA/John Frass
When undertaking a long journey to a new place, it helps to have a road map to guide yo

new space exploration program is such a journey, one whose length, complexity, and c

make a good map especially important. The new Program and Project Management Proc

Requirements (NPR 7120.5D), which outline the policy and processes designed to ensu

success and knowledge sharing at NASA, are part of that map. Taken together, those req

and this special pullout of the Agency’s exploration architecture—a map of milestone

Constellation program—show where we are going, the important stages of the journey, and 

have to do to reach our destination. We hope this map brings into focus what we need to ac

today and tomorrow to achieve our ambitious goals. 

The mission we are beginning now will span decades. We need to defi ne, record, and com

the path we take to ensure we—those of us working today and those joining the program in th

are all working with the same vision in mind. NASA’s new policies and the exploration ar

offered here are part of this process, providing the maps we and our successors will re

refi ne as we expand human exploration in space.

Exploration Architecture
There is nothing so far removed from us to be beyond our 

reach, or so far hidden that we cannot discover it. 

RENÉ DESCARTES

We shall not cease from exploration and the end of all our 

exploring will be to arrive where we started...and know the 

place for the fi rst time.

T.S. ELIOT

It is diffi cult to say what is impossible, for the dream of 

yesterday is the hope of today and reality of tomorrow.

ROBERT GODDARD

In the long run men hit only what they aim at.

HENRY DAVID THOREAU

Where there is no vision, the people perish.

PROVERBS 29:18

The Moon is the fi rst milestone on the road to the stars.

ARTHUR C. CLARKE

The important thing is not to stop questioning.

ALBERT EINSTEIN

For I dipped into the Future, far as human eye could see; saw 

the vision of the world, and all the wonder that would be.

ALFRED, LORD TENNYSON

I had the ambition to not only go farther than man had gone 

before, but to go as far as it was possible to go.

CAPTAIN COOK

The greatest gain from space travel consists in the extension of 

our knowledge. In a hundred years this newly won knowledge 

will pay huge and unexpected dividends.

WERNHER VON BRAUN

The past is but the beginning of a beginning, and al

has been is but the twilight of the dawn.

H.G. WELLS

We are at a point in history where a proper attention 

and especially near space, may be absolutely crucia

the world together.

MARGARET MEAD

Freedom lies in being bold.

ROBERT FROST

To set foot on the soil of the asteroids, to lift by hand 

from the Moon, to observe Mars from a distance of 

tens of kilometers, to land on its satellite or even on 

what can be more fantastic?

KONSTANTIN E. TSIOLKOVSKY, FATHER OF RUSSIAN ASTRON

Destiny is not a matter of chance. It is a matter of ch

It’s not a thing to be waited for—it is a thing to be ac

WILLIAM JENNINGS BRYAN 

A sense of the unknown has always lured mankind, 

greatest of the unknowns of today is outer space. T

the joys, and the sense of accomplishment are epito

space program.

WILLIAM SHATNER

In my own view, the important achievement of Apoll

demonstration that humanity is not forever chained 

planet, and our visions go rather further than that, a

opportunities are unlimited.

NEIL ARMSTRONG
The surface of the Moon is reflected in the command 

and service module in this December 1972 image 

from the Apollo 17 mission. NASA’s Vision for Space 

Exploration will use a new spaceship that builds on 

the best of Apollo and shuttle technology. 

Low-Cost Innovation 

AND THE VISION ND THE VISION for Space Exploration

BY HOWARD E. McCURDY
The first phase of the Vision for Space Exploration—wherein 

humans and their machines return to the Moon—is no 

exception. NASA officials could dust off old blueprints and 

return to the Moon using 1960s technology. That path is well 

known. Yet any attempt to repeat the lunar landings using Apollo 

techniques would degrade one of the primary objectives of the 

return—the desire to develop technologies that eventually will 

carry humans beyond the Earth–Moon system toward Mars.

Of these potential innovations, few are more important than 

those affecting cost. When quizzed on the affordability of the 

Vision for Space Exploration during its consideration in 2003, 

NASA officials assured White House aides that a return to the 

Moon could be accomplished using Apollo-style technology for less 

than the cost of landing the first humans on the Moon in 1969. 

NASA officials pointed out that they would not need to incur 

the expense of constructing the Johnson or Kennedy space centers 

or a new tracking network. They would not need to charge the 

cost of excess equipment used for future missions against the 

first, as Apollo program managers had done. By using tested 

technologies, they could save money on the crew exploration 

vehicle, the lander, and a new launch vehicle. The total savings, 

NASA officials estimated in 2003, would amount to about half of 

the inflation-adjusted $147 billion spent to send the first humans 

to the Moon. The estimated savings have varied from study to 

study, and recently shrunk, but the underlying principle remains 

the same. Using Apollo-style technology, the United States can 

return to the Moon for a sum that fits within projected NASA 

budgets. It will not be easy, but it can be done.

Now take that analysis one step further. Suppose the 

United States, with its international partners, attempts to use 

Apollo techniques to send humans to Mars. In other words, the 

expedition uses chemical-fueled rockets, small capsule-shaped 

spacecraft, a Martian orbit rendezvous, a mission length of 

900 days, and Apollo-style project management in which every 

element of the mission and its possible interaction

checked before the first astronauts leave. The cost 

of such complexity rapidly approaches $1 trillion

United States afford to organize such an expedi

could. Is Congress likely to provide the necessary 

In short, any attempt to return to the Moon u

style techniques is likely to defeat the ultimate pu

undertaking, making the next Moon landing an 

rather than a means to a more spectacular objectiv

What can NASA officials do to resolve this 

As a first step, they can seek inspiration from the 

organized Project Apollo. When President John 

challenged Americans to race to the Moon in May 19

NASA knew how to do it. NASA engineers had not 

lunar-orbit rendezvous. Wernher von Braun’s rocket 

ANY ATTEMPT TO REPEAT THE LUN

LANDINGS USING APOLLO TECHNIQ

WOULD DEGRADE ONE OF THE PRI

OBJECTIVES OF THE RETURN—THE 

DESIRE TO DEVELOP TECHNOLOGIE

THAT EVENTUALLY WILL CARRY HU

BEYOND THE EARTH–MOON SYSTE

TOWARD MARS.

Nearly every project that NASA scientists and engineers undertake requires some 

innovation. Project managers generally employ proven technologies as a means of redu

but invariably some innovation occurs. Most engineers who work in the realm of sp

enjoy innovating and are not content to build the same system over and over again. The 

innovate is part of NASA’s organizational culture.
yet perfected the hydrogen

burning J2 engines that would propel 

the Saturn V rocket’s second stage. NASA officials had yet to 

embrace consolidated or “all-up” testing, one of the practices that 

allowed the space agency to meet its end-of-the-decade deadline. 

More significantly, few people in NASA knew how to organize 

projects as big as Apollo. NASA scientists and engineers had 

plenty of technical capability, lots of hands-on skill, and plenty 

of experience with small projects. People in the newly created 

space agency had practically no experience, however, managing 

an undertaking as interactive and complex as Project Apollo.

To resolve the management challenge, NASA Administrator 

James Webb looked outside the Agency. He turned to the U.S. 

Air Force and its supporting contractors, where people working 

on the crash program to deploy a fleet of intercontinental 

ballistic missiles (ICBMs) had spent the previous decade 

developing a technique called large-scale systems management. 

Webb recruited people like George Mueller and General Sam 

Phillips from the air force ICBM program to help reorganize 

NASA. They introduced techniques like configuration control, 

concurrent development, progressive design freezes, and systems 

integration studies to produce an agency organizationally 

capable of reaching the Moon. Historian Stephen Johnson has 

called these techniques “the secret of Apollo.” Without largescale systems management, the lunar landings would not have 

occurred—certainly not with the degree of reliability that the 

United States achieved.

So where can NASA officials turn for the next round of 

innovations, in particular for the low-cost innovations necessary 

to take humans beyond the Moon? To start, they can look within 

their own organization. This may seem like a strange suggestion 

for an agency that has struggled for thirty years to meet cost 

and schedule goals on the Space Shuttle and International 

Space Station. Yet NASA program managers have accumulated 

many years of experience with low-cost innovation, including 

experience from projects that worked (like Mars Pathfinder and 

NEAR-Shoemaker) and ones that failed (like Mars Climate 

Orbiter and CONTOUR).

The techniques used to manage a succession of “faster, 

better, cheaper” projects during the past fifteen years may not 

scale up well to projects as complicated as human expeditions to 

the Moon, but they contain valuable lessons nonetheless. One 

profound lesson is the importance of centers of integration. The 

low-cost projects that worked best possessed focus

integration in which the same team of technicall

people designed, built, and flew the spacecraft. T

used contractors to build spacecraft components, b

did not distribute their core functions. Low-cost 

got in trouble invariably did, with results like tho

Mars Climate Orbiter, with one team working w

units of measurement and another using metrics.

A preference for work packages and extensive 

characterizes NASA’s preferred approach for large-

management. It worked well for Project Apollo, acc

that was by a strong center of systems integration a

in-house technical capability. Yet the approach is ve

prohibitively so when one considers it as a method 

humans to Mars. To get to the Moon and beyond 

NEAR-Shoemaker approaches asteroid Eros in this artist’s conce

of many successful projects that helped program managers gain 

low-cost innovation.
NASA officials might consider reestablishing single centers of 

systems integration with very strong technical capabilities. It 

would be nice if those centers were inside the Agency, but they 

could be outside as well so long as they are concentrated and 

technically strong.

Next, NASA officials can look beyond the Agency to 

innovations taking place in the private sector and elsewhere in 

government. The aerospace contractors on whom NASA project 

managers have traditionally relied are not a good source in this 

regard. They exist in a business environment that provides 

few incentives for cost innovation. The reverse is true in the 

highly competitive electronics and information sectors, where 

firms face incredible pressures to innovate or perish. Backed by 

entrepreneurs from these sectors, innovators like Burt Rutan 

are seeking new and economical ways to accomplish the first 

steps in space that NASA officials took forty-five years ago. The 

management techniques and technologies they use are often 

radically different from the ones NASA pioneered.

Government leaders insist that the new vision for space 

exploration will be carried out by humans and robots exploring 

space together. Some of the most innovative work in this regard 

is taking place in the U.S. Department of Defense, especially 

the Defense Advanced Research Projects Agency (DARPA). 

The defense department is working to reengineer one-third of its 

transport vehicles so they can be driven by robots by 2015. One 

of the lessons to be gathered from this activity is the importance 

of prizes. DARPA officials have used contests such as the 132-

mile Grand Challenge for robot vehicles across the Mojave 

Desert to encourage innovation in pursuit of this goal.

Finally, NASA can learn from its international partners 

and competitors, especially Russia and China. Both nations 

conduct space programs at a fraction of the NASA enterprise 

expense. They accomplish less, but what they do produce (like 

the Soyuz launch system) costs far less than U.S. counterparts. 

The difference cannot be explained entirely by lower labor 

costs. The adoption of production line methods may account 

for a significant portion of the cost reductions achieved on the 

Russian vehicles.

When President Kennedy assigned NASA the ta

humans to the Moon in the spring of 1961, agency 

not capable of doing the job. Yet eight years late

stood on lunar soil. Through two major reorgan

frequent innovations, NASA founders transformed 

agency. Most of the transformations were painful

controversial. The desire of NASA officials to achie

outweighed their pain. The NASA that dispatched A

the surface of the Moon in the summer of 1969 litt

the organization that started the journey eight year

In a similar fashion, if NASA employees and the

succeed in returning humans to the Moon and 

them and their machine companions to Mars, the 

that completes the work will bear little resemblanc

that exists today. Innovation will occur again. The 

completes the new challenge will be as transformed 

of 1969 was relative to itself in 1961. ●

HOWARD E. McCURDY is a professor in the School of Public 

Affairs at American University in Washington, D.C., and author 

of six books on space policy, including Faster, Better, Cheaper: 

Low-Cost Innovation in the U.S. Space Program and Inside NASA, 

a study of the Agency’s changing organizational culture. He is 

currently completing a book with Roger Launius on human and 

robotic fl ight.

SO WHERE CAN NASA OFFICIALS T

FOR THE NEXT ROUND OF INNOVAT

IN PARTICULAR FOR THE LOW-COS

INNOVATIONS NECESSARY TO TAKE 

HUMANS BEYOND THE MOON? TO 

THEY CAN LOOK WITHIN THEIR OW

ORGANIZATION.
NASA’s space fl ight programs and projects are highly visible national priorities. The 

strategic plan articulates these space fl ight goals and the timetable for reaching them. Pro

project management translates the strategy into the actions needed to achieve these goals

7120.5D, which defi nes the requirements for effective program and project managem

essential contributor to the Agency’s ability to fulfi ll its mandate.
Why Revise 7120.5D?

The new revision of NPR 7120.5D is part of a realignment 

of governing documents within NASA designed to increase 

accountability and general clarity about management process 

requirements. When NASA revamped its governance model 

in 2005 in response to the long-term challenge posed by the 

Vision for Space Exploration, it became essential to bring NPR 

7120.5D into conformance with the Agency’s new direction. 

Some of the changes to the document respond to external 

reviews of NASA’s performance over recent years. For instance, 

the establishment of a technical authority and the protection 

of dissenting opinions have their roots in the findings and 

recommendations of the Columbia Accident Investigation 

Board Report. Defining and standardizing key decision points 

in the project approval process acknowledges the Government 

Accountability Office’s recommendations about best practices 

in knowledge-based acquisition. Most important, though, 

the thorough internal review process that accompanied this 

revision makes it a compendium of NASA’s nearly fifty years of 

knowledge about the most successful practices for space flight 

program and project management. 

How Does the Governance Model Affect 

Programs and Projects?

The NASA governance model describes a management 

structure that employs checks and balances between key 

organizations to ensure that decisions have the benefit of 

different points of view and are not made in isolation. NASA 

has adopted two basic authority processes: the programmatic 

authority process and the technical authority process. The 

programmatic authority process is largely described by the 

roles and responsibilities of the NASA Associate Administrator, 

Mission Directorate Associate Administrators, and program 

and project managers.

The technical authority process provides for the selection 

of individuals at different levels of responsibility who offer 

independent views of matters within their areas of expertise. 

The term “Technical Authority” refers to such an individual, 

but it is also used (without capitalization) to 

elements of the technical authority process taken 

key aspect of the technical authority process is th

Authorities (TA) are funded independently of pr

projects. Their responsibilities include approving 

and waivers of, all TA-owned requirements; an

members of program/project control boards, cha

and internal review boards. The technical autho

ensures that the golden rule of the governance mod

don’t check their own work—has sound imp

through processes and procedures. 

What Is Different This Time?

Beyond supporting the new governance mod

7120.5D accomplishes a number of “firsts.” For t

in NASA’s history, the program/project life-cycle a

reviews that occur across the Agency have been i

both human and robotic missions. There is also no

set of terms, so a critical design review (CDR) me

thing at one center as it does at another. 

This does not mean that the milestones for 

robotic missions are now identical in every phase a

cycle; manned missions will still have Mission M

Team meetings, for instance, while robotic missi

But the missions are standardized and synchron

greatest extent possible. This will offer myriad 

NASA. Common procedures and terminology a

will increase our efficiency and reduce the risk o

to misunderstandings. They will also lay the gro

tightly integrated robotic and human missions on 

Mars, or the International Space Station in the fut

Program and project reviews are essential fo

conducting, managing, and evaluating space flig

and projects. In preparation for these reviews, p

projects conduct internal reviews to establish 

the program/project baseline. These internal rev

decisional meetings where the programs/projects 

plans, technical approaches, and programmatic co
life cycle, so every requirement includes answers to the questions 

“who,” “what,” and “when,” defining roles and responsibilities 

along with their places in the life cycle. NPR 7120.5D defines 

two types of requirements—programmatic requirements and 

management process requirements—that apply to programs 

and projects. Programmatic requirements focus on the space 

flight products to be developed and delivered and specifically 

relate to the goals and objectives of a particular NASA program 

or project. These requirements flow down from the Agency’s 

strategic planning process. Management process requirements 

focus on how NASA does business and are independent of any 

particular program or project. 

How Do Projects Get Approval?

The new 7120.5D introduces two new concepts: key decision 

points, when approval is given to proceed to the next life-cycle 

phase, and the Decision Authority, the responsible official who 

provides that approval. 

The key decision point (KDP) is defined as the event where 

the Decision Authority makes a decision on the readines of the 

program/project to progress to the next phase of the life cycle. 

KDPs serve as gates through which programs and projects 

must pass. Within each phase, the KDP is preceded by one or 

more reviews, including the governing Program Management 

Council review. For programs and Category I projects, 

the Associate Administrator is the Decision Authority. For 

Category I projects, this authority can be delegated to the Mission 

Directorate Associate Administrator. For Category II and III 

projects, the Mission Directorate Associate Administrator is 

the Decision Authority. Category assignments are based on a 

project’s life-cycle cost estimate and their priority level.

How Are Dissenting Opinions Protected?

NASA teams must have full and open discussions based on 

all relevant facts in order to understand and assess issues. 

In keeping with NASA’s core values of teamwork and 

integrity, diverse views are to be fostered and respected in an 

environment of integrity and trust with no suppression or 

retribution. Unresolved issues of any nature—programmatic, 

safety, engineering, acquisition, or accounting—should be 

quickly elevated to achieve resolution at the appropriate level. 

At the discretion of the dissenting person(s), a dissenting view 

How Is Compliance Ensured?

Center management holds the primary respo

ensuring programs/projects comply with NASA 

documents such as 7120.5D. Each center does this 

and documenting its institutional engineering, pro

management, and safety and mission assurance st

practices. At a minimum, each Center Director i

for preparing and executing a center implementatio

• Project management standards and practices

• Engineering standards and practices

• Safety and mission assurance standards and 

• Technical authority standards and practices

• Traceability and conformance of center st

practices to NASA policies and procedures

• The system used to verify that these standards 

are employed by programs and projects at the 

How Does This Fit Within the Big Pictu

The intent of all these changes is to clarify lines 

to streamline processes and procedures across the 

ultimately to give NASA the program and project 

structure it needs to implement the Vision for Space 

Given the thoroughness of the review process that a

this revision, the team has done its best to devise 

that helps program and project teams do their jobs

adding levels of unworkable bureaucratic interferen

test of its effectiveness lies ahead. ●

MIKE BLYTHE serves as the Program Executive for Program and 

Project Management in the Offi ce of the Chief Engineer. Prior to 

coming to NASA Headquarters, he was deputy project manager for 

the CALIPSO project at the Langley Research Center.
Intro

Part of the reason there’s so much disagreement about the 

definition of systems engineering is because of the difficulty of 

measuring its value. If you’re a structural engineer or a thermal 

engineer, success is easy to measure: the system sustains all the 

loads and performs as predicted or the spacecraft reenters the 

atmosphere with no problems. In systems engineering, if you 

use a good, consistent approach, you reduce the system risk and 

rework. It’s difficult to calculate the resources you save by doing 

things right the first time. 

A common misconception about systems engineering 

is that it is an “up-front” activity that takes place only in the 

requirements definition phase of a program or project life 

cycle. That view doesn’t properly account for the complexity 

of engineering and integrating systems. As systems are added 

and modified over the course of development, the number 

and complexity of interfaces increases in a nonlinear fashion. 

Problems resulting from conflicting or missing interfaces are 

the norm, not the exception. The only way to deal with this 

type of dynamic environment is by adopting an end-to-end, 

logical systems approach that emphasizes robust modeling and 

simulation, verification, and validation testing. These rigorous 

systems processes must be repeated throughout the life cycle of 

a system to detect unexpected consequences that can flow from 

even small design changes. 

Given the complexity of the systems that N

designing for the Vision for Space Exploration, it’s 

we have a shared understanding and a common la

will enable us to do our jobs effectively across or

lines. To address this need, the Office of the Chief 

undertaken an overall systems engineering excellen

Its objective is not to define what a systems engineer 

it is to transform systems engineering from a tas

by individuals to a logical systems approach p

multidisciplinary teams. 

A systems perspective does not just belong t

who wears the “systems engineer” badge. Even 

might be a thermal engineer, you need to und

requirements that are allocated from the system ab

down to the subsystem below your system. You n

what your margins are and how you fit into the ov

That way, when you conduct trade studies or select 

understand how your system operates within a b

Educating just systems engineers is insufficient. 

whole is adopting a systems approach. 

This multidimensional problem calls for a mult

approach. The Office of the Chief Engine

engineering excellence initiative has three dimensio

technical processes, tools and methods, and workf

Winston Churchill once famously remarked that the United States and Britain are two great 

separated by a common language. That’s a useful metaphor for thinking about the dis

systems engineering. If you ask any two systems engineers to defi ne the job, chances are t

get two very different answers. 
and development. By integrating processes, tools, and training, 

this approach aims to create an engineering culture in which 

continuous improvement is the norm. 

NPR 7123.1 is the result of an extensive, iterative effort to 

define the common technical processes of systems engineering. 

The team that developed the document represented all 

NASA Centers and mission directorates. Before the writing 

began, the 7123.1 team held a series of workshops with both 

NASA stakeholders and external experts, including officials 

from government agencies, private industry, and professional 

organizations. Their perspectives helped us survey the state 

of systems engineering both within and outside NASA and 

identify common practices. Most importantly, though, the 

workshops made clear that promoting a systems approach across 

all engineering disciplines will require a change in culture that 

won’t happen overnight. It will take time, persistence, and 

support from senior management. 

The document itself describes at a relatively high level 

what to do, not how to do it. The challenge in developing it 

was to target the right level of detail—neither too detailed 

nor too general—and create something that adds value. There 

are important differences in the types of projects that NASA 

conducts. Within that range, the NPR defines a standard 

design review approach that conforms to the common lifecycle definition spelled out for programs and proj

7120.5D, and it lays out a systems engineering pro

be applied to any system, regardless of scope or sca

Once the team completed a draft, we ran it t

tabletop simulations involving the Constellatio

satellites, ground systems, and research projects. Th

led to significant changes that made it more practi

oriented. It’s no secret that if the document doesn’

do their jobs, it’s going to be shelfware.

In short, NPR 7123.1 is part of a larger initiati

and implement a common systems engineering f

NASA. The missions and systems ahead demand a r

advancement in our capability. The only way 

is through a continuous improvement process 

understood, consistently applied, and flexible eno

the diverse needs of our programs and projects. ●

STEPHEN J. KAPURCH is currently assigned to the Offi ce 

of the Chief Engineer at NASA Headquarters. In this position 

he directs the Engineering Excellence Initiative to assess and 

improve NASA systems engineering processes and the Advanced 

Engineering Environments Program.

THE CHALLENGE IN DEVELOPING IT WAS TO TARGET THE RIGHT LE

OF DETAIL—NEITHER TOO DETAILED NOR TOO GENERAL—AND CRE

SOMETHING THAT ADDS VALUE.
Intro

In the past, Agency-wide requirements documents for program and project manag

NASA have typically been shaped by contributions and advice from the fi eld centers, th

directorates, and people who have been involved in past programs. 7120.5D represen

approach because the team that developed it also received real-time input from a program 

being formulated—Constellation, NASA’s largest new program. The Constellation pro

the Exploration Systems Mission Directorate (ESMD) have collaborated with the 7120.5D 

develop realistic, workable processes and procedures early in the game. This provided an i

reality check for the document’s usability and created a sense of ownership of this critic

document within the program, which represents the direction of human space fl ight at th

for the foreseeable future. Everybody involved wanted to take advantage of this opportun

the processes right the fi rst time. NASA’s future accomplishments will depend on it.

EXPLORATION 

SYSTEMS MISSION 

DIRECTORATE AND 7120.

ENABLING EXPLORATION

 BY GARRY LYLES
As the 7120.5D team worked on the policies and requirements 

spelled out in that document, the Constellation team developed 

requirements for its program. At the request of the Constellation 

program manager, the Office of the Chief Engineer established 

a technical requirements team to help determine processes to 

apply to the new governance model established by NASA Policy 

Directive 1000.0. This team would also provide information to 

the 7120.5D team that would allow them to properly document 

these processes, which define the working relationship between 

the program and projects and the technical authority as well as the 

role of the technical authority within the program’s management 

structure. Processes for managing selections, changes, and 

waivers to institutional engineering requirements (specs and 

standards) as well as dissenting opinions between the program 

and the technical authorities were established. These processes

were tested in the real 

program environment as 

Constellation developed 

its requirements. For 

example, this testing 

within the Constellation 

program helped establish the method for effectivel

technical authorities into a program’s requirements d

configuration management, and control processes. T

contributed to the scope and definition of the Stan

Board to provide oversight at each critical review to 

decision points throughout the program life cycle. 

for handling dissenting opinions was also establishe

documented within 7120.5D. 

Since NASA has never had a requirements d

systems engineering in the past, Constellation 

from the requirements and common definitions 

NPR 7123.1. The same good systems engineeri

are applicable to small science missions and large h

flight programs like Constellation. The 

processes defined by 7123.1 will give

systems engineering a structure for 

formulating, designing, verifying,

and operating a whole range of

Constellation system elements that 

must work together to successfully 

accomplish a mission. For the lunar 

Test engineer Alonzo Frost prepares 

a Constellation program crew launch 

vehicle model for testing in the Marshall 

Space Flight Center Aerodynamics Research 

Facility. Constellation played an important role 

Photo Credit: NASA Marshall Space 

Flight Center/D. Higginbotham

in testing NASA’s new NPR 7120.5D policy.
exploration mission, for instance, the Orion crew exploration 

vehicle system will function in cooperation with the Ares I 

crew launch vehicle, the lunar surface access module (LSAM), 

and the extra-vehicular activity systems. The LSAM, in turn, 

will function integrally with the lunar surface habitation and 

surface mobility systems. There are a tremendous number of 

systems that will be developed to perform the complex mission 

of establishing a lunar outpost. Successfully managing the 

complex interactions within and between Constellation systems 

demands clear, consistent, effective systems engineering across 

the board. Under these new NASA procedural requirements, 

systems engineering will function as a clearly defined process 

designed to manage and simplify the complexity inherent 

in the Constellation program while allowing for the unique 

characteristics of robotic and human missions.

An important aspect of both 7120.5D and the newly 

formulated systems engineering processes and requirements of 

7123.1 is their blending of best practices for robotic and human 

space flight missions. These documents bring together the 

experience and knowledge of the entire Agency in a form that 

establishes guidelines and sets boundaries for future programs 

and projects and will increase the probability of successful space 

flight missions. These boundaries will help program and project 

managers and systems engineers avoid the pitfalls of the past. 

Based on the real-world lessons taught by extensive experience, 

the new requirements for program/project management and 

systems engineering represent the best guidance the Agency can 

give its programs.

The Constellation program is tasked with nothing 

less than translating the Vision for Space Exploration 

into real accomplishments that will expand the bounds of 

human endeavor, developing the transportation systems, 

infrastructures, and power and communication systems for 

human and robotic missions. The challenges of achieving 

the goals of returning humans to the Moon, establishing a 

permanent presence there, and then preparing for human 

exploration of Mars and beyond are complex and beyond 

anything ever attempted in human history. NPR 7120.5D 

and NPR 7123.1 provide the glue that brings 

experience and capabilities of all ten NASA Cen

in one integrated set of system design, develo

and operation activities that will enable humans

collaboration with robotic systems, to explore an

scientific knowledge of the solar system. ●

UNDER THESE NEW NASA PROCED

REQUIREMENTS, SYSTEMS ENGINE

WILL FUNCTION AS A CLEARLY DEF

PROCESS DESIGNED TO MANAGE A

SIMPLIFY THE COMPLEXITY INHERE

IN THE CONSTELLATION PROGRAM 

WHILE ALLOWING FOR THE UNIQUE 

CHARACTERISTICS OF ROBOTIC AN

HUMAN MISSIONS.

GARRY LYLES is currently the Exploration Systems Mission 

Directorate (ESMD) chief engineer. His responsibilities include 

broad technical cognizance, insight, and oversight of all ESMD 

programs and responsibility to establish, approve, and maintain 

technical requirements, processes, and policy. ESMD is responsible 

for directing the design and development of new capabilities 

necessary to achieve the nation’s new exploration vision—human 

and robotic missions to the Moon, Mars, and beyond.
Intro

Engineers inspect and test a boilerplate Mercury space capsule. Project Mercury spanned five years and achieved the goal of orbiting Earth in a man

Former NASA Administrator T. Keith Glennan remarked about Mercury that he had been associated with “one of the best organized and managed” p

 APOLLO 

EXPERIENCE

 BY ROGER D. LAUNIUS

Managing NASA’s Complex Space Flight Programs: 

THE 
Initially, NASA applied principles of management learned 

during nearly fifty years of experience in the National Advisory 

Committee for Aeronautics (NACA), whose members made 

up the majority of NASA in its first years. This government 

institution, with its three research centers and single flight test 

facility, had a breadth of experience undertaking aeronautical 

research, but by far its largest management effort to date had 

been the X-15 hypersonic flight research project begun in the 

latter 1950s. 

Its approach to the X-15 as well as to its other programs 

had been to empower an authoritative project manager to 

oversee all aspects of the effort and to rely on that individual to 

organize resources as deemed appropriate, to acquire personnel 

seen as necessary to the project, and to bring it to successful 

operational status. In the case of flight research projects, 

this involved building the research vehicle and conducting 

a measured program of research and technical publication 

preparation. The method worked well for the relatively modest 

projects of NACA.

The newly established NASA followed basically the same 

approach in 1958 during its first human space project, Mercury, 

placing it under the direction of Robert Gilruth’s Space Task 

Group at the Langley Research Center and giving Gilruth 

virtually total control to ensure its success. This proved a difficult 

but “doable” task, as Gilruth had to structure the project to 

involve other teams at different NASA Centers, something not 

common in the NACA experience. 

Just six days after NASA was established on October 1, 

1958, Administrator T. Keith Glennan approved plans for 

Mercury. On October 8 he gave Gilruth authority to proceed. 

Thirty-five key staff members from Langley, some of whom had 

been working on the military human space flight plan, were 

transferred to the new Space Task Group, as were ten others 

from the Lewis Research Center near Cleveland, Ohio. These 

forty-five engineers formed the nucleus of the more than 1,000-

person workforce that eventually took part in Project Mercury. 

As Glennan wrote in his diary, “The philosophy o

was to use known technologies, extending the sta

as little as necessary, and relying on the unproven A

looks back, it is clear that we did not know much 

we were doing. Yet the Mercury program was on

organized and managed of any I have been associa

Such a small program, imbued with outstandin

from Robert Gilruth and staffed by a dedicat

engineers, succeeded well. But its relatively u

approach would not do for the massive Apollo p

took Americans to the Moon in the 1960s and 19

NASA borrowed the program management concep

Department of Defense in building the first inte

ballistic missiles (ICBM). To accomplish its goal

to meld disparate institutional cultures and app

an inclusive organization moving along a single, u

Each NASA installation, university, contractor, 

facility had its own perspective on how to go abou

accomplishing Apollo. 

The central figure in implementing this m

approach was U.S. Air Force Major General Samue

the architect of the Minuteman ICBM program be

to NASA in 1962. Answering directly to the Offic

Space Flight at NASA Headquarters, which in t

to the NASA Administrator, Phillips created an 

program office with centralized authority o

engineering, procurement, testing, construction, ma

spare parts, logistics, training, and operations.

One of the fundamental tenets of the program 

concept was that three critical factors—cost, sc

reliability—were interrelated and had to be manag

Many recognized that if program managers he

instance, to a specific level, then one of the other tw

both of them to a somewhat lesser degree, would 

affected. This held true for the Apollo program. T

dictated by the president, was firm. Since humans w

aog ateested ageces ote Uted States odeto avod uecessay dup

effort, facilities, and equipment.” Congress did not, however, tell NASA how to accomp

diffi cult tasks. The Agency has been working ever since to develop approaches to man

that achieve those objectives. 
in the flights, and since the president had directed that the 

lunar landing be conducted safely, the program managers 

placed a heavy emphasis on reliability. Accordingly, Apollo 

used redundant systems extensively so failures would be both 

predictable and limited in their effects. The significance of both 

of these factors forced the third factor, cost, much higher than 

might have been the case with a more leisurely lunar program 

such as had been conceptualized in the latter 1950s. As it was, 

this was the price paid for success under the Kennedy mandate, 

and program managers made conscious decisions based on 

knowledge of these factors.

The program management concept was recognized as 

a critical component of Project Apollo’s success in November 

1968, when Science magazine, the publication of the American 

Association for the Advancement of Science, observed the 

following:

 In terms of numbers of dollars or of men, N

been our largest national undertaking, but 

complexity, rate of growth, and technological s

it has been unique. ... It may turn out tha

program’s] most valuable spin-off of all wil

rather than technological: better knowledge of 

coordinate, and monitor the multitudinous 

activities of the organizations required to acco

social undertakings.

Understanding the management of complex struc

successful completion of a multifarious task was a

outgrowth of the Apollo effort.

Under Phillips, this management concept orche

than 500 contractors working on both large and sm

Apollo. For example, the prime contracts awarded 

Neil Armstrong sits in the X-15’s cockpit in this 1960 photo. The X-15 hypersonic research project was one of NASA’s largest management efforts.
The Apollo 11 Command/Service Module is mated to the Saturn V Lunar Module Adapter. NASA borrowed the program management concept us

Department of Defense to establish a strong management model for Apollo. 
for the principal components of just the Saturn V included the 

Boeing Company for the S-IC, first stage; North American 

Aviation, S-II, second stage; the Douglas Aircraft Corporation, 

S-IVB, third stage; the Rocketdyne Division of North American 

Aviation, J-2 and F-1 engines; and International Business 

Machines (IBM), Saturn instruments. These prime contractors, 

with more than 250 subcontractors, provided millions of 

parts and components for use in the Saturn launch vehicle, all 

meeting exacting specifications for performance and reliability. 

The total cost expended on development of the Saturn launch 

vehicle was massive, amounting to $9.3 billion. So huge was the 

overall Apollo endeavor that NASA’s procurement actions rose 

from roughly 44,000 in 1960 to almost 300,000 by 1965.

Getting all the personnel elements to work together 

challenged the program managers, regardless of whether or not 

they were civil service, industry, or university personnel. Various 

communities within NASA differed over priorities and competed 

for resources. The two most clearly identifiable groups were the 

engineers and the scientists. As ideal types, engineers usually 

worked in teams to build hardware that could carry out the 

missions necessary for a successful Moon landing by the end of 

the decade. Their primary goal involved building vehicles that 

would function reliably within the fiscal resources allocated to 

Apollo. Again as ideal types, space scientists engaged in pure 

research and were more concerned with designing experiments 

that would expand scientific knowledge about the Moon. They 

also tended to be individualists, unaccustomed to regimentation 

and unwilling to concede gladly the direction of projects to 

outside entities. The two groups contended with each other over 

a great variety of issues associated with Apollo. For instance, the 

scientists disliked having to configure payloads so they could 

meet time, money, or launch vehicle constraints. The engineers, 

for their part, resented changes to scientific packages added after 

project definition because these threw their hardware efforts off 

kilter. Both had valid complaints. They had to maintain an 

uneasy cooperation to accomplish Project Apollo.

The scientific and engineering commun

NASA were not themselves monolithic, and 

among them thrived. Add various other groups 

industry, universities, and research facilities, and t

widespread competition among parties at all leve

further their own scientific and technical aims. 

leadership generally viewed this pluralism as a p

within the space program, for it ensured that al

their views and encouraged the honing of positio

edge. Competition, most people concluded, mad

precise and viable space exploration effort. There w

and losers in this strife, however, and sometimes 

harbored for years. Moreover, if the conflict beca

and spilled into areas where it was misunderstood

devastating to the conduct of the lunar program

of the Apollo program worked hard to keep t

balanced and to promote order so NASA could 

the presidential directive.

Another important management issue aros

Agency’s inherited culture of in-house research. 

the magnitude of Project Apollo and its time sch

of the nitty-gritty work had to be done outsid

contractors. As a result, with a few important excep

scientists and engineers did not build flight hardw

operate missions. Rather, they planned the progra

guidelines for execution, competed contracts, and o

accomplished elsewhere. This grated on those NAS

oriented toward research and prompted disagreeme

to carry out the lunar-landing goal. Of course, the

for complaint beyond the simplistic argument of w

“dirty-handed” engineers; they had to have enou

expertise to ensure program accomplishment. If 

engineers did not have a professional competence 

the individuals actually doing the work, how could 

the contractors creating the hardware and per

experiments necessary to meet the rigors of the mis
One anecdote illustrates this point. The Saturn second stage 

was built by North American Aviation at its plant at Seal Beach, 

California, shipped to NASA’s Marshall Space Flight Center in 

Huntsville, Alabama, and there tested to ensure it met contract 

specifications. Problems developed on this piece of the Saturn 

effort and Wernher von Braun began intensive investigations. 

Essentially his engineers completely disassembled and examined 

every part of every stage delivered by North American to ensure 

it had no defects. This was an enormously expensive and timeconsuming process. The stage’s production schedule ground 

almost to a standstill, jeopardizing the presidential timetable.

When this happened, then–NASA Administrator James 

E. Webb told von Braun to desist, adding, “We’ve got to trust 

American industry.” The showdown came at a meeting where the 

Marshall rocket team was asked to explain its extreme measures 

to Webb. While doing so, one of the engineers produced a rag 

and told Webb that “this is what we find in this stuff.” The 

contractors, the Marshall engineers believed, required extensive 

oversight to ensure they produced the highest-quality work. 

A compromise emerged that was called the 10 percent rule: 

10 percent of all funding for NASA was to be spent to ensure inhouse expertise and in the process check contractor reliability.

The project management of the Apollo program involved 

these major features:

• A well-staffed headquarters group with strong systems 

engineering and integration capabilities

• Strong field centers using extensive in-house technical 

capability

• Independent contractors relied upon to do their work 

effectively

• Extensive checks and balances, inspections, safety reviews, 

systems engineering, and configuration management

• Recruitment of exceptional engineers and scientists, 

allowing them wide latitude in taking initiative and 

responsibility

• Hands-on engineering at all levels

• Extensive research and testing of component

systems

• Practices that encouraged constant learning 

creating new challenges on each flight and le

through failure)

NASA added to that an aggressive program-pla

that ensured clear objectives, well-defined lines o

accountability, and consistent and objective man

also necessitated complex systems integration 

orderly, clear, reliable, and consistent oversight, c

control, decision making in a timely and effective 

omnipresent communication and accountability.

The program management concept worked we

enormously expensive. NASA officials realized at th

of the Apollo program that they would never ag

resources that had been made available for the Mo

and they had to find another means of accomp

projects without such a broad effort. Perhaps mos

the experience of Apollo suggested that this approac

and could easily become flawed if its managers faile

practices strictly. In the face of conflicting or

demands, the practices so successful in Apollo 

to disappear. Maintaining such practices requi

vigilance and adjustment. ●

ROGER D. LAUNIUS is chair of the Division of Space History at 

the Smithsonian Institution’s National Air and Space Museum in 

Washington, D.C. Between 1990 and 2002 he served as chief 

historian of NASA.
FOR THE MOO

MARS, AND BEYON

BY 

PROFESSIONA

DEVELOPMEN
Our current focus is similarly driven by the challenges of the day. 

To ensure that NASA’s technical workforce has the capability 

to execute the missions that will comprise the Vision for Space 

Exploration, Administrator Michael Griffin and Chief Engineer 

Chris Scolese directed us to do for systems engineering what 

we have done over fifteen years to build program and project 

management capability at NASA. We merged the Academy of 

Program/Project Leadership (APPL) with NASA Engineering 

Training (NET) to create APPEL, and over the past year we 

have conducted an intensive requirements-driven process to 

address systems engineering development. 

This is the most dynamic time at the Agency since I 

arrived in 1982. The portfolio of human and robotic missions 

required to implement the vision is on a scale that has never 

before been attempted. These missions will span more than 

a single generation, so our strategic planning for professional 

development has to include developing multigenerational 

capability. Given the complexity of the missions ahead, 

it’s essential for NASA to provide its workforce with the 

professional development opportunities it needs t

Budgets are already tight, and there’s skepti

NASA about the real cost of these missions. As a re

afford to be anything less than optimally efficient

error approach won’t suffice. For its part, APPEL h

efforts on developing the technical excellence of th

on three levels: individuals, project or engineering 

the institution as a whole. 

At the individual level, APPEL offers a

integrated core curriculum that addresses prog

management and systems engineering at all stage

entry-level, mid-career, and executive. Teachin

about electrical engineering or propulsion sys

APPEL’s job. Members of our technical commun

NASA with a great deal of education and often w

professional training, and APPEL is not a su

either. Rather, we address a unique need by delive

specific knowledge to our practitioners. For e

course for new hires, “Foundations in Aerospace 

APPEL has developed a conceptual framework for building 

project team capacity that focuses on four essential elements 

of success: teamwork, leadership, process utilization, and 

knowledge. APPEL addresses these elements through a variety 

of approaches, from coaching to coursework to online learning. 

While the new NPR 7120.5D clearly concerns process, it 

also represents a compendium of NASA knowledge about the 

practices for space fl ight program/project management that are 

most likely to result in mission success. It strives to facilitate 

better leadership by clearly delineating roles and responsibilities 

across the project life cycle and to foster teamwork—one of 

NASA’s core values—by establishing an open environment in 

which all opinions are heard and respected. To varying degrees, 

it touches all the bases that enable team success.

Most of us, and perhaps most particularly NASA 

project managers, live in habitual “time starvation.” It 

is never enough time to deal with the urgent matte

much less educate ourselves on the content of do

7120.5D. Yet, if program/project team members fail t

and then implement the policies and processes co

document, they may place their endeavors in peril.

To address this dilemma, we built a quick-resp

learning tool (available at http://teambuilding

com/public). Our team converted the most impor

information into about 190 question-and-answer 

with each question requiring about thirty seco

minutes is an acceptable amount of time to ded

important subject.

Making Sure People Know What They Need to Kno
The Q&A set for 7120.5D has three components. The fi rst 

dozen questions address the salient parts of NPD 1000.0, the 

NASA Strategic Governance and Management Handbook. The 

next hundred address core concepts from parts 1, 2, and 3 of 

7120.5D. The last eighty or so address part 4, which covers the 

program/project life cycle.

The tool has no evaluative scoring. At the start, all Q&As are 

displayed in a bucket labeled “These Remain.” The tool moves 

correctly answered Q&As into “I Know These.” Incorrect answers 

move into “Still Need to Learn These.” When “These Remain” is 

empty, the tool resets by moving all the “Still Need to Learn These” 

into “These Remain,” and the process continues. All answer 

screens show the correct answer, so anyone with persistence 

can complete the learning process.

Team leads or management selects participants. The system 

automatically issues status reports indicating whether individuals 

have started and how far along they are. (Individuals can also 

voluntarily take the assessment.) The system does not routinely 

generate reports for management other than the t

its primary purpose is education, not evaluation. It c

mine the data if needed. 

Every answer page offers an opportunity to co

a box to check if people want to remain anonymo

anticipated that there might be Q&As that peop

incorrect or annoying. Rather than force them to giv

answer, there is a radio button choice labeled “Flaw

I’ll comment instead of answering.” They must ente

comment box, and the question is removed from th

We have tested the system with several groups

consistently reported that they enjoyed taking the 

The online 7120.5D knowledge tool is Web-based, 

and easy to use, all of which make it an approp

reach a vast workforce of civil servants and contr

geographically dispersed centers. It is a key par

effort to support the rollout of 7120.5D and, in do

project team capacity for NASA. ●

systemlevel leaders. Our executivelevel course is designed 

to give emerging senior leaders realistic simulations of toplevel issues such as launch decisions. We also offer in-depth 

courses tailored for specific needs in areas such as risk 

management, requirements development, system architecture, 

verification and validation, program control, and project 

planning and scheduling. 

For project or engineering teams, APPEL offers support 

at any phase of the project life cycle. Team members begin 

by completing an online assessment that takes no more than 

ten minutes to fill out. The team then typically has a threeday workshop, followed by one-on-one coaching sessions 

for individuals who request them. Expert practitioners with 

decades of experience in every discipline within NASA are also 

available for consultations on subjects ranging from instrument 

development to cost estimation. Follow-up assessments after 

workshops, coaching, and consultations show that these services 

produce measurable team improvements. 

On an institutional level, APPEL seeks to build, 

maintain, and share knowledge that will be critical for this 

Masters Forums, and through ASK Magazine a

OCE e-newsletter.

 The challenge of establishing a permanent lu

sending humans to Mars and beyond is daunting, 

Wernher von Braun said, “I have learned to 

use the word ‘impossible’ with the 

greatest caution.” Our success 

in accomplishing these 

objectives will depend 

on many things, 

ranging from sound 

financial management 

to sustained political 

support, but without 

technical excellence the rest 

is irrelevant. Through our efforts 

to develop individuals, project teams, and 

our institutional knowledge base, APPEL is commi

to helping NASA develop the technical excellence 

make the vision a reality. ●
Intro

The primary factor in project success is the quality of program and project man

Quality begins with excellent human resources, but effective processes are also critic

NASA’s founding in 1958, the Agency has undertaken various efforts to develop, main

improve program and project management policies and processes to help ensure projec

These efforts can be grouped in four eras: an aggressive initial development in the A

maintenance-level actions during the post-Apollo era of the 1970s and 1980s; a proacti

of reformulation in the faster, better, cheaper era of the 1990s; and the current era, whi

with a recognition of the limitations of faster, better, cheaper and is establishing process

achieve the Vision for Space Exploration. 

This color mosaic of Viking Orbiter 1 and 2 images shows Candor Chasma, part of the Valles Marineris system on Mars.
The Apollo Era: 1958–1969

NASA’s first formal system of program/project management 

was introduced in three stages between 1960 and 1968 in 

response to the need for standards and discipline in managing 

the complex, expensive, and ambitious programs of the Apollo 

era. The first stage saw the introduction of the Program 

Management System (PMS) in 1960. Basically a reporting 

system, the PMS was NASA’s first disciplined system to address 

program management.

The second stage came in 1961, with the development of 

the Project Planning and Implementation System (PPIS). This 

primarily added authorization to the existing PMS and was 

created partly in response to external reports recommending 

that procurement be strengthened and project management be 

tightened. The PPIS also created policies and processes for agencylevel approval and for project planning and implementation. 

The system was modified several times to include the Program 

Evaluation and Review Technique (PERT) and the Program 

Approval Document (PAD), along with changes to simplify 

the system and to integrate time and cost, a major step in 

establishing a total project management system.

The third stage was marked by the introduction of Phased 

Project Planning (PPP) in 1965. Previously informal practices 

were formalized via a NASA Policy Directive (NPD) as one of 

several responses to significant 1964 problems: major delays in 

Apollo and the fourth consecutive Ranger failure. The formal 

guidelines were intended to make practice more uniform and to 

give management an additional intervention point in the project 

life cycle. The PPP policy was not fully established until 1968, 

the year of Administrator James E. Webb’s departure, through 

a revision to the NPD and issuance of a handbook. This policy 

has been attributed to Webb’s determination to regain control 

of the Agency, which he believed he had lost sometime before 

the Apollo 1 fire of 1967. 

The success of the effort to develop these policies and 

processes can be primarily attributed to Webb’s strong focus 

on agency organization and program management and his 

determination to establish a disciplined program management 

system. Most of the program/project management staff from 

that era I have spoken with feel that discipline in 

policy and processes was maintained, and program 

managers were very much in charge of their respect

and projects. By the end of the era, mission succe

performance) had improved.

The Post-Apollo Era: 1970–1991

The policies and processes of the Apollo era unde

revisions in 1972 and again in 1977, but significant 

did not occur until Congressional concerns aros

1970s over both Space Shuttle program managem

cost and schedule performance of robotic flight pr

concerns resulted in three studies: the 1979 Shu

Management Assessment, the 1980 NASA Col

Project Management, and the 1981 NASA Project M

Study of robotics missions. Collectively, these st

problems in almost every area of program/project m

and the latter two indicated needs for policy revisio

The 1979 Shuttle Program Management 

performed in response to cost increases and sch

found budgeting, management, and personnel prob

findings included clear violations of good pro

management practice. However, follow-up wa

limited to strengthening the program budgeting st

The 1980 Colloquium on Project Managem

to prepare for restarting the Program Managem

Experience Program (PMSEP), the first agencywi

project management training program. The colloquiu

a number of problems, but some of its recommen

not implemented until thirteen years later. 

The 1981 Project Management Study, 

referred to as the “Hearth Study,” would come t

within NASA as a landmark. It was undertaken in 

Congressional requests resulting from concerns ab

schedule performance problems. It was the first 

study of program/project management by the Age

the first study of the topic by an agencywide NA

the direction of NASA Administrator Robert Fro

Research Center Director Donald P. Hearth led 
studied thirteen robotic projects, including projects such as 

Viking and Voyager, undertaken over a twenty-two-year period. 

Hearth was chosen at least in part to minimize the potential for 

center bias; Langley did not have any space flight projects in 

development at the time. 

The study found significant problems, including inadequate 

project definition, overoptimism during advocacy, and low 

contractor bids. However, it also found NASA performance 

was good overall, that cost growth may have increased but the 

evidence was inconclusive, that agency inability 

project cost was not a problem when a project was 

and that no new management tools or layers were 

particular note, the team stressed the importance of 

continuous top management verification of the 

of sound management principles, and the use 

management tools.

The study made nine recommendations, one o

to “reexamine, revise, and reissue” the NASA M

Instruction (NMI) that covered program/project 

policy. Although the initial policy update was ready 

the NMI revision was not issued until 1985—fo

two months after the study had been completed—

follow-up by senior management. The revision wa

only after Hearth himself took it on as a short-

assignment immediately prior to his retirement. 

After the Hearth Study, no significant activity 

formal project and program management process

the 1986 Challenger accident. The loss of Challenger 

studies: a 1986 study of NASA organization and m

a 1988 study of NASA Headquarters, and a 19

program control. They were sponsored by Admi

James Fletcher, who was brought in following the 

were performed under the auspices of the National 

Public Administration and led by former NASA H

executives who had played key program/project 

roles while at the Agency. Many recommendations a

these studies, including improving discipline and re

of the program/project management system, but fol

was generally poor. A notable exception was the e

of a formal program and project management train

which continues to function today. 

The Faster, Better, Cheaper Era: 1992–

In the early 1990s, cost overruns and schedule slips

forgiven in the Cold War era if mission performance 

This picture of Neptune was produced from the last whole planet images taken 

through the green and orange filters on the Voyager 2 narrow angle camera. 

Photo Credit: NASA
were met, became unacceptable. Daniel Goldin was appointed 

Administrator in 1992 with a mandate to change the Agency. He 

introduced the “Faster, Better, Cheaper” (FBC) concept at NASA 

as well as thirteen continuous improvement initiatives, including 

one devoted to program/project management improvement.

The program/project management improvement initiative 

included a 1992 internal study that identified eight major 

factors driving program cost and technical risk. Of particular 

importance, it noted the issue of problem repetition: similar 

findings had been widely documented over the past fifteen 

years, and many had been reflected in NASA policies and 

processes. This persistence of previously identified problems 

signaled to senior management a breakdown in policy/process 

discipline. In 1993 this led to a major revision of basic program/

project management policy, establishment of the Agency 

Program Management Council (PMC), and reassignment 

of ownership for these policies and processes to the Office of 

the Administrator. The follow-up actions did not include an 

effort to determine the specific causes of the breakdowns in 

discipline in policy/process implementation, however.

Extensive reviews, audits, and investigations throughout 

the 1990s on the Space Shuttle, International Space Station, 

and Mars programs found that these lapses continued. Most 

importantly, a number of these studies also found that many of 

the problems would not have occurred if existing policies and 

processes had been followed.

Prior to completion of the 1992 study, Goldin established a 

Program Excellence Team (PET) to strengthen, streamline, and 

consolidate the policies and processes governing management of 

major system development projects. In my role as deputy associate 

administrator for Space Systems Development, I led the PET, which 

consisted of senior headquarters and field center program/project 

management executives. The team developed a consolidated NASA 

program/project management policy (NMI) and supporting 

handbook (NHB) for implementing policies and processes that 

were approved in late 1993 and subsequently underwent the most 

extensive rollout to date. The new NMI consolid

program/project management policies and processe

artificial separations that existed between pro

management and acquisition, and placed responsi

integrated policy with the deputy administrator in h

Agency’s senior acquisition official.

These new policy/process documents reflecte

of all studies, colloquia, reviews, investigations

subsequent to the 1981 Hearth effort. Extensive po

included the introduction of life-cycle costing, ree

of PPP, selection of “Down Select” (narrowing 

selection of a contractor through successive 

phases) as the normal acquisition mode, and esta

requirements for independent reviews and cost est

these changes did not meet all policy needs.

In developing the new program/project 

policy and handbook, the PET found problem

aspect of the program/project management func

implementation, and training. The team also fou

repetition of program/project management proble

to the stress of performing in a very difficult 

combined with a lack of senior management o

policy documentation. The new policy addressed 

assigning overall program/project management r

to the deputy administrator. Acting Deputy A

General John Dailey subsequently established a PM

Group (PMCWG) and used the Office of the Ch

a part of the Office of the Administrator, to sup

meeting this responsibility.

Shortly after the PMCWG was estab

Administrator made two decisions that would 

a major revision of the new program/project 

policy: program management responsibility woul

headquarters to the field centers, and NASA was t

a strategic-planning process that would eliminate 

life-cycle approach to program/project managemen

The Viking 1 lander is shown in a cleanroom d
The program/project management policy revision needed 

to effect these changes was developed by the PMCWG and 

issued in 1996 as a NASA Policy Directive (NPD 7120.4A). 

This revision expanded the policy scope to all agency programs 

and projects and replaced the five phases of the life cycle with 

the four component processes of the strategic management 

process for program/project management. It was significantly 

briefer than the PET-generated version it replaced, with the 

expectation that the deleted material would be updated and 

included later in the needed revision of the Program/Project 

Management Handbook. However, when the PMCWG updated 

the handbook in 1998, much of the deleted material was not 

included. The review rollout process for NASA Procedures and 

Guidelines (NPG) 7120.5A, the precursor to today’s 7120.5D, 

was personally led by the acting deputy administrator and was 

the most comprehensive ever. 

Lessons for the Road Ahead

What can be learned from reviewing these efforts? First, NASA 

has no trouble identifying its weaknesses. The “usual suspects” 

appear repeatedly in these assessments: inadequate program/

project definition, complex or unclear roles and responsibilities, 

budget instability and inadequate resource reserves, inadequate 

program/project control, inadequate risk management, poor 

implementation of management and engineering processes 

and practice, and poor communication. Other persistent 

problems include discipline breakdowns, a lack of agency buyin, inadequate training resources, inappropriate management 

approaches, organizational fragmentation, and deficiencies 

in the policies and processes themselves. Where problems are 

concerned, there is nothing new under the sun. 

Second, this repeated identification of the same problems 

indicates that additional top-level agency management 

attention to program/project management improvement is 

essential to the success of the Vision for Space Exploration 

programs. The increased attention that NASA Administrator 

Dr. Michael Griffin is devoting to the improvement of 

program/project management and systems engineering is 

very encouraging. The breadth and depth of the ongoing 

improvement efforts and their strong suppor

Administrator are the critical prerequisites to t

as were the similar efforts of Administrator Jam

behalf of the Apollo program. ●

DR. C. HOWARD ROBINS, JR., spent more than 40 years with 

NACA/NASA, retiring in 1994 as deputy associate administrator 

for Space Systems Development. He currently serves as a 

consultant in program and project management.

An artist’s impression of the Voyager spacecraft.
The Secret of Apollo: Systems Management in 

American and European Space Programs (New 

Series in NASA History), by Stephen B. Johnson 

(Baltimore: Johns Hopkins University Press, 2006)

Using case studies, including the development of the 

intercontinental ballistic missile, the Jet Propulsion Laboratory’s 

(JPL) entry into space projects, the Apollo program, and the 

creation of the European Space Agency, Stephen Johnson—a 

space historian and engineer at Marshall Space Flight Center—

demonstrates that systems management sustained large projects 

and led to mission success:

 Social and technical concerns drove the development of systems 

management. ... Investigation of the technical issues led to the creation 

of stringent organizational methods such as system integration and 

testing, change control, quality inspections and documentation, and 

configuration management. Engineers led the development of these 

new technical coordination methods, while managers intervened to 

require cost and schedule information along with technical data ... The 

result of these changes was systems management, a mix of techniques 

that balanced the needs and issues of scientists, engineers, military 

officers, and industrial managers.

The case studies he chooses reveal how the organizational 

methods emerged as responses to problems within projects and 

became the discipline now called systems management. He 

also examines how JPL shifted from an army contract missile 

laboratory to a successful NASA Center conducting lunar and 

planetary space flight missions, noting that “recognition of 

the ‘systems concept’ marked JPL’s transition from research to 

engineering development. Systems engineering, which began 

as coordination between technical divisions and between JPL 

and its contractors, became a hallmark of JPL.” JPL learned 

from its mistakes on the Ranger and Surveyor programs about 

the need for stronger project management, better change 

control, and progressive design freezes. The highly successful 

Mariner project became a model for the lab: 

 JPL engineers repeatedly found that many technical problems could 

be solved only by using organizational means. Problems with missile 

reliability demanded engineering design changes, parts inspections, 

and test procedures. Systems engineers solved interface problems 

by maintaining interface drawings, mediating subsy

and chairing change control meetings to track and 

modifications.

The lessons from these early successes 

eventually contributed to JPL’s reputation as the w

in deep space exploration.

Although NASA’s organizational structure an

proved successful during Mercury and Gemini, 

program faced increasing cost pressures as t

developed. Apollo program director Brig. Gen. 

Phillips brought helpful Air Force Systems Comm

into the NASA organization, such as configuration 

the Program Evaluation and Review Technique. 

chief in the Office of Manned Space Flight, Ge

also quickly realized the need for better cost pr

control. Johnson credits Phillips and Mueller wit

the management of the Apollo program: 

 Mueller forced MSC [Manned Space Center] and M

Space Flight Center] to adopt stronger project manage

systems engineering, expand ground testing, and report m

to headquarters. Phillips instituted configuration ma

project reviews throughout Apollo to control technical

contractual aspects as well as the scheduling of the pro

officers brought in by Mueller and Phillips propagated t

transformed OMSF’s organizations into project-orient

development organizations.

NASA’s successful approach to the Apollo p

not go unnoticed. Johnson shows how the Europ

American managerial practices to successfully cre

after the embarrassing failure of the European S

Launcher Development Organization (ELDO). W

had revealed significant communication and interf

among the British, French, and Germans, the Eur

Research Organization borrowed from NASA

practices to produce a series of scientific satellites.

The Secret of Apollo provides a valuable historica

on the importance of good systems managem

development of large-scale projects and programs, 

remain relevant to this day. ●
The Communications Challenge

BY LAURENCE PRUSAK

The complexity of NASA’s projects and the 

challenge of coordinating and communicating 

among the centers and organizations that do the 

work have parallels in enterprises that flourished 

long before the beginning of the space age. In the late 

nineteenth century, large-scale organizations began 

to emerge in the United States, Western Europe, 

and Japan. Driven by the first and second waves 

of the industrial revolution, along with concurrent 

changes in demographics, they were unlike 

anything seen before. The work of these firms, 

which produced railroads in the United States, 

textiles in the United Kingdom, chemicals and steel 

in Germany, and weaponry in Japan, was far more 

complex than that of the firms that preceded them. 

A hallmark of these new organizations was that their 

work was spread out over space and therefore also 

over time, since contact and communication were 

not instantaneous. The thinking that went into 

running these new-fangled enterprises also began 

to be divided and distributed. Functions such as 

operations, finance, and sales migrated to separate 

departments and the well-known advantages of 

dividing labor into specialized components made 

themselves quickly obvious.

In those expansive and functionally divided 

organizations, discussions and conversations about 

how work would be done were no longer as direct 

and “hands-on” as they had been in the smaller, 

localized organizations of the past. Many of those 

instructions needed to be communicated through 

written directives or schematic plans, often 

unaccompanied by a person who could explicate 

them and see that they were properly applied.

Of course, large-scale enterprises existed 

before the later nineteenth century. The East India 

Company was already an effective in

the mid-seventeenth century, run

trade with a mere handful of emp

Dutch also had similar organizat

aftereffects are still with us. Even f

the Roman and Chinese empires we

and models of extremely large orga

was the Roman Catholic Church. B

the work of those early “global” o

was fairly routinized and varied only 

time. Tasks were well defined, and te

especially rapidly changing technol

no significant role in how the wor

So there was limited need for lo

communication explaining how to 

novel and ambiguous situations.

At the end of the nineteenth centu

we began to see large, dispersed o

that had to learn to deal with 

complexity and change. Today com

change have become fundamental 

Technologies, both hard and soft, 

with ever-greater rapidity. Waves o

sweep over organizations like tsuna

disruptions as well as creating opport

remarkable dispersion of cognition th

by communication technologies 

much knowledge is widely shared b

the knowledge needed to accomplish 

is widely scattered. Like fish that nev

water they swim in, we give little if 

to this volatile, fragmented environ

must be taken into account for us 

live successfully.

The trends toward complexity, 

dispersion increase the need for m
every level to focus on communication—on how to convey 

instructions and communications with the greatest possible 

effectiveness and sticking power. Fundamental to that 

effectiveness, of course, is the quality of that communication, 

its relevance to work it is meant to guide. But process matters as 

much as content. Words alone, especially when conveyed over 

great distances, are ambiguous and easily distorted. A policy 

statement, memo, or e-mail offers few if any opportunities for 

the negotiation of meaning that is so critical to any effective 

knowledge transfer. Without that negotiation—without, for 

instance, conversation about what the words imply—what the 

creator of a document means and what its readers understand 

are likely to differ dramatically. Communication is not a oneway activity limited to sending a message. It is a social process, 

a shared refining of ambiguities and distortions and building of 

context and understanding to create meaning.

This brings us to a few of the lessons that practitioners 

and researchers have learned about how to structure effective 

communication. Here they are in a digestible form:

• Believe in “ground truth” and local truth—the experiential 

knowledge of those who do the daily work. People can 

tell from a long way off if a communication is dictated 

from on high with little input from those who have the 

real know-how about what is being communicated. Lack 

of trust and an unwarranted belief that all wisdom resides 

at the top can impede the use of this critical source, 

especially in hierarchical organizations.

• Think of communication as a process, not a message. 

Without mechanisms for discussion, debate, and demonstration, even the most carefully crafted instructions will 

probably be misunderstood or ignored.

• Communicate with stories. They provide the context 

and emotion that rules cannot convey. We are wired 

to understand things through narrative. Storytelling is 

slowly becoming the norm in many organizations. To its 

credit, NASA was one of the first orga

institutionalize this practice.

• Do not be cynical or skeptical. Most em

recognize good advice and will use it if it h

their work. They are, as the social scientist

intendedly rational. That is, they make purpo

that they believe will help them achieve their 

COMMUNICATION IS NOT A ON

ACTIVITY LIMITED TO SENDING 

MESSAGE. IT IS A SOCIAL PRO

A SHARED REFINING OF AMBIG

AND DISTORTIONS AND BUILDI

CONTEXT AND UNDERSTANDIN

CREATE MEANING.
For More o

Our Stories

Additional information 

to articles featured in 

can be found by visitin

following Web sites:

Cosmic Background 

(COBE): http://aether.

www/projects/cobe

The Vision for Space E

http://www.nasa.gov/m

pages/exploration/ma

Exploration Systems 

Directorate (ESMD): h

exploration.nasa.gov/

The Hearth Report: h

klabs.org/richcontent/

NASA_Reports/hearth

feedback

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

would like to see in future issues. Share your thoughts with us at http://appel.nasa.gov/ask/about/wr

Learning and Development

The Academy of Program/Project and Engineering Leadership (APPEL) has updated 

its curriculum offerings. The APPEL Program Management and Systems Engineering 

development structure includes three major components: core curriculum, in-depth 

courses, and outside-the-classroom development experiences. Evaluating the quality and 

results of this curriculum—and providing for its continuous improvement—is a high priority 

of the APPEL team. For more information, visit the newly revised site at http://appel.nasa.

gov/node/28 or e-mail APPELcourses@asrcms.com.

Web of Knowledge

Find the new NASA Program and Project Management Processes and Requirements (NPR 

7120.5D) and more in the NODIS library at http://nodis.hq.nasa.gov/main_lib.html. The NASA 

Online Directives Information System (NODIS) is a searchable online library that contains 

agency-level directives, reports, other policy documents, and useful links to other executive 

orders, standards, and more. Since its inception in October 1986, NODIS has earned its 

reputation as a simple, effi cient, and user-friendly service. Prior to NODIS, NASA relied 

heavily on telephones and the postal service for disseminating information and fulfi lling data 

requests. NODIS played an instrumental role in revolutionizing information dissemination and 

request coordination at NASA. It won the 1992 Federal Leadership Award, co-sponsored by 

the Federal Open Systems Conference Board and the Federal Computer Week newspaper. 

The History of NASA

Lessons from the past can help solve problems today, and the NASA History Division is a treasure t

important lessons. Established in 1959, the NASA History Program documents and preserves the A

remarkable history through a variety of products. The History Division serves two key functions: fulfi 

the mandate of the 1958 Space Act, which called for NASA to disseminate aerospace information as 

as possible, and helping NASA managers understand and benefi t from the study of past accomplish

and diffi culties. The History Division has an array of resources available on their Web site, http://www.history.nasa.gov, in

a list of interesting and helpful publications. One of their new books, Critical Issues in the History of Spacefl ight, is a colle

of essays that analyzes some of the perennial issues in the history of the Space Age. Edited by NASA Chief Historian Ste

Dick and Roger D. Launius, former NASA chief historian and current chair of the Division of Space History at the Smithso

Institution’s National Air and Space Museum, the essays examine some of exploration’s perpetual questions: What are th

motivations for space fl ight? Is human space fl ight necessary when robotic spacecraft are cheaper? This collection is av

to read online at http://history.nasa.gov/SP-2006-4702/frontmatter.pdf.
Not yet receiving your own copy of 

To subscribe, send your full name and preferred mailing a

(including mail stop, if applicable) to ASKmagazine@asrc
National Aeronautics and Space Administration

NASA Headquarters

300 E Street SW

Washington, DC 20546

www.nasa.gov

NP-2006-01-450-HQ