Discussion on:

Sample directory structure helps manage project documentation

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.

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 .....

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).

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.

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 ??

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!

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

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.

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?

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