This post is a continuation of The Indie Infrastructure, a series for those thinking about “going indie” or still getting their bearings once casting off from salaried shores.

• The Indie Infrastructure #1: Game Engines
• The Indie Infrastructure #2: e-commerce
• The Indie Infrastructure #3: Employees

In my last Dinosauria update post, one of the commenters asked how I came up with the “Percent Complete” metric.

[pfmeter id=2 target=100 progress=9 display=4]

Answer: Microsoft Project.

If you are making games on a development schedule over 6 months, or you are an aspiring game producer, you owe it to yourself to learn to use this program.  Project will help you with three things:

1. Recognize dependencies (so you can make sure no one is waiting around for someone else to finish an asset or feature)
2. Schedule your tasks and create milestones
3. Track progress

Having a solid idea of when things SHOULD be done is important, because otherwise it’s all too easy to dither around on unimportant features, leading to overall schedule slippage and eventual cancellation.

Project can be a difficult beast, though.  It is an open-ended program, and if you don’t learn to use it efficiently, you can waste a lot of time fiddling with schedules without gaining any additional insight into your production pipeline.  This post is about how to set up a game development project file that is sufficiently detailed and malleable for a small, dynamic team.

Step 1: Create a broad set of tasks broken down by category

For instance, I have 1 main task called “Dinosauria”.  Under that, I have “Code”, “Assets”, and “Misc”.  Under “Assets”, I have categories for “Models”, “Animation”, “2D Design”, “Concept Art”, “Environments”, etc.  Under each of these I have tasks broken down to 1-5 day long tasks.

Step 2: Estimate Durations, Set up dependencies, and assign resources

Next, I go in and assign resource names to each task.  For resources I haven’t yet hired, I use a temporary name.  This part is usually pretty easy for a small team, but it can help you to figure out how many you need to hire in order to get the game done on the desired schedule.

By the way, you can also edit an inidividual resource’s availability by changing that resource’s calendar.  For instance, I set up the Andy Schatz resource to only work on the project Tuesday-Friday, since I usually use Monday and one weekend day for non-development related tasks (support, website, blogging).

After that, I estimate the durations of each task.  If any particular task takes more than 5 work days, I try to split that task into multiple tasks.

Finally, I set up dependencies with the “Predecessor” column.  This step can be tricky.  If you get too stringent about setting up individual predecessors for all your tasks, you project will start to look like spaghetti and it will be very difficult to adjust the schedule to changing circumstances.

For this reason, I prefer to be a bit lax about setting up individual dependencies, we will come back to this in the next step when we create our milestones.

Step 3: Set up milestones

One of Project’s interesting features is called Level Resources.  This uses your task information to automatically set dates for each of those tasks.  It essentially creates your schedule for you.

The weakness of leveling is that Project has no idea which tasks you want to finish first and which you want to finish last, except in the case that you have predecessors set.

The WRONG thing to do it to set up predecessors for EVERYTHING so that Level Resources builds the schedule the way you want.

The RIGHT thing to do is to set up milestones as tasks in your project, create “predecessors” to those as the tasks you want complete in each, and then level.  You can then go back and assign the milestones themselves as predecessors to task categories so that you make sure certain tasks don’t even start until after certain milestones have been hit.

Once you’ve done this, Level Resources can help expose what tasks have not been figured into the schedule and what tasks may blow your project’s schedule.  Adjust the milestone in which each task’s category is due in order to fit the project to your schedule.

Step 4: Track your progress!

Once this is all done, you can start checking off tasks as complete.  Then you can use the “Tracking Gantt” to see what percent complete the entire project is.

One final note: You should NOT adjust your task estimates in order to make your project fit your schedule.  It’s awfully tempting to say “oh, we’ll just work extra hard and get this tasks done in 3 days instead of 4″, in order to make the Project file fit your overall timetable.  One of Microsoft Project’s most important benefits is exposing to the developer when their ambitions for a project are too big for the reality of the budget or timeframe.

That’s it, happy Project-ing!

You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.