Welcome back! Or, welcome for the first time. If you're just jumping in, consider reading the previous posts in this series before tackling this last one. It's not a prerequisite, but it'll put what I'm about to discuss in full context.

In Part 1, I covered running the day-to-day operations of your team using two week sprints. In Part 2, I discussed issue tracking databases and processes to put in place for funneling bugs & tasks into them. For this last installment, I'm going to cover how to approach long term planning. Also, much like the previous posts, this is influenced by Jeff Morris and his leadership on Star Wars: First Assault. If you like what I have to say, please thank him for being amazing.

Waxing Philosophical

Many people have compared Jeff Morris to The Dude; both in style and attitude. — Many people have compared Jeff Morris to The Dude; both in style and attitude.

I think that we, as an industry, overcomplicate long term planning. Why is that? Well, I think it's cause we, as humans, get stressed out by uncertainty. Especially business execs and investors that are dumping money into our games. However, flying in the face of this instinct to predict the future is my belief that there's a fair amount of chaos we need to embrace in order to be truly successful (and happy). There are limits to what we can predict or control and those limits start increasing dramatically on a very short timeline. If you're going to buy what I'm selling in this post, you're going to have to become a reed in the wind to some degree. My philosophy around game development (and kinda life in general) is all about focusing on what you can do today to make your desired tomorrow a reality, while at the same time managing your expectations and minimizing your mindshare thinking about the future.

WAT. I know. I'm talking about long term planning and telling you not to worry about the future. Really, it's all about planning for the future as much as you need to be, but no more than that. This post is very much in contrast to the previous posts, which are all about having a pretty stringent discipline when it comes to designing and implementing your production processes. Though, I suppose this one is all about having stringent discipline to just take it easy, man. On a long enough timeline, I think we all benefit from being more dude-like; both financially and emotionally. Hopefully you'll agree by The End.

LONG TERM PLANNING

First things first; let's develop some high level guidelines to help with long term planning. We'll do this by having a well defined project timeline w/ major milestones called out. Typically, at the very least, these milestones would signal the transitions between traditional phases of game development. These phases warrant a lot more discussion, but I'll do my best to sum up their focus.

BLUE SKY

This is when you don't know anything...or maybe you've just got the very basic seed of an idea. Brainstorms are raging, concepts are churning, prototypes are hacking and hopefully your team is very, very small. There's no such thing as a bad idea and it's time to explore the full spectrum of possibilities with your most influential team members. Before you exit this phase, you should have an X statement for your game and/or 3-5 pillars defined to help guide the development going forward.

PREPRODUCTION

Now that you've got a fuzzy picture painted for your game, it's time to lock down some details. This is also an extremely experimental phase of your project, but it's more focused than the Blue Sky phase. By the end of it, you should have built "one of everything" in your game and all content creation pipelines should be in place. This minimizes surprises and redo of work during the next phase of your project when a majority of the content will be created. Also, it'll help you estimate how long the rest of the project is going to take cause you have at least some experience developing every feature you're shipping.

Traditionally, Preproduction is longer than Blue Sky, but shorter than Production. I'm gonna throw it out there and say that Preproduction should be your longest phase of development. If you're doing it right, a day spent in this phase is worth a week (or more) in the later phases. Knowing exactly what you want your game to be when you exit this phase is crucial to avoiding crunch and wasted work.

PRODUCTION

This phase should be as assembly line-ish as you can make it. It's all about cranking out content as quickly as possible. You definitely shouldn't be exploring new features in this phase, but the reality is you're going to have a small subset that sneak in there so don't be too militant about shutting that shit down immediately. Give your team just a little bit of wiggle room to adjust in areas that they didn't totally nail in Preproduction. By the end of this phase, your game should be "complete" in the sense that it's playable from start to finish and every single asset that is going to ship in the game exists in a mostly polished state. In addition, things like memory footprints and frame tick allocations need to be clearly defined for your features so you can get this thing out the door.

ALPHA

Your primary focus for Alpha should be making your build stable AF. If you go 1 day without a new build to playtest, that's like 3 days too many. Something to be careful about now that you're in shipping mode is fixing things that don't really need fixing. Jeff Morris used to say, "Don't poke the jello!" This is sage advice with regard to the unintended ripple effects you incur by changing a single line of code, even if that line of code fixes a bug. Make sure it's worth the unpredictable jello shake reverberating through your software.

BETA

This is it, folks. The final countdown. Do whatever it takes to get the game over the line. Fix all the bugs that absolutely need fixing and start making some tough decisions about shipping with some Medium Severity bugs (see Part 2). Luckily (with restraint) you can rely on patches in the future to hit some of the things that you just didn't have time for. Also, make sure you put on your "consumer" hat when you're making decisions about where to focus time and energy. Imagine what's going to bother them the most, cause maybe that's not what bothers you the most.

SUB-Milestones

In addition to the more traditional milestones, maybe you've got some other important dates in mind, like beginning a Kickstarter campaign or locking a build for E3. Scatter those sub-milestones on your timeline and now you've got a super useful tool for prioritizing work over the course of your project. Carefully consider these milestones when you're putting the remaining processes below into practice.

Handling Dependencies

Now that you've got some good high level guidelines for planning your project, it's time to utilize them to plan your first sprint and think about dependencies. Ensuring that work is executed in an order that both satisfies your project's most important/urgent needs and keeps no one waiting on a dependent task is not easy. Also, I'd bet all of your hard earned money that the first thing 99% of producers will suggest is using MS Project to solve that problem. MS Project is the worst tool for planning the development of a video game. Its fundamental design totally disregards the iterative, experimental & organic nature of video game development. Delete the application from your computer and never look back. There's a reason why you hate using it; it doesn't work.

With just a little bit of process sprinkled on top, the only tool you'll ever need to run your project is a simple issue tracking database. However, the degree to which that statement is true depends on how seriously you take Part 2 of this series. More specifically, you need to ensure that all bugs and known tasks are in the database, categorized, prioritized and assigned with time estimates. If you can get that far, you're most of the way there. The rest of the magic is in analyzing that data and making informed decisions based on the priorities you've set as a team.

As Much As You Need, But No More

So, you're an issue tracking database master and you have leveraged your OCD to get everything in order there. Now, plan your first sprint (refer to Part 1 for more info) and in the process, if you come across some tasks that don't have their dependencies covered:

Throw those tasks back in the backlog.
Assign the relevant dependent work you identified with P0 priority (see Part 2) for this next sprint you're planning (or as soon as possible).
Find some work to replace what had to go back in the backlog.

That's one, 2 week track w/ dependencies covered that you've managed to throw down.

Now, before you quit planning and start working, you need to do just a little more thinking about what you want coming up two sprints ahead. Do those tasks require work done in this next sprint you already laid out? If so, see if you can adjust it (e.g. swap tasks, reallocate resources, add new resources, etc.). If you can't get that dependent work in, mark it with P0 priority and try to schedule it ASAP. Now you've done everything in your power to line up another 2 week track. Maybe the work isn't exactly what you wanted to get done, but it's moving in that direction and that's the best you can hope for. This is an example of where managing your expectations is important. Accept your current situation and then adjust your long term planning (getting to that soon...).

Once you get comfortable with this process and you've been doing it for a while, I'd argue you can stop with 4 weeks of work planned out with dependencies. But, maybe you're just starting out and you're like, "Ryan, there's no way I feel comfortable only planning out 4 weeks worth of work. I NEED MORE CERTAINTY!" Ok. Plan one more sprint ahead and adjust the schedule to front load any dependent work you've identified, if you can. Now you've got 3 sets of tracks lined up w/ dependencies covered that is streamlined to deliver your project's most urgent/important needs as quickly as humanly possible. Feel good about that, despite some work not getting scheduled. You've done the best you can.

Now there's enough room between your team and chaos. Stop here and revisit the process every 2 weeks during Planning Day of your sprint (see Part 1) to maintain the 4-6 weeks of buffer. Embrace the remaining chaos and let's talk about how you can contain it, because you'll never be able to control it. That's what MS Project tries to sell you. Any effort you spend trying to plan dependencies more than 6 weeks out is like lining up grains of sand in a windstorm. You're in very low predictability/control territory.

Containing Chaos

The first step in containing chaos is knowing exactly what flavor of chaos remains by categorizing all the known tasks and bugs into resource buckets. Then, determine how much each of these buckets weigh in work hours using the time estimates assigned to the relevant issues. You can do this because you're an issue database master after having read Part 2 of this series.

Maybe you want to get super detailed and instead of resource buckets, you want to list actual names of people cause issues aren't interchangeable between team members on your project. That's totally valid. Either way, now you have to add up all the resource hours actually remaining in your project for each category. For example, if you have 5 environment artists working 40 hours a week and you have 100 weeks left, that's 5 x 40 x 100 = 20,000 Environment Art Work hours remaining in your project. Now, how do your resources measure up against the weight of work remaining in your buckets above?

Shit! The Environment Art chaos weighs too much. No worries. I present to you the most stereotypical set of production actions you could ever take to help fix this problem.

Add time.
Add resources.
Cut scope.

There is no right or wrong choice here. It's whatever your team can afford most. Maybe it's some combination of all 3 of the options above. Actually, more than likely it is. If you can find some way to bring the remaining work in balance with remaining resource hours, you're good to go. This is all you have to do in addition to continuously reaching into that chaos to lay out 4-6 weeks of dependency free tasks every sprint.

The Devil Is In The Discipline

I bet some of you are skeptical this will work. Actually, I bet most of you think I'm full of shit. On the surface, seems kinda crazy to let that much of your project be "planned" just by balancing the weight of some resource buckets, but is it any crazier than trying to plan for a future you could never predict in the first place? I think on the surface this might seem over simplified, but it's the perfect amount of complexity for a high level process. That doesn't mean it's easy, though. It's going to be very difficult to execute the process I laid out in Parts 1 & 2 of this series. That's where discipline will make or break the entire thing for you.

The End

I'm slow clapping for you right now if you've read all 3 of these posts. Especially this last one. Thanks for coming along for the ride. I can only hope the amount of useful tools and processes I've discussed outweigh the amount of dumb shit I've said <3

Take 'er easy!

EDIT FROM THE FUTURE:

Designing a Production Process: An Addendum

Designing A Production Process: Part 3