The Hoyt Method of Game Development Scheduling - Project Scope

This post is a somewhat abridged version of a dialog that I had with a colleague (Jamie Fristrom) after the 2007 IGDA Leadership Forum, in November. In a presentation regarding the difficulties of accurately scheduling a project, he asserted that it might be a good idea to simply double all your estimates when presenting a schedule to a publisher. As he has mentioned, I took issue with this idea, because I feel that it is unnecessarily deceptive. I advocate a different, and more transparent, approach, that integrates a concept called “Judgment Day” (which was originally explored by the Production team at High Voltage Software, when I worked there under Kevin Sheller. I don’t know whether or not they are still using it).

It’s worth noting that the Judgment Day concept arose out of a specific type of game development: 3rd-party licensed titles with very rigid ship-dates. In these cases, you KNOW your ship date, and you can be almost certain that the game won’t be canceled if it’s looking mediocre during development. It’s really just a question of how good it will be by the time that you get there. The goal of the Judgement Day philosophy is to ensure that what you end up shipping is great, and not just mediocre.

The developers I’ve worked with invariably bemoan how much better their game could have been, if they’d “just had a couple more months.” (This is basically a variation on the “games are never finished, they’re only abandoned,” concept.) So, if you acknowledge that you are ALWAYS going to wish that you had a little more time, then it’s foolish to schedule yourself right up to the wall, in terms of the time that’s available. Why not design a smaller game (after all, scope does not equal quality), that you could “finish” sooner?

It is my assertion that a smaller game, with 2-3 months of carefully-targeted additional work at the very end will be a BETTER game than a larger one that is scheduled right up “to the wall,” EVEN IF you have doubled your estimates. This is because you are inherently better-informed about your game late in production than you are at the end of pre-pro. This means, that if you decide THEN where to focus your finite amount of polishing time, you will make wiser decisions than if you decide during the design phase, which is effectively what you are doing if you double your estimates.

Also, as I mentioned, the “double your estimates” approach suffers from the drawback that it lacks transparency. The padded estimates are not “wrong,” it’s just that you are taking a whole bunch of valid things that slow production down, and hiding them from the publisher. This FEELS deceptive and creates unnecessary management stress/overhead while endangering your relationship with the publisher. Ultimately, I think that what you end up promising the publisher is probably roughly the same, in terms of the scope of your features/content, just with less transparency.

Here’s an abstract example of a very high-level timeline that I would present to the publisher:

So, what, does this mean for the scope of the project? Let’s assume that this timeline represents a 24-month, cross-platform, console project with limited online functionality (in other words, no open beta).

1. We need to set-aside 30% (roughly 7.5 months) of the overall schedule for Pre-Production. This period consists of 3 key deliverables:
   1. Pre-Pro Deliverable #1: Prototype (aka: X Demo, Vertical Slice, First Playable, etc.) – The First Playable is intended to prove 3 things: a) That your game will be “fun” – So, it must include enough gameplay that you can be confident in your core game mechanic(s), b) That you can hit your visual bar – So, content must be polished to a point that you feel accurately represents your finished, shippable, project, c) That your pipelines have been proven – So, it must contain at least 1 of every major asset type, such that your team feels confident about estimating the amount of time it will take to create additional assets
   2. Pre-Pro Deliverable #2: Design Doc - Comprehensive documentation, including descriptions of functionality and reference materials necessary for all deliverables identified in the Production Schedule. (Remember, this is the design doc for the whole game, which you expect to be able to complete by Judgement Day).
   3. Pre-Pro Deliverable #3: Production Schedule - Your most accurate, honest, attempt at a schedule for the entire team, up through Judgement Day. Must include all tasks necessary to complete all features and content described in the design doc. Must be mindful of major dependencies. (Note: my philosophy on tasks is that they should be the largest chunks of time that meet the following criteria: a) Properly documented, b) Can be unambiguously tested, c) Can be assigned to a single individual, d) Fit within a single milestone)
2. We also need to set-aside 20% (roughly 5 months) of the overall schedule for Post-Production (aka: QA, Verification, etc.). Post-Production includes 3 key sub-milestones:
   • Alpha = (This is actually the final milestone of Production, and the beginning of Post-Production). Alpha is defined as Content and Feature Complete. All remaining work should be bug-fixing & optimizations.
   • Beta = The first build that the dev team believes to be shippable (aka: ZBR, RC1, etc.)
   • Final = All bugs have been fixed or waived

• After you’ve set-aside Pre-Production and Post-Production as described above, you’re left with 50% of your project (roughly 12 months) for Production:

1. Now, set-aside 25% of the Production time (3 months) for post-Judgment Day (this time is for either the addition of “wish-list” content/features that were either discovered during development or for the polishing of content/features from the “original” design doc that was submitted at the end of Pre-Production. It is very important that the publisher understand that this time is for NEW work or RE-work, but it is NOT “buffer time” for the team to take longer to do the things that they thought they could do more quickly).
2. Of the remaining 9 months of Production time, roughly 33% (3 months) will be consumed with on-going bug-fixing, Holidays, PTO, preparing milestone builds, meetings, publisher visits, trade shows, etc.
3. This leaves you with 6 months of actual production time for your 24-month project.

Thus, the schedule and design doc that you submit to the publisher at the end of pre-production should only include 6 months worth of tasks. (Guess what, that happens to be 50% of your 12-month Production schedule. In effect, you are “doubling” your estimates). However, now the publisher can see all of the valid thinking that has gone into such a conservative commitment. It’s not that I think it’s a mistake to double your estimates. I just think that it’s important to communicate a strong case to the publisher for why you are doing so. Also, by setting aside the Judgment Day period, you leave yourself the time for NEW work and RE-work that you didn’t anticipate during Pre-Pro (so long as you make damn-sure that you hit Judgment day.)