Search
  • Tomasz Wacławek

The dirtiest words in game development: “project management”

If you have a project, you have to manage it. There’s no escaping from that, no matter the size of the project or the organization you’re with. Examples of games such as Anthem, Mighty Number 9, No Man’s Sky, Duke Nukem Forever, Yogventures, Fallout 76 and recently Cyberpunk 2077 prove, that all, big and small, have to yield before the universal equalizer that is project management.


Setting yourself up for failure


It would be foolish to suggest only one true source of project failures, since this would infer one true solution, a silver bullet, and those don’t exist. The biggest leitmotivs that seem to be present however are: waste, miscommunication and incorrect estimates.


They pay me to work, doesn’t matter on what


There’s this bit of wisdom, that you should not only “do the work right” but also “do the right work”. Removing unfinished features is not unique to game development. SaaS offerings and desktop productivity software suffer from the same problems. This happens not only because of time and monetary constraints, but also because said feature may simply not make sense in the context of the rest and not integrate properly. Cutting out such a piece of content is necessary, but this means effectively wasting all the effort and money that went into it’s development. When should a feature like that be cut? When you realize it’s not making sense. And when should you realize this? As soon as possible. More on that later. Yet another face of waste is context switching. Multitasking is a myth: by doing more, people are generating less results, less value. This rings especially true in technical and art fields. Whether it’s coding or creating a character, both call for solid, well thought out designs. This is not doable, when specialists are constantly distracted by shifting priorities and instant messages.


Many heads of miscommunication


Another thing that keeps cropping up is dissatisfaction with the quantity of messages. Yet, this is just the result of a much bigger issue: the quality of communication suffers. One of the reasons may be lack of clarity: people are unsure what are they supposed to be doing, so they keep spamming their peers for clarifications. Knowledge and asset sharing is a big thing here. Without a central source of wheels employees keep reinventing them, usually rather poorly, injecting their own idiosyncrasies in places that demand standardization. What happens more commonly than we’d like to admit, are basic misunderstandings of a desired end state. Team members may have different ideas on what constitutes “done”. A 3D model may look finished, but is it ready to get integrated into the game as an asset?


Underestimating the estimates


Estimation seems to be one of the hardest things during a project’s lifecycle. How much effort is required to produce a single asset? A complete animation? A story arc? Or to fix a specific bug? The delicate art of estimation seems to be akin to walking at night without a map. It’s really easy to get lost, or be tempted to make false promises. Some people are well aware of that and fall into the opposite extreme: they overestimate and over-provision resources, such as effort and staff’s attention. They also ask for a lot of time to “buffer” just in case something unforeseen happens. This can backfire however, by inviting procrastination and scope creep. One thing that seems to be making estimation much more unpredictable is that jobs, even those with a well defined end result, are usually not homogenous. An example would be producing a million toothpicks. First you need to figure out how to make one toothpick, preferably by building a machine. When that is done, you just need to supply the device with raw materials and collect the results: a process which isn’t all that mind-intensive. I wouldn’t be surprised if building and testing out the machine took a vast majority of production time. Once you solve the biggest challenge, you start gaining ground much faster. Naive estimation assumes, that all sub-tasks get completed in roughly even time windows.


Not silver, but still bullets


In the spirit of “under-promising and over-delivering” I offer a few potential solutions or at least inspirations for seeking solutions.


Prototyping up the hill


Something that ties neatly into both doing the right work and providing estimates is creating prototypes. Prototypes are meant to provide answers and more importantly, to generate new questions. They should encourage exploration and seek breakage. The faster a prototype breaks, the better. You can then examine the wreckage and draw conclusions. This is much cheaper and less stressful than fixing a game that shipped with major bugs and design flaws or cutting a large feature last minute. A great way to approach prototyping and estimation is the hill method suggested by Basecamp in Shape Up. In their publication they address one of the most dreaded aspects of work: proliferation of sub-tasks during development. Instead of “working on work” you should “work towards understanding the work”. The exploding prototypes come into play here: they catch all the flack when you make mistakes during your explorations. You’re charting the territory and beginning “actual work” only when you know what’s exactly required. You’ve dealt with “surprises” beforehand, so the only thing left is performing the job. This method is vastly different from work as it is done usually, which mashes exploration and working together. The worker has no good idea of progress, because the territory is being conquered and mapped at the same time.


Workflows, not work-tools


Many companies have opted to move from email to Slack, because they had too many emails and couldn’t handle them. Now they have too many instant messages to cope with. Worse even: emails can be shoved into a folder and forgotten, or easily filtered. Chat programs create an implicit desire or compulsion even, to respond ASAP, breaking any concentration and disrupting workflows. What a shame that a great solution already existed, which could be easily applied to email, probably much less to instant messaging: Getting Things Done. GTD is a method of handling workloads that prioritises quick removal of trivial tasks to make room for more complex ones. In my personal work I’ve found it works surprisingly well with Kanban: GTD’s to-do items become Kanban cards. A Kanban provides great visibility for the individual and shines especially bright in a team setting. Yet another way to fight miscommunication is a Definition of Done. A proper DoD is known to all team members and stakeholders. Ex. “A feature tagged as DONE has all code implemented, has been playtested, documented and does not create regressions and exploits, both in code and gameplay. All assets required have been integrated into the build with no placeholders left”.


Doing the talking


Different specialists speak their own languages and view the world in their own way. People also tend to be biased in their own favor when it comes to valuing work. One way to battle this would be to introduce peer work, such as peer coding. This helps in breaking down silos or prevents them from happening in the first place. I’d like to see this practice extended not only within teams but across teams. An artist and a coder observing each other’s work every now and then could protect themselves from various biases. Knowing the other person’s work is also beneficial, since they’d understand limitations and possibilities better.


Working on work


Work itself requires reflection and constant improvement. Otherwise we’ll start running in circles and not even notice when it happened. But we’ll notice our failure to deliver.

21 views0 comments

Recent Posts

See All