Please login or join to subscribe to this thread
I prefer go by the project phases. In my case as it is customized to suite my industry that is software development. Hence the level below the root project level (with the project code) has the sub folders corresponding to the project phases. By doing this way it's easy to track any documents later in the project life cycle. It is also very important to place the documents or any other items in the right folders other wise there is no point of having a excellent folder structure. Sometimes you feel like putting the artifacts in to more convenient place rather than the best place due to the heavy work schedule, etc. But you will have to spend far more time to search for those documents when you need lately.
Project documentation organization by project phase has been extremely useful to folllow the changing nature of the document in question.
Also, organization by phase by project component track is useful. Project component tracks could be Process/Performance Management, Org Change Management, Data Mgmt., Requirements Development, Design, Construction, Testing. Operations Planning etc.
As one of the members have asked for some of the details on how I am doing this. Thought of sharing the following information with you all. Please read the file below.
I keep most of the project management documentation in a folder called project administration. This contains the pm project deliverables. For the rest of the documentation it is up to the discretion of the functional manager over that team member. They will normally have a standard for what is needed for after the project transitions to support.
Hope this helps,
Hi Robert, great post and replies by all. Of course, there is no one best approach, so the answer is to pick an approach and make it best. We see many PMOs having a policy for document management that among other things provides a recommended approach for project folders. While there can be an initial desire to organize project folders by process group or phase, this can often be problematic as many project documents span multiple processes or phases. We see many PMOs having four kinds of first level sub-folders for project documents; PSR for project status reports, MOM for minutes of the meeting, DOCS for project documents, and APPROVALS for signature documents. Whether the repository of the organization is a well organized network file share or a vendor platform like SharePoint, having a common approach (policy) for project document folders enables all involved to easily access completed project documents. For many, the value of having a common approach that everyone adheres to is likely to be of more benefit than having the "best" folder structure - whatever that may be. Good luck..!
The first question you should ask is this:
"Who are my key stakeholders that will care how this is organized?"
After you've identified WHO, organize it to work best for them. For me, the answer to this question has always been the project team members...the ones who are actually doing the work. They will need to reference requirements and design documents. The executives involved don't go looking for a document anyway; if they want to see it they just ask.
We prefer to have it arranged by phases since it is how we monitor deliverables and status of the project. This way it is easier to check documents and other stuff related to the phase we are into. We just have separate folders for other PM administrative tasks such as resource monitoring.
In this case, let me go with the flow. :-)
Generally, we also create the directory structure that follows the Project Life Cycle, i.e. its phases.
Additionally, there is a directory structure accessible to project team only and a parallel structure accessible to other stakeholders, including the customer. The purpose of that approach is to protect the team from too many lateral interruptions and comments while working on project documentation (and/or deliverables).
I know this is an old thread but I thought I'd weigh in. We organise by workstream, so there is a folder for PM activity, subdivided into plans, comms etc. Then there is a Technical workstream folder where the IT guys store network diagrams and their subplans. There is typically a Requirements folder as well.
We do what Josh said: it's the project team members using it so it has to make sense to them. If there isn't a suitable folder at any time then we create one. It works for us.
There are different ways to organize your project documents. I agree that you need to pull together the immediate users of these documents and ask them what would make sense for them to make it easily accessible.
What I have done in the past is to sort documents by project or programs and then sort it by document type; e.g. project charter, risk board, etc. It would be good if your documents are online so that you can cross reference them easily by tags. Some collaboration software would easily allow you to search documents by whatever tags you use - it could be by project phase, document type, project name, project dates, cost, etc.
Please login or join to reply