By Jon Verville, Patricia Jones, and Mark Rober
How Does a Wiki Work?
The NASA workforce is hungry for ways to improve collaboration. Wikis can help—and are helping—to do that. These powerful tools exist at every NASA center and across many levels of organizations, from wikis running on a temporary server for a team of five to others for the benefit of an entire field center. There are grassroots, bottom-up systems, originating to meet a particular need for a specific project or group. There are top-down institutional systems, provided for the benefit of a larger organization. Among other uses, they are helping project managers promote better communication within their teams, and engineers collaboratively document the results of their work.
A wiki is a web site that can be edited by its users. It tracks sitewide activity (typically called “recent changes”) and individual page history, provides profiles, and retains authorship information about every change. This enables community cleanup and policing of the site, generally called “wiki gardening.” With a wiki, there is no need for a flurry of e-mail to go around to discover who has the most recent version; a central wiki page incorporates all the changes made along with information about when and by whom they were made.
The ability to go into a site and easily update and enhance material is the game-changing feature of wikis. Since it is done through the user’s web browser, no special software needs to be installed. Of course, the openness to editing that makes wikis a powerful tool for collaboration also raises concerns. What about “contributors” who maliciously or ignorantly falsify content? That problem does occur on fully open sites like Wikipedia, but all the wikis at NASA we have encountered are open only to a NASA network. And they all require users to log in to make changes. This ensures that everyone is accountable for their activity, eliminating the Wikipedia problem.
Some Cases
The potential value and ease of use of wikis do not mean that they are readily embraced by people who have never used them before. These brief examples suggest some of the work that needs to be done to make them an effective tool in NASA organizations.
Goddards AETD Wiki (go.usa.gov/8mb)
The engineering wiki within the Advanced Engineering and Technology Directorate (AETD) at Goddard Space Flight Center had humble beginnings. It started as a grassroots effort in October 2009 within a group of about thirty engineers, the Microwave and Communication Systems Branch, under the name CommWiki. The leadership of the directorate heard about the work being done and wanted to learn more about it. Along with a team of other young professionals, Jon Verville put together a slide presentation that answered the question, “If this tool were to be deployed across the directorate for all our engineers, what would it look like?” At this presentation, funding for one full-time government employee and procurement of wiki software was approved.
From the beginning, the main purpose of the AETD Wiki was to capture “information living in experts’ e-mail inboxes, binders, loose papers, and brains” and enhance collaboration among engineers at Goddard. After receiving resources and developing a basic charter, the team decided that the best approach would be to choose a few suborganizations within AETD for a pilot study to gauge interest and learn how to adapt the tool to the organization. Five branches were chosen for the nine-month pilot study that ran from March to December of 2010.
Leveraging existing stores of information turns out to be a great way to seed information into a wiki.
These branches had very differing levels of success. Much of that difference depended on cultural factors, so we determined early on that it would be crucial to make as personal a connection as possible with each branch to identify and address these cultural factors.
One notable example was the Materials Engineering Branch (MEB). Even before the pilot officially launched, the MEB branch head, Mike Viens, had heard of the wiki. He was very enthusiastic and invited Verville to introduce the branch to the tool at the next all-hands meeting. The presentation was greeted with quite a bit of skepticism about both the utility and value of the tool, given the extra burden it could impose. During this first introduction, Verville discussed the philosophical and technical aspects of wikis. Viens continually pushed the idea of using the wiki in many different settings. His championing of the tool was tremendously important.
That summer, Viens had two interns devote nearly all their time to adapting existing material to the wiki. Much of this material was in the form of a handbook, the Materials Selection Guide, that had not been updated for more than ten years. The interns designed the way the material, information, and data would be presented and cleaned it up in order to make it accessible and usable on the web.
Some NASA Wiki Cases
Here are some quotes from our case study gallery, which you can visit by following the links or using your smartphone and scanning the QR codes.
Systems Wiki, Langley Research Center (go.usa.gov/8m2)
To drive adoption, the Space Mission Analysis Branch has started defining uses for which the wiki is the primary, and preferably only, documentation location, which they refer to as official uses. Once an official use is defined and enforced, system adoption occurs more rapidly as people have to use the wiki to either add or view content. For example, since Space Mission Analysis Branch leadership declared the wiki the official repository for software documentation, a gradual transition of documents has occurred.
Robotic Servicing Wiki, Goddard Space Flight Center (go.usa.gov/8mT)
If something on the wiki wasnt accurate, it was the subsystem leads responsibility to make sure it was changed immediately. Team members were constantly told by the project manager to put information on the wiki; otherwise, it didnt exist to him. It was this type of top-down encouragement to use the wiki that enabled the team to see its power of collaboration. Team members that were initially reluctant came around very quickly to its uses and benefits.
Leveraging existing stores of information turns out to be a great way to seed information into a wiki. Once this information was posted, the branch wiki saw a large increase in activity and additional contributions. Since NASA engineers have so much information to deal with, we found that organizing this material around the way the engineers think is critical to their being able to find what is relevant to them.
When our engineering directorate needed an intranet site for hosting material, they asked Verville to show them what the wiki could do. He prototyped some pages, which is very easy in a wiki, laying out the structure of the pages and doing some basic HTML/CSS coding so that it matched the look and feel of some other pages AETD had developed. The wiki is now the place where the directorate posts all the information they wish to share internally on the web. Directorate staff now easily keep the material up to date because they no longer need to rely on web developers to make changes.
JPL Wired (go.usa.gov/8mW)
JPL Wired is a Wikipedia-style online resource customized for and written by Jet Propulsion Laboratory (JPL) employees. Even though the staged rollout to the entire lab is not complete, it is open and ready to be used by anyone at JPL. The “big picture” goal is to capture all the great information that people have stored on their hard drives, in their file cabinets, or in their heads and put it in “the cloud” so everyone can have access to it. JPL Wired has been in a beta/live mode since early 2010 and now has more than 740 articles. It has had 38,180 site visits and 157,771 article views since February 2010.
A few distinct challenges emerged from the introduction and expansion of the wiki. Some key roles are important to success. These include a wiki champion—someone in management who has the authority to push the project, to get behind it and promote its use. The champion should be a respected individual. There also need to be people who will do the day-to-day “dirty work.” Also, it can be challenging to get people to edit other people’s material. The culture in general is reluctant to correct others’ work because people know each other (unlike Wikipedia where other editors are just another screen name). This is especially true if the original author is highly respected or considered an expert. Other users will readily change obvious things like an incorrect phone number but hesitate to edit important content. Some power users, those who will make changes, did emerge. Letting them share their stories about how it works to edit someone else’s material has helped free up others.
It is not easy to maintain the grassroots culture of a wiki with management support that conveys it as something valued by the organization. Having a system that management encourages the use of yet does not stifle from oversight is a difficult balance to maintain. Management must be willing to talk about and encourage the use of a system they may not be able to control.
Keys to Wiki Success
Experiences from these case studies and others in our Wiki Case Study Library suggest some practices and principles that groups developing and supporting wikis need to consider. These are some of the most critical:
- Wikis work best when they solve a problem that is evident to most of a group.
- Wiki use needs to replace an existing work process, not add to work.
- Wikis need advocates and advertising.
- Seeding the wiki with valuable content helps jump-start the process; with a blank page, no one knows where to start.
- Gradual growth is fine, and starting small helps a core group of users become accustomed to the wiki (think pilot study).
- A wiki that serves a niche need is okay; it does not need to be all things to all people.
Any great technological or societal change requires the alignment of technology, economy, and culture. The technology must be reliable and usable; the economics of adopting it must make sense; the organization or society must be culturally ready to adopt it. Our goal is to spread the stories of managers, engineers, and scientists who have adopted wiki technology and achieved a new level of collaboration, innovation, and efficiency. Wiki technologies have proven themselves to be usable, robust, and affordable. With wikis and other collaborative technologies springing up around NASA, we believe the technological, economic, and cultural forces have aligned to make us a more highly collaborative culture. We are excited about the conversation that can develop through uniting those who read this article and have a genuine need for better collaborative technologies. Please visit our wiki at go.usa.gov/8mC and join our mailing list at nasa-wikis@lists.nasa.gov.
About the Authors
 |
Jon Verville is an information-based systems engineer at Goddard Space Flight Center. He is the lead for Goddard’s engineering wikithe AETD Wikiand the architect for the NASA Software Engineering Handbook, an effort led out of the Office of the Chief Engineer. Previously, he worked for seven years in radio-frequency and microwave engineering for Magnetospheric Multiscale, Tracking and Data Relay Satellite System (TDRSS), and the South Pole TDRSS Relay. Connect with Jon online at http://go.usa.gov/9Zx. | |
 |
Patricia M. Jones is the deputy director of Exploration Technology at Ames Research Center. Previously, she was the acting chief and deputy chief of the Human Systems Integration Division. Before joining NASA, she was an associate professor of industrial engineering at the University of Illinois at Urbana-Champaign. | |
 |
Mark Rober is a mechanical engineer at the Jet Propulsion Laboratory (JPL). For the past six years he has designed and delivered hardware on several JPL missions, including AMT, GRAIL, SMAP, and Mars Science Laboratory. He is one of the primary architects for JPL Wired, which is a comprehensive knowledge capture wiki. |
