I used to be a producer. I also used to be a game designer. Now I’m a UX designer with the experiences of a game designer and a producer.

I’m pretty sure there are producers at companies that I’ve worked that are supremely pissed at me because I ask for processes, reviews and accountability. I would however never ask for anything that I’m not prepared to offer myself, meaning that I often ask for others to hold me accountable to what I do and make sure that my work is reviewed and follows process. So what are those processes and reviews?

Well, the first thing to know in this context is that every team is different and every publisher will ask for different information. What you need to do as a producer (and as a team member) is to ask yourself “what information do I need?”. Before you know what the requirements on you as a producer are, it’s very hard to ask the team for that information. Best case, you get what you need. Worst case, you don’t get what you need and the team suffers from a bunch of useless overhead administration.

We often talk about how designers write too much documentation, and that we should only write the documentation that the team needs. The same philosophy is valid for project management. Never ask your team for more than you need from them. But never ask for less either. That will only lead to you running around trying to fill gaps.

The second thing to know is that everything is much easier if the team feels that they have agency over the process they’re being asked to use. What does that mean? It means that you need to sit down with your team and discuss the process with them. Tell them what you need, tell them the requirements that your publisher or leadership has on you, and try to make the process as streamlined for them as you possibly can.

The third thing to know is that no process is perfect from day one and that implementing a process takes time. One of the most common issues on game teams I’ve been on is the tendency to discard a process that “doesn’t work” way too soon. Think about on boarding. How long does it take for a new employee to be fully integrated into the team? About six months, correct?

There is nothing to indicate that a process can be implemented, adopted, refined and working without a hitch in a shorter time period than that. And yet we often rush process. We want it to be flawless from day one, and that’s just naive. Process takes time. It also takes being consistent and sticking with it, despite not wanting to or thinking that taking that one short cut just once won’t hurt, and then you do it again, and again, and again. And of course, the repercussions of taking those short cuts are blamed on a faulty process, when in fact the process wasn’t followed to start with.

The fourth thing to know is PROJECT MANAGEMENT AND PRODUCTION IS HARD WORK IF YOU DO IT RIGHT. In other words, project management and production is NOT about standing on stages and looking glitzy. It’s knowing, sharing, facilitating and understanding process. It’s knowing your team. It’s getting rid of obstacles and protecting your team from feature creep. It’s doing all of the admin that the team hasn’t got time or energy to do. It’s not making power points, although those may occur. It’s making sure the team understands the deliverables and that they have a good overview of what the processes used are. I have met WAY too many project managers and producers that are just there for the glory and won’t do the work. I’ve also met producers that are dedicated and efficient and know how to get shit done. Guess which ones I like?

I am, and I’m sure other people will agree with me on this, an organizational freak. I like process. I’m also very good at process. The reason I’m good at process is because I follow it.

So lets break it down a bit. What do I usually insist on?

• Clear time frame – how long does the team have to deliver the thing they need to deliver?
• Clear deliverables – what is the team (and individuals on the team) expected to deliver at the end of that time frame?
• Estimates – Every deliverable needs a clear time estimate. Personally I prefer complexity points (don’t worry, I’ll tell you why in a bit)
• Priority – All tasks on a sprint need a priority.
• Accountability – The team members need to be a part of planning from the start, including what to deliver and how long it will take.
• Reviews – Once a deliverable is finished, it also has to be verified. That’s what reviews are for.
• Backlog cleanup – Seriously. Do it.

Timeframe
The time frame helps the team to decide what can be delivered. My preference is a short time frame in which to deliver a thing, mostly because it requires the team to break down complex items into smaller pieces of work which makes the work in itself easier to get an overview of, and because with a short time frame it’s easier to change direction without derailing the team. If the team has two weeks to work on a thing, that’s long enough to get somewhere, and short enough that a change in direction won’t be put off too long.

The exact time frame is something to agree with the team and the project management at large about. I’ll get back to this often. You have to make sure the team has say in how the process works, because a team with agency is a team that will take responsibility, not only for the work they do, but also for how that work is done.

Deliverables
Oh my god. This is the hardest part, isn’t it? Getting a clear idea of what to deliver at the end of the time frame. Why is it important, though? Because if you don’t know what’s coming out at the end of the time frame, how the heck is the team member supposed to know? I prefer a clear list of statements that can be answered with a yes/ no, because that makes it easy to quantify the deliverable.

One of the discussions I’ve had quite a few times with project management and as a producer is the issue of quality. A yes/ no statement can’t ever be quantified from a quality perspective, and some creative directors I’ve spoken to have been very worried about the quality aspect of a deliverable.

My advice is this: let it go.

Usually, being worried about the quality of a deliverable is because the creative lead or director feel the need to control and micro manage. In short, it’s a lack of trust in the team on the leadership’s part.

In my experience, there are very few developers that will willingly hand over something of low quality for review. This is also why all deliverables should be reviewed, to make sure they live up to the demands of the game. HOWEVER, micro management is the death of a good team. “Move that thing one pixel to the right” comments should be forbidden. We can talk about the issues in wider terms, such as “I think that the information is scattered across the screen too much. Could we move it closer to the action.” Or “Could we make the navigation more consistent?”. Not “I want you to put that information there and I want you to navigate the screen exactly like this”.

Let it go. Your designers, programmers, tech designers and artists are doing the best job they can. It’s your job as a lead or project manager to let them do their job.

Estimates
So here’s a sore point. If you use Scrum, it’s my firm belief that putting non-abstract numbers on a deliverable is counterproductive. I know, I know. Usually we want to put days, weeks or even hours on a task. Our brains are however stupid. If I say I’ll take a day to do something, I’ll take a day to do it because I feel that I have that time, even if the thing really only takes a few hours. In essence, I’m blocking myself from moving on, because I had a day to do this! So it should take a day! In addition, I may stay really late and crunch because a complex thing that was underestimated should only take a day, but it turns out that it needed more time than that and so I’ll push myself to deliver.

If I use complexity points, I’m not assigning a concrete value to a task. Instead I am assigning complexity to a task, meaning that I’ll measure the difficulty of the task in relation to my skill and to other tasks that I’ve already done. This way I’m not biasing myself to think in days or weeks, which won’t lock me into thinking that I only have one day to do something, alternately can take all day to do it despite the task not needing it.

If you’re at all familiar with Scrum you’ll know that complexity points are measured on a burn down chart, so instead of saying “we can take on 10 man days of work in a two week sprint” we’ll say “we can take on x amount of points in a two week sprint”. The point number – if you’re doing scrum correctly – will go up as the team gets better at estimating and increases their knowledge of the project, which is also very motivating. Seeing a team manage 5 points, then 9 points, then 15 points in a sprint is usually very enjoyable. Having the complexity points measured against sprints will also give the publishers an idea of how long something will take but again, without biasing towards days. As you can imagine, the man days of work will never increase if you use days to measure. Complexity points will.

Priority
All tasks in a sprint need a priority. A developer should never have to work on more than one thing at a time. Multitasking doesn’t exist. As a dev you work best if your attention is on one thing at a time. For you to know WHICH thing to focus on, you need a priority.

It is leadership’s responsibility to give you that priority. If they don’t they have no grounds for complaint. Priorities change from sprint to sprint.

Accountability
This is the most important part of the whole thing. Accountability. This means on the teams part that they do not take on more work than they can handle. And you do not ask them to take on more work than they can handle. I don’t know about you, but I’ve been in situations multiple times when I’ve been asked to do work in addition to the work I already have on my plate with the same deadline as before, just much less time to do it.

The most egregious situation was when I was volunteered to do a task that would take me at least two weeks to complete in three days. I had no say in the matter, I was just expected to do it. That’s not a good situation.

Accountability goes both ways. On the one hand you have your team member who promises to do the work in a specific time frame. On the other, you have production and leadership who promises that this workload won’t change.

This is why we have clear deliverables and a clear time frame. I can almost promise you that this is the hardest thing in game dev. Hold creative leads accountable and push back on producers that want to squeeze just one more thing into the sprint, despite it being full.

In other words, accountability goes both ways and for the team to trust you, you must make sure that they can trust that the work doesn’t change.

Reviews
This is part of the accountability and deliverables. At the end of the time period, go through all the deliverables and see if they have been fulfilled. If they have, awesome, put them on the done pile. If not, they get another turn in the sprint with clear feedback so that – yes, you guessed it – the deliverables are clear to the developer.

This is an opportunity for the team to shine and show off. It’s also an opportunity to clarify direction, but most of all, it’s an opportunity to put a big ole done check mark on work.

This means that the team knows that something is done. It means that leadership knows that something is done. It means that if any of the work that has been checked off needs to be redone, it is classified as new work and not the very nefarious idea of “fixes”.

Again, it ties into accountability. The team is held accountable for what they are producing, the creative leads are held accountable for what they’ve asked for.

Backlog Cleanup
Do this after every sprint and every review. Clean shit up. Reprioritize based on requests from project leads. Re-estimate if it turns out new knowledge has come along. Weed out old user stories or tasks, put new ones in. It’s possible that you don’t have to do it after every sprint, but I would be surprised if you didn’t have to do it after every milestone.

As you can probably see, I am a stickler for process. There’s a reason for it. When the process works, the team works, and the project works. When the process falls apart, so does the team and the project.