Network share organization strategy?

[hygear]

I am trying to help our department getting a little more organized and I think a good place to start is to clean up our network shares. Right now we have tons of duplicate files and no real organization method which has caused us to use up our disk quota on more than one occasion. I attempted to fix this problem a few years ago when I created a new project by using the following directory structure for the project:

Project X
|-->01 Engineering
| |-->01 Subsystem A
| |-->02 Subsystem B
| |-->03 Subsystem C
|-->02 Project Management
|-->03 Manufacturing
|-->04 Quality
|-->05 Product Cost
|-->06 Purchasing
|-->07 Marketing and Sales
|-->08 Testing
|-->09 Misc.

This worked for about the first 3 months of the project, but quickly fell apart when people started putting files wherever they wanted.

I'm not sure of the best way to fix these issues, so I wanted to dig around and see what strategies others are using to keep their network shares organized. Do you have company standards for organization? Do you appoint someone as the primary data organizer? What strategies have worked for you? What strategies simply don't work?

 

[MiketheEngineer]

Kind of the way I do it. Master folder for each project and sub-folders below.

BUT IT MUST BE ENFORCED!!

 

[zdas04]

I was a database administrator before ever doing any Engineering. I used to teach database theory. I am a huge proponent of organizing data so it can be found. Today I am a one-man company. Some asshole keeps putting files in the wrong place and I can't find them again. My point is that with just me using the files I don't do a wonderful job of organizing them properly, I don't know how you do it in a big company. I've been working with several big companies that have whole document control departments. If I ask for a document by number I get it pretty fast. If I'm looking for a goby data sheet for a control valve I get a blank stare. If I want to see an underlying calculation (that doesn't have a document control number) it seems to be impossible to come up with.

When I first started my business I had an idea to put information on every single file on my hard disk into a database that had key info like client, file location, keywords, etc. I kept this up for almost 3 weeks before I got too busy to continue and after a year I erased all trace of the database so I wouldn't continue to feel bad about not doing it.

There is a certain kind of project where the file structure you listed in the OP would be perfect. In some companies that sort of project is 60-70% of the work. In my company it is 1-2% of the work. That format wouldn't work for me. Might work great for the lion's share of your work. Enforcing definitions can be a challenge (I've seen a lot of these schemes fail because one guy's "Engineering" is another guy's "Project Management").

David Simpson, PE
MuleShoe Engineering

"Belief" is the acceptance of an hypotheses in the absence of data.
"Prejudice" is having an opinion not supported by the preponderance of the data.
"Knowledge" is only found through the accumulation and analysis of data.

 

[GregLocock]

Dude, you are doing well if you can keep all of Project X's files in the Project X folder, and Project Y's in in the Project Y folder, never mind correctly sorted into some elaborate hierarchy underneath.

I have worked with a system where a manual register of files was kept. It sounds like a pain, but it wasn't too bad.



Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376

http://eng-tips.com/market.cfm?

 

[MrHershey]

That's essentially how we do it. These folders are all set in stone when the project folder is created and everyone understands what they're for.

We've toyed with trying to lock things down so these folders can't be changed and so project folders can't be accidentally (or god forbid, intentionally) deleted. But haven't found a real good and practical solution yet.

 

[hendersdc]

We start off with a default directory structure broken up by discipline. It can get messy on the longer projects or if we have a lot of engineers coming on or off over the course of the project. Nothing is perfect but the naming of the files themselves will go a long way towards helping others locate things as well. Avoid acronyms where possible to help when using the search function. Our projects vary significantly from one to the next so maintaining felxibility is important and we don't lock down the file structure, just start with a base model.

Where things really get dicey is when people on the project start creating folders named after themselves. How would you ever know what was in directory John.Smith if they got replaced on the project?

Doug

 

[JayMaechtlen]

In theory, a content management system (CMS) would help.
In theory, they let you attach relevant information about each file and make the files more searchable.
In practice, the information still has to be assigned somehow- so you can still wind up with a mess, just like with a file system.
Except that you have your mess inside of a software system/database that must be maintained.

hmmm

maybe an intern or flunky to organize files and/or track them?
- would that be a function that a small business might be willing to pay for?

cheers
Jay


Jay Maechtlen

http://www.laserpubs.com/techcomm

 

[vandal06]

We use a revision control software package with a file structure similar to the one you posted. The files live on a central server and using the software you can "check out" individual files or even whole directories to perform work on. While checked-out the files/folders are marked as read only to other users, preventing any sort of duplication of work. At any point you can check the file back in and it's uploaded to the central server and the previous revisions are saved, and it's ready for the next user to check out and do work on. There is a bit of a learning curve, but it's pretty slick when used properly. Of course, enforcement is always an issue.

 

[truckandbus]

We use the directory structure as you have it outlined. It works fairly well since usually only one person owns the directory and the rule is only the information within the directory is considered Gospel - any duplicate files elsewhere are uncontrolled and are used at your own risk.

I've been considering using a tag based system for identifying documents, but that requires discipline as well. It wouldn't be popular but I can see a solution as being sending all documents to the office admin to file and only allow read access to everyone else.

Running file management software that looks for duplicate files every month is a good idea as well.

The oter option is to reduce the number of files that you need to look after. Do you really need to have "Proposal 1 Draft", "Proposal 1 Draft (2)", "Proposal 1 Final", Proposal 1 Final2"?

 

[drawoh]

hygear,

I was in charge of a UNIX network quite a few years ago, and I set up a system very much like yours. It worked for a remarkably long time, and I am not sure I understand why.

A big defect of Microsoft Windows is that it aggressively steers you to your local hard drive. It takes quite a few clicks to reach the network drive you should be using. Under UNIX (Solaris), I was able to make the official network drive conveniently accessible. Users usually had no clue about the network topology.

Most of my sysadmin successes consisted of me making the correct way to do stuff (my way), convenient.

Eventually, we transitioned over to Windows, and people transitioned to their local hard drives. I could not do anything about it.

You need management backing. If people do not follow your file protocols, you need them to get disciplined. If management will not do this, you will not succeed.

--
JHG

 

[JayMaechtlen]

As far as convenience goes, you can easily map arbitrary network folders to drive letters for users.
There are deeper trickeries to make personal folders live on network drives.

Yes, you should make it as easy as possible for users to do it the right way.
You can suffer now, setting it up -
or you will suffer later, because you didn't.

Jay Maechtlen

http://www.laserpubs.com/techcomm

 

[joehvac]

A firm I used to work at had network drives with assigned drive letters g:, r:, etc, by company division. Certain employees had access to certain drives. Within each drive was a folder for each job, by job number. When each folder there were some default sub folders. The company preached storing all job related files to the job folder and nowhere else. Local file storage of job files subjected employees to a chewing out. It seemed to work fine, except for a few situations. Some of our analysis software did not like working with files over the network. We had to remember to save the analysis files to the network drive in between sessions. Overall a good system. If you got assigned to a project halfway through, you could reasonably expect to find calculations, equipment, drawings, spreadsheets, etc in the job file.