Change Technology, Not People - Catering to The Unique Workflow


change-technology-image-blogMany post coordinators live by the credo, "If it's not broken, don't fix it". The problem is, there are various levels of broken. Think of a road with a pothole. Patching it with sand will solve the problem temporarily, maybe enough to announce that the road is no longer broken. Filling it with asphalt patch will do a better job, but eventually that will crumble with wear. In the long run, the best bet is just to drive around it.

Workflows built around deficiencies in networks are like driving around the pothole. You may have tried to patch it a couple times, but in the end you just build enough avoidance into the process that it doesn't affect you. After several years, we find ourselves in the middle of a workflow that makes little sense to anyone that wasn't around since the beginning.

How to tell if you have an "Avoidance Workflow":

  • Do you ever copy between two different places on the same network?
  • Do you download files to a local "Work drive" before working?
  • Do you copy things before you transcode, or vice-versa?
  • Are you using shares of local hard drives as a library?
  • Are you using re-shares of already shared drives?
  • Do you use multiple locations for the same project files?

If some or all of these are embedded in a regular process at your facility, you're avoiding something that doesn't work. You may or may not want to change that, depending on how broken it really is.

An example:

Project-based volume workflows have been around since the 90s. Since it was first possible to create new storage allocations on the fly, and permission them easily, this has been a popular way to work. Some Avid editors are so used to the workflow of project-based volumes, that they continue to use them even when dealing with projects that are primarily AMA-based. This is interesting, since project-based volumes were a workaround for a deficiency in Avid Unity and Media Composer. File count limitations and various database management problems would arise when combining too much into a single workspace. Project-based volumes kept the file counts down, the databases small, and added a bit of security and low-level management to the project data as well.

This is not broken. If this is the way your people work best, you should buy a system that caters to this type of volume creation and permissioning, like TerraBlock. Where things get broken is in the workarounds to other limitations of these earlier systems. These include splitting audio, video and project file allocations for each project; re-sharing allocations over slow 1Gb backbones to add new Ethernet clients, leading to download of data to avoid slow network paths; copy before/after transcode because of the drain on network speed, etc..

We place dozens of servers each year into facilities with very strict workflow guidelines that have been honed through years of avoidance. I consult weekly with those facilities on what it makes sense to keep, and what doesn't. I often find that there's a benefit to keeping things status quo, as long as loss of efficiency is limited, and the process is sustainable and scalable. Let the creatives be creative in the best way they know how, and set up your network to remain invisible in that process.