Project Respository - Creating a Structure for Project Documentation

When starting a project, one of the first steps is to define a project repository that can effectively collect project documents and can help the entire team in maintaining a productive team and project environment.  There are many ways to create a repository, you can use web-based collaboration tools, one such tool could be Google Docs; you can use sophisticated / developed document management and collaboration technologies, one such tool is Microsoft SharePoint; or you can use a simple directory structure.  Here I will give some examples of using a directory structure since that can be used by almost anyone in any work environment; the structure can be applied to more sophisticated solutions as well.

Regardless of what method you use, you need some fundamental guidelines for using and maintaining a quality respository:

• Guideline 1:  The project manager is the "owner" of the repository and ultimately responsible for the quality and content.  For large projects a "repository owner/manager" can be designated.
• Guideline 2:  The repository's use must be required for ALL team members.
• Guideline 3:  Some level of standards must be applied to ensure consistency.
• Guideline 4:  In each directory and sub-directory, add a "_readme.txt" file that describes how to use the sturcture.  This way the instructions to maintain consistency are easily available.

Option 1: One approach is to create a structure that mimics the existing or defined project management methodology that is used in your organization.  The benefit of this option is that documents can be stored based on the phase that you are operating under and it will reinforce the method that the project managers should use.  The drawback of this option is that the structure might not be very intuitive for people to work with.

Option 2: Another approach is to organize the documents based on a set of standard documents that are created during the project life-cycle.  The structure can be modified to include or remove certain groupings.  However, the high-level groupings / directory names would be consistent from project to project.  The benefit of this option is that it is easier for project managers to work with during the project life cycle.  The drawback can be that over time, the grouping and conventions might sway from the original intent.

A readme file, for instance, could say something like:

business_case directory is used for:

- project justification/feasibility assessment
- cost-benefit analysis or return on investment
- overall plan/timeline/etc.
- pros and cons
- decisions

Keep your naming conventions / standards simple, clear and easy to use, for instance:

1) Use all lower case letters with underscores to separate words. This will allow for easy copy/paste/publish on multiple platforms, e.g., WebServers, UNIX machines, Windows, etc.

Example:

name_qualifier

meeting_agenda_minutes

2) Keep names short and descriptive: 8 characters to 25 characters (if possible)


3) Whenever possible, add the project acronym to the file names for easy searching, retrieval and grouping.
Example:

[acronym]_[file_or_directory_name]
hr_requirements
hr_designs
hr_training

dw = data warehouse
dw_requirements
dw_rfp
dw_designs
dw_training
dw_business_case


4) For date-specific files/information (e.g., meeting agendas and minutes), use the format:

[yyyymmdd]_name
Example: 20070113_design_mtg_agenda

Whatever method works best for you, use it consistently, improve it over time and establish some simple guidelines so people know what to do and how.