If you’ve ever played with balloons, you know tangibly how the elasticity of the balloon is a key characteristic.  Until you’ve filled it to the breaking point, you can squeeze one part of a balloon, and the filling just moves to another part.  I use this as a shorthand to describe the class of problems where there is a fixed amount of work that has to be done but multiple resource allocations that can handle it.

For example, when I was working at THQ, the accounting/finance department rolled out a new purchasing/reimbursement software package.  It was a high-end package from a company that worked with a lot of big, enterprise-level companies, and it could handle everything from requisitioning a dev kit to making milestone payments to filling out expense reports.  We spent days getting trained on how to use this software, from lowly QA folks all the way up to the VP level, and I’m sure that it made things much easier for the accounting/finance department by eliminating policy violations at the input level.  However, at the same time, it shifted that work from the accounting/finance folks to everyone else in the company.  The overall amount of work didn’t change; it just got pushed around and re-distributed.  The productivity numbers for accounting/finance probably skyrocketed, because they had (knowingly or not) drafted everyone else in the company to help do their work.

Tools development is a classic balloon-class problem.  Whenever you run across work that is highly repetitive, is executed according to well-known rules, and will take a lot of hours to do by hand, it is natural to look at tools-based solutions.  You can do a simple algebraic cost-assessment on this kind of work (artist/designer time saved per unit times number of units minus tools developer time); you can even get into a finer calculus involving the cost differential of programmer time vs. artist/designer time, throwing in variables for debugging, interface improvements, and other iterative aspects of toolchains.  At the end of the day, though, you are re-distributing work, and more often than not, there isn’t a clear “win-win” scenario because the marginal difference isn’t significant in the face of all the other work that has to be done on a project.

As a project manager, you constantly have to assess, balance, and re-assess the effectiveness of your resource allocations.  Balloon-class problems are a real headache because they tend to muddy the waters rather than bringing clarity.  So, when I recognize a balloon-class problem, one of the first things I look at is where the best match is between the workflows of the people who will have to do the work and the type of work that is required.

For example, populating levels with enemies is a common balloon-class problem in RPG’s.  You’re never really going to be able to eliminate the designers from population (not if you want solid gameplay), but it is a tedious, repetitive task, and optimizing your toolchain so that your designers can focus on refining gameplay rather than simply implementing it can be a huge win. However, when push comes to shove, I would rather have my designers implement and refine the populations rather than develop a toolset that can populate automatically, for the simple reason that the designers need to be hands-on with all of the gameplay experiences.  Particularly when you’re trying to develop large amounts of content, the natural inclination is going to be to go for systemic, broader solutions, but your gamers are better served by less content that is better tuned over more content that is systemically, programmatically generic.

At the same time, designers are generally creative people and want to be problem-solving and creating in interesting ways, not doing the same rote tasks over and over.  If you can afford to support them by providing appropriate tools so that they can spend more time raising the quality of the content you have rather than churning out content from scratch, you would be well-advised to do so.  But, in a pinch, give the work to the people who are best suited to achieving the best result.

Designers craft gameplay; accountants can run numbers and policies better than anyone else.  As a project manager, you have to know when to ask your team to swallow the bitter pill, even when they think there is a better solution, especially when that better solution is just redistributing the work rather than substantially reducing it.