Milestones and Glass Houses

• It is an objective means by which both the developer and the publisher can measure progress. However, milestones need to be written in such a way that a third person can read the milestone description and determine exactly what the milestone should accomplish. It also helps for the developer to establish procedures to help the publisher determine that the milestone does exactly what it's supposed to do. An excellent place to include such procedures is in a technical design document created as one of the game's first milestones.
  
• It provides interim goals for the developer, helping him to focus his efforts. Developers should prioritize tasks so that they do the most important tasks first. If the project is technology-based, completion of the game engine should be one of the earlier milestones. For games primarily driven by art, the initial milestones should involve storyboarding and approval of art direction. Scheduling the difficult milestones to be early in development allows both the developer and the publisher to project the completion date more accurately. Just be sure to build in time at the start of schedule for experimenting with new techniques, as well as time at the end for debugging and polishing.
  
• It alerts both the publisher and developer to problems early enough for them to correct the problem or re-evaluate their participation in the project. If the project is determined to be jeopardized, it is best to terminate it quickly so that everyone can get on with their lives and move on to more profitable ventures.
  
• It allows the publisher to invest money into the game gradually, minimizing his exposure should the project suffer problems. This is best done by weighting milestone payments toward the end of the project, although it does place an extremely heavy burden and risk on the developer, especially if the game is canceled before its completion.

Unfortunately, some developers with whom I've worked did not take such planning seriously, which was obvious by the very terse technical design documents they created at the start of the project. They apparently thought that, with the difficulty of predicting creative and technological inspiration, with so many details being discovered or changing during development, how can anyone possibly come up with a plan that's worth the paper it's written on? Why not just design as you go?

Such thinking misses the point entirely. As Dwight D. Eisenhower was fond of saying, "In preparing for battle I have always found that plans are useless, but planning is indispensable." Taking time to create a plan has the following benefits:

• It creates a clear, well thought out vision for everyone to follow. The people who have a claim on creative control (director, writer, producer, designer) need to share a common vision for the project, or they will be working at odds with each other.
  
• It helps the developer to consider all the necessary factors and make informed ongoing judgments. If a developer deals with problems only as they occur and fails to have any contingency plans, he is guaranteeing that the project will go over time and over budget.
  
• It demonstrates to the publisher that the developer has seriously considered all aspects of the process. Building confidence between the developer and publisher early on will help minimize problems that will surely come down the road.

"But wait!" you say. "If it's so important to carefully craft milestones that will guide the developer and the publisher through the project along the safest path, then why are most milestones written into the contract - before the developer has had proper time, resources and funding to analyze the project?" That is a conundrum, all right, but there are ways around it available to both parties.

The publisher has a strong interest in having the interim steps of the game's development delineated in the contract. Should it ever be necessary to cancel the game, it is easier from a legal viewpoint to determine how far along the project was and what each party's remaining obligations are to each other. However, some publishers create two agreements for each project - one agreement to develop the project up through the design, technical design review, and creation of development milestones, and a separate agreement to develop the project from that point onwards. Thus, the publisher keeps inherently flawed milestones from being put into the contract while minimizing his exposure should he have to cancel the project.

If the publisher won't enter into such a two-stage development agreement, the developer still has some recourse should he discover that his initial milestone schedule is flawed. He can amend the contract with a revised milestone delivery schedule. Both parties must be agreeable to revising the contract, of course. But if the developer does indeed have a compelling argument for changing the milestones, then it would be of mutual interest to make such a revision.