How to clean up messy servers

I've never encountered a shared network drive inside a business that wasn't at least a little bit sloppy. Shared servers are typically designed to enable collaboration, as well as make files and information freely available to our fellow employees. They also help businesses capture and backup data easily and efficiently – in theory, that is.

In reality, they turn into the place where photos of the company Xmas party from six years ago are stored. In that last sentence, I used the passive voice intentionally because no one ever seems to take responsibility for putting something onto a shared drive that shouldn't be there. Things just appear. No one knows how or why they got there. And therefore, no one removes them out of fear of stepping on someone else's toes, or deleting something that someone else needs.

Shared spaces should be designed in a way that matches a department or company's workflow or organisation chart. Things that are parallel in nature, like two teams who report to the same management level, should be parallel in folder structure. When a new person joins a department, he or she should be able to quickly figure out where important files live on a shared network because their location (folder name and how it's nested within other folders) should mirror how the business is designed. A real red flag is when someone who's worked on a team for a long time can't find stuff because they don't know where it is, or worse, don't even know where it should be.

I must have been the squeaky wheel when it came to the messy servers here in our editorial department, because one day the director of online content – who is a highly organised person – initiated a server clean-up project and asked for my input. I was thrilled to hear about it, and even more excited to participate and take notes on the process so I could share them our readers.

Here's everything we did, step by step, to clean up our sloppy servers. At the end, you'll find a summary of the results, as well as notes on what went right and what went wrong.

Step 1: Communicate

Firstly, we talked about the problem of having a sloppy server, including why it's a problem (inefficiencies, inconsistencies, straining our network space), possible solutions, and procedures for implementing those solutions.

Then we talked some more. Then we talked about who else we needed to talk to. As regards the success of this project, I can't stress the importance of communication enough. We talked a lot, both in person and over email.

During those conversations, we realised how important it would be to communicate with the IT staff, too. So we looped them in on our plan and proposed timeline. The IT team gave us one crucial piece of advice that, in the end, became our true launching point for the project. They said: Don't try to clean up what you have; rather, start with a blank canvas and create the folder structures you want, and only copy over files you want to keep. Everything else, they said, they'd archive.

Step 2: Review existing data

Secondly, all the stakeholders – mostly team managers – sat down at a table with a laptop and a projector. We connected to the server space in question and looked through some of the existing files, just to be sure no one overlooked some batch of files we should keep.

We also thought about the existing data in terms of how it did or did not reflect our current workflows. Shared spaces are generally used for collaborating on work. The structure and names of folders needs to accurately reflect that workflow for it to be useful.

A lot of what we found on the servers was horrifically out of date. There were folders named for employees who hadn't been with the company in years. We found files dating back to 2003. There were remnants of projects that never got off the ground. No one needed any of this stuff.

Step 3: Map out the new structure

While we were still sitting around that table, we sketched out the folder structure we thought should be in place. All the managers had their say regarding the design, which needed to reflect our team structure and workflow.

So, what did we come up with? At the top level, we have folders for each team and special project or task, as well as one for "Resources" that apply across all teams.

Then each team has a subset of folders: A few that show workflow, one for each team member, and additional folders as they make sense for that team's needs. For example, my team's subfolders look like this:

We used underscores and numbers to make our workflow folders sit at the top of the structure and appear in the same order that the work takes place. The folder called "_1EDITING" is where files that are ready to be edited go, and stay, until the editing is finished. Then they move to "_2RTP" which means "ready to produce" – in other words, editing is complete and these files are ready for the next stage. After a file is produced, it should be moved to "_3PRODUCED," which essentially becomes our living archive. Anything in that folder could, in theory, be archived, so we will always have a cache of files that we know we can remove should we ever need to claw back some space.

Step 4: Create rules

As I already started to explain in the previous section, each folder has some rules associated with it regarding what can and cannot go into them, or how they should be used. If someone wants to share photos, for example, they must put them in their own namesake folder. That way, it's clear who is responsible for the data.

We also discussed whether we had files that need to be accessible for multiple teams (we did, and we created a Resources folder for them) and whether any information should be locked down (yes – everything in the Management Team folder).

Step 5: Ensure consistency

As we designed our folders and rules for using them, we also looked for areas where we could (and should) be consistent. When folder structures and workflows can be consistent, it makes things easier during times of personnel transitions, such as when someone leaves the company, goes on maternity leave, or is unexpectedly ill. Consistency on a shared server space helps everyone in the organisation figure out the state of current projects, as well as what's important, what work has already been completed, and so forth.

A follow-up project (that we're just implementing now) is to create better consistency across our file naming conventions, too. We decided to hold off on implementing this file naming change until after everyone has become accustomed to using the new shared folders, to avoid the danger of overloading folks with too much new information at once.

Step 6: Check one last time with all stakeholders

Before we implemented anything, we ran one final check through of the plan with every stakeholder, including a few people whom we originally didn't think to include, but whose names came up in our review of the existing data. "Isn't that Arielle's area of expertise? We'd better ask her what she thinks needs to be done in this section."

Step 7: Finalise and communicate the timeline

The last task was to finalise the timeline and then kick off the project. These were the final pieces of the puzzle:

  • Decide when and how to disseminate the information: Email all employees mid-week about the new server structure, rules, and all related information, including dates (see next item).
  • Set dates for: When people must copy over the files they want to keep (end of week); when they should start using the new structure (in our case, immediately, upon receipt of the email); when the old server will be cut off (we told them the end of the week, but in reality, we padded this deadline with a few extra days).
  • Plan a few reminder emails before actually cutting off access to the old server.
  • Let IT perform the actual cutoff.

Server clean-up results

That mid-week email containing all the information about the server clean-up project went out at 11:27 one Wednesday morning. A few people had burning questions, but the reply-to-all thread quietened down by midday. That means all basic questions had been answered within 30 minutes.

Within my team, additional clarification continued regarding our workflow — but the last message I got came at 13:05 the same day. No doubt a few people asked additional questions without replying to all, but the majority of questions were answered within two hours.

Over the next several days, we completed the timeline without a hitch. The IT team ran a quick report showing that we reduced the total data by 76 per cent. The numbers speak for themselves.

Before

  • Total Space: 250GB
  • Number of files: 447,249
  • Number of folders: 36,773

After

  • Total Space: 59.2GB
  • Number of files: 58,624
  • Number of folders: 2,962

Project post-mortem and feedback

A few weeks after we finished the server migration and restructuring, I asked the project lead, managers, and IT network administrators if they had any feedback or post-mortem notes. No one did. It all went remarkably smoothly. Here's what the lead IT guy had to say:

"In the 10-plus years I've been here, this is the first time a departmental team has undertaken a project like this out of their own interest and carried it off so well. This helps both [the other IT network administrator] and me better maintain the network, and I'm sure it helps your team with workflow and organisation. We literally asked several generations of management to mandate what your team has accomplished at the grassroots level, and it is much appreciated."

From my perspective, there is one thing I wish we had done slightly differently. I wish we had initially told employees about the project in person in a quick impromptu meeting, rather than via email. Email is fine, and sure, no one likes meetings, but I felt like people would have felt more included in the process had they been told during an open discussion rather than through an "IMPORTANT!" email.

We now have a better, more consistent, more efficient, and simpler shared server. The rules for how to use it are clear, with accountability built in. Team managers are responsible for team folders, and individuals are responsible for what's in their named folders.

If you're thinking of initiating your own server clean-up project at your organisation, I hope you can glean some useful advice from this article. And don't forget about the importance of getting advice from your IT department, and the fact that communicating thoroughly at every stage is crucial to success.

404

Sorry! Page not found.

The article you requested has either been moved or removed from the site.