There are no rewards for starting games, only for finishing them. More than anyone else on a game development team, this is the producer's job: Getting the game done.
Getting the game done means making sure that everything -- art, features, design decisions, UI elements, platform requirements, integrations, updates -- gets decided on, planned, built, tested, bug-fixed, past cert, signed off on, translated, shipped, maintained, and updated. Concurrently, all of the preceding must happen on schedule, under budget, and without hiring more people or lowering quality control.
This, of course, is impossible.
This is game development. Your team is full of extremely smart, ambitious, and creative people, who want to build something amazing. They already have way more features, characters, levels, etc., in mind than your team has time to build -- and that's before development even starts. Since you can't do everything, your job is really to make sure the most important stuff gets done, and that time isn't spent on anything that's not needed. That's prioritization.
The basics of prioritization are simple:
- Make a plan
- Follow the plan
- Measure progress
- Communicate progress
- Adjust the plan as needed
- Return to Step 2 and repeat until done
But if it were that easy, we'd never hear about games that pushed their release date back by months (or years) or teams that spent months working on features that were cut from the final game.
5 Reasons Prioritization is Hard
1. The project is always changing.
Even if you had a perfect plan, it wouldn't last very long: Product owners are always coming up with cool new ideas or improvements, and the game's design is always changing based on internal reviews, play-tests, industry innovations, and customer feedback. And even if the plan didn't change, priorities change based on when in the project you are. Right before an important trade show, having a great demo will be more important than whether matchmaking is fully functional.
2. Lack of scope discipline.
Dreaming up neat stuff is almost always more fun than actually building it. Your project scope has to match your team's capabilities or you won't be able to finish, and it almost never does. In my entire career, I've been on one project that was appropriately scoped from the beginning, and it was an expansion pack to a sequel the team had just finished, so we were very familiar with what our capabilities were.
3. Priorities are different for each product owner.
On the Lord of the Rings games I worked on, the lead designer's top priority was to make the highest quality game possible. The studio head's top priority was to make a financially successful, well-reviewed game. The VP's top priority was to get a game that fit well into the yearly product slate and that supported film ticket sales, while the license holders' top priority was to make sure our game matched their branding requirements.
You need to make sure that all of these priorities align with the priority list that your team is working off of (and that your whole team is working off of the same list). Strong disagreements or even fights aren't uncommon between discipline leads. You have to make sure that those disagreements are resolved and that everyone agrees on who's responsible for making the final decision on each area of the project. Only then can you make sure important decisions get made correctly, by the right people, and on time.
4. You're working within a lot of constraints.
Some of them are not negotiable, e.g., the game has to ship before the movie opens, or you only have 3 gameplay engineers and can't hire more. It doesn't matter what your prioritization list is, if you hit a non-negotiable constraint, it will override everything else. If you have to ship on PS4, a PS4 cert failure will automatically go to the top of the priority list.
5. Scheduling polish time feels bad
Nobody wants to plan ahead for polish and bug-fixing time, but just finishing all of the Pri 1 items will not make a great game. Polish and iteration are necessary for quality. It's extremely hard for product owners to accept a schedule that has any significant polish time built in if they don't have scope discipline. Think of how many features we could fit into that useless polish time padding!
Product owners have to be ambitious and optimistic to be effective, but as a producer, you need to make sure your project plan is realistic. Don't let product owners force you to schedule as though nothing will go wrong and everything will be perfect on the first try. That never happens, and we all know it.
Easy Solutions -- That Don't Work
Everyone would like there to be a simple solution to this problem. There isn't one, but that doesn't stop teams from looking for one. (For a great book about this problem, I highly recommend The Mythical Man-Month by Fred Brooks.)
Here are a few silver bullets I'm sure you've heard people propose (or proposed yourself!) and why they don't actually work:
The first time I took a Scrum class, I was as excited as Jared on HBO's "Silicon Valley." I had found the secret to fix all of my team's problems! I was wrong, of course, but I definitely understand why so many people cling to Scrum as a savior. The problem is that Scrum is a rigid solution to a very specific problem: Teams that are so bogged down or gridlocked that they literally can't produce anything. In that sense, Scrum is the Heimlich maneuver of project management: If you can breathe (i.e. if you are actually getting work done), it's just as likely to make things worse as better.
Scrum is still worth learning about. There are good, useful tools in Scrum that can help you create a good project plan and execute it effectively. But be aware that Scrum can also mask and encourage bad behaviors, including:
Product owners who refuse to exercise scope discipline
Team members who aren't honest (or realistic) about how much they can accomplish
Spending too much time on minor features that are cool but that won't really help your game succeed.
Even if Scrum is a good fit for your team, realize that every change has a cost, and big changes have big costs. That cost might not be worth paying, depending on your project and depending on where in the project you are.
2. Eisenhower Matrix
This project management tool does help you understand your problem space better:
Importance and urgency are different, and they combine to determine a specific item's overall priority. The Eisenhower matrix is most useful for deciding which items are important enough to spend a lot of time deliberating (the top half).
Unfortunately, I've never worked on a project where this matrix would make a dent in the overall problem of "too much to do": Even if you separate all your work into quadrants, you'll still have way too much to do in quadrants 1 and 2, and you weren't ever going to get to the stuff in quadrant 4 anyway. And even if an E3 demo is less important to the overall project than getting your matchmaking to work, you do still have to make an E3 demo.
At some point, every producer will be expected to find a way to get everything done. "Find a way," "think outside the box," and "don't let constraints rule your schedule" often really just mean: "Get your team to work longer hours because we refuse to cut anything."
This is a recipe for disaster.
Crunching can let you get more work done, but not much, and not for long. The recent Game Outcomes Project is full of incredibly useful data about high-performing teams, and one of its clear conclusions is that crunch ultimately just makes things worse. Most teams might get 10% or 20% more done; really focused teams working in short bursts (2 weeks) might get 30% or 40% more work done during those periods. But burnout is high, and honestly if you have a scope discipline problem, the overrun isn't going to be in the 10-30% range. It'll be somewhere between 200% and 1000%.
Crunching means means you and your product owners have failed in your planning, and your team knows that. Like the other tools discussed here, crunch may have a role in very specific situations. But it is not a solution to the problem of too much to do.
Solutions That Work (but are Hard)
Most of the actual solutions to the "Everything is Pri 1" problems are really about scope discipline. Product owners are rewarded for their ambition, and there's a strong culture in games (and software in general) of refusing to be disciplined in scope. Game studios could design a game that they were certain they could build, and assume that they'll find cool things to expand on and add later. But I've literally never seen this happen.
The headline of this article is a bit tongue-in-cheek: If your product owners really believe that everything is Pri 1, then you have a scope discipline problem. However, if they initially believe everything is Pri 1, but you're able to work with them to focus the scope to realistic levels and create a prioritized project plan, that's a healthy tension that will benefit your team. They bring the ambition, you bring the realism, you get a good game done.
Here are some ways of doing this:
1. Practice what you preach
Making a realistic plan starts with you. Do you have a good understanding of what your team is capable of? And do you have enough credibility that your product owners will believe you?
Don't commit to more work than your team can do. This is difficult, since you almost never have a really good idea of what your team is capable of unless they've been together for a while and have worked on similar projects in the past. You'll almost certainly overestimate what you can do, but do your best to make sure that that overestimation isn't too high, and that you have a plan to cut scope if (when) needed.
Be consistent. Work with your product owners to ensure that priorities are consistent across the entire team so that the most important stuff gets done. Then track and report on that progress, which will in turn contribute to both your understanding of the team's capabilities and your own credibility with the product owners.
2. Define 3 success pillars
It's hard to stay focused on critical work if you can't identify what's critical to begin with. You never really know which feature or polish item will be one that your players will fall in love with, or which bug will be the one that frustrates them into quitting. But thinking in terms of "will this make us succeed or fail" helps keep your team in the right frame of mind. Asking this question may lead to features that seem critical being cut, and work that wasn't getting enough attention prioritized higher.
Start by defining three pillars to plan your game around. Pillars are major features, selling points, or unique aspects of the game that will lead to success. (Three is a good number because it will require some discussion to get your team to agree on three, and any more than that will be hard to remember.)
Good pillars are actionable, specific, and positive. They should cover large areas of the project and make it easy for developers to know whether their work is aligning to the goals of the project. Bad pillars are those that won't help team members prioritize their own work or understand its context in the overall project. "Monster to the monsters" and "accessible to all skill levels" are good pillars; "90% Metacritic" and "unique art style" are bad ones.
Pillars are often very similar to a game's unique selling points, or marketing points. Which makes sense, because in a way pillars are how your team markets your game to yourselves. It's a way for your team to have context for what you're working on and to understand what the final, finished product will look like and how each person's work fits into that finished project.
Finally, if a feature or work item doesn't align with your pillars, ditch it or change the pillars.
3. Make a ranked backlog
Work with your product owners to list out everything everyone wants to do. Hunt down all the Post-Its, wish-list items, and task lists that everyone on your team has squirreled away, and get it all onto the same list. Then rank the entire list; don't just assign priority numbers. Get sign off from the product owners on the final list. Then have your team start at the top and then work their way down. (This is an example of a core Scrum principle being useful, incidentally.)
Keep this ranked backlog maintained and keep everything on it. If a product owner says "It would be cool if the unicorns exploded," add it to the backlog and make sure it gets ranked against the other items already there. Use this ranked backlog to resolve prioritization mismatches between different team members or different product owners. Your backlog thus becomes a communication tool as well as a planning one. It gives teams a clear view into what's being prioritized and it's easy for them to understand.
4. Use the right process for your team
Process is how you plan your project, execute on that plan, control the work being done, and use what you've learned to update your plan. Selecting the right process for your team is part of getting familiar with what your team is capable of, and how you can most effectively help them do their best work.
I could spend the next year talking about nothing but agile vs. waterfall, but the key thing to remember is that whichever you pick, it needs to be the right one for your team. More experienced, smaller teams or projects with more uncertainty benefit more from agile processes because they let you continually change your plan in response to changing circumstances. Agile also works well with live games, such as Eve Online, because it lets teams iterate in response to player behavior.
Waterfall gives more predictability but makes it harder to respond to unforeseen problems. Larger, more distributed teams or projects with clearer paths to success (e.g. sequels, DLC updates) work well with waterfall schedules. A lot of people hate waterfall because it's less flexible, but for the right team it can work well: Rocksteady uses a very strict waterfall scheduling process for their Batman games, for example.
Most teams work with a mix of the two; most teams I've been on have used waterfall for art and level design, and agile for engineering and design.
5. Familiarize your team with the process
The best process in the world won't work if your team doesn't use it. Another of the conclusions of the Game Outcomes Project was a positive correlation between team buy-in to the process and a game's success. Does everyone on your team know how to tell the team when something is done, or what to do if they get blocked? How do they track their task list and know what to work on next? Do they know how to find out what someone else is working on?
Give your team ownership over the process. They know what they can do, so involve them in milestone planning and decision making. At PlayFab we have quarterly and yearly planning meetings where the whole team works together to plan the main features to work on next. We have a lot of Pri 1s, but we're able to make a plan that everyone understands, everyone owns, where nothing important is overlooked, and that was decided on with the maximum amount of available information, and thus is likely to succeed.
6. Communicate the plan
All models are wrong, but some are useful. Visualizing your schedule in different ways helps you make sure you're taking all costs into account. You might find that different ones are more informative to different teams, or that some of them help you plan your project and others help you track work or communicate the plan to your team. Here are a few examples:
- Easy for team members to understand what they're responsible for
- Forces product owners to realize they've asked for too much at once
- Easy to update, and to customize (I use Excel)
- Lets you identify tasks with a deadline but no assigned team member
- Almost impossible to schedule polish and bug-fixing time, because product owners will instantly see it on the chart and wonder why their favorite feature isn't there instead.
- No task is allowed to start before all its dependencies are finished, and no person can have two tasks assigned to them at the same time.
- Entering everything into a Gantt chart forces everyone to realize just how long it would take to get everything done. It's a good "reality shock" too.
- They're very difficult to read and nearly impossible to keep updated.
- There are tons of programs out there for making Gantt charts, but many people get stuck using Microsoft Project, which is expensive, hard to use, and doesn't run on a Mac.
Kanban (or Scrum) board
- Can be used either offline or online, and many good tools exist for creating them
- Useful for smaller teams or parts of a project, such as an art team
- Once your team is bigger than 10 people, it starts to break down quickly, and gets very hard to keep updated
- Less useful if your work has many external dependencies or milestones that can't be tracked on the board
- Forces everyone to focus on non-negotiable deadlines (that E3 demo again) that are more than 2 weeks ahead.
- Not intended to be used on its own. Pair it with other tools to let the team see how their work fits into this bigger picture.
7. Be prepared for problems
Plans that only work if nothing goes wrong are bad plans. Your art team will get the flu; your only network engineer will quit; core requirements will change; and a critical feature of your game won't be fun. This is where having 3 pillars is a good idea; if one of them collapses, you still have two others supporting the game.
Fantasy scheduling is particularly a risk if you're surrounded by happy, creative, optimists (so, basically the rest of your team.) The producer's role is to gently (at least at first) remind them of reality. Get used to communicating bad news and pointing out risks in advance. This will not make people hate you. Good product owners appreciate that someone else is keeping track of the bad stuff so they can keep main focus on all the cool features they want to build. Point out fantasy scheduling when it happens, and make sure your plan has some slack to deal with potential problems.
8. Conduct a risk analysis
Get your team together and list potential risks to your project; for each one, give it a score for likelihood and impact. For example, your publisher cancelling the project is usually low-likelihood, high impact, but it could be high likelihood if you know the publisher has been cancelling a lot of projects recently or is in financial difficulties. Team turnover is usually medium likelihood, low impact, but if your only network engineer hates living in your city, it might be the highest in both categories.
Rank the risks based on those two scores. The top ones (aka the scariest risks) are the ones you should worry about the most. Make sure you have a plan for minimizing the likelihood and impact for them; a plan B, basically. Going through this process (and updating it at each milestone) will also give everyone a place to voice their fears for the project and to have some control over the things they're afraid of.
9. Answer the right questions
Unless you're working on an extremely strictly scheduled waterfall project, new stuff is going to get added to the prioritization list, often at the top. When that happens, the question that's asked is usually, "Is there any way we can do [X new item]?" This is a bad question, because the answer is: We have a super smart, creative team. Of course there's a way we can do X new item.
DO NOT give that answer. It doesn't give your product owners the information they need to make good decisions, and if they have a scope discipline problem, it lets them get away with it. Also be wary of the question, "Can I add this item to the list and still get everything else done that I want?" The answer is no, because of the laws of physics. But that's not a useful answer and it won't help your project get done. These are both questions with no good answers. Don't answer them.
Instead, answer this question: "We have a new priority: X. Can you adjust the plan to include X and tell us how that's likely to affect the other high-priority items on the list?" That's the question product owners should be asking, so that's the one you should answer. Verify with them where on the list X should go. Is it more important than our previous top priority items? Is it more urgent than other items, and therefore needs to get done earlier even though it's less important? If so, definitely let them know how that's likely to affect or delay the higher-priority items. Does it fit your established pillars, or conflict with them? If it conflicts, do we need to change the pillars?
Adding new top priorities needs to be done carefully, and it's never free. Don't let your team fall into the trap of thinking that it is. That's how scope discipline deteriorates, and that's how long, terrible death marches happen. Successful teams learn how to control that risk.
Embrace Your Role as the Producer
Finally, don't let the coolness of the art or gameplay distract you from your role on the team. As I said at the beginning, the producer's job is to get the game done. Your team can't build every cool thing they think up, so your job is to make sure you get the most important ones done, and that your team agrees which ones are the most important -- and what "done" is.
Lack of scope discipline is your enemy, but you have a number of tools to fight it:
- A workable plan. Start with a ranked backlog.
- Various ways to visualize and communicate your schedule, to catch problems with it early and keep people working on the right things.
- Clearly defined pillars to help you know whether you're working toward success and to help your team know how their work contributes to that success.
- Anticipating problems and making sure your team is prepared for them.
PlayFab senior producer Ruth Tomandl has been a designer and producer for 14 years. This article is adapted from a talk of the same name she gave at GDC 2015.