By Edward W. Rogers
On May 13, 2003, I reported to work at Goddard Space Flight Center as the center’s “knowledge management architect.” Looking back after ten years there, I will try to summarize why knowledge management was successfully adopted at Goddard. Of course, the process was not as neat and orderly as this retrospective analysis may suggest; it was more of a journey of discovery with a few basic guiding principles to help keep me on course.
Take Time to Understand What Fits the Organization
The first thing I realized was that knowledge management would come across as a fad or a waste of time to the competent and busy people at Goddard—more than three thousand government employees and six thousand contractors on site—unless what I did clearly met the organization’s real needs and suited its way of working.
I began by thinking about what Goddard actually does repeatedly as a business. What we “produce” over and over again is not any particular mission but the assembly and execution of a project. Because each project team has a different assignment and a different mission, people tended to think, “We never do the same thing twice. Lessons don’t apply since the mission is always unique.” But what we do over and over is put together a team to accomplish a mission. So that suggested what the knowledge management focus should be. Many of the lessons we should be learning had to do with how we manage those teams as much or more than the technology or design of a specific mission. To be useful, knowledge management would have to address issues of how we manage our projects, not just pass along test and failure data at the technical level.
One fact of working life was immediately clear: Smart people make rational decisions about how they spend their time. They rarely see value in management meetings and events designed to extract knowledge from them. On the other hand, they see high value in the exchange of knowledge among peers. The critical difference is whether individuals leave the meeting knowing more than when they came. I knew I would have to design knowledge sharing and learning sessions as “exchanges” and not knowledge-extraction activities.
I modified the After Action Review (AAR) concept used by the U.S. Army into a NASA process we called Pause and Learn (PaL). Most NASA projects last years; some go on for a decade or more. An AAR at the end of a long project would be almost meaningless with respect to design decisions made years earlier by people who may have left months or years before. So I introduced the idea of pausing during development at appropriate points to reflect on what has been learned so far. I called it Pause and Learn to make it unique to NASA and to distinguish it from an AAR. It focuses on group reflection and learning that will be valuable for the participants first and foremost. Participants are encouraged to share their perceptions of what happened and process the insights together. Because the PaL is local and real, it is seen as valuable. After PaL sessions, participants often comment that this was a lessons-learned activity from which they actually learned something.
Building on the PaL success, I focused on two other learning activities at Goddard. I set out to write case studies to help people think about the project and management aspects of our missions in addition to the technical lessons. I also started holding interactive discussion sessions often using these case studies to engage people in learning from prior missions.
Use Terms That Have Meaning for People
Rather than talk up the value of knowledge management to a skeptical audience, I used words the technical workforce understood and cared about, things like “cost,” “schedule,” “reliability,” and “decision making.”
I argued, for instance, that knowledge had to be better organized and shared at the working level so Goddard could assemble teams more reliably. The hook I used to explain this was asking whether it was important which engineer was assigned to a project. Many project managers were quick to admit they spent much time trying to get the “A team” of engineers onto their project. I had my opening. If the engineering branch as a group shared and organized their knowledge effectively, then it would matter less which engineer was assigned, because any engineer would bring the network of knowledge from the entire branch to the project.
Similarly, good decision making is a practice that all managers treasure. Using case studies, we focused on improving decision making, something managers could recognize as an immediate benefit to them and their team. Project managers who thought of their projects as unique could see that decision-making processes are similar across projects and they could learn from others. So we connected knowledge management to something considered a core cultural attribute at Goddard: the ability to make good decisions.
Brand Your Knowledge Activities
As the previous section suggests, what you call your knowledge activities and aims matters. While “knowledge management” didn’t resonate with project teams, “reliability” did. The names of things should tell what they are about and what their value is to your specific organization. So, for instance, I coined the term Pause and Learn to describe exactly what those sessions were for and to indicate that they were designed specifically for Goddard—not just imported from other organizations.
Start with Small Steps and Use What’s Already There
The PaL sessions and case-study-based workshops I’ve described were relatively small-scale and opportunistic knowledge activities. Based in particular projects and designed to create immediate benefits to participants, they justify themselves with clear practical results and encourage others to take part in similar activities. These relatively modest initiatives are much more likely to demonstrate their value and win converts than big systems that take months or years to set in motion and seem to promise big improvements at some unspecified future date. One of the many pitfalls of those large-scale efforts is they demand time and effort from participants long before they give any value in return. And the fact that they have large, general goals means they are much less likely to ever produce useful results than more focused modest efforts.
Other people at Goddard were already playing around with wikis and collaboration tools. The action I took was to not shut things down or assume a command and centralize approach, except in areas of IT commodities such as search capability. The more local efforts the better, and the more grassroots sharing and learning the better. Whenever possible, I encouraged and showcased good things others were doing. In the government, there is often an assumption that things need to be hidden or cost-cutting managers will whack whatever is not part of their own agenda. Clearly, that kind of approach would not work for knowledge management, which is supposed to be about sharing and openness.
Create Demand and Encourage Knowledge Management Converts and Evangelists
Participants in successful knowledge activities who tell their peers how those events helped make their projects successful are your greatest allies—their stories will do more to promote your knowledge management work than any arguments, presentations, and advertising you offer. Encouraging others to “sell” knowledge management for you helps make up for the fact that a chief knowledge officer only has so many hours in the day and can’t do it all alone.
On a similar note, the best way to ensure that valuable knowledge management activities become a robust and persistent part of how your organization does business is to “reproduce” yourself. Start investing in people who can take over significant parts of what you do as early as possible. You don’t want to be the sole source on knowledge management energy and therefore a single point of failure.
Ten Myths About Knowledge Management
These positive lessons about making knowledge management work suggest why some of the commonly held beliefs about knowledge management don’t work. Here is my top-ten list of false assumptions about knowledge management. Think about them as recipes for failure that should be avoided.
9. Collaboration can be “purchased” or sharing can be rewarded.
8. Knowledge management can be outsourced.
7. Anybody (who isn’t busy) can do knowledge management.
6. Knowledge management can be done by buying the right software.
5. Knowledge management can be independent of the business process.
4. Communities of practice can be established by the top.
3. Knowledge management is about centralizing knowledge content to use it more efficiently.
2. Knowledge management is really about databases.
1. Knowledge management is an IT function and should be given to the chief information officer.
As simple as these errors are, they are repeated over and over by people who hope that those failed approaches will work this time. If anybody ought to learn these lessons, it should be the people whose job is sharing lessons learned, but that is sadly often not the case. A main source of these repeat failures is the assumption that myth number seven doesn’t apply. Over the years, I have met dozens of knowledge management managers in various government agencies with no relevant experience who were assigned to “go do knowledge management” and given budgets to do it. One scientist-turned-knowledge-management-expert told me she had a $2 million budget and no idea what knowledge management was but was eager to find out. Another told me confidently, “I’ve got knowledge management all figured out. It’s just a matter of getting the right software systems in place.” Ten million dollars and five years later, this same person told a public meeting, “We now know that knowledge management is 80 percent people and only 20 percent software”—which he could and should have known at the outset. This is an expensive way to educate government leaders.
The Knowledge Management Journey
At the outset, I described my ten years at Goddard as a journey of discovery. Some might say I haven’t accomplished much by their metrics. I am the first to admit I haven’t accomplished all I wanted to do. When people go on a journey they often notice different things. It depends what you’re looking for. What I’m looking for and what I see is NASA as a vibrant, dynamic, pulsating organization—almost a living organism that needs to stay healthy. Knowledge management is an ongoing effort. When you join a gym, it’s not buying a membership that gets you in shape—you actually have to go there to work out and keep doing it. I set out to create exercises that would help Goddard be a stronger and healthier knowledge organization over time. I feel confident that those exercises are paying off and improving Goddard’s knowledge fitness.
NASA employees are busy working on complicated missions, so finding knowledge management strategies that fit within hectic schedules is key.
Featured photo credit: NASA/Chris Gunn
About the Author
|Edward W. Rogers is the chief knowledge officer at Goddard Space Flight Center. He joined NASA in May 2003 as the center’s chief knowledge architect, working first in the Safety and Mission Assurance Directorate and then in the Office of Mission Success. He became the chief knowledge officer in 2006 and subsequently moved to work for the center director.|