Preparing For The Inevitable

---

How To Make A Project Plan

As we've mentioned, the project plan is the most important document that the developer creates. This set of documents is a road map for producing the game. It includes the schedule and the budget, which are generally attached to the contract for the production. The diagram in Figure 13.2 provides an overview of the process for creating a realistic project plan and budget. Notice how each step directly affects its successor. Here is a description of each step of the process.

Exercise 13.1: Goals

Working with the team you've recruited, write down the goals for turning your original game idea into a finished product. Make sure to include both gameplay goals and technical goals.

Goals

First articulate all the goals of the project. Include gameplay goals, such as features and levels, and technical goals, like enabling multiple players over the Internet. Also include the target platform and proposed launch date. An example might be to launch on the Xbox and PlayStation 2 for Christmas 2006.

Schedule

A schedule is an estimate of how long it will take your team to complete each deliverable. The deliverables are made up of tasks, and these tasks are assigned to specific team members. The best way to begin creating your schedule is to break down each deliverable into a list of tasks. If you are experienced, you will know the tasks already. If you are not experienced, you may need to confer with your team members to get an idea of what tasks will need to be done and how long each task will take. Next go through the tasks and define what resources (i.e., team members) you will assign to each one and how long, in terms of days, it will take to complete.

Finally, assign start dates to each task on the list. Some tasks can be done in parallel, while others won't be able to begin until certain other tasks are completed. These are called dependencies, and they must be accounted for in the schedule. It can become quite complex when one aspect of the game requires fifteen tasks to be completed by three different groups in a very specific order. You will also need to make sure you are balancing the workload for each team member. If you schedule a programmer to be coding three features at once, you will undoubtedly be disappointed when only one task actually gets accomplished.

Figure 13.2: How to make a project plan

Deliverables

The goals have a direct impact on the deliverables, which are the materials that you produce as part of the project. List out everything you envision making, and organize them under the stages of development. For instance, you would list a design document under the design stage. If your game has levels, you should list the number of levels or environments under the production stage. Likewise, you would detail out exactly how much artwork, animation, and other media you will need to produce and during the production as well, defining things like the number of 3D models, characters, sound effects, minutes of music, seconds of linear animation, seconds of voice recordings, etc. Each one of these is a deliverable, and it has to be both budgeted for and placed on the schedule.

Exercise 13.2: Deliverables

List out the deliverables for your production based on the goals you just stated. Think of every single element that goes into making up your game, from code modules to sound effects. Work with your team members to make your deliverables as accurate as possible.

Many game producers use a software program like Microsoft Project to create schedules. Microsoft Project and other scheduling programs allow you to drag tasks around the schedule visually and create links and dependencies between tasks. If you don't have a scheduling program, you can use a spreadsheet like Excel or even a paper calendar. The key is to organize all the tasks that will need to get done during each stage of development and to estimate how long each one will take and how many people will need to work on it. When you are done, you will have an overview of your production time line, and a list of resources you will need and for how long. This list is what you need to produce the budget.

As you'll see, the schedule forms the foundation of your project plan and will become an indispensable tool for managing the production. The sample schedule in Figure 13.3 is shown in Gantt chart format-a typical view for looking at schedules.

Exercise 13.3: Schedule

Using either scheduling software or a paper calendar, create a detailed schedule for the production of your original game. Don't leave any tasks unspecified. Also, make certain to identify any dependencies. You may need to estimate the length of time it will take to complete many of these tasks. Don't worry, the important thing is not how accurate your schedule is right now, but that you think through the process and see how the pieces all fit together.

Figure 13.3: Sample schedule in Gantt chart format

Figure 13.4: Sample budget

Budget

The budget is a direct function of the schedule. This is because the schedule tells you exactly how many people you'll need and for how long, and salaries comprise the majority of a game budget. Other 'direct' costs include things like software licensing and specialized services.

The sample budget in Figure 13.4 was created using Microsoft Excel and shows several important elements of a budget. The cover page on the left shows total costs for various types of production labor: project management, game design, graphic design, digital video, 2D/3D animation, and software development. It also shows the direct costs for testing, production supplies, media, licensing, and administrative costs. In this instance, the testing costs are probably being paid to a third-party testing facility. If they were internal resources, the producer would have included them under production labor. Every production will have its own way of handling specific things like this.

The right hand page is an example of how each of the labor totals on the front page is calculated from a breakdown of line items. In this case, on a small web game, one game designer is going to work 20 weeks at $2000 per week. It looks like this is a very small company, because they aren't paying any benefits to this employee and they are only calculating an overhead cost (the cost for equipment and facility) of 15%.

Overhead expenses refer to all nonlabor expenses required to operate the business. For game developers it generally includes rent, utilities, supplies, insurance, and other such costs. A true overhead percentage can be calculated by an accountant as a function of the developer's real labor and nonlabor costs. This percentage is extremely important because many developers do not calculate it correctly and wind up shortchanging themselves. A typical overhead amount for developers is 100%. That means a typical developer should charge at least double their labor costs in order to cover their actual costs. This developer has probably underestimated their overhead, which may cause difficulty for them down the line.

After the benefits and overhead are calculated for a specific line item, it is included in the total for the group of resources and carried over to the front page. All the various costs are added in a subtotal. And then, several important percentages are calculated. The first is 'production insurance.' If you have taken any insurance out to back-up your company's ability to complete the job, you'll need to add that cost here. In this case, the developer has not done so.

The second percentage to be calculated is 'markup.' This is a percentage that the developer charges above their costs. Thus it may be possible for a developer to actually make some money on a production if they manage it closely and meet their expectations. A standard markup amount for developers on a work-for-hire agreement is about 25%. The percentage varies depending on the developer's total compensation. A lot of developers spend everything they're given and rely upon the royalties to yield their profits.

If you're starting out as a developer, we recommend that you get your hands on budgets from similar game titles or ask a more experienced producer to review your work. Short of hiring an experienced producer, this is the best way to make sure you have considered everything. In the end, you will probably forget something, so keep in mind that it's always better to estimate just a tiny bit high-the fat you build in will get worked out during the next part of the process.

Exercise 13.4: Budget

Now it's time to create the budget for your original game. Use the sample schedule form in the Appendix on page 443 to build out a budget for your original game idea. It's okay to put down your best guess for the various costs, because you will be revising your estimates later.

Revise

After you've gone through the first four steps, don't be surprised if you wind up with a gigantic budget number that far exceeds what you know the publisher will advance you. Let's say a typical budget for a console title is $4 million, but yours comes out to be more like $6 million-what do you do? First, don't panic. This is normal. Second, don't give in to the urge to just cut the budget number down to match the publisher's expectations.

Your next step is to go back to the beginning: look at your goals and revise them. Once your revised your goals, you'll need to revise the deliverables, which should now require a shorter schedule. Once you've revised your schedule, you'll need to reflect those changes in your budget. If, for example, you cut down your goals down from 'recreate the submarine battles of WWII' to'recreate three major submarine battles of WWII,' this would cause a ripple effect in your deliverables, your schedule, and, of course, your budget. This is because the change in goals in this case would drastically cut the amount of media and levels you needed to produce, reducing resource requirements and effectively lowering the budget.

The biggest mistake that beginning developers make during the budgeting process is to not change their goals and deliverables but instead fiddle with the numbers until they come out looking 'reasonable.' Always start with your goals and work down through the deliverables and schedule, item by item. If you over-promise and under- budget you will run the risk of losing money, overworking your team, and being unable to complete the project as promised.

Exercise 13.5: Revise

Now assume the publisher has asked you to cut 20% out of your budget. Starting with your goals, and working your way through the deliverables, schedule, and finally the budget, revise your plan to reduce costs.

Milestones and approvals

Each time a stage of development has been completed and approved by the publisher, the developer receives a milestone payment. It's important that the developer keep a written record of all approvals and decisions from the publisher. This is a time-consuming but necessary process handled by the producer that helps manage the production.

Quite often the publisher will ask for changes to the design in the middle of production. For instance, let's say a developer was producing the submarine game we've been talking about. The developer has received written approval for the concept/contract stage and the pre-production stage.

Then during production, the publisher decides that the submarine game should be set in modern times instead of WWII. This kind of radical change in direction is not uncommon. This means that the developer would have to re-think the project, starting with the early concept deliverables and the schedule and budget would have to be extended accordingly. A proper response from the developer would be, 'We will be happy to make the change if you extend the schedule and pay us an overage that covers the additional expense.'

Naturally, the publisher won't want to pay more money or extend any deadlines, and they may even threaten to withhold approval and payments if the developer doesn't acquiesce. Despite how it may seem, in this scenario, the developer is in the position of strength. The record of signed approvals should show that the developer has followed the contract unequivocally, and it is the publisher who is pushing to alter the scope and direction of the game. If the producer for the developer has been thorough about getting signed approvals, the developer should be in a defensible position. Without a signed record of approvals, the publisher could say that they had not agreed on the concept for the game and demand that the developer fulfill the original schedule and budget terms with the requested changes.

Unfortunately, many times the developer will want to please the publisher, and so they'll make the change without defining the overage costs at that point-believing they can make up the time later in production. This is a strategy that is sure to fail. Eventually, the team will fall behind, and the developer will have to ask for an extension on the schedule. If the developer asks for overages at this point, without any record of how the requested changes have affected the costs of production, the publisher is sure to deny the request.

The bottom line is that nothing should be left up to good faith. The developer can and should manage the publisher to the schedule and contract in the same way they manage their own team. Approvals should be handled in writing, as should change requests and overage estimates. These details that seem so formal and unnatural in the rather casual environment of game production can mean the difference between completing your game on time and on budget, or having the project terminated. Again, it comes to down to maintaining a clear line of communication and letting the publisher know the consequences of every request that they make.

---