Game Law: A Case for Flexible Milestone Deliverables

“Milestone Deliverables” are interim and final assets delivered to a video game publisher by the developer throughout the term of the development agreement. The approval of the “Milestone Deliverables” by the publisher triggers the payment of “Advances” that fund the ongoing development process. These milestone deliverables are defined in the publisher/developer agreement, often in minute detail. My latest 'Game Law' article for Gamasutra addresses the fallacy of detailed “Static Milestone Deliverables” and discusses a preferred methodology involving “Flexible Milestone Deliverables.”

“I hear you know how to make games... here's $5 million - make me some!”

As the stories go, in the wild and wooly early days of the video game industry, developers were funded by publishers via the delivery of rather large checks. These funds were dispersed solely on the developer's representation that they could actually make games. Sadly, publishers eventually realized that they needed some form of control over the developer, or there would be no way to assure that the publisher would ever receive a game for their investment. So, milestones were born. Instead of a single check to pay for the entire game, the funds were delivered over time, with the developer being required to show the publisher that progress was being made on the development of the game.

At first, a few milestones with general descriptions were given, such as, 1.) the signing of the contract, 2.) a playable alpha, 3.) fully completed beta, and 4.) delivery of the gold master. Except for the first milestone, each of these deliverables would have to be accepted by the publisher before the correlative advance payment was made to the developer to continue the funding of the development of the game.

As this milestone process evolved, publishers began to add more milestones into their contracts and put more detail into each milestone to better manage the process and reduce their perceived economic risk. Often, the details of the deliverable were derived from the design document supplied by the developer. As deliverables became more and more defined, developers became less and less likely to meet them as required under their agreements. Eventually, “Milestone Deliverables” became a running joke in many studios, because as long as the publisher was satisfied with the actual progress of the game, compliance to the details of what the contract defined “Deliverables” was, in practice, not much of an issue. But it should be.

Feature Creep, New Technologies, Iteration vs. Static Deliverables

The simple reality is that things change throughout the development process. Even the best planned development cycles do not go as expected. Of course, the creative process in developing games gives a solid justification to this fact. After all, games are the result of a creative process and often rely on emerging technologies. They are also the product of a group effort with many cross dependant assets. This already complex process is complicated further by the fact that developers and publishers often attempt to define all the deliverables over a 24-30 month project before the project has even begun based on a design document. Then new technologies emerge, designs change (hopefully for the better), and cross dependent elements fall off track because other parts of the game are simply more difficult to implement that anticipated.

Quite frankly, some times developers pitch games too zealously and end up over-promising in the process. All of these complications, and more, end up with developers making commitments to milestone deliverables that they can not and do not keep. And most developers and publishers know this fact when they sign their contracts.

"Developer is in default from Milestone 2, or maybe 3...?"

There is an inherent risk to the developer in this process. It puts the developer in technical default under the contract because of a failure to provide the deliverables called for in the contract. As a result the publisher can terminate the contract “for cause” at any time, rather than exercising the “for convenience” termination. Under these contracts, a “for cause” termination is inevitably less advantageous to the developer than a “for convenience” termination. A “for convenience” termination often requires the publisher to pay out a portion of the remaining advances to get out of the contract where the “for cause” termination does not. No developer should put itself in a position where it is in breach of contract within a few months of signing with their publisher.

As you probably know, certain elements in the asset pipeline are expected to occur at certain points, and certain elements are necessarily dependant on the pre-existence of other elements. Other elements are completely independent and due to personnel issues, allocation of resources, or a myriad of other things that may not occur exactly when you anticipate. These matters often result in an actual delivery schedule that does not even vaguely resemble the milestone deliverable schedule in the contract.

Just like when milestones were first implemented to accommodate an evolving industry, as our industry matures we need to find ways to accommodate this disparity. This is not just because of the unreliability of the deliverable schedule, but because great games require iteration. And iteration cannot be written into a hard milestone deliverable schedule. Most importantly, milestone deliverables need to reflect what is actually occurring in practice. The inclusion of flexible milestone deliverables in the contract recognizes these facts, builds this flexibility into the contract to create a more organic relationship throughout the development process.

A Fixable, Flexible Solution?

Here is how it works. The initial milestone deliverable is, of course, defined. That's easy, as it is usually the signing of the contract itself. The next full deliverable in the contract is also fairly simple and straight-forward in that it is invariably based on the first iteration of the existing project, whether it is a partially completed game, proof of concept or technology demo or even a completed design document. From there on, the publisher and developer agree to confer periodically throughout the development of the game to set the deliverables. In this manner flexible deliverables allow the developer and the publisher to continue to write the specifications for each deliverable based on the prior deliverable. So, the second deliverable is based on what was delivered in the first deliverable. The third deliverable on what was delivered in the second, the fourth on the third and so on.

In addition, if there is a departure from the original design that requires substantial additional work by the developer; the developer has the opportunity to “up-sell” the publisher. Then modifications can be negotiated to the advances due under the contract to facilitate additional funding to compensate the developer for approved additions to the game. That way, the additional enhancements are not done at the developer's expense. They can be factored into the deliverable and also added into the advanced payments that accompany it. Of course, this process does require a close working relationship between the publisher and the developer. But the benefits to both are well worth the effort.

Conclusion

So, while some of the best developer war stories come out of discussions regarding the difference between the deliverable and ‘the deliverable,' meaning, the deliverable in the contract and the deliverable delivered, this is really no laughing matter. Often with static deliverables, the developer finds itself dependant upon the good graces of the publisher to accept a deliverable that in no way resembles what is called for by the contract. It is hardly a decent position to be in when the advances tied to those deliverables could mean life or death to your company. It is bad enough when there are a few items missing from the list of deliverables in the first few milestones.

However, the problem exacerbates exponentially as the project moves from milestone to milestone, due to the interdependency that naturally exists among the deliverables. So, let's make the deliverables in the contract match the deliverables in practice. Sure, there will be fewer war stories to tell. But it will be better for everyone involved, both developer and publisher. After all, static milestone deliverables have been a joke in the industry for years and it is time we stop laughing and started doing something about it.

______________________________________________________

(2005 Thomas H. Buscaglia. All rights reserved.)