Effective file organization for managing projects
If everyone on a team is not on the same page when it comes to file storage and keeping everything orderly, the result can often lead to a mess that will require a project-sized effort to fix the problem.
One of the more interesting aspects of executing and then managing projects over a number of years is that the project manager gains the realization that things left unsaid—often because of the assumption that everyone sees the iron logic and perfect reason in doing something a particular way (yours, naturally)—are actually the things that are the most important to talk about, however mundane and pedestrian they might be.
The way the project manager, might do something is likely directly at odds with how people on your project think it ought to be done and if everyone is not on the same page, everyone will do it as he sees fit and the result will be a mess so deep and tall that it cannot be cleaned up without a project-sized effort on its own. One of those things is file storage.
Every lesson comes with scars, and this lesson was no different. In this particular projects, the realization came when the file management arrived at a point not too terribly different from an electronic version of the picture above: Files were scattered over multiple servers and even personal laptop hard drives, multiple copies of the same file existed, only with different "modified" date and time, the same file information was duplicated in several files, but with different file names and the "rules" for file archiving were so byzantine and obscure that even the person applying them couldn't remember what they were or what purpose they served. To make matters worse, each team member had his own system that clashed utterly with everyone else's.
The project was completed, albeit with a great effort expended to unravel these issues. Afterwards, there was a resolution to develop a better way of managing this problem. While there are many ways file management can be implemented there are a few principles that should be adopted:
- It must be unambiguous. It should be apparent to even a casual user of the system what the nature of each file is, either by its file name, file location, properties, metadata or other easily-observable characteristic what the file is. This is especially important for the most current version of the file. There is nothing worse than putting a lot of time and effort into completing a document, then having an earlier, incorrect version of it sent to a client.
- It must be intuitive. Complex rules invite misinterpretation, so keep the system simple so that it can be quickly comprehended, even by someone that comes to your files months or even years later. Most electronic archiving today will be done using the form that the project was executed under, so keep rules so simple they can be understood just by observing the system itself.
- It must be traceable. Frequently how a solution was developed and why is just as important as the final product. Previous file versions must be kept and stored so as to clearly identify them as non-working versions, but retained for document genealogy. At the very least, retain all versions transmitted to a client, but more complex solutions may even call for keeping work-in-process versions to show how those documents arrived at that point.
The projects following the chaos of the original effort implemented the above in this nuts-and-bolts way:
- All files were kept in a single location, with no local copies permitted. Normally, a folder on a server would have been used, but since the team was widely dispersed, geographically, a cloud-based system was used.
- Folders for each major file type were created and file names standardized.
- The current "one true file" for each was kept in the root folder of that file type..
- One a file was considered complete, a PDF with the same file name (but with the .PDF extension) of the file was generated and kept alongside the editable file. This signaled all users that there were no pending edits. Files without PDF companions were considered to be in revision.
- Files that were transmitted to the client were copied to other folders labeled "Rev 1," "Rev 2," etc. within the root folder. Both the editable and PDF versions of the file were archived. In this way, revision progression could be easily reconstructed for any file.
While not perfect, this methodology greatly reduced confusion, rework and risk associated with errors in file management. Project managers needs to ask themselves how to implement these principles or what additional criteria could be applied to make a system more usable and error-proof.
This post was written by Bradley Ems. Bradley is a project manager at Maverick Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. Maverick delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.
Maverick Technologies is a CSIA member as of 4/5/2016