These two problem areas have been lumped together because they yield very similar outcomes -- people are stretched too thin, and hold too many responsibilities. This means people often can't see past their bottom line to check the larger trajectory of the game's progress or feel.
Age of Booty (Certain Affinity, Max Hoberman) "Despite our strong start, we made some serious mistakes. Much of this was due to the fact that we split our focus across too many projects and shifted staff onto and off of the game on numerous occasions.
"On the programming side, for instance, we pulled the original two programmers off of the project while we negotiated the deal, which took several months to finally get signed. We eventually got these two back on it by hiring two replacements to handle Left 4 Dead, our other big project at the time.
"We hired a third programmer to assist these two while also contracting out some programming work. We then hired another full-timer and ended our work with the contract programmer. We handed the work the contractor was doing over to one of our Left 4 Dead programmers, who volunteered to complete it in his spare time."
And it goes on from there. Certain Affinity then took on a third project, pulling the volunteer back off, and eventually putting the original two coders back on. This coder confusion, even on a smaller project, can make a game's development a bit schizophrenic. While Certain Affinity felt as a young company it couldn't say no to projects, Age of Booty would've been better off without distractions.
Catan (Big Huge Games, Brian Reynolds) "Our biggest mistake ... was failing to assign a full-time lead programmer or lead artist to the project.
"Not having a solid management structure meant that things tended to fall through the cracks. There was no one to set goals for the programming team or art group. There was no one to assert what needed to be done day-to-day, or week-to-week, or month-to-month. The employees sometimes drifted, unsure what they should work on next, spending too much time on assets that were unimportant, neglecting elements of the game that were actually critical."
Microsoft/Big Huge Games' Catan
As much as developers rail against management on occasion, leads are important for setting structure and scope. Left unchecked, an artist (just as an example!) will fiddle with an asset until doomsday.
This problem was more common than I imagined it would be. But it does stand to reason that determining the scale of your tools, with appropriate code review, is incredibly important to building out your game in the early stages.
Rock Band (Harmonix, Rob Kay) "Expanding our code department for Rock Band meant bringing in new programmers who were very talented but weren't all designer-programmer hybrids, or if they were didn't know they were allowed to be. Too often we jumped headlong into implementation of a new system without taking the time to properly examine the implications or test the edge cases of the design. This bit us in a few areas, notably online matchmaking, which had to be redesigned multiple times.
"No doubt about it, jumping into development of complex new systems without a technical plan upfront was a flat-out mistake."
Harmonix's solution going forward is to include code review and a technical design document before implementing new systems. It seems obvious in some ways, but the frequency of this problem in postmortems indicates it's not yet at the top of everyone's list.
Indigo Prophecy (Quantic Dream, David Cage) "Another classic error we committed was trying to develop generic tools with a view to possible future productions, rather than tools dedicated to the experience of the game we wanted to create. The initial scripting tool was supposed to enable us to script both an FPS and a tennis game. The reality quickly proved to be different from the theory.
"A generic tool enables management of a great variety of cases, but none of them very effectively. The prospect of reusing a tool as-is for future productions is usually a pipe dream that costs time and money in the short term, with no guarantee of profitability in the long term."
Quantic Dream managed to realize this mid-project, and adapted the tool -- but not without some lost work. Naturally, what would help here is some proper technical documentation of the project's specific needs.