Please login or join to subscribe to this thread
Just like all other artifacts in a project, the folder structure will change project to project - it will be dependent on the structure of your scope, team and plan. For instance - if the project is the delivery of a web based, 3rd party provided HR system, then the plan and folder should be divided into the major elements of scope, RFP related, integration (if required), UAT, etc. If the project is internal application development, you would see the scope, requirements (including the various sub types), plans, team folders (BA, Development, QA, etc.), meeting communications, etc.
I don't use the process groups as not everyone understands them. I use Project Documents, Plans, Budget/Contractual, Meetings (sub-folders for team meetings, project board) and then typically a folder per workstream so people can put their specific info, requirements etc in there. I number the folders 01_TITLE so that I can order them alphabetically and they all line up nicely!
How good is the underlying search capability of the system you are using to store documentation - if it's good why not just throw them into a few top-level folders vs. developing a complicated hierarchy?
Below are few Tips
1. Structured way to Create Folder - Sub Folder -as per project organisation need
2. Define a Administrator / Role to manage these folders / sub folders landscape
3. Provide access to user like create change display delete wrt folder subfolder files
4. Group e mail trigger for create / change / delete functions
5. Version & varaint control features for duplicate or restrutring
6. Monitoring meeting as per need monthly / quarterly to review this data/process
6. Archive or data security control in place.
Folder conventions are a personal thing, in the absence of some organizational standard (ie. through a PMO or PMIS). Whatever you come up with, I would suggest getting buy-in from the people who will be using it. Have a short meeting on the structure and get consensus. That way you will come up with something in no time, and they will be happy with it.
Agree with Sante.
In my case we have organization wide common directory structure used for all projects. I think one sitting with all stakeholders including PM, SCM, SQA, development team, testing team etc should be able to arrive at a directory/folder structure
In our case we use our governance process steps to name and create portfolio/program/project folders maninly to maintain trazability too.
Keep it simple. I have found that over organization leads to more chaos and added difficulty in finding stuff. Don't go more than 2 deep and keep the structure basic in a way that anyone can understand, not just a seasoned PM.
Also, leverage the systems versioning to managed files instead of having many versions of the same with a v1,v2, etc. or the date. That will naturally reduce clutter. If that is not possible, manually archive versions into a separate folder every month or two, or whatever makes sense.
Yes, keep it simple, nobody wants to search for documents in a complicated multilevel file structure. Use a tool - if you can - with overall search capability. If your team members work on different projects, a common standard is helpful. Create document name standards.
Here is an example I used:
01 Meetings SteerCo, Internal Meetings, Agendas, Meeting Minutes, Contact List, Orgchart, Communication Plan
02 Schedule & Effort Baselines schedule, budget(efforts), PMP (processes), milestones, external dependencies
03 Actions / Decisions Action Tracker, Open Point List, escalation management
04 External Support SOW, RfP, decision criteria/matrix, Proposals, Contracts, Assignments(Orders), deliveries, quality checks,
05 Actuals, Monitoring & Reporting Status reports, effort tracking (internal/external)
06 Change Management Project CRs, Project Change Log, Change Control Board Meetings/Decisions
07 Project Scope scope (deliverables list, WBS, scope statement), Requirements register/backlog, pre-project results (business case, SOW), Project Mgmt Plan (Processes), acceptance criteria,/DoD, acceptance letters
08 Project Risks Risk Register, Contingency Plans
09 Financials (restricted) Budgets/rates in €, invoices, plan/actuals in Euro, ProQuest CRs
10 Stakeholders (restricted) Stakeholder Analysis Engagement Plan
Please login or join to reply