chapter four • external partnerships
4.4.1 The Assignment Is the goal of the project spelled out clearly enough that someone who is familiar with the industry (but not involved in creating this game) could understand what you’re trying to build? Are the specific tasks that the developer, the publisher, and any other parties will undertake spelled out as explicitly as possible? You need to ensure that responsibilities are clearly articulated. Ask yourself, Who is responsible for testing the product? Who is in charge of localizing it? If there are publisher-side community management tasks, they should also be detailed in the contract, and so on. Finally, you’ll need a mechanism within the definition of the work that spells out what process is to be followed for change requests. Unless there is some limit to the number, the complexity, or the increased implementation time that can be spent on change requests made by the publisher, it’s very easy to get yourself into a situation in which your studio ends up spending far more time on the project than you’ll get paid for – situations in which you finance change requests out of your own pocket in order to try to appease a publisher, just to get your milestone payments. This can easily become an untenable position that breeds friction in the relationship. Get your change request procedure and contract extension mechanism in place up front, and everyone will be better off. Make sure the following three items at least are spelled out clearly: • Task definitions • Dates • Dealing with change requests
4.4.2 Pay Typically, you determine how much your team is owed for a project based on the number of people employed and a fixed cost per man-month rate. Currently, for most developers, this is between $8000 and $16,000 per head per month. Obviously, such a wide cost spread represents the different levels of experience that different teams offer, as well as how much money the publisher has to devote to a particular project. For most “work-for-hire” projects, these per-head, per-month costs represent the total recompense for the work the developers do on the project. It’s very valuable to think of the work in terms of man-months as per-month costs, because it helps tie the costs to the project schedule. It also makes it fairly easy to calculate how much extra funding needs to be appended to the contract in the case of change requests, project extensions, etc. It is common to try to lay out all payments associated with explicit milestone criteria that are defined at a very high level. To understand how this is usually structured, let’s take a look at the sample milestone list and payment schedule shown in Figs. 4.4 and 4.5.
82