solving problems before they happen

Production / Friday, February 27th, 2015

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.

20150224_Assn3Postmortem_01 20150224_Assn3Postmortem_02 20150224_Assn3Postmortem_03 20150224_Assn3Postmortem_04 20150224_Assn3Postmortem_05 20150224_Assn3Postmortem_06 20150224_Assn3Postmortem_07 20150224_Assn3Postmortem_08 20150224_Assn3Postmortem_09 20150224_Assn3Postmortem_1020150224_Assn3Postmortem_11 20150224_Assn3Postmortem_12 20150224_Assn3Postmortem_13 20150224_Assn3Postmortem_14 20150224_Assn3Postmortem_15 20150224_Assn3Postmortem_16 20150224_Assn3Postmortem_17 20150224_Assn3Postmortem_18 20150224_Assn3Postmortem_19 20150224_Assn3Postmortem_20