Boy this quote really speaks to me. I’ll definitely pick the book up. The last (non game) project I was on matches this perfectly. The project was to do a complete rewrite of UI and middle layers of an existing system. Management didn’t want to spend much time on this because a completely new system was in the works that would replace the old. But in the mean time the existing product was so unpopular a stop gap was needed for customers. Given the requirements and (small) dev resources we came up with a good design and a fairly aggressive implementation schedule of 10-11 months. However this was unacceptable and the product had to ship in 6 months. This was a low value project and management wasn’t willing to pay the costs in time and resources. At this point fun new macho “can-do” terminology emerged and I discovered we were in “internet time” implementing a “compressed development cycle”. What this meant was that everyone single person had to do the work of two. Crunch time started at the very first milestone and dinners were brought in for late hours. To make a long story short, the product shipped 14 months later with very questionable quality. Work on the new system was slowed and still at least two years out.

This was without doubt the worst managed project I’ve ever been on and seems fully predictable from this book. Another sad but funny anecdote is how management motivated the developers. We had a “ship party” at the head honcho’s home about 4 months before actual ship (management was still in a state of denial). This “home” was a large mansion complete with a full blown movie theater (including lobby and wet bar) built on the bottom floor. I don’t know the message management was trying to convey, unless it was “we really appreciate the unending long hours you work so we can continue to live in total decadence”.

Except… there often is no single managerial “you” in this business, because responsibility is split between publisher and developer, lead programmer, producer, CEO, marketing and business development. They’ve all got different interests and perceptions, and for many of them keeping a team and developers sane functioning isn’t a rewarded activity.

I would be willing to bet that nearly every failure in the industry was accompanied by “heroic” amounts of overtime, too, but still failed. Clearly the justification is no justification at all.

To look at it from another angle… all the successful games may have been GIVEN “heroic” amounts of overtime, but who’s to say they would have failed if they hadn’t, and there had instead been a sensible, rational, realistic project management solution?

Leaving aside other potential reasons for working overtime (which I’ve discussed quite a bit here before: http://www.gamesfromwithin.com/articles/0412/000054.html ), I think it can still apply to a large percentage of the projects in the games industry.

The book says “the one common characteristic among death-march projects is low expected value”. It doesn’t say anything about whether the projects were a mega hit or not. Just that not much was expected out of them.

If a company is making a game and they know it’s going to sell 5 million units, it would stand to reason that they would put whatever resources were necessary behind the project. In the grand scheme of things, spending an extra million bucks in development is nothing compared to the many more millions of profit that it will reap.

On the other hand, if they’re not sure how well the game is going to do, then they’ll try to cut every corner and minimize costs on the hopes of breaking even or not losing much money (low expected value).

The games industry is a very hit-driven industry, and we don’t often know we have a mega hit in our hands (unless our game is called Halo 2 or Half Life 2), which might explain some of the attitude from publishers.

In any case, low expected value or lack of resources are not the only reason for overtime in the games industry. Which is unfortunate because those could be relatively easy to fix compared to ingrained cultural issues.

Maybe I have the wrong definition of death march but if it means 6 or more months of overtime then I can tell you 100% for sure that the above statement is pure BS in the game industry. I would be willing to bet that every nearly every hit game in the industry required heroic amounts of overtime to ship. Clearly the justification was very real.

http://www.gamasutra.com/features/20041229/kelly_01.shtml

I haven’t read the book but it makes an interesting comparison with your review.

I disagree with you on one point. There should not simply be “somebody on your project managing risk”. That is something that management cannot deal with alone, or even fully understand. Everyone but the most junior employee should be aware of and managing their risks and those of their team and their project as a whole. I would argue that a programmer with average technical skill but a sound understanding of risk is far more valuable than a programmer with extraordinary technical skill but no awareness of risk.

It seems to me that it is impossible to consider risk in isolation. At a minimum, here is a trade-off between risk, timeliness and quality. Are these issues considered in this book?