Lessons Learned - Check it works and again

Tue, 04/15/2008 - 06:30 — Alan

Check with your client before you delete anything

I was the client the other day and this happened to me.

Compositing

I'd passed the compositing tasks out to someone else. I sat in for a few minutes to check that it was going as I wanted it and make some decisions about how it would look. e.g. I'd prefer to have less foreground and no green showing rather than have the green showing in order to get the foreground complete.

I received a message a few days later and went round after a few days to pick up the results. The project had been rendered and had been burnt as a data file onto DVD.

I was able to view the rendered movie the following day. The compositing was great, a brilliant job on the chromakey process, especially when you consider the bad quality of the sources that I'd provided. Unfortunately, the background was only changing scene every second or so, not every frame as it should have been.

The compositor had deleted the source foreground and background files before I'd had chance (less than a day) to check the work.

Results

I've written about testing before. I've just experienced the effect of someone else not testing their work. It's put back the movie a couple of weeks, due to our conflicting diaries.

The format of the rendered file wasn't usable in Logic either. That's a big deal for me. I could have converted it, but I'd prefer to have it rendered into that format in the first place. Fortunately the file was still playable in VLC so I could see the quality and the juddery background.

Lessons that we both learned

Supplier should check that files are in a suitable format to the client before removing
Supplier should check that the client formally accepts the product

A comparison

I work differently, I still have the source files and rendered files for the Memory shorts a year after the event and I've still definitely got the files for the more recent Venn short which is a few months old now. If anything, I've got the opposite problem and I may have too many copies of the same files. I tend to have a decent backup routine in place anyway. It's sometimes the ad-hoc backups that I do in addition to routine backups that can cause confusion.

Tales from the commercial world

I've worked in a few industries. There are a couple of nice concepts that I've worked with:

Customer Acceptance. There should always be a documented process for what the customer has to do to sign-off the product. If there isn't one, it's usually one of the first things I write and get agreed, otherwise it's asking for trouble later on. The work doesn't count as being accepted until the client signs the acceptance.

User Acceptance Testing (can you tell I've some background in ICT?)/ Operational Testing. Leading up to the Customer Acceptance is a phase in which the customer tests the product. The product should be tested against defined criteria (defined and agreed by the supplier and client). In my case I'd have said that the foreground and background would be rendered at the same framerate, I'd have stated the resolution, the delivery format, when I expected it by, etc. It can get very formal, very quickly. Unfortunately, the more formal it gets, the less in touch we all become with whether the client likes the product or not.

Use in a Live Environment. No matter how much a client likes the product, they still may not sign to say that they accept it. Possibly from being too busy, possibly wanting it improved (forever and forever), possibly from trying to avoid paying or a variety of other reasons. A nice clause is to state that use of the product in a live environment constitutes acceptance. For media, there's copyright which supposedly makes it easier, after all clients should obtain an appropriate licence to use your media. So no matter how much they argue or ask for a better version (whether reasonable or not), it becomes more awkward for the client to use your product in their finished product and then say it wasn't good enough.