Project Management Software
Specialists in Project Infrastructure
Why do you need a Project Folder Structure
If the only reason you can think of is that it keeps things “neat and tidy” then I expect you have given it about as much thought as I had. There are a number of other reasons which I will outline.
Project Folder Structure Familiarity
The first is partly the “neat and tidy” answer but it also has to do with reducing the learning for people who move between projects. If they are familiar with a common structure, it is easier to file new things, and find old things.
Project Folder Structure Accessibility
In this ever converging world, things like individual Gantt charts get sucked up into project master plans. Common documents like a business requirements statement get used as models for other projects. If they can be easily located for each project, it makes life easier all round. If I am a new project manager and want to know what a BRS looks like, I can dive into other projects and quickly locate the BRS directory.
Project Folder Structure Organisation
Hands up those who have clicked down and down and down into subdirectories looking for a document and reached the end of the line only to find the file you were looking for was not there? By this time I assume you are sitting there with both hands in the air. You can put them down now.
Another reason for having a common structure is that we are not subject to the warped mind of someone who decides the issue register should be at the bottom of a folder structure called L:\IT\Projects\Financial Projects\2006\First Quarter\Project X\Miscellaneous\Updates\Recent\IR
After you have clicked away for five minutes following every conceivable logic path to find the register, you do a search only to find nothing. You then find out the 2006 refers to the end date of the project rather than the start date which was 2005. Incidentally, we changed the whole directory structure at the start of 2006 and migrated only half the files for Project X.
Options to Organise
There is no right answer to this question. There are two broad approaches:
Most times a mix of both are used. You have a phased top level with the next level devoted to functions. For larger projects, the top level may in fact be a business area. For example, it for an ERP implementation, it might be Finance, Manufacturing, Sales etc.
My Preferred Approach to Project Folder Structure
I prefer the structure as a combination of the two options above. Firstly, I ask myself what will span phases. Things like:
All tend to span phases. I firstly create a set of directories for these functions.
The second set of directories cover the phases. The next level down under phases is focused on particular activities within the phase. The first subdirectory is usually Planning which is for anything associated with Phase Planning. The next set of directories are for deliverables. For example in an initiation phase, I might have directories for:
These are all the things I need to physically deliver as part of the Initiation phase. A quick glance at my project plan should tell me the deliverables.
As a rough rule of thumb, I would look at a subdirectory if a directory was going to exceed 20 documents. These subdirectories may be split by time (Jan, Feb, Mar) or by Phase. If Change Control was going to generate 20 or more entries over the life of the project, I might create subdirectories under change control based on phase. Month could work equally well. It just depends on the expected volume.
I usually have a “slow throw” drawer or manila folder when I work in an organisation. Anything where it is not quite clear that it should be filed, but it is not clear that it should be thrown away goes on the top of the pile. Every month or three, I start at the bottom and review the bottom half to see if they should be filed or thrown. It is rare to find something that needs to be kept. On the other hand, about once or twice a week, I go back to the pile to check something I had kept. Usually it is only a week or so old.
For projects, I usually set up lots of archive subdirectories. Typically I rename the file by putting a date in front (060413 format) which can be easily sorted if I need to find an old file. Typically it is used as a crude version control mechanism.
Another area to set up is a working directory for each person. Here you can store documents that are in development and are incomplete. Once a document is finished (even as Version 0.1) it should be moved to a permanent directory. About once a month I ask everyone to take 10 minutes and clean out their working directory so the file numbers stay low and current.
Document Management Systems
There are a number of document management systems on the market that hold meta data about each document, and have powerful search facilities. If your organisation has one, you will probably also have a standard structure for storing documents. If not, you should purchase our Project Administrator software that has a built in document management system which describes each document and hyperlinks them. It also provides a document cover sheet which has dates, versions etc. on it.
Here is an example structure you might want to use as a starting point for your projects.
There is no perfect way to create a project file structure. If you do give it a bit of thought, you will save yourself considerable time and grief. It is too late when you have 100 documents in one directory to start getting organised. Spend some time before you begin and get a project file structure in place. Even if it is not perfect, you can change it later on