I used to love the idea of MS Project.
While working on Spider-Man 2, we'd often hear the same story:
"I was going to work on this, but I couldn't because such-and-such wasn't ready, so I tried to work on this other thing instead, but such-and-such wasn't ready, so I ended up working on item C."
I kept hearing those stories and thinking - we really should be using MS Project. It tracks dependencies! It will help prevent these sorts of problems! It's the piece of the puzzle we're missing! Once we start tracking dependencies, we'll be unstoppable!
So I looked into using Project, and some other scheduling software, and experimented with some dummy schedules and leveling tools and decided that not only did they not work very well, but we weren't ready to switch to a whole new system, not with Spidey 2 already more than halfway done.
Still, when Spidey 3 came along, I spent over a month near the beginning making a detailed schedule with MS Project. We did a bunch of things right. We asked the people doing the work how long the work would take (or their leads if those people weren't actually available yet). We extracted our staffing plan from the schedule. And we deputized some producers to run around and check to see if people were working on what the schedule said they'd be working on and to adjust it if necessary.
And after a month or two (it's been a while, I don't exactly remember) we scrapped it, because the schedule seemed completely unrelated to what people were actually doing in the offices. They still weren't working on "what they were supposed to be working on", despite the wonderful dependency tracking that was supposed to take care of that. Game development is still far too fluid and unpredictable, even when dependencies were being noted, we had problems with staffing and prototyping and changing plans that made dependencies pale in significance.
Now, some people swear by MS Project. I think they break down into a few categories:
* People who use it but not to track dependencies. For example, they might make a list of tasks, select them all and make one giant dependency chain, and then have a pretty (and completely linear) gannt chart they can show off, but under the hood this is no better than using excel and doing a Sum. They might as well use Excel.
* People who have modded the crap out of MS Project. Mike McShaffry's tools are prety cool but they actually don't seem to use Project's ability to automatically track and level dependencies - as he points out at the bottom of the page, his tools are for tracking high-level dependencies, and even then you have to eyeball it: oh look, Joe is starting a level before the World Editor is done.
* People who "do it right" but it still doesn't help them - Erik Bethke's book showed how they used Project and its leveling features for Black 9...a game that never shipped. We can't blame Project for that but it does help to show that we have bigger things to worry about than tracking dependencies.
* People who "do it right" and it does help them. I did an informal poll of the room before my Theory of Drag talk last year and it looked like maybe 1 in 200 people used Project's leveling features and believed it helped. Still they're spending an awful lot of resources on it - resources that could possibly be spent more directly on the game.
Now, let's go back to this original "problem" we had that I thought MS Project would solve. "I couldn't work on Item A or Item B, I had to work on Item C."
Is this really a problem? It's only a problem if Item C is some low-priority item that we might want to cut from the game - chances are, all of these things need to be done and although it might be nice to work on Item A first it's just fine to hit Item C instead.
And if Item C really is optional, or someone really is blocked, there are lots of things you can do that will suck down less resources:
When I wrote those articles I was still trying to make Project work. I have since given up - now I believe Excel beats Project, hands down. (Microsoft still wins, of course...)
FWIW, dependencies weren't an issue on Schizoid at all - the biggest scheduling issue on Schizoid was that I was an overbooked resource, and this was a blindingly obvious problem that we didn't need any fancy scheduling software to see.