Ahh, the art of 20-20 hindsight. This week’s Production and Leadership assignment was to analyse three postmortems on Gamasutra, find things in common that went well and went wrong, and propose a course of action. So it seems fitting that I am writing a blog post on how I’ve found that production is about solving problems before they happen. Two examples from my team stand out in my mind.
1) Choosing a team name
Very early on, we decided on “Baymax 6” as our team name, and artist Wei was doing awesome concept branding art based on the Disney movie Big Hero 6. We figured that adding a number after the character name made it okay, and as our advisers never really advised us against it, we went forward, all up to branding day on 2 February 3 weeks after term started. Then, other teams and faculty started voicing concerns about copyright issues. This is something I should have foreseen and changing the name put a lot of extra work on the IT support (such as changing website URLs and things on the website) and on me, when it could have been simple had I caught this before we submitted our name. I got my fair share of “how could you have been so naive?” on this one. We are happily now “Stellar 6” but it took way too much work to get here.
2) Scheduling team presentations
It is often not until something has been scheduled that people pipe up with “oh, actually, I have something going on that day”. I learned this the hard way – after requesting a halves presentation date that fit our client and teammates and getting it, two of my teammates announced their conference plans for the week. With this in mind, I now realise that people will not tell you in advance if they have plans during an important week, as you expect, so you have to check and double check and confirm that they are available before you do any planning. This debacle resulted in me having to scramble to swap with another team (no mean feat) for a presentation time, which was work and time I could have saved had I bugged my teammates and just requested the best day for everyone in the first place.
In both cases, a lot of extra work was required and a lot of bothering other people and giving them more work, which I dislike. Predicting these mistakes is not always easy, though, and I think part of being a producer is knowing that things are going to go wrong, trying to foresee what might go wrong ahead of time (and doing better at this through the years), and rolling with the punches when they do go wrong in ways you don’t expect anyway.
Postmortems can help us learn what issues might come up, but I think that these issues may not always be preventable. What I am trying to do is learn how to adapt quicker and more effectively, and use the lessons of the past to inform what I can check for in the future, and what warning signs appear during each phase of a project. Gracefully admitting these mistakes and asking for help to solve them (especially if someone else has to do more work, which is often the case), is another important skill.
I have attached my Production and Leadership postmortem analysis assignment below, and though it seems that we are doomed to repeat the same mistakes over and over again, it is comforting to know that at least in hindsight, we can analyse them and maybe learn a thing or two.