0

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
Improve this question
1
  • 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. Commented Dec 12, 2021 at 2:13

2 Answers 2

Reset to default
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?

Improve this answer
0

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.