Last year I was invited by a former colleague to give a talk about project management to game development students at Manchester Metropolitan University. During my career I have held the role of both lead designer and game director, but since I have never actually been a project manager, my initial reaction was to submit to the creeping sense of impostor syndrome the invitation had provoked.

Having recently made the move from the world of big budget, big IP development to running a small indie studio, I realised that I could no longer afford to pretend that project management was somebody else’s responsibility. More importantly, if we were to flourish, I knew I had to slay the demon of impostor syndrome whenever and wherever it raised its ugly head. So, I accepted the invitation, and set forth into the darkest corners of my memory, in search of the dreaded closet of development nightmares I had buried there.

Instead of applying the experiences I found to models pulled from project management textbooks, which presumably the students had studied to death, I thought it would be fun to create a new model to properly encapsulate the sense of anguish I wished to impart.

The model I came up with is called the Development Diamond, and this is how it works:

A Universe of Problems

Often, when we measure the progress of a project, we look at tasks and bugs. These are assigned to team members, and the rate of resolution versus the rate of creation gives us a sense of project’s progress.

However, tasks and bugs are but a drop in the ocean. They are well-defined subsets of a much larger universe of problems which amounts to your project. That’s right, your project isn’t made of ideas and mechanics or art and rainbows. It is, at the quantum level, nothing but an infinite soup of problems.

Not all problems can or should be formally encapsulated in a task, but we need to be aware that for every task and every bug there exists a multitude of additional problems which affect the progress of the project. Here are a few examples:

Here is the Venn diagram again, this time with every potential problem I can think of:

This universe of problems is both vast and constantly evolving. After the big bang of entering production, it will and must inflate, but more importantly it must at some point begin to contract back towards a big crunch if you want to release your game. This, of course, is the tricky bit.

The Development Diamond

The Development Diamond is a way of encapsulating this idea of inflation and contraction. For the ideal project it would look like this:

Meanwhile in Reality…

The ideal Development Diamond, if it exists at all, can only be observed in hindsight. When we recall a project from memory, we subconsciously edit the tedious bits out of the narrative. If you are lucky you will believe that you have experienced it at least once in your career, but this is probably just rose-tinted spectacles playing tricks on your mind. I believe that I have come close to experiencing it once, maybe twice, but I am almost certainly wrong.

In reality, the Development Diamond of your project will end up looking warped, stretched, and mutated, like something out of the lab scene from Alien Resurrection.

Here are three monstrosities let loose from my aforementioned closet of development nightmares:

1. The Whale of Glutinous Over-Scope

We all know the rule: never go grocery shopping when you are hungry. Similarly, you should never define the scope of your game when you are excited by the possibilities of your awesome ideas. If you do, you will end up with an extended period of inflation, leading to a delayed turning point, an intense contraction period, and a broader set of unresolved problems on release. This bloated beast can be painful to give birth to, but if you battle through, you can still end up with a great game at the end of it. Then, when a journalist casually comments that the game is “a bit on the small side”, you can indulge in a face-palming session of Picard-like intensity.

2. The Tadpole of Piss-Poor Planning

Just as your project is about to start, all of your plans are turned upside down by the decision to overhaul the development pipeline at the eleventh hour. Or perhaps there was no plan, and you are thrust into production completely rudderless. Maybe your entire team are pulled onto another urgent project, leaving you with a skeleton crew as you set sail into uncharted waters.

The deadline for releasing the game is immovable, but forget about solving problems more quickly, you are not even CREATING them fast enough to properly kick-start the inflation phase.

3. The Mutant of Eternal Despair

The mutant of eternal despair develops multiple tadpole tails, each one emerging from the last, because not only is it poorly planned, but the fundamental design of the game keeps on shifting beneath your feet.

Goalposts aren’t just moved further away, they are uprooted and launched into entirely different stadiums. The cause might be difficult-to-tame technology at the heart of your project or loose cannon, nutcase managers. Perhaps it is the result of an overly ambitious, unrealistic design or the switching of publishers half way through. Perhaps it is a mixture of all of the above.

If you are lucky, this abomination is mercifully euthanized — shot dead by concerned investors, or slowly suffocated by a dwindling team, as bleary-eyed developers question whether the games industry is really for them. Sometimes, however, whether through grit and determination, pure tenacity or naked naivety, the turning point is eventually reached, albeit years later than planned, and with a drastically reduced scope, the mangled project finally crawls towards release, amidst mutterings of, “I no longer care if the game is any good, it just needs to die” from the team.

Killer of companies, destroyer of souls, the mutant of despair will leave you a shell of your former self, but if you live through it, you will be eternally bound to your teammates, even after they have been scattered to the wind. And when your paths cross again, you will exchange knowing glances across crowded rooms with an unspoken acknowledgement that you are never to speak of it.

Control the Inflation and Reduce the Pain

The mutated Development Diamonds described above represent some of the more difficult projects I have come across, from a production point of view. No doubt you could describe some interesting abominations of your own.

Although the circumstances were different in each of these cases, the fundamental problem was a disruption to the inflation period, which was either swollen (whale of glutinous over-scope) or prolonged (tadpole of piss-poor planning and mutant of eternal despair), leading to a delayed turning point and therefore a bigger set of problems to solve in a shorter period during the contraction phase.

When I cross-reference these with the smoothest production experiences I can recall, the key difference was our ability to control the inflation phase, and if you can control the inflation phase, the contraction phase takes care itself.

That is easier said than done, and even if you do achieve it that doesn’t mean the project will be painless. But there is standard project painful and then there is, in the words of one insightful former colleague; “I no longer see the point in anybody’s existence” painful.

So, how do you control the inflation phase? Here are a few strategies.

Learn to Love the C-word

Picture the scene. Project leads are gathered around the boardroom table discussing how to get development back on schedule, when the producer casually throws the C-word into the conversation. A shiver ripples down the spine of the lead designer, culminating in a prolonged sigh which sinks the room into silence. The design team had been pushing for more time and more resources, but once again the dreaded “cutting content” conversation is rearing its ugly head.

It doesn't have to be this way. Experienced designers learn not only to plan for the cutting contingency, but also to actively embrace it as an opportunity to practice design by subtraction and to focus in on the features that matter most. Defend crucial content passionately and vigorously, but also be prepared to re-examine the structure of your game objectively. The requirement to cut is just another constraint forcing you to find clever, creative solutions.

The end consumer doesn't know what content you planned; they only know what you deliver. They can’t miss content they never knew about, but they can appreciate a focused, elegant and polished design.

Practice the Pre-Mortem

Hindsight is a wonderful thing, and many studios routinely conduct post-mortems to channel lessons learned in hindsight into the next project. However, each project is different, and no matter how much you learn there are an infinite number of new problems waiting to be discovered.

While it is very difficult to predict specific problems before they occur, you can help to prepare yourself for the consequences by conducting pre-mortems not just at the start of every project, but routinely throughout development every time a major production decision is taken.

The pre-mortem works by imagining the worst-case scenario and then constructing a narrative that gets you to it from where you are now. Imagine yourself, for example, as the Democrat party in early 2016, constructing a narrative for the seemingly impossible scenario in which Donald Trump actually becomes president. As you invent the story of your own nightmare, you may discover that not only is it less far-fetched than you imagined, but that there are some clear dangers which you can prepare for, if not prevent, by considering and acknowledging them beforehand.

So far as I can tell, the pre-mortem was originally devised by the Harvard Business Review.

PCU Problems Table

The requirements for each project are different and there will always be difficulties which are unavoidable. If you are working on a movie tie-in game, for example, then cutting content becomes a much bigger challenge because your backstory is fixed.

The pre-production phase is the ideal time to draw up a PCU (Preventable, Controllable, Unavoidable) table of problems that might afflict your project, so you can prepare and mitigate accordingly.

First you draw up a list of every potential problem you can think of, like this:

Next, you put each problem into the appropriate column in your PCU table, like this:

While you won’t be able to identify all of the problems which could afflict your project, at least you have thought about how you can tackle those that you can.

Embrace the Anguish

I thoroughly enjoyed delivering my Development Diamond talk to the unsuspecting students of Manchester Metropolitan University, and I trust that my “universe of problems” analysis wasn’t too disheartening. Making games is, after all, supposed to be a dream career.

But that is the point; despite all the anguish involved, making games is a dream career.

Many other jobs are full of stress and pain. The fact that game development is also thrilling, captivating and wonderous is what keeps us pushing onward through the storm, but it is no use pretending that the storm does not exist.

As Theodore Roosevelt so eloquently put it, “Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty… I have never in my life envied a human being who led an easy life. I have envied many people who led difficult lives and led them well”.