Difference in Type
The difference between management of a project that finishes and management of a project that goes on until abandonment is a difference in type, not amount. Putting more time into the project isn’t necessarily what’s needed to finish it – as is evidenced by the droves of finished games that get made in days (game jams, much of my work since 2007, etc.), vs the heaps of unfinished projects that have dragged out for years.
Finishing requires a different mentality in managing development energy. Closing out a project means identifying what is incomplete about a project – which can be done at any point in development – making a list of what absolutely has to be done, then only making that list shorter.
Stability or Scramble
There are two different, somewhat incompatible styles of team management: a way that works to maintain a project that’s stable, and a way that scrambles to bring order to the chaos of an early or troubled project. The latter can be a dangerous approach in a large project with momentum, since it can muck up an otherwise good thing; conversely, the maintainer is just as dangerous when a project is starting up or undergoing major shifts, since a sense of urgency and higher risk tolerance are needed to progress those situations. Someone might be naturally more inclined to use one approach or another, someone might have more practice at one strategy or the other, but someone’s ability to recognize and switch according to context is ideal.
Although one approach isn’t universally better than the other, one or the other may be a better fit for a particular situation.
Many small videogame creation efforts involve similar situations.
If You’re Making Small/Medium Games…
Projects at the exploratory, student, and amateur scale tend to favor the scramble. The creation of original, coordinated, multi-person industrial arts on a limited time frame – especially with learning on the fly – has a way of going immediately from chaotic start (what are we doing?) straight to troubled finishing (how are we going to finish on time?).
Only in the case of projects consisting mostly of experienced developers, where everyone involved has a sense for how long it will take to hammer out the initial and final elements (generally because they’ve completed similar games many times before), does stability management strategy have a place. At that point, management efforts only need to coordinate and facilitate the parallel production of countless levels, animations, sounds, features, and other content without thrashing the direction or getting in anyone’s way. Though this situation is rare in hobby or student projects, this pattern is appropriate for stable, successful, large companies churning out more sequel(s) to successful franchises.
When the stable maintenance management style pops up in little indie projects, there’s a danger that the project will drag out forever with only minor, incremental, increasingly unimportant changes. Every week becomes more about tracking what’s happening in the present tense, instead of ensuring that the team is tracking toward what needs to happen next. The comfort and consistency create a feeling of steady progress for all involved, meanwhile postponing or ignoring the closing decisions that need to be made, forgetting that next week needs to be different from this week, if the project is ever going to end.
Does your project need someone with a scramble mindset?
Does it have one?
Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.
Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!