Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 31, 2014
arrowPress Releases
October 31, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Time and Timing...
by Kimberly Unger on 04/07/10 03:07:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


One of the things I have noticed in developing games is the difficulty in accurately figuring out how long it's going to take to complete any given task. It's the kind of thing that really only comes about when working with an established team, when you've been working together on one or two projects, you get a sense for how accurate the team members estimates are, how long it can take to create specific assets, etc.

But when your team is new, or ever changing, it's a much stickier wicket. You don't have that experience to fall back on and you are required to, well, trust your people and make a good-faith guess at the timeline. This happens so often, you'd think it would be an "understood" almost an industry standard.

If you've been a producer on multiple projects, over time you learn how to counter this, you know about how long the last three projects took and can project what is going to happen with the next. It's an experiential value, one you can't get through a degree, through managing a project or two for the Game Design club. It's the kind of thing that takes time and boots on the ground, so to speak.

So when young and inexperienced, or even when you jump from producing games of one stripe to games of an entirely different sort, what do you do?

Well, "Marc's Rules of Research" number one states "If you don't know the answer, ask someone who does.".

Chances are you are going to know at least one established producer if you've come this far. Ask them. You're not going to get a "this is what you do" answer, it's going to be more anecdotal, than what you might have been expecting, but buy him/her a beer and listen up, because the answer is *in* there, an average of what had to be done for this project versus that project versus the other thing. Be appreciative and ask leading questions, they are handing out experience you haven't had time to get yet.

If you *don't* know any producer types, and aren't enough of a social barracuda to get through the mobs at GDC or Pax to do more than cross business cards, there is another basic rule of thumb you can work with. This is pulled from the old hoary chain-smoking advertising guys lectures (and may have a touch of Mr.Scott in there to boot, the guy was quite a Trekkie). Take your best, well thought-out guess and double it. You're still going to come up short, but not catastrophically so.

This project I'm working on now, it ought to be done. My inexperience is showing, but there's no way through but forward. Everything is again on track, moving towards the inevitable (and glorious) conclusion, but the bumps in the road are all almost directly attributable to my inexperience in timing, in making sure the right assets get developed in the right order and delivered to the right people at the right time.

Can I fix this? Absolutely! Every bump, every lost contractor, every hiccup has shown me ways to improve this process.

Will it go more smoothly next time? Absolutely!

Do I lie awake at night mentally flogging myself for failing to make a deadline clear or for forgetting a crucial component? Absolutely!

But it has been an enlightening process and I can already see how this experience is helping me set up the time and timing better not only for the remainder of this project, but for the next three I am already lining up.

Related Jobs

Forio — San Francisco, California, United States

Project Manager / Producer (Games)
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States

Senior Sound Designer - Infinity Ward
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States

Multiplayer Level Designer - Treyarch
Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States



ken sato
profile image
Well, for what it's worth, I've found a strong pre-production process to be helpful in at least generating a list of concerns and timing on resolving them. The weights on tasks and processes are usually subject to change over time.

For example, one of my first experiences was generating a flow diagram of tasks with assigned dev just so I could get a handle of project work flow. I had a HUGE dry erase board left in my corner cubical left by the design team. (They later came back for it but not until several months had gone by.)

I had maybe 80% of team mapped out and went home...the next day the dev brownies filled in the rest for me. Apparently someone had come by, left a note, took a look at the wall and made a notation. I made some comments about it in the morning kick off meeting, they chuckled and asked me what it was for, and I told them. After I came back from lunch, the diagram was rebalanced. (i.e. work flow had changed. Can't say it was because of the diagram but a producer had come by, made changes.)

Long story and 'stone soup' copy, I had a diagram that reflected what the team felt reflect the project work flow at least up until that point. From there I turned from task to controls, "What controls do I have on this task?" Obviously I have the requirements and dev to whom it is assigned, but is there anything else?

While process and task assessment to quality and time is continuous, and there are a number of methodologies available, that damn diagram always sticks with me.

Glenn Storm
profile image
[me buys Kimberly and Ken a beer and listens up]

Robert Anderson
profile image
Great article and I feel your pain! Producers are like ring bearers.

Some wise catch phrases I have found over the years:

Hofstadter's law, It always takes longer than you expect, even when you take into account Hofstadter's Law.

Parkinson's Law, Work expands so as to fill the time available for its completion.

These two more than anything are the hardest to find the sweet spot for!

Robert Horvat
profile image
KIRK: Mr. Scott. Have you always multiplied your repair estimates by a factor of four?

SCOTTY: Certainly, sir. How else can I keep my reputation as a miracle worker?

Mark Harris
profile image
The most common phrase I hear when I'm chatting with project managers is "herding cats". Apt, for obvious reasons, evincing somewhat organized chaos and unpredictability. Unfortunately there is no magic bullet to estimating task time, even when you're dealing with experienced PMs, producers, senior programmers/artists, whatever. More experience always helps, but is not a guarantee for more successful estimating.

There are plenty of methodologies for decreasing the risk of time estimation, several of which you mention, but there is a very good reason we still call it estimation. Keep working hard on refining your techniques and if you find something that really helps you, be sure to share!

Kimberly Unger
profile image
Ken, that's *so* cool that you had a team that would input (even on the "sly") :D

Glenn, I'm pretty sure I can regale you with things "not" to do :D But the "must do" are still a bit on the light side, at least until I get a chance to postmortem my process :D

Robert A., I think both Hofstadter and Parkinson are both sitting in my ready-room with a hammer :D

Robert H., YAY, someone got the reference :D

Mark, I'll be posting new methodologies as I run across them. I'm planning on writing up a postmortem when this whole thing is finished, so I and my team will have something to work from for the next one (and there *will* be a next one :D)

Raoul, I think you're dead-on, I don't think very many people in general have tried to put together something on the scale I am working on with such a short dev-cycle and with such a small team. "Quick and dirty" has become the group mantra because we are trying to develop a process that will allow us to dev products like this fast enough to put out two or three a year. I haven't run across "burn-down" charts yet, but I will take a look!

ken sato
profile image
Well the interesting thing about the diagram wasn't the was that everyone understood it enough to make corrections. In a later project at a different company, everyone just accepted the burn down chart and nodded through performance and planning meetings. What good is a chart, except for management, when the staff can't see the trends or extrapolate what the chart reflects. Granted, a producer or manager can go and 'explain' it, but it puts an extra step which creates an 'en passant' mode to problem solving.

That damn chart (damned because I haven't been able to recreate it in standardized development) not only gave me an idea where work was at but also where it was going, and once the team changes were made an idea of where they would be at the start of the next phase from their perception and planning. Or more to the point I had not just my perspective an understanding of where the project would be but I had the team members perspective as well. This wasn't just the addition of data in the sense of metrics, but had added perspective of weight and continuity to task.

Finally, while I agree it is sly as my intent wasn't to get the team to do my work for me, it did point out a glaring problem that is the same with having an exclusive tool set, optimized for a single project and too arcane to be easily changed--that everyone, not just the managers and producers, need to be able to extract data from project management charts. (Not for reports and assessments.) A burn down chart does little good if it has to be explained to an artist or designer and paraphrased into a schedule or a list of reassessed tasks as the added time and disruptions can by project systemic. If it needs to be done, so be it, but 'needs' means it's already too late. Better to have active awareness, make minor changes that are local to the developer, and don't even get into those situations.

Andrew Grapsas
profile image
There's an entire section of the software engineering discipline devoted to properly estimating, time boxing, etc. No producers needed.

Mark Timmins
profile image

Here's just some of the reasons why producers can be an invaluable resource to a team:

* Estimating and time-boxing are on-going activities that require time to formulate and distil into an understandable form for external parties - i.e. the boss, or your publisher. On large projects this overhead can effectively take programmers away from what they do best; the programming.

* Producers are the go between with the publisher; a good producer is going to be able to cut the developers some slack, renegotiate milestones etc. Most substantial projects are going to have an outside influence. You need someone to act as a buffer and draw the line when that 'small change' pushes the game down the wrong avenue and the wheels inevitably fall off. (How many real-world examples do you want?)

* Outsourcing is playing an increasingly important role in game development. Who is going to spend the time sourcing them and keeping them on track, organising and approving payments etc.? You may argue the relevant lead - but their time could be spent internally with the team. Unless you have the luxury of a dedicated Outsource Manager, the Producer can do this work.

* The only time a producer may not be needed is in cases where there is a small team with a short dev period. In this scenario a small team can be very successful - but this is not attributable to the lack of a producer; but rather the inherent benefits of a low communication overhead and a clear finish line. As project duration and complexity increases the above scenario becomes less reliable for success as goals become blurred (especially if they keep changing) - the producer (or a team of producers) need to be on hand to guide efforts, provide reassurance and clarify goals.

* Producers can teach you about social lives, girlfriends and soap. Help us to help you.

The above is just from the developer's producer. A publishing producer does a lot of other tasks that rarely get the credit they deserve. In a nut shell, project estimation is only one aspect of making a game - people who make the actual game need to be free to do just that.

Kimberly Unger
profile image
Hi Ken!

:D I didn't mean "sly" in that sense, but rather that everyone on the team was willing and comfortable enough to help out and make adjustments as needed without a series of meetings and memos :D

Andrew, I will wholeheartedly admit, the programming estimates I get from my team are quite accurate estimations, but getting those to dovetail cleanly with the delivery of the art assets, in the right order so tere are minimal hangups in the pipeline, thats where things seem to go wonky.

Mark, I think you're right on with mush of this, though I would also extoll the virtues of a producer even with a small 3-4 person team, having your lead programmer or lead designer try and manage both jobs means there's going to be slippage.