The Art of Project Management: Expert advice from experienced project managers in Silicon Valley, and around the world
TOPICS:

Knowledge Management for Virtual (and non-virtual) Teams

knowledge managementProperly managed project documentation is critical for all types and sizes of projects. After all, the project documentation is the only real output from most projects. It is not the prototype that matters. It is the production documentation that includes things such as material lists, part drawings, assembly instructions, diagnostics, and source code that defines our products and services. I’m sure this is nothing profound to any of you. However, what you may not realize is that making it easy for everyone to find the latest version of a given document is especially important for virtual teams. Virtual teams often consist of people from different time zones or who work different schedules (i.e., a four-day week). As such, these teams rely more heavily on online sources of documentation throughout their work week. If they struggle to find the latest documentation on some aspect of the project that affects them, they’ll waste time sending e-mails, calling around or worse still, end up using an outdated version by mistake.

The obvious solution for most teams is an on-line file sharing mechanism of some sort. What? Did I hear groans? Oh, yes, I understand. Like you, every time I search a project document repository for something I need, I have a hard time locating it, if I find it at all. I’m sure you’ve all experienced these project file-sharing nightmares. What starts out as a relatively simple and clean place to share documents quickly degenerates into a mass of detritus, empty folders, interim versions, and other junk. Eventually, inevitably, and even predictably, the project file share gets so clogged that nobody can find anything. Everyone then falls back to contacting the owners of the documents they need, which is a total waste of valuable project time.

So, why does this happen? Here are a few of my favorite reasons:

  1. No organizational standard. There is neither a standard structure nor training on how to utilize a project share, so people treat it as another folder for data as if it was an extension of their desktop (and those poor IT folks have to back it up each day!)
  2. People being too helpful. To be ‘helpful’, some people load up the project share with everything they consider even remotely helpful: Web links, research papers, prior project documentation, every version of their work-in-progress, etc.
  3. Inappropriate use of the share. Because they are told to use the project share for documentation, people upload items they would normally just e-mail to those who primarily need it.
  4. Old versions not archived. Document versioning is used, but older versions are not moved to an archive, making it hard to figure out which is the most current. Confusing this further is that people mark document revisions differently.
  5. Everyone organizes things differently. If everyone has permissions to create a new folder on the project share, they will do so whenever they can’t find a folder that suits them for their immediate purpose. They give no thought as to how the site is structured (or they may not understand it) before they save their documents, making it hard for people to find the documents later. It is very common for even the person who stored the document the first time to not be able to locate it later. The share essentially becomes a ‘Write-Only’ repository.
  6. Empty folders. The organizers among us create containers for documents based on our ideas of the ideal taxonomy. There the folders sit, for the entire project, completely empty. It becomes a ‘shell game’ for people looking for documents.
  7. Nobody is in charge of cleanup, so out-of-date documents, WIP, and documents no longer needed stack up like old shirts in the back of our closets. With nobody in charge of cleanup, things pile up until the really important material is lost like the proverbial needle in a haystack.

The good news is that, with a few simple rules and a bit of discipline, you can fix this problem. Here is what I’ve found that works well:

  1. Assign a librarian. They don’t have to be the only who has write access to the share, but they should be the only one to create new folders. Choose someone with decent organizational skills. You will know them by how clean they keep their desktops (both physical and computer).
  2. Try for no more than 8-10 folders at any level. In the above example, there are five folders at the highest level. When the number of folders gets too high, create another level of folders and group similar documents in those.
  3. Archive prior versions into a folder called “archives”. This is the garbage can that gets deleted at the end of the project. Nothing is lost, but the primary sharing areas are kept much cleaner.
  4. Version your documents. Maintain a standard naming convention for versions. If you have a document repository that takes care of versioning, use it. If not, tack on something like “-v1.01” to the end of the file name, ahead of the file extension (i.e., filename-v1.01.doc).
  5. Notify people of changes. Each person uploading a new version of a document should notify all pertinent parties (per the RACI chart). Some document repository tools can do this for you.
  6. Keep the folder structure simple and standard for all projects across the department. Obviously, a standard structure makes it easier for people working in multiple projects, as well as department management, to locate documents. Here is an example of a structure for a typical project:

Project XYZ

Specifications

  • Project Data Sheet (PDS)
  • High-level milestones
  • Detailed project description
  • Detailed product specifications
  • Target customer(s) details
  • archives

Detailed Schedule and Tasks

  • Work Breakdown Schedule (WBS)
  • Task assignments by team member
  • archives

Team

  • Roles and Responsibilities chart (something like a RACI table works well)
  • Project team bios
  • Contact info
  • Org charts (if needed)
  • archives

Financials

  • Budgets, cost tracking, etc.
  • archives

Deliverables

  • Folders for deliverables as required
  • :
  • archives

If you follow these simple rules, your project documentation will be easy for people to find, so everyone will be more inclined to go there when they need the latest versions. This means communications and document management are improved, which is all we need from a file share space anyhow.


Loyal is an expert in the use of collaborative technologies for virtual teams and has led advanced technology research teams chartered with improving the effectiveness of virtual workers. He and his team of experts are currently building a support site for virtual work at http://commutezero.com/. Feel free to visit and contribute to the effort.

Share

About the Author

Loyal has more than 28 years of project engineering and management experience in R&D, manufacturing, and information technology. He has worked in the high-tech industry as a design engineer, R&D section manager and manufacturing engineering manager, and has led teams that included virtual and telecommuting contributors from all over the world. He is an expert in the use of collaborative technologies for virtual teams and has led advanced technology development efforts to improve the effectiveness of virtual workers. He is founder of calendarism.com and leads a blog site for virtual teams and collaboration tools at commutezero.com. He has a degree in Electronics and Computer Science and lives in California's Silicon Valley. Loyal can be contacted at loyal@commutezero.com
Creative Commons License
Note: This work and all associated comments are licensed under a Creative Commons Attribution-Noncommercial 3.0 United States License.

Leave a Reply

*