Most project managers are familiar with the phrase “fast, cheap, or good, pick two”.  It’s a classic formulation of a resource constraint tradeoff.  If you need it fast, you can spend more or lower the quality bar; if you need it cheap, it’s going to take longer or be lower quality; if you need it to be top-notch, you’re going to have to either spend the money or the time to get it there.  This triangle of constraints represents (in some ways) a particular version of balloon-class problems: squeezing any one angle is going to put pressure on the other two; if you try to pressure all three, it’s likely to explode in your face.

In my experience, though, things are rarely so clean.  For example, where does scope fall in these constraints?  Is it a sub-set of quality?  And labor cost factors into both fast and cheap; even if you’re running a small team, burn rate X time = money.  The idea that spending more money can make things faster also runs into problems with critical path and non-segmentable work (see The Mythical Man-Month on why 9 women can’t have a baby in 1 month).  In team situations (and almost all game development is team-based), you also run into problems because communication efficiency scales inversely with team size, and scaling a team is a risky and time-consuming proposition.

People have tried to refine this triangle by making diamonds, or Star-of-David type diagrams, which really misses the point.  Project management is not a problem you can solve in the abstract.  Every team, every project has its own dynamics.  The triangle is a tool.  Like a forking move in chess, it allows the project manager to present clearly to other stakeholders that they must make a choice, and regardless of which choice they make, they are going to have to give something up.  It is a defense against outside forces who often want everything, or, for that matter, against inside forces that are not setting priorities realistically.  Its simplicity is its strength; it embodies the problem.

Even though it’s not the most precise formulation, it’s still a useful tool.  It allows you to negotiate without saying no, a valuable move particularly when you’re managing up.  On the flip side, if you recognize that you’re getting this a lot from your team, you need to revisit the project priorities, risks, and mitigation plans; something has drifted out of alignment, and you may well be the one who is drifting.

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.