Windows Movie Maker wouldn’t let me choose arbitrary starting and ending points for panning across a document. How frustrating: I wanted to be able to pan across our interview guides in a very specific way.
No sweat, I thought. I will just switch to the studio Mac and use iMovie.
In that instant, that split second decision to switch tools, I set myself on a collision course with this future, approximately 42 hours later:
There, under the harsh fluorescent lights in the Queen Mother Building, at 3 am on a Sunday, I was unconscious, face down on an impossibly scratchy sofa so short that I had to fold myself up to fit on it.
On the computer monitors is the video podcast I was working on, in the
third fourth fifth piece of software I had tried.
This was the second night of a weekend in which I lived at the university, worked until I collapsed, and slept on the stupidly short and itchy sofa for a luxurious three hours before getting up to do it again. If this was not one of the most horrific experiences of my academic career, it is only because of a few of the people I was working with.
The full list of technical difficulties I encountered that first day of production can be found here, but they are insignificant in comparison to that fateful moment when I thought, “No sweat, I’ll just switch to the studio Mac.”
This decision was so significant for two reasons:
- I moved from tools over which I had complete control to resources over which I had limited control and even less access.
- I chose perfection over completion.
I did not realize this at the time, of course. At the time, I was just pursuing my vision. In my head, I could see exactly how those frames would flow together, and I simply could not do it with the tools that were in my control. I wanted to make the beautiful thing in my head into a real thing to deliver to my client. If I was going to be doing the work anyway, I thought, I might as well do it properly the first time. These were good intentions.
The road to sleeping face down on a scratchy sofa under buzzing flourescent lights is paved with good intentions.
There are two valuable lessons to be learned from this disaster.
1. Always use the resource that affords the most access and control.
- Always choose your own laptop over university resources. (The corallary to this is keep your laptop in good running order. Regular maintenance is essential, so that when crunch time hits, your own resources can support you.)
- Avoid resources for which you do not have admin rights, unless your sys admin is going to be available the whole time you are working.
- When rapidly approaching a deadline, use familiar software and methods. Even if the unfamiliar software or new method would produce a more perfect deliverable.
- If you ignore any of this advice, plan at least a week of buffer time to juggle technical difficulties and sleep.
2. Produce deliverables through a series of progressively better complete deliverables.
Your goal is to assemble a complete deliverable together as early in the production process as possible and then to iterate on that, as opposed to trying to produce a perfect deliverable from the start. (This is an tenant of Agile software development, and works well in other realms as well.) Then, should disaster strike, you have a complete deliverable to hand to your client, as opposed to a near-perfect half deliverable.
For the first pass of a deliverable, do the bare minimum to present the information.
This is your disaster insurance policy. This is your “break in case of emergency” version. This is what will fulfill your contract and help salvage your professional reputation if all hell breaks loose.
Don’t make it pretty. Don’t make it snazzy. Do it in the simplest possible way. Do it the stupid way, the way that makes your inner designer/artist cringe. Make it blank white powerpoint slides with plain black text if you have to, but get all of the information there. Make it simple, and make it complete. Make it something that, should your house get hit be a meteor the next day, disrupting your ability to work, you could still give it to your clients for them to benefit from the research. Save this first draft as version one.
Make a list of all of the specific things you would like to do to version one to improve it. Prioritize the list.
Bad list item: “Make it pretty.”
Good list item: “Add images of dinosaurs to slides 5, 6, 18”.
Choose a few of the highest priority items from the list and iterate on the previous version to include those high priority changes.
Do not go over-the-top on this iteration–you’re not aiming for perfection, just for “better than the last version”. Save this as version two.
Repeat steps two and three, saving each new version with its version number, until you have a deliverable you are satisfied with.
General notes on this method:
- Go for speed–consider setting a time limit for each iteration.
- Do not get bogged down in details that no one will notice.
- Take your inner perfectionist out back and shoot him or her.