I’ve always enjoyed encyclopedias. As a child I found them indispensable for explaining the world around me. The wonder I experienced as a youth when discovering new information was only surpassed by the sense of accomplishment I felt when learning by doing. I have the same sense of wonder as an adult regarding project management, although at this stage in my life, I am less inclined to learn by doing and more inclined to teach what I know.
Thinking about making an encyclopedia of project management knowledge for my work led me to a major epiphany a couple of years ago. I was on vacation at Yosemite National Park. While standing at the overlook on top of Glacier Point and looking down at Yosemite Valley, I noticed a plaque showing the major landmarks. It had landmark names etched in bronze. I located Half Dome on the map in seconds. It occurred to me that some park ranger had grown tired of answering the question, “Is that Half Dome?” So he created the equivalent of a wiki post, but etched in bronze. Each year, thousands of visitors use the Glacier Point wiki without realizing it. 
I quickly realized that I could create the same valuable information on our project wiki by naming everything of interest to a vistor. A visitor could find the information they were looking for by reading a series of linked posts. In effect, I would create a visitor’s map to our project community. Visitors who are interested in the duties and responsibilities of our Financial Business Analyst need only to browse a few key pages to find the information they seek. I started naming everything, although I started with something easy.
We started with people. The expectation was that any time a person’s name was used in an article, it would hyperlink to a page featuring information about that person, but in the context of a project. This is not a profile page. It is project specific content focused on helping an outsider understand what a person does on each of the different projects we have open. We call these pages Project Resource Pages. Each page shows a picture of the person, gives a brief description of their job, describes who they work for, who they work with, and who works for them. After the generic descriptive information, we add sections that display related information flows (activity streams) of their project work. These are articles, comments, and tasks owed to other projects. In just a few seconds, a visitor can gain insight into how a person is contributing to the collaborative project management experience. The visitor is often me. I find these views invaluable when conducting 1:1 meetings.
We soon learned that what is good for project resources is also good for anyone participating on the project, so we added lots more people. We started with the staff of each facility, and then we added their teams. With this advancement, I could brief in a new project team member in a few hours. We did not stop with people, we added maps, directions, recommendations for hotels, lists of all computers and printers, pages for each piece of software in use, and pages describing business processes. In short, we created wiki pages for anything that would come up while working a project. New team members need only spend a few hours on the wiki to learn the “who, what, and when” story associated with a project. We reduced the need to answer questions about the project. Each time we bring on a new team member, we realize the benefit because there are no orientation meetings. It’s takes 10 minutes to point them toward the wiki, and away they go. Work gets done.
There are hidden benefits too. New members of a project team are often given the job of describing a process as a way to teach them about our project wiki. For example, a new team member was asked to describe every report that runs in batch mode on our old HP3000. We asked the he provide the report’s code and a sample of the report’s output. This task alone would be enough to keep him busy for a few weeks, but we also asked him to meet with the users and identify the report’s business purpose and its primary owner. In fact, we encouraged him to have the users collaborate on each post, editing as necessary and posting additional content where possible. After completing the project, we will gain a valuable information resource which will serve as part of a larger project next year. We also gain a seasoned content creator who understands how to structure meaningful project information and connect with users. I call that a win, especially considering that he was afraid to use the tool.
One of the unanticipated benefits of naming things is that we now have tools for monitoring parts of the project that we never thought to manage before. For example, we have a page named “CERT”, which describes software created in-house. It’s used to make product certifications. Now that is has its own page with sections summarizing its activity stream, we can keep up-to-date on its operation by monitoring it. Plus. we can see how others are using it and adjust our planning based on news from the activity stream. Seeing how other people interact with the software translates into less time lost to unforeseen circumstances. It reduces the, “you don’t know, what you don’t know problem in project management.
In our quest to name everything we’ve discovered a few problems. The most notable problem is change. People come and go. Our wiki is old enough to hold several generations of project teams. I was just looking at a picture of a team from three years ago. Not a single member of the team is still working for us. Everyone has moved on. Besides the coming and goings of team members, people change jobs. Maintaining the information is every bit as important as creating it and you must plan for it or it will not happen. We’ve opted for a refresh at the start of every new project. It’s working so far, but I foresee problems with this as the number of articles grows. Right now we are at about 10,000 articles in our project workspace alone.
Another problem was less obvious. When we started down the path of naming everything, we tended to work within projects. We soon found that there were multiple copies of named things. We realized that we had to remove the duplicate entries and make the original entries project neutral. In other words, we need the information to be generic enough to cross multiple projects without hurting its value to a specific project. This is no small task and requires constant attention. A set of guidelines would have helped, but we did not foresee the problem.
Our successes are important too. We find that naming things helps reduce the need for meetings, emails, and training time. Plus, we want the casual user to move through the information and find meaningful content without the need to search for it, or worse, ask the PM. For example, lets say a user lands on the John Smith resource page and sees that John is working on three projects. The visitor would follow hyperlinks to each project’s home page and find a wealth of information in the form of articles each with hyperlinks to hundreds of named resources pages. If they get to a project homepage, the chances are pretty small that they will aks a PM for more information. Users, customers, managers, and project team members should be able to find important information without bothering the project manager. The PM needs to work on strategy and recovery planning. Of course, if he’s a smart park ranger he builds a useful wiki along the way.