Skip Navigation
NASA Logo, National Aeronautics and Space Administration
Academy of Program / Project & Engineering Leadership

Academy of Program / Project & Engineering Leadership

ASK the Academy

October 30th, 2008 - VOL. 1 Issue 10

In This Issue

Message from the Academy Director

Can We Learn to Innovate?

Innovation is critical to our continuing progress in space. Can it be learned?
+ Read More


Features

Reflections on the Project Management Institute's 2008 North American Congress

The Project Management Institute (PMI) North American Congress, held in Denver in mid-October, reflected the growth of project management as a profession, writes Academy Director Dr. Ed Hoffman.
+ Read More

Academy Brief: Performance Enhancement Support for Project Teams

No matter where your project team is in its life cycle, the Academy offers direct support that can help.
+ Read More

Academy Holds Masters Forum 17

NASA's 50th anniversary was the theme of the Academy's seventeenth Masters Forum, which took place at the Jet Propulsion Lab (JPL) from October 28-30, 2008.
+ Read More

Tool Innovation: The Distributed Observer Network (DON)

Video game technology is providing the basis for robust visualization and collaboration capabilities at NASA.
+ Read more

Can the Theory of Inventive Problem Solving Help You?

What's the contradiction in the problem you're trying to solve? The Theory of Inventing Problem Solving (TRIZ) may help you find the answer.
+ Read more

Innovative Partnership Resources

Learn more about NASA's publications that deal with innovation and public-private partnerships.
+ Read more


Inventor's Bookshelf

Designing Interactions

If a system is both digital and interactive, it falls under design guru Bill Moggridge's broad definition of interaction design.
+ Read More


View from the Outside

South Korea Prepares KSLV-1

As it readies the first Korea Space Launch Vehicle (KSLV-1) for flight, South Korea aims to become the ninth country to launch its own satellite within its borders.
+ Read More


This Month in NASA History

Thirtieth Anniversary of Nimbus 7

Nimbus 7, the last in a series of R&D weather satellites operated by NASA and the National Oceanic and Atmospheric Administration, launched on October 25, 1978.
+ Read More


In the Current Issue of ASK

+ A New Astronaut Seat
by Dustin Gohmert

+ International Cooperation: When 1+1=3
by Toshifumi Mukai

+ Staying Motivated During Tough Times
by Jennifer Cole

October 1st, 2008 - VOL. 1 Issue 9

This Month in NASA History

Fiftieth Anniversary of NASA's First Launch

Pioneer 1, NASA's first-ever space launch, rocketed into orbit on October 11, 1958.

Pioneer 1 was the second in a series of scientific launches as part of the International Geophysical Year and the first attempt by the United States to launch a spacecraft beyond an Earth orbit. The first launch attempt, Pioneer 0, was aborted due to a rocket explosion 77 seconds after launch.

Pioneer 1, which flew aboard a Thor-Able launch vehicle, was designed for insertion into a lunar orbit, where it would send back photographs and data about the Moon. Due to the malfunction of an upper stage valve, it did not achieve the escape velocity necessary to break out of Earth’s gravitational field.

During its 43-hour flight, it did reach an orbital height of 113,800 km at its highest trajectory. While in orbit, it returned valuable data on the near-Earth space environment, including confirmation of the existence of the Van Allen radiation belts discovered during the Explorer I mission in January 1958.

Pioneer 1's scientific payload had a total mass of 17.8 kg, including an image scanning infrared television system to study the Moon's surface, an ionization chamber to measure radiation in space, a diaphragm/microphone assembly to detect micrometeorites, a spin-coil magnetometer to measure magnetic fields, and temperature-variable resistors to record spacecraft internal conditions.

Read more about Pioneer 1.


If you would like to forward this article to a friend click here

If you would like to receive ASK the Academy straight to your email box click here

October 1st, 2008 - VOL. 1 Issue 9

View from the Outside

ESA's Rosetta Meets an Asteroid

The European Space Agency’s (ESA) spacecraft Rosetta did its first fly-by of the asteroid 2867 Steins on September 5, 2008.

ESA considered the fly-by, a nominal target in Rosetta’s eleven and a half year mission, a huge success that provided a wealth of information on smaller solar system bodies. Rosetta came as close as 800km to 2867 Steins, flying by at a speed of 8.6 km per second and performing maneuvers that pushed Rosetta to its design limits.

At a distance of roughly 360 million kilometers from Earth, Steins are small irregular shaped E-type asteroids that have never been observed directly by any interplanetary spacecraft before. The Steins asteroids are small in size and mainly orbit in the inner part of the asteroid belt situated between Mars and Jupiter. They are thought to be composed of silicate minerals with little or no iron content.

Read more about Rosetta.


If you would like to forward this article to a friend click here

If you would like to receive ASK the Academy straight to your email box click here

October 1st, 2008 - VOL. 1 Issue 9

From the Archives

An Iconoclast on the Definition of Systems Engineering

In the spirit of NASA's fiftieth anniversary, ASK the Academy looks back forty years to a letter written by George S. Trimble, Deputy Director of the Manned Spacecraft Center (now Johnson Space Center) from 1967-1969, on the definition of systems engineering.

Trimble's skeptical, humorous letter was reprinted in “Readings in Systems Engineering,” a 1993 anthology edited by Francis T. Hoban and William M. Lawbaugh (NASA SP-6102). The text and editors' note below appear verbatim as printed in that volume.

Defining Systems Engineering
by George S. Trimble

Editors' Note
Back on September 27, 1968, a NASA engineer by the name of George S. Trimble wrote to the Chief of the Management Analysis and University Programs Office after the Chief issued a letter to find a universally suitable definition for "systems engineer." The engineer told the manager that the term had no particular meaning at all. "In fact," Trimble claimed, "I may know the guy who thought it up or resurrected it, as the case may be, for modern usage." His seemingly authoritative account follows:

During the war, new management practices were introduced at a great rate, and one of the functions that came to the fore was the business of writing job descriptions and evaluating them. Certain industrial relations experts fell heir to this function, and there was a tendency for them to write very clear job descriptions for all jobs except their own. It soon became obvious that the value of a job, or, more importantly, the money it paid (or even more importantly, its draft-dodging power), was inversely proportional to the ease with which one could describe it. Industrial relations people were able to describe any engineering job in 25 words or less, whereas an industrial relations function might take two or three pages. Miserable to begin with, engineering salaries were futher threatened and so was draft status.

Of course, everyone knows that engineers are very creative. They could see that the industrial relations boys had a good thing going, so they borrowed the approach and improved on it (typical engineering method).

Soon it took five pages to describe the most menial engineering task, and the engineers were saved. It was a simple matter to spend three hours explaining to a job analyst from industrial relations why a 'systems engineering' blueprint file was much more complicated to run than a simple old 'engineering' blueprint file, which was, of course, familiar. The guy from industrial relations never did understand it because the guy who explained it didn't. It takes a lot of words to explain something you don't understand or that isn't there. Try explaining 'zero' sometime.

A parallel effort with the objective of emphasizing *!!ENGINEERING!!* was carried out with great dispatch by the 'scientists,' all of whom became famous at the close of WWII because a couple of them invented and built the A-bomb, all by themselves, with great secrecy. What they were really doing all that time, of course, wasn't science--it was engineering. When this was discovered, a mixed wave of nausea and terror ran through the brotherhood. It was worse than being caught reading a dirty book in church. Most learned scientists knew that engineers were people who ran around with special hats and oil cans and made steam locomotives go, and who, incidentally, made too much money. Being identified as part of the same crowd was too much for the intellectuals to bear. Scientists had to be working on something more important than 'engineering,' which is supervised by a Ph.D and is therefore high-class and also obvious to those schooled properly, but difficult if not mpossible for anybody else to understand.

Since, as we all know, very few, if any, Ph.Ds understand the meaning of plain, ordinary 'engineering,' it follows that 'systems engineering' has given engineering a bad name, and should be avoided for that reason alone.

A third group who helped the cause for systems engineering were the pre-war 'handbook' engineers who discovered creative engineering when they joined up with a wartime industrial engineering group to avoid being drafted. They had always thought that engineering was the choosing from a catalog of the proper washer for a quarter-inch bolt. It was difficult for them to use the same name for their new discovery, creative engineering (designing a washer for a quarter-inch bolt). The term 'systems engineering' suited well, and groups of people were noising it around by then. It sounded nice and, after all, a quarter-inch bolt is a fastening system of high complexity. It consists of a bolt with threads (helical inclined plane), a nut of the proper size, hand and thread configuration (bolt interface problem), external shape (wrench interface problem), one or more washers (structures interface problem), and sometimes even a cotter pin (reliability).

Moreover, one could dream of performing systems engineering at increased hierarchical levels by considering at one and the same time not only the quarter-inch bolt, but also the half-inch bolt. Advanced systems engineering. So much for the history and meaning of systems engineering. You can demonstrate the validity of my story to yourself in several ways. Your letter, for instance, can be clarified by eliminating the word 'systems.' I believe it appears 10 times. Check the universities for courses in systems engineering and find out what they are really teaching. Note also that the term 'systems engineering' does not yet appear in an accredited dictionary. This is because Webster cannot figure it out either. Good luck!


If you would like to forward this article to a friend click here

If you would like to receive ASK the Academy straight to your email box click here

October 1st, 2008 - VOL. 1 Issue 9

Leadership Brief

Judgment: How Winning Leaders Make Great Calls

The evidence of great leadership manifests itself in great judgment, according to Noel Tichy and Warren Bennis.

Why do some leadership decisions result in successes and others in failures? Ultimately, a large part of the answer is judgment. The good news, according to the authors, is that judgment is a skill that can be developed; they strongly resist the argument that it is simply a matter of gut instincts.

Tichy, a professor at the University of Michigan and Bennis, a professor at the University of Southern California, draw extensively on personal interviews and case histories to illustrate examples of good and bad judgment calls. Their framework for judgment divides decisions into three domains -- judgment about people, judgment about strategy, and judgment in a time of crisis -- and examines the phases of decision-making as well as the importance of managing stakeholders during and after the decision-making process. They also identify four types of knowledge that leaders must possess to arrive at good judgments: self-knowledge, social network knowledge, organizational knowledge, and contextual knowledge.

Tichy and Bennis see knowledge creation as a critical element of developing judgment capacity. Organizations in which everyone teaches and everyone learns offer decision-makers the best input for making considered judgments. Citing examples from organizations as different as Best Buy and Intuit, they write:

"The paradox of shifting power to the front lines is that it requires senior leaders to use their authority to overcome the technical, political, and cultural barriers that often stand in the way....When they do, they realize that frontline leaders are those most skilled in making local decisions to simultaneously delight customers and protect the bottom line and continuously create knowledge."

 

Read more about Judgment: How Winning Leaders Make Great Calls.


If you would like to forward this article to a friend click here

If you would like to receive ASK the Academy straight to your email box click here

October 1st, 2008 - VOL. 1 Issue 9

Features

Research Brief: Space Security

Space debris poses an increasing threat to space security, according to Space Security 2008, the fifth annual report by spacesecurity.org

The dangers of space debris have been understood for decades, but progress on controlling the amount of debris in space has reversed. After several years of declines, the annual growth rate of debris has been increasing since 2004. The Department of Defense's Space Surveillance is currently tracking more than 17,000 objects that are 10 cm in size or larger, and Russia is believed to be tracking 5,000 objects with its own monitoring system. During 2007 trackable space debris increased by 20.12%, according to the authors.

The report assesses space security in terms of eight dimensions:

  • The space environment
  • Space laws, policies and doctrines
  • Civil space programs and global utilities
  • Commercial space
  • Space support for terrestrial military operations
  • Space systems protection
  • Space systems negation
  • Space-based strike systems

Read the full report.


If you would like to forward this article to a friend click here

If you would like to receive ASK the Academy straight to your email box click here

October 1st, 2008 - VOL. 1 Issue 9

Features

Academy Case Study: The New Horizons RP-1 Tank Decision

In early September 2005, the Launch Services Program at Kennedy Space Center received an unexpected call from Lockheed Martin, the manufacturer of the launch vehicle for New Horizons, NASA’s long-planned mission to Pluto.

The news on the other end of the phone was not good. The launch vehicle’s fuel tank had experienced a catastrophic failure during the final stages of qualification testing. With just over four months until the planned launch date, work began immediately to determine the cause of the failure and the implications for the mission.

New Horizons, the first-ever mission to Pluto, posed a number of technical challenges simply due to the sheer difficulty of reaching its destination. Slated to launch on January 11, 2006, it had a 17-day launch window (the period during which it could be launched) in the winter of 2006 that would put it on the shortest trajectory, allowing it to reach Pluto in 2015. If it failed to lift off during this early window and launched between January 28 and February 2, its arrival at Pluto would be delayed until 2016 or 2017. A little more schedule slippage, to as late as February 14, meant that the spacecraft would lose the benefit of a “Jupiter gravity assist”—a swing past the huge planet to gain energy from its gravitational field—and the missed opportunity to pick up speed would push back the rendezvous with Pluto until 2019 or even 2020. If the launch was delayed beyond February 14, the next opportunity to launch New Horizons would not come until 2007.

As is the case with many NASA missions, New Horizons comprised a dense web of partnerships among many organizations. NASA provided overall project management through its Science Mission Directorate’s (SMD) New Frontiers program. The mission’s Principal Investigator, Dr. Alan Stern, was not affiliated directly with NASA at the time, but rather with the Southwest Research Institute, a non-profit applied engineering and physical sciences research organization. The Applied Physics Laboratory at Johns Hopkins University designed and developed the spacecraft. Responsibility for the launch rested with NASA’s Launch Services Program (LSP) at Kennedy Space Center, which was using an Atlas V expendable launch vehicle manufactured by Lockheed Martin. In short, there were numerous organizations that could rightfully claim important stakes in New Horizons.

The New Horizons RP-1 tank problem ended up presenting a test case for NASA’s new leadership. Virtually the entire senior management team had turned over since the loss of the space shuttle Columbia two and a half years earlier. A new set of leaders, including Administrator Dr. Michael Griffin, brought fresh perspectives informed by NASA’s recent history. Among the senior leadership involved in this case, only Bryan O’Connor, the Associate Administrator for Safety and Mission Assurance, had been in his position for more than a year when the New Horizons RP-1 tank issue reached the top tier of NASA management. Chief Engineer Chris Scolese came to his new position at NASA headquarters the same month that the tank failure occurred. The team would face its first technical decision that required the involvement of the highest levels of agency management.

Read the full case study.Adobe PDF


If you would like to forward this article to a friend click here

If you would like to receive ASK the Academy straight to your email box click here

October 1st, 2008 - VOL. 1 Issue 9

Features

Academy Brief: Knowledge Sharing

Knowledge sharing is a critical pillar of the Academy's professional development framework that is central to its efforts to build a community of reflective practitioners across NASA.

In a hard-nosed engineering culture like NASA, knowledge sharing sounds like the softest of soft skills. In reality, though, it is essence of how people learn to do their jobs. Acquiring knowledge is different than mastering information -- otherwise, brain surgeons, auto mechanics, foreign language translators, and computer programmers would become experts through rote memorization. Knowledge doesn’t work that way.

Knowledge sharing happens all the time, whether we realize it or not. When we learn from colleagues on the job, that's knowledge sharing. It is simply a part of life in a project-based environment. At the same time, one of the side effects of project work is tunnel vision. The singular focus necessary for project success makes it easy to lose sight of the larger project community. NASA's technical workforce possesses an incredible richness of expertise in every conceivable discipline, but that expertise is distributed among ten field centers, four mission directorates, dozens of programs, and hundreds of projects. Lots of knowledge connections never get made simply because there is no organizing principle that makes it easy to access the depth that already exists within the agency.

As NASA designs and develops the most complex systems it has ever attempted, it faces a critical need to transfer knowledge and expertise from those who have done this kind of work before to those who are doing it now. The broad programmatic shifts in human space flight and the changing demographics of the workforce only make this more urgent.

The challenge of knowledge sharing is not a new one at NASA. After the 1999 failures of the Mars Climate Orbiter and the Mars Polar Lander, the U.S. General Accounting Office (now the General Accountability Office, or GAO) did a survey of NASA’s lessons learned process and issued a report that called for a comprehensive knowledge sharing effort at NASA. GAO found that “NASA’s processes, procedures, and systems do not effectively capture and share lessons learned and therefore, NASA has no assurance that lessons are being applied towards future missions.”

The report recommended “that the NASA administrator strengthen the agency’s lessons learning processes and systems by…developing ways to broaden and implement mentoring and “storytelling” as additional mechanisms for lessons learning.”

Even before GAO issued its report, the Academy had begun to develop practices for knowledge sharing that would fulfill GAO’s recommendation. The Academy based its approach to knowledge sharing on three guiding principles:

  1. The practitioner knows best.
  2. It's important to create a community of reflective practitioners.
  3. Storytelling provides the best medium for knowledge sharing

The Academy focused its knowledge sharing efforts in two areas that would promote the use of stories: practitioner forums and publications. Today, these remain the core knowledge sharing activities. The Masters Forums and the Project Management Challenge are its two signature events, with the former offering opportunities for informal sharing among expert practitioners and the latter serving as an annual gathering of the agency-wide project community. Its publications give practitioners venues to document and share their stories, best practices, and lessons learned in ASK Magazine, the ASK the Academy e-newsletter, and case studies of NASA missions.

Learn more about the Academy's knowledge sharing activities.


If you would like to forward this article to a friend click here

If you would like to receive ASK the Academy straight to your email box click here

October 1st, 2008 - VOL. 1 Issue 9

Message from the Academy Director

What's the Story with Your Project?

A project's storyline is a powerful force that can play a crucial role in determining its success.

What exactly do we mean by a project's story? In essence, it's the narrative we tell ourselves and each other every day about our project. How can it have any impact on mission success? Imagine the following:

A new project starts up, and the excitement is palpable. The core team consists of smart, highly dedicated professionals who come to work early and stay late. Even so, there are a few question marks about ambiguous requirements and the compressed schedule. As the project moves from one phase to the next, the question marks become fault lines, and eventually cracks begin to appear. Requirements creep kicks in from on high. A teammate who seemed highly driven turns out to be inflexible in the face of a changing environment. The project becomes a source of constant anxiety for you and a few colleagues who "get it." A milestone review determines that you're approaching the red zone. Rumors begin to circulate about your cancellation.

We all know the feeling of a project storyline that gets away from us. A project's negative story, or its context, can become a self-fulfilling prophecy. Likewise, a positive storyline can reinforce the things that are going right and help steer a project toward a successful outcome.

Responsibility for the project's storyline begins with the project manager. Ultimately he or she plays a key role in helping to shape the story for the team on a daily basis as well as for others outside the project. A project manager who understands the power of the story knows how to incorporate both the positive and negative developments into the storyline in a way that is constructive and honest. Managing the negative or challenging elements of the story is critical. Denying the negative is a surefire way of destroying the credibility of the story and the storyteller. At the same time, setbacks have to be framed in an appropriate context in order to prevent them from taking on lives of their own that can be destructive.

Responsibility for the storyline does not end with the project manager, though. Every team member owns a part and contributes to it every day through meetings, conversations, emails, and any other form of communication. The story we tell others becomes our story. We need to be aware of the power of that story to shape the perceptions of others, ranging from our teammates to senior leaders.

The stories of our projects are not simply instruments that we manipulate to further our own ends; that is the definition of propaganda. Though we can play a central role in shaping our stories, they respond to multiple dynamics that are not fully under our control. Ultimately our stories simply reflect the truth as we understand and convey it -- nothing more and nothing less. As the political theorist Hannah Arendt once said, "Storytelling reveals meaning without committing the error of defining it."


If you would like to forward this article to a friend click here

If you would like to receive ASK the Academy straight to your email box click here

October 1st, 2008 - VOL. 1 Issue 9

In This Issue

Message from the Director

What's the Story with Your Project?

A project's storyline is a powerful force that can play a crucial role in determining its success.
+ Read More


Features

Academy Brief: Knowledge Sharing

Knowledge sharing is a critical pillar of the Academy's professional development framework that is central to its efforts to build a community of reflective practitioners across NASA.
+ Read More

Academy Case Study: The New Horizons RP-1 Tank Decision

In early September 2005, the Launch Services Program at Kennedy Space Center received an unexpected call from Lockheed Martin, the manufacturer of the launch vehicle for New Horizons, NASA’s long-planned mission to Pluto.
+ Read More

Research Brief: Space Security

Space debris poses an increasing threat to space security, according to Space Security 2008, the fifth annual report by spacesecurity.org.
+ Read more


Leadership Bookshelf

Judgment: How Winning Leaders Make Great Calls

The evidence of great leadership manifests itself in great judgment, according to Noel Tichy and Warren Bennis.
+ Read More


From the Archives

An Iconoclast's View on the Definition of Systems Engineering

In the spirit of NASA's fiftieth anniversary, ASK the Academy looks back forty years to a letter written by George S. Trimble, Deputy Director of the Manned Spacecraft Center (now Johnson Space Center) from 1967-1969, on the definition of systems engineering.
+ Read More


View from the Outside

ESA's Rosetta Meets an Asteroid

The European Space Agency’s (ESA) spacecraft Rosetta did its first fly-by of the asteroid 2867 Steins on September 5, 2008.
+ Read More


This Month in NASA History

Fiftieth Anniversary of NASA's First Launch

Pioneer 1, NASA's first-ever space launch, rocketed into orbit on October 11, 1958.
+ Read More


In the Current Issue of ASK

+ A New Astronaut Seat
by Dustin Gohmert

+ International Cooperation: When 1+1=3
by Toshifumi Mukai

+ Staying Motivated During Tough Times
by Jennifer Cole

First Gov . gov NASA Logo - nasa.gov