Any tips for setting realistic time frames, especially when dealing with something the team hasn't done before? Would you consider it better to work in a certain amount of flexible time to the initial schedule for when things run over, or is it more like a plan runs off track and you start fresh from where you are now?asked by Gravy

That actually pretty much defines what a producer does – keeping things on track. There are always going to be surprises that pop up unexpectedly. if things ran perfectly like on a train track it would make production way too easy of a job. So, things are going to pop up. Schedules do skew. Suddenly a blocker bug – something that prevents us from finishing the task that we're working on or prevents us from actually releasing it publicly because this bug is so severe, obviously that is going to take a higher priority and that's going to steer a lot of resources away from certain aspects depending on how sever that issue is. So, in a nutshell it's going to be a ubiquitous yes and no.

Sure... and I think to your first question about when you're working on something brand new or someone is working on something they've never worked on before how do you bid out that work to understand the full scope of it.

And how do you set realistic time frames.

Yeah, that's a very very great question and it's very difficult. Especially if, let's say you don't work in the industry and you just want to make a feature for a game that already exists or get an SDK and start building something with a designer and a programmer and an artist. You've never done it before so how do you bid it out. That's a great question. The biggest thing is you try to use folks who have done it before. Right? We try to reach out to people who have done it before. First within the company – go, "Hey, have you worked on this before at a previous company? Or even here as we have multiple locations. At your location, how did you do that or what would your bid be for that?" to kind of give us set timeframes. If you don't have that at all, it's just kind of an instant. Right? It's breaking down that task with the person who is going to do the work the best they can, go, "I think that would be this amount of days and this amount of days," and you just schedule that out and then you'll likely be wrong... hopefully too long so you can go, "Look, we go it done sooner!" but that's not always the case. So, sometimes it's just trial and error and that's how it is when you're doing something you've never done before, right?

Ultimately it becomes a kind of skill set that you just kind of develop over time. If we're developing a brand new torpedo model. Historically you look at – okay, Dan developed this model in three days, Patrick animated it in a day and a half... so if this is going to be much bigger how do we scale it up? Okay, last time it took us four days so let's add a couple extra days for QA time, some play testing... so let's make it a week. So kinda start learning how to gauge things like that but ultimately any time you put a schedule together for production purposes – almost kind of a golden rule is the minute that you put that schedule out it's going to be outdated and wrong right away.

That's right.

Because scheduling is always going to be just a series of best guesses anyway.

That's right and our job is to update it every day and move things around every day and bring up red flags where we're like, "Hey, the original idea was this. It looks like we're not going to make that date. Are we all okay with that? What should we shift around to make that happen? We do that all the time.