Author: Neville Turbit

Overview

I was recently asked to provide advice on a folder structure for projects in a large organisation. Like most project managers I have developed a number of structures but never given it much thought. The project file structures sort of grew organically. I checked Google and that was not much help either. It was then I thought it was a suitable topic for a white paper. It may sound trivial but the more I thought about it, the more factors started to emerge.

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:

• Organise by phase so that each top directory is a phase. For example, you might have directories for Feasibility, Business Analysis, Design etc. or whatever your phases are called.
• Organise by function so that the top directory level are functions. For example, Risks, Requirements, Scope, Change Control, Development.

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:

• Issues
• Risks
• Budgets
• Change Control
• Weekly Reports
• Steering Committee Minutes and Agendas

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:

• Project Charter
• Resource Recruitment
• System Setup
• Equipment Purchase
• Induction Training
• Miscellaneous

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.

Subdirectories

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.

Working Space

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.

Example Structure

Here is an example structure you might want to use as a starting point for your projects.

Summary

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

Copyright Project Perfect