Level of (Planning) Detail
You’ve probably heard of the phrase attributed to the U.S. president Dwight D. Eisenhower, “Plans are useless, but planning is everything”. While this quote was originally delivered as part of a speech talking about the U.S. Army and military exercises, the general idea is highly applicable to any domain: even if the details of a plan turn out to be incorrect when put into practice, the exercise of planning forces you to explore options, alternatives and possible contingencies, allowing you to make better decisions when face to face with the real situation.
As someone who thinks about this phrase often, I’ll be the first to admit that I’m the kind of producer that drags my feet when it is time to make planning documents. If you ask, I can definitely build a nice looking color-coded Gantt chart with clear mapped dependencies, estimates, and resources… but for how long will this plan actually be useful to the team? Game development is extremely iterative, especially in the early phases of a project when you’re still making important decisions about core gameplay systems and overall art direction. Trying to make a detailed project plan at this stage feels like being asked to draw a map of a stage that is still mostly covered by fog of war.
All that said, I wouldn't go as far as Eisenhower and say that plans are useless — at the right moment, there is still a lot of clarity and alignment that can be gained by making and referencing them. But as anyone who has played Pokemon knows, “there’s a time and place for everything”. So what is the right time and place for making detailed plan? I like to make an analogy with levels of detail.
Levels of Detail
LODs (level of detail) are a common optimization technique used in games to create worlds that are both great to look at up close but also feel big and expansive. The idea is to have multiple versions of a 3D model (normally high, medium and low quality variants) and switch between them depending on the distance between the object and the player — if a player is close to something, you can load the highest quality version to ensure the best fidelity for the player, but if the model is far away, you can load a low quality version that will still look “good enough” as the actual size of the object on the screen will be too low for the player to be able to tell the difference.
I approach making plans in a similar manner:
For the short-term I try to prepare a "high quality", detailed plan. Since the time frame is shorter and I have more information, I have higher confidence that I can actually plan tasks, estimate duration and map resources in a way that will be useful to the team and can be followed up upon. Even if the plan does end up changing due to a change in direction, the amount of work to redo will be less.
In the medium-term, I try to create a "medium quality" plan with less detail. It is important to understand how the work we’re doing right now will play into the work we’ll do right after, so I try to have a general idea of what are the big areas of work and their complexity (e.g. What are the next parts of the game we need to work on? Which team members will work on each part?). But at the same time, any present decision (like deciding to scrap a feature or level) can completely change what our medium term plan will look like, and even if it doesn’t change, waiting until we have more information to make this plan will ensure the details are more accurate.
In the long term, I only think about the most general plans. The form this takes tends to be similar to the way you would usually define milestones, such as “feature-complete” or “content-complete”. It might not make sense to have a detailed plan of the work required to reach feature-complete (or maybe even the exact list of features that “feature-complete” entails!), but knowing what state we want the game to be at by a certain date allows us to have a general intuition about whether we’re on track to meet that goal, or if we’ll have to make some hard choices soon to ensure we’ll hit that milestone (or well, delay the delivery).
Note that I explicitly avoided giving time frames for these three categories because they’ll depend heavily on the scale of the project and the team. The time frames you will be working with will not be the same on a 3 month contract versus a 2 year game, and what is considered “short-term” will be very different for a nimble indie team that can change direction on a dime versus a AAA studio where any decision requires multiple levels of approval.
A plan is ultimately a way to guide the team, and more detail can sometimes achieve that goal, but sometimes too much detail is just busy work that might not be useful a few months down the line. There’s no right answer about how much detail is the right amount, but I hope this is a useful model for you to think about!