I am new to project management and would like to know, where is a standard either a best practice to define name of project folder tree in the filesystem, or SharePoint.

Maybe there is something defined/derived in relation to ISO 9001/PMP?

Example, somethning like this? I do understand this can be very context specific, but maybe there is some sort of meta-requirement based on best practices?

01 - Kickoff
02 - Plans
03 - Protocols
04 - Orders
05 - Invoices
06 - Milestones
10 - Manuals
11 - Specifications
  • I think Vicki's answer is on the mark, but also feel like there's insufficient context to make this more than a search or opinion-generating question. If you could add some detail about what practical problem you're facing with your current folder structure, or what problem you're trying to solve, that would definitely make it more useful to others and more on-topic. If you look hard enough, someone defines a "standard" for everything. That doesn't make it useful, practical, or widely-used, so there may be an underlying X/Y problem we can help with.
    – Todd A. Jacobs
    Commented Dec 12, 2021 at 2:13

2 Answers 2


I don't have any experience with this use case, but there's a general guideline for datastores that would seem to apply: organize from the perspective of the questions you will be asking when you want to get data out of it.

So, when will people come looking to find things in this tree? What questions will they be asking? What will make it easiest to find what they are looking for?


Every place that I worked had a different standard, usually defined by the Project Office / Project Management Office. Your suggested layout looks reasonable, but without knowing your specific organisation, it is hard to be specific.

Your suggestion combined deliverables and stages into a single structure, so one possible alternative that I have seen is to structure the documentation according to the phase of your project. In such a structure you might have a folder structure for Project Startup, one for Design, one for Development, one for Handover, one for Close Down, etc. But then you still need to know how to build a sub-structure that makes sense within that high level structure.

I can't comment on the documentation that you would adopt for a more agile project (my experience is all gained in Waterfall), so I'll leave that for others to answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.