Google-drive – We are sharing corporate data, how to improve our Google Drive setup

google-drive

We have a corporate Google Apps account (paid), and we have a central user (I will call it CompanyArchive) that owns all of the documents that were on a network drive before we started using Google Drive. This is approximately 50 Gb of data, not all of which is relevant today. All this legacy data is contained in a single folder which I will refer to as "LegacyData".

This folder is shared with everybody in the company.

This gives us the following unwanted situation:

  1. Employees can only see LegacyData if they search for it. It does not show up anywhere else on their Google Drive.

  2. If an employee searches for LegacyData he/she can drag it to their "My Drive". Then 50GB of old data will start syncing, at which point the employee will usually freak out and do stuff like terminate the syncing, kill the Google Drive app, or phone an IT Guy.

  3. If the syncing is successful, employee will find an interesting item inside LegacyData, determine it should be somewhere else, and move it outside of the LegacyData folder. At which point all of the other employees will think something important has been deleted, and start freaking out and phone an IT Guy.

So to me it feel we went about this the wrong way, and our current setup is bad. I can't find any sort of best practise that will allow us to set up Google Drive as an actual company wide "network drive in the cloud". Meanwhile, the employees have started to use free Dropbox account to share documents, because they do not trust Google Drive. However, Dropbox for teams would cost us 1000-2000 euros a year, which is roughly 900-1900 euro's more than we pay for Google Drive. Also, the entire company is very happy with all other facets of Google Apps.

Question:

Who can put us on the right track using Google Drive as a company wide "network drive in the cloud"? Ideally every employee would decide for themselves what they sync, but they are perfectly capable of adhering to a few simple IT rules, as long as those work, and breaking of the simple rules does not result in immediate "Oh my… I deleted the company contracts folder" panic.

Best Answer

Unfortunately, your problems with Google Drive are symptomatic of a deeper set of problems. Changing some settings or switching to other tools or just using Drive differently might create a different set of symptoms, but it isn't going to resolve the core issues.

(Buckle up, this might take a while. The TL'DR version is: You should to have and implement a records retention and disposition plan, as well as a records access plan.)

So, what I take to be your "core" problems:

1) If users are freaking out, it is because the system they are using behaves in an unexpected way. Before you can solve the problems, you need to reset the users' expectations in a way that will allow you to implement solutions. Otherwise, your changes just make the system yet more capricious and unpredictable.

2) If you are relying on a loose set of "a few simple IT rules," you're probably DOA. Competent people make mistakes, and often times their mistakes are more. . . interesting. Competent people can also disagree about the best solution to a problem well after "best" has metamorphosed into "most intuitive." Where you can be flexible, be flexible; where flexibility leads to systemic problems, become rigid. There is no way to figure this out a priori.

The first step is to make sure users have a good idea where a certain kind of record will be. The second step is to make sure users know when a certain kind of record has outlived its usefulness and will therefore die. This is called a records retention and disposition policy (or "guidelines" for the bureaucratically squeamish—your corporate culture and legal needs will determine how "squishy" the records plan can be). A clear plan prevents (reasonable) freakouts, and gives you some wiggle room to start solving your problems.

Personally, I would start with as simple a records schema as you think will pass muster and then when users complain that a node of that schema has become unwieldy you can create subdivisions. If you have time to do a quick review of the research on menu tree design, this will be a huge help to your schema design and revisions.

(ASIDE: Any schema you devise will be somewhat arbitrary. What's intuitive to the goose is not necessarily intuitive to the gander. This is why Drive and similar tools allow users to "symlink" read-only folders into their own folder structure. Using CTRL+click to select multiple locations in Drive's "Move To" panel is incredibly helpful in this regard.)

Now that everyone knows what you're aiming for, you can select and implement tools that reinforce the plan. In your case, it sounds like "LegacyDrive" needs to be a read-only band-aid that holds old data while you migrate all of it into a current data structure. (That is, unless your retention plan calls for 'LegacyLegacyDrive's ad infinitum.) LegacyDrive, and perhaps other drives, will be read-only to avoid simple "Oh my. . ." scenarios, leaving you more time to deal with complex "Oh $#!T. . ." scenarios.

You can use Google Groups to better manage complex access rights (the link refers to Gmail, but the solution proposed there works for Google Drive as well). Google Drive folders generally inherit sharing rights from their parent folder, but you can change the rights for any child folder in any way you like. With a bit of practice and testing, you can create very sophisticated and granular role-based access schemas in Drive (via Groups).

If your corporate culture is such that users are accustomed to deep collaboration (and hallelujah for that), you might include an "open sandbox" folder inside every "closed" folder. The "owner" for the "official" folder can move files into the official folder or make changes there based on discussion in the sandbox. This approach is modeled on how open source software often has a "master branch" with a "maintainer" controlling access to the official build while still providing other areas and opportunities for completely open collaboration. YMMV; make local access and schema decisions as needed.

One other thing to keep in mind: There will be some things that Drive cannot do on its own without a lot of programming work. Sometimes it is easier to act on the files that have been synced to a computer, and to let Drive sync those changes back to the cloud storage. You may, however, need to restart the Google Drive application to get all those changes into the cloud. Drive's "on start" methods for identifying file changes is more thorough than its live methods.

If I've missed anything, well, that's why this answer is a community wiki. Please alter as needed!