Do better than the Ancient Egyptians - Have a well organised Project File

Historians have deduced that the Ancient Egyptians must have had very poor filing systems - this is why they chose to write all their history on the walls :-). You need to be careful not to repeat this situation in your Project else the team will have difficulty finding useful documents / information resulting in communication problems, a loss of productivity and a lack of auditability.

Here is my suggested check-list for establishing and using a Project File

1) Shared File Store

First and foremost you need a Shared File Store which all the Project team can access. The old fashioned way of achieving this was a Project folder on a Shared drive. This can still work although many organisations have SharePoint and you can establish a Project specific site. SharePoint has a number of useful features which you don't get with a Shared drive such as Document Check-Out / Check-In, the ability to make a more interesting site through web-parts etc. 

Please check that this shared file store is backed up, ideally nightly.

2) Create a Project File Structure to aid easy retrieval of Information

Don't assume that your team will organise things sensibly, they won't! So dictate a sensible structure. Give this some thought, it will pay dividends in the long term. So for example, in IT Projects adopting a waterfall SDLC type life-cycle you might have a Management folder plus one for each major phase. Then I would encourage use of sub-folders below this basic structure.

3) Communicate structure and dictate usage to the team

Make a summary document about the structure and communicate this to the team. If it is a SharePoint site, this introduction to the structure can be made prominent for "new users" of the site. 

Tell the team that they need to use the Project file when drafting new information not just when submitting for review (every heard the story about the person who lost a months work on a draft document stored on the "C:" drive when it failed?).

4) Use link to Project File in Emails

Ensure the team utilise links to documents within the Project File rather than embedding them in emails which wastes space on the organisation's email servers with duplicated copies.

5) Consider document version control practices

In general terms I adopt the following principles on document versions.

• Drafts should progress through versions 0.1, 0.2, 0.3 etc 
• When the document is baselined (see previous post on document quality) it moves to the next integer, typically 1.0 for first baseline, 2.0 for second baseline. Ideally I like the evidence of signoffs to be embedded in the baseline document

Some practices will change depending on the technology used for the Project File:

• Shared Drive - To support configuration management, I like the version number included in the file-name
• SharePoint - This should be set-up to maintain versions and the version number should always be excluded from the file-name. I have yet to crack using the SharePoint version within the document (let me know if you know how!) so for me the version number embedded in the document change history section is the Master version label

Lastly - Stamp on "poor team behaviour"

You have communicated about the structure of the Project File and how it should be used as above. But you need to acknowledge that your team are humans and humans are set in their ways. Remember my post on Newton's 1st law of motion (People tend to continue travelling in the same direction.....unless acted on by an external force). 

So be prepared to call out poor team behaviour (e.g. emailing documents around) and by catching this early you will get the team all pulling in one direction in the use of a well structured Project File which will be a useful asset in your Project execution.