Fusing Risk Management
and Knowledge Management
An idea had been percolating in Dave Lengyel's mind for some time: how to integrate risk management (RM) and knowledge management (KM) to create a better risk-management approach for the Exploration Systems Mission Directorate (ESMD). How could the wealth of current and future lessons-learned information be fused with RM practices in a dynamic system?
Then, in 2005, came the Reese's moment, as Lengyel, who had recently joined the Exploration Systems Mission Directorate, calls it—Hey, you got KM in my RM! It was the idea of knowledge-based risks, or KBRs, which would couple continuous risk management with lessons learned.
The goal, says Lengyel, was to get away from a passive collection system of lessons and into a framework where recognized risks guided knowledge capture and delivery. Rather than introducing new KM tools, a KBR-oriented system would focus on transferring knowledge by infusing it into existing work processes. It would aim to close knowledge gaps by providing broader access to risk information not only relating to NASA legacy programs such as the Space Shuttle and International Space Station but also capturing and transferring what ESMD learns in managing risks along the way.
A great way to identify risks is through lessons learned, which in many cases were risks that challenged a previous program. KBRs provide that as well as analysis and planning information, says Lengyel, who is now the risk and knowledge management officer at ESMD. We're just saying, ‘Here's what worked or didn't work for this particular risk.’ A lot of risk management requires a little bit of art in putting a good plan together.
The timing for launching the KBR effort dovetailed with the cancellation of the Orbital Space Plane, conceived as a crew rescue and transport craft for the space station. There was an abundance of lessons about lessons that proved useful in building the KBR construct.
About that time, recalls Lengyel in an interview in his office at NASA Headquarters, we started looking at how we were going to do lessons learned differently and more meaningfully than we had in the past. He asked risk and knowledge managers from across the directorate to join a working group that included representatives from NASA's Academy of Program/Project and Engineering Leadership (APPEL) and Office of Safety and Mission Assurance, as well as contractors such as Pratt & Whitney Rocketdyne, Lockheed Martin, the chief knowledge officer at Goddard Space Flight Center, and information technology specialists. We came up with the concept of knowledge-based risks. We said we were going to capture what worked and what didn't work within the context of risks, put it back into our risk system, and use that knowledge to help us write better risks, identify risks, and have better plans and discrete mitigation steps. The risk database becomes a knowledge base over time—not a separate lessons learned system.
The KM working group began to do benchmarking inside and outside the Agency. It looked at aerospace companies, financial firms, the Department of Defense and the CIA, and a top pharmaceutical company, culling best practices. The initiative began to evolve, taking shape as a four-spoke wheel with KBR as the hub. One of the four practices, called Pause and Learn (PaL) and developed by the Goddard KM officer, was based on the U.S. Army's after-action review; the others are knowledge-sharing forums, experience-based training using case studies, and Webenabled teams that are growing rapidly. The ESMD's Risk and Knowledge Management portal is located within the Integrated Collaborative Environment (ICE) and already has more than 16,000 registered users. [See accompanying article on how Lengyel's first KBR is displayed on the ICE site.]
At the heart of all this activity was a guiding principle: power to the people. It was a movement away from technology. A lot of KM effort in the Agency is very IT-centric—what I call the ‘IT junkyard' approach to knowledge management, says Lengyel, a former marine aviator and FA-18 and F-15 aircrew training instructor at the McDonnell Aircraft Company before coming to NASA. We're taking a light-touch approach when it comes to IT tools. Much of what we're doing depends on learning through conversation, people talking to each other, knowledge-sharing forums ranging from brown-bag lunches to more focused workshops and conferences to experience-based training. We wanted to put these things together in a way that would be more closely aligned to process improvement than just strict KM.
The Constellation program provided fertile ground for the new integrative approach. For Constellation, we looked at requirements-related risks and found that we had 255 risks. Only about a third of them had legitimate mitigation plans. They ranged from ‘I'm not going to be able to meet this performance requirement’ to ‘Given the lack of requirements or immaturity, this risk is going to happen to me.’ The fact that they didn't have good mitigation plans was not a good thing for us. So we did some more analysis and found ten things that seem to be working that are reducing risk. Over time what we can do is build templates so we can sit down with risk owners when they come in with a certain type of risk and say, ‘Here's a better way to identify the actual root cause, and here are some things to consider in your plan and mitigation steps to really work your plan.’
One of our challenges two and a half years ago was opening up the risk database. We were told by really experienced risk managers in our directorate that if you open up the database, people will not put risk information in there because they didn't want Ground Ops to look at Capsule to look at Booster, that there would be hesitation to put that information in because we didn't do that before because of different cultures, different centers.
But you just can't do enterprise risk management if you close the database and partition it off by program and project. We said we've got to get over this structural barrier. So we opened it up and moved on. What helped us immensely during this period was adopting best practices from space station and shuttle and moving it into Constellation, Ares, Orion, and so on.
Lengyel likes to describe RM-KM integration as a processimprovement approach that helps the experts—the risk managers—play to their strengths. People in human space flight understand what risk management is. They understand the foundations, they understand the resource challenges. They also understand why it makes sense to let the risks point you to areas you need help in. I think we do a really good job of risk management. I think we do a lousy job of KM.
As the integration plan is implemented, Lengyel envisions a KBR-capture system built on quality, not quantity. In the last lessons learned system, there were sixteen hundred–plus lessons. On a good year they collected eighty to a hundred. A lot of that was useless—what I call ‘spilled milk’ stuff. We want to capture really meaningful information, maybe ten or fifteen KBRs per year.
At ESMD, where the future of U.S. human space flight is being shaped, Lengyel believes merging risk and knowledge management is essential, and that it starts with the practitioners. It's the risk community, the risk managers, who form the central nervous system for information flowing in our directorate, he says. I don't expect risk owners to be dancing around in the database looking for KBRs that might help them. You've got to feed this information to them, you've got to do the analysis and get it to them to help them do their work more effectively. Otherwise we're just going to have a fancier lessons-learned system. I call that the ‘collect, store, and ignore’ approach. Let's stop doing that. Let's make it an active system.
About the Author
Charles Tucker works with Dr. Edward W. Rogers, chief knowledge officer at Goddard Space Flight Center, on organizational learning and knowledge management initiatives using case studies of Goddard and other NASA missions.