Leadership

Sample directory structure helps manage project documentation

Project managers on large projects should plan ahead for how they want their documents to be organized, stored, and retrieved. Here's how to set up the document directory.

Large projects tend to generate a lot of documentation. If you're not careful, these documents will become disorganized and require extra effort from the project team to find, store, and manage. Project managers on large projects should plan ahead for how they want the documents to be organized, stored, and retrieved.

There are many aspects of project document management. One of the things you need to define is a directory or folder structure that provides guidance to team members on the specific locations for storing documents.

The first step is to define a logical view of how the documents should be organized. The logical view just means that you place a draft on paper for feedback. Once you have agreement on this view, you implement it in the specific directory structure or tool. The structure should be one that's easy to understand and easy to use. I recommend that the document repository be comprised of four main areas:

  • Project Deliverables. A directory for storing all project related deliverables. This is further broken down into subfolders to provide more guidance on where specific documents should be stored.
  • Project Management Deliverables. A directory for storing all project management related deliverables (Charter, Status Reports, Communication Pan, etc.). This is further broken down into subfolders to provide more guidance on where specific documents should be stored.
  • Reference. This directory is used to store documents that are used as input to the project, such as architecture definition, client organization charts, training material, graphics, etc.
  • Work Area. This area includes a directory for each team member to use to create work products. Each team member can organize their directory in whatever manner makes sense to them. There is no standard structure.

The following directory is an example of how you can use the four areas above to create a directory template that can be used on all projects.

Project ABC (place your project name here)

\Project Deliverables

\Final
\Draft
\Work in Progress

\Project Management Deliverables

\Project Definition
\Communications
\Presentations
\Financial Information
\Logs
\Miscellaneous
\Workplans
\Status
\Meeting Minutes
\Reports

\Reference

\Tutorials
\Templates
\Other Reference Material

\Workarea

\Team member 1
\Team member 2
\(etc..)

11 comments
mudassar.raza1434
mudassar.raza1434

Suppose you are responsible for project analysis and planning. How you will documentation. (Make relevant assumption)

GL44
GL44

All of the comments made have value. Here is my list of issues to consider when deciding the structure to use and the type of storage mechanism. When deciding on the structure you should consider: 1) What entities and kinds of entities need to be stored? 2) Who wants access to it? 3) Why do they want to access it? 4) Do any entities need to be accessed by more than one project or person? 5) When if ever will an entity become a ?production? entity & how is that decided? 6) Does your organization have existing standards that need to be adhered to? When deciding the type of storage mechanism you probably want to consider: 1) Is authority to access or change and entity and issue (Change Control issues)? 2) Who decides what goes where (Ownership issues)? The article listed one approach to classifying entities. Another one would be: 1) General Issues a. Project background b. Entities that are referenced only c. High level designs or specifications 2) Deliverables a. Documentation specific to that deliverable (specifications) b. Production versions of that deliverable c. Notes about problems, etc for that deliverable This approach assumes that work area issues are handled by another mechanism such as the person?s private work areas. I don?t think one classification system is automatically better than another one, but some work better than others for individual projects Two issues that seem to have a large effect on my approach when deciding on a classification scheme are the kinds of entities that are shared between projects or project members and when to classify something production or semi-production. Does anyone have suggestions on handling these two issues?

bcastle1986
bcastle1986

On the projects that I have worked, we use underscores and dashes to link the words (e.g. Project Management Deliverables becomes Project_Management_Deliverables). This allows for very easy creation of hyperlinks when referring someone to a folder (i.e. in an email). It can be done with spaces, but many people in a hurry do not right-click edit the hyperlink. Of course for programmers, we are used to removing the whitespace altogether (e.g. Project Management Deliverables becomes ProjectManagementDeliverables or for the C code version projectManagementDeliverables). Regarding the actual folder structure, use what works for your situation. ?Use what ever works, but use something.? It is better to have a plan and modify it to fit reality than to not have a plan at all.

stephen.burns
stephen.burns

Instead of storing your project documents in folders, store them in you change management/change control systems, along with your software, database designs, data dictionary, and everything else. Then, everything the project produces is managed in the same way. Design documents, project reports, all project documentation should be treated with the same respect as source code. Folders... like using a stone axe.

mhullin
mhullin

Is anyone using Office SharePoint for this? With workflow management, version control, and a "directory structure" layout, it seems ideal for this.

PMPsicle
PMPsicle

Someone else has already hinted at this but ... Whenever you're dealing with choosing a tool you need to make sure people are talking the same language. In this example ... To a programmer the focus is on code. So any package which is designed for the programmer will focus on storing code. And (comparatively) will do the job quite well. However, if it does any documentation versioning/storage it will be a) an add-on, and b) rudementary. We generally call these applications Change Management systems (why - they were the first). To a business/systems analyst the focus is on requirements. Applications designed for these people tend to focus on the retention of UML documents. They tend to be called Requirements Management systems and are reasonably new to the market. With a project manager the situation is a little more complex. In this case, the focus is on documents - any type of document. Generally speaking a package which manages this is referred to as a Document (or Workflow) Management package (Documentum was mentioned). What makes it more complex? PMs often have a seperate system (called either a Change Management or Issues Management system) which provides control over project-level changes (not code level). Most of these packages do not provide a link to a document management system since PMs tend not to work that way. The point I'm making is that most (code) change management systems will not provide the flexibility/control needed by a PM. And many (most?) companies do not have Document Management systems generally available (even if they do have a Change Management package). To make matters worse, most DM systems really don't handle the project process well. What Tom has provided is a basic structure which does handle the process. If you have a DM package available (perhaps as part of a (real) PM package) - great! If, like the rest of us, you don't - then what Tom is suggesting is a good stop-gap. Two other points ... Most DM packages don't force a directory structure on you ... they handle only the versioning leaving the organization to you. So the article's structure would still be needed. Second, you'll notice that nowhere in Tom's suggestion is there any reference to code (or requirements for that matter). That's someone else's job!

francois.guely
francois.guely

As the project management director, I have tried both approaches. In fact for non text documents (specifications for instance) folders are indeed the simplest and best approach, for several reasons : - letting everybody entitled to do so to access the documents, even the company boss for instance... and not letting everybody use the change control software (definitely not for everyone) - there are many differences between document management software like DOCUMENTUM and change control like CVS. If you wish to go beyond simple folder based management, Documents should be taken care of in a document management system (which for instance takes care of sophisticated workflows, and manages content, which is different from source code).

jeraldj
jeraldj

Storing them in Change Management is not as user friendly compared to folders. It also depends on the organization size, Lack of full Technology expertise, like SMU can use folder structure which is faster & flexible in reach rather Change control systems...... This is my opinion, so kindly comment on this .....

jeraldj
jeraldj

Taking DM into Consideration, there are no any Standard rules or we cant frame a rule to maintain the Directory structure, hence resulting in Less force to the organization on maintaining a directory structure. And DMS cannot be developed flexible to all Industries and verticals. Some scenarios like as we discussed Programmers concentrate on Code, we cannot have a universal concentration on one document structure encompassing all departments. So DM cannot force a structure to follow orelse the Customization of the DM tools goes for a toss.... Now comes the Question, if we are going to Develop a DM to suit this environment and Issue, How can a DM be developed for this Scenario...... Because our company is in a urge of developing a DMS, So these sugesstion can help us to track these issues in Future.... Kindly comment on this

Ivy Clark
Ivy Clark

We're looking for a tool suitable for Change Control Management with some workflow management included as well, and it's proven very challenging! Tools in the market seem to handle microsoft documents ok, even with versioning, promotion to production environment, etc. Unfortunately, if we have databases to update and java objects to deploy, it is still not so straightforward. Which means even with the automated tools to manage the documentation, and some of the source code; an additional (more manual) workflow still needs to be in place. But I guess it's better than filling out a change control form for each of the files that we need to promote to production.

jeraldj
jeraldj

Dear Clark..... I do agree that change control systems are proving challenges, but in the field to promote production, acessibility thru-out the hierarchy???? does this not come into the table of Constraints ??

Editor's Picks