Guest Contribution by Michael Schiciano
Introduction
The process of working on a collaborative process can be riddled with logistical headaches. Miscommunications, lack of clarity in project goals, last minute revisions, and just bad luck/circumstances can lead any project down a path of frustration. These problems become more apparent when the element of remote/online/virtual collaboration is added, which relies on more indirect forms of communication (e.g. voice mail, email, instant messaging).
Dealing with the reduced quality of communication requires the same tactics and strategies you would use in traditional collaboration, but with minor adjustments. This means recognizing when you’ll be communicating more frequently, what kinds of goals you should have for each stage of communication you are engaged with, and being flexible with how you clarify points of confusion in the production process.
Establishing the Vision and Scope of the Project
Whenever I had issues coming up with ideas in the middle of a project, a very likely culprit was simply not doing enough communication early enough in the project. Sure, I might have spent some time talking with the director/editor about what type of music they wanted for a video when the project was getting started.
However, if I didn’t finish that round of emails/chats with a sense of knowing what they wanted, then it was likely that I was going to be struggling for far too long on conceptual problems instead of actual production problems. As a result, not only would I recommend a fairly aggressive series of communication early on in the project (as in, before the actual production phase itself even began), I would also recommend some degree of prototyping* ideas to the client/collaborator if words alone are not providing enough clarity.
*A prototype in this context means a ‘working concept,’ which can either be made with original materials, or cobbled from existing sources.
1. The client/collaborator does not seem to understand what it is you are trying to describe.
2. You are having a hard time putting an idea into words that would make sense to the client/collaborator.
In either of these cases, spending an hour or two putting together a basic example of what you are thinking of can make all the difference. This can be the case if you are, for example, trying to describe a type of creature sound that is rather alien or foreign. A phrase like “It’s a mixture between a tiger’s roar, a Ford Mustang revving up, and an electrical buzz” may be good inspiration for the sound designer, but a producer/director might not understand the intended sound texture. A quickly drafted mock-up, however, can convey information that words alone cannot.
An example of this in my own experience was during the process of scoring a short film for a friend in New Zealand. The deadline was tight, but the majority of the scoring was able to be done in one day because I had already given the client rough versions of cues for the early parts of the film. Once they all were green lighted, I knew the direction he wanted clearly, and was able to finish writing very quickly.
Many of you are likely familiar with this concept in the opposite direction; a director/producer may provide examples of the type of sound or music they are looking for, when they can’t find an effective way to explain their vision.
Detours and Changes
A clear vision at the beginning of a project is useful, but inevitably there will be changes to those plans. Sometimes these are messaged down from a client. Other times they are discovered as part of the work itself. The first question that should be asked is:
How does this change my ability to meet the goals of the project?
If the impact is null to minimal then the matter can be addressed without issue. Naturally, providing feedback to a client who frequently makes abrupt but minor revision requests can be helpful for future projects, but that can wait.
A notable impact, however, should be followed up with contacting anyone relevant and letting them know the nature of the situation. The purpose of this communication would be to clarify any concerns about the project, without being alarmist about the situation. You’re trying to come up with effective solutions and strategies to problems here, not cause alarm or place blame.
One client I was working with wanted some sound effects modified in a game, to be able to play not only randomly, but also with random intervals of time separating each instance. This was a change from the original design plans, and while it seemed like a simple adjustment at first, I found that our middleware toolset couldn’t do these changes on its own. Finally, I had to tell the client what the situation was, and provide two possible solutions. One of the solutions required coding the randomization into the game engine, due to limitations of the middleware.
It could be that by bringing up concerns, the requests end up being tabled for the project at hand, but even that should be viewed as a positive outcome – taking on more work than is feasible only to have a less than stellar end product is a losing prospect for all parties involved. Most of us have experienced this at least once, and it’s never a fun time.
Getting the Names Right
Another area you’ll want to make sure gets addressed during the middle of a production are the simpler, smaller details of effective naming conventions. This will help you to keep track which projects/sessions are relevant at different parts of the project. They also help your collaborator/client to easily communicate where problems are happening.
While it’s possible that some industry standard in naming protocol is used, my standard mode of operation is to determine the client’s preference, and match their needs first. After all, the client I’m working with might be the one doing the implementation.
In the same game project as the previous example, there were a lot of music and sound cues that were required, but because everyone involved adopted a relatively easy naming protocol, it was easy to point to a problematic sound or music cue in an email, and not have to clarify further which file was being discussed.
This benefit is improved further by having parity between the working file names, and the sessions they are associated with. In the case of music cues I wrote, the sessions were named to match the rendered cues themselves. This might have taken a little more disk space on my part, but it saved a lot of time when it came to doing revisions.
Making the Delivery
The start of any project will have plenty of back and forth between you and your client/collaborator. Assuming the production goals are established well, the amount of communication during the bulk of the work should be minimal (updates, minor requests, etc.). The final stages of a project, however, will bring forth another wave of heavy communication, most notably focusing on the details of the submission process. Be prepared for these exchanges to border on being protracted and tedious, because your first version of the delivery will rarely be the last.
One example of how this can play out happened to me when I was working on music for a Nintendo DS game. Due to circumstances, I was unable to have direct access to the game and the implementation tools, meaning I had to format my delivery to make it easier for the programmer to implement everything. This involved making sure my sounds were all in the right format, labeled and referenced properly, and packaged in an easy to use format. In almost every delivery, there were songs that didn’t play right, and I had to rely on the feedback from the programmer to indirectly guide me toward solutions. Sometimes, I ended up spending more time troubleshooting a song than I did writing it!
Because remote work lacks immediacy, you should allow yourself and your client several days after your initial delivery to be able to hash out these issues. Be prepared, however, for revisions requests to come up well after those few days.
In the DS title I worked on, there was a point weeks after submission where I had to address a minor formatting problem. Fortunately, I had the files immediately available, and was able to make the revisions in short notice. These sorts of ‘post hoc’ tune-ups are among the more frustrating aspects of remote work, especially since they can occur right up to release. Being aware of them, however, will make you better equipped to handle them
Closing
With the advent of faster speed internet, social networking, and even tools that allow for direct, remote collaboration (e.g. Steinberg’s VST Connect), the prospect of doing work for clients well outside of your immediate area is very much a reality. Even though there are inherent differences in the quality of the communication available to you during these projects, those differences can be accounted for.
Of course, some of this advice may not be as relevant to you, and you will likely come across circumstances that provide different insights than are listed in this article. This is why being flexible to the demands of this sort of communication environment is just as crucial as being flexible to any other demand you would have during a project with clients or collaborators, both near and far.
Feel free to contact Michael “Skitch” Schiciano via email: [email protected]