In his “From the Academy Director” column, Ed Hoffman says, “Knowledge is the coin of the realm at NASA,” and discusses the challenges of “identifying, capturing, and sharing” the wealth of valuable knowledge the agency possesses. These are the goals of knowledge management, which is about making essential knowledge available and usable where and when it is needed in an organization.
When we consider knowledge and NASA, we probably think first about technical knowledge—the countless insights the agency has gained over the decades into how to engineer spacecraft and launch vehicles, and its wealth of accumulated scientific findings. As Laurence Prusak points out in “The Knowledge Notebook,” though, there are many kinds of knowledge. Purely technical knowledge (say the behavior of a particular material in the vacuum of space) is near one end of a spectrum that extends to much less explicit expertise—for instance, knowledge of how to meld disparate groups into a collaborative team. The difficulties of communicating technical knowledge effectively are real but may be ultimately less challenging than teaching the subtler lessons of how to get the work done (among many other skills, how to guide and inspire people, how to recognize problems before it’s too late, how to adapt to the unexpected events that are inevitable in complex projects).
Several of the articles in this issue of ASK illustrate the critical importance of those so-called “soft” skills (which include, by the way, understanding when you need new or better technical knowledge—one source of problems and failures on technical projects is thinking you know everything you need to know). In most of these cases, the most important contribution to solving both technical and organizational difficulties was to gather people in one place to work and talk together. So, for instance, much of the team that built IBM’s Watson computer (“Building the Watson Team”) spent their days in a single large room without cubicles or closed offices. That proximity supported the exchange of technical information and helped create a shared sense of mission.
Similarly, David Young’s discussion of planning for an important climate mission (“CLARREO: Bringing Disciplines Together”) describes how gathering scientists, engineers, and managers together as early as possible in the process can avoid later wasteful conflicts between what scientists want and what engineers (and budgets) can provide. And in the interview, Lisa May talks about how program execs in the Science Mission Directorate meet to share knowledge from the programs they help manage. And James Fanson offers a negative example of what can happen when you don’t bring people together in “GALEX: Managing the Unexpected,” telling how leaving an engineer alone to design a key component led to an unusable unit and the need to scramble for a replacement.
The articles here that focus on international collaborations add a further element to the kinds of knowledge needed to carry out projects successfully: cultural knowledge. “An Argentine Partnership with NASA,” “Managing Multicultural Teams,” and “International Collaboration on BepiColombo” all emphasize the importance of taking time—and spending time together—to learn the values and perspectives of team members from other cultures. The time together and the understanding it helps generate contribute to another essential element of project success: mutual trust.