I'm starting a new project and a perenial problem is how to set up a useful file structure. I can set up one up of my own devising that seems to fit the bill well enough, or I can ask the team for recommendations, or I can use the org template, or I can ...
Just wondering if someone's nailed this already.
Some of problems I'm trying to minimize:
1. Something people will easily understand and use/align with
2. Has a reasonably well understood place for all the documents we'll create
3. Finding stuff is as easy as it can be with minimal effort
4. Isn't just focused on being a PM's view of where documents should be stored, something the project team members will actually want Saving Changes...
Here are a few ideas. Folder structure can and should reflect the security/access levels needed by the staff. For instance, under a folder Communication there could be subfolders for Team status, Project status (to stakeholders), PMO status reports, Vendors, Misc, etc, There should probably be folders for official project document; those that might be required for audit and archive. Examples: Project Schedule, Budget, Quality, Scope Control, Issues, Risks, Software Control, etc. You get the idea. If agile, folders could be organized by Sprint, or by subject, with folders for each sprint within the subjects. This kind of structure can stand up to Windows Active Directory as well as software that layers over top of AD such as Sharepoint, MS Project, JIRA, etc.
...
1 reply by Robert Neil Wood
Nov 27, 2018 6:01 PM
Robert Neil Wood
...
Thanks John, security access is certainly a worthy consideration. However, it's not (currently) a factor in our current environment.
To further clarify my question, I can (and often have) set up a structure like:
Project Management -Planning -Execution -Control -Reporting -Closure Environment Vendor Mgt Procurement Scope, Strategy, & Objectives Requirements Architecture & Design Build Test -Unit -Integration -Acceptance Deploy Close etc.
And I may go forward with this same or similar structure again, but it's big, based on how I think to organize project files and at times I've had issues with team members who had different ideas on structure.
So I'm wondering if someone has a really good structure or approach that I can model this go-round.
Saving Changes...
Ed Tsyitee JrConsultant | Consultant Tucson, Az, United States
A lot of the project management software has a file system in place. Smartsheet Asana etc have the capability to create files for the project that are easily accessible by the project team.
You can set admin status for those files that the team doesn't need to access to-such as the stakeholder register or budget file.
What project management software do you use? Saving Changes...
Here are a few ideas. Folder structure can and should reflect the security/access levels needed by the staff. For instance, under a folder Communication there could be subfolders for Team status, Project status (to stakeholders), PMO status reports, Vendors, Misc, etc, There should probably be folders for official project document; those that might be required for audit and archive. Examples: Project Schedule, Budget, Quality, Scope Control, Issues, Risks, Software Control, etc. You get the idea. If agile, folders could be organized by Sprint, or by subject, with folders for each sprint within the subjects. This kind of structure can stand up to Windows Active Directory as well as software that layers over top of AD such as Sharepoint, MS Project, JIRA, etc.
Thanks John, security access is certainly a worthy consideration. However, it's not (currently) a factor in our current environment.
To further clarify my question, I can (and often have) set up a structure like:
Project Management -Planning -Execution -Control -Reporting -Closure Environment Vendor Mgt Procurement Scope, Strategy, & Objectives Requirements Architecture & Design Build Test -Unit -Integration -Acceptance Deploy Close etc.
And I may go forward with this same or similar structure again, but it's big, based on how I think to organize project files and at times I've had issues with team members who had different ideas on structure.
So I'm wondering if someone has a really good structure or approach that I can model this go-round.
...
1 reply by Anton Oosthuizen
Nov 27, 2018 11:59 PM
Anton Oosthuizen
...
Robert I think your structure is good and is typical of what is normally used. I do not think size should be a factor, if it makes sense then it is good. As an analyst my mantra is that when you do something you need to do it for me, not for you i.e. If those who will use the repository can understand it without elaborate explanation from you then you've done a good job. For me, not knowing you or your work environment, just looking at your proposed structure I will now where to find the right document, if it has been filed correctly ;)
On that topic, I have always found that document naming convention is important in helping the odd slow poke find their way around i.e. it makes searching easier and more effective.
A detailed structure is needed if you don't have a good search capability in the repository solution.
I'd suggest working with whichever stakeholders will most frequently access documents within the repository to develop a structure which fits their needs and then, as part of project closeout, migrate the documentation to a structure which is suitable for post-project document retention purposes.
Kiron
...
1 reply by Robert Neil Wood
Nov 27, 2018 6:16 PM
Robert Neil Wood
...
Thanks Kiron. I've done that too, many times. Was just wondering if someone had another approach or solution.
A detailed structure is needed if you don't have a good search capability in the repository solution.
I'd suggest working with whichever stakeholders will most frequently access documents within the repository to develop a structure which fits their needs and then, as part of project closeout, migrate the documentation to a structure which is suitable for post-project document retention purposes.
Kiron
Thanks Kiron. I've done that too, many times. Was just wondering if someone had another approach or solution. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The answer to your question, at least the basement, is Configuration Mangement. You will find it inside IEEE Std 1042 including good examples. It does not matter that document is about software it is applicable for any type of project. It is the basement because you will find there good "cook book" about what to take into account. Something obvious: is not about to create documents, it is about to maintain them.
...
1 reply by Robert Neil Wood
Nov 27, 2018 6:49 PM
Robert Neil Wood
...
Are you meaning a folder called Config Mgt or are you meaning that Config Mgt is a key part of any project work?
There is no "best" way as different stakeholders will want to use the information in different ways. In the science of Systems Engineering, a significant body of knowledge is dedicated to how the various information is logically organized, and a Systems Engineering Management Plan or SEMP is created up front to document how all that information will be managed. Data architecture is part of the overall system architecture. You can look up example SEMPs from multiple industries if you want to see how they're organized.
That being said, here is what I would suggest from a practical standpoint: Some information can be logically organized by project phase since it's really only used during specific timeframes. Within those phase based folders, I would tend to break things down by function of information such as business management, design, supplier management, etc.
Other types of information evolve from phase to phase, such as requirements traceability to product, verification, and closure activities. For these I would consider how the information is used and by whom. They can be broken out either by activity type, or by functional organization. If you have a few people dedicated to managing an activity while few others use the data, I would pull it out into it's own folder for convenience. By contrast, we have utilized a Lifecycle Product Team structure where your design team, manufacturing, team, verification, supplier management, product support etc. is more tightly integrated by product, in which case I'd break it out more aligned with how your WBS breaks down at a high level, and each folder would have sub-folders for the various functions supporting it such as design, build, etc.. By having the same basic sub folders under each function, it helps to know where to find stuff and see if things are missing.
On very large projects, we will spend a lot of effort developing a WBS that really guides these sorts of decisions. The data structure is organized much the same as the WBS. If you are in a more digitally enabled environment where the data is shared, i.e. linked from source to source rather than federated, it becomes even more important as systems accessing the data need to know where to link.
The bottom line though is if I'm a design team leader on the project, it's easier for me to have all my info in the same set of folders. If I'm the supplier management focal on multiple teams, I'd want all that in one place rather than scattered among the team folders. You can never please everybody. Saving Changes...
The answer to your question, at least the basement, is Configuration Mangement. You will find it inside IEEE Std 1042 including good examples. It does not matter that document is about software it is applicable for any type of project. It is the basement because you will find there good "cook book" about what to take into account. Something obvious: is not about to create documents, it is about to maintain them.
Are you meaning a folder called Config Mgt or are you meaning that Config Mgt is a key part of any project work? Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
Nov 27, 2018 6:01 PM
Replying to Robert Neil Wood
...
Thanks John, security access is certainly a worthy consideration. However, it's not (currently) a factor in our current environment.
To further clarify my question, I can (and often have) set up a structure like:
Project Management -Planning -Execution -Control -Reporting -Closure Environment Vendor Mgt Procurement Scope, Strategy, & Objectives Requirements Architecture & Design Build Test -Unit -Integration -Acceptance Deploy Close etc.
And I may go forward with this same or similar structure again, but it's big, based on how I think to organize project files and at times I've had issues with team members who had different ideas on structure.
So I'm wondering if someone has a really good structure or approach that I can model this go-round.
Robert I think your structure is good and is typical of what is normally used. I do not think size should be a factor, if it makes sense then it is good. As an analyst my mantra is that when you do something you need to do it for me, not for you i.e. If those who will use the repository can understand it without elaborate explanation from you then you've done a good job. For me, not knowing you or your work environment, just looking at your proposed structure I will now where to find the right document, if it has been filed correctly ;)
On that topic, I have always found that document naming convention is important in helping the odd slow poke find their way around i.e. it makes searching easier and more effective. Saving Changes...
Robert, I think it can be any folder structure as long as it is reasonably organised in a way that suites the project team. But then there are always issues with each structure.
We found a workaround to this problem by creating a 'Master Document' that contains the path/name of the document of every key file and folder. This document is usually a spreadsheet and at the root of the project folder. The only drawback is that you need to keep it up to date but then it works!
...
1 reply by Anton Oosthuizen
Nov 28, 2018 2:42 AM
Anton Oosthuizen
...
Good suggestion LK. I actually forgot that we use to do this on big construction projects where they required hard copy of all submittals and this approach helped us to satisfy part of this since the index needed to the printed as well. We did however automate the index by using a CMS. The index would be rebuild whenever a change is made in the structure or content.
