« Slings And Arrows | Main | Notes on Puzzle Quest »

May 14, 2007



I was like your acquaintance. Same deal. We worked our butts off, as much as 92 hours a week (okay, 92 was the high for the project, but way too many weeks were over 80 hours). Then when we tried to find out how the box art and trademark search were going back at HQ as the game neared completion, we discovered that they were PLANNING on us being 3 months late, and hadn't even started on some of that yet.

That burned me out in a way that 4 previous years of crunches and lost time with my family had never done.

Screw that. You know how it should be done? Pass the incentive back to the employees. "We get final release in EXACTLY by this date, you all get a $200 bonus. And you'll each get a $200 bonus for each week you get done early, up to 4 weeks early. That's right, an $1000 bonus for each of you if we make it past the finish line a full month ahead of schedule."

Yes, that has to be planned out carefully - you want the employees more motivated by the quality of the product than on the possibility of cutting corners to get that extra $200. And if the game DOES go over schedule, you could be doubly screwed as motivation might disintegrate. But it sounds to me like that's the best way to get employees on exactly the same page as management --- make their goals and rewards as similar as possible.

Nathan McKenzie

I'm not sure in the general case, but I can tell you this, speaking of long-term versus short-term...

If this works, it only works for a final deadline.

I've been on projects before that attempted this with internal milestones - lots of mid-project crunching for "unmovable" deadlines, only to discover those deadlines were, in fact, movable.

Eventually everyone decided (correctly) that they were being lied to, and they started disregarding (with extremely prejudice and more than a little ire) the sky-is-falling-we're-shipping-tomorrow verbiage filtering down from on high.

Frozax Games

C) Lying is wrong!
And when you've done that for a few years, people understand it's wrong and therefore thinks: "he said the deadline is in July, so we'll have until September". I see both these behaviors very often.


Honesty works. Honest implementations of Critical Chain work very well. That entails getting both the honest 50% estimates and communicating the amount of slack and the rate or slack consumption back.

Mat Noguchi

Re: Critical Chain

Critical Chain endorses Parkinsonian scheduling? I didn't see that at all. I think it was proposing to understand where all that time comes from and actively preparing for failure. Or something like that. Not at all the same as "ask for something now so that it will get done soon." In fact, the other books in the series say that that technique ultimately fails due to emphasizing optimizations for the wrong thing.


Brett Douville

On the three products I shipped for my former employer, team management was up-front and clear about all of our dates (in two of those projects, I was part of team mgmt). Every now and again, there would be a temptation on someone's part to hold back information from the team, and time and again we'd stop and say, "What, are we nuts? Even if we're comfortable lying (which we aren't), if we lie to them *ever*, we lose. They'll never trust us again."

I don't know if Parkinsonian mgmt would have worked on those teams -- we didn't do it. A couple of the games slipped a bit -- but as soon as we could tell that they were going to slip, our project lead/director/producer (the role names changed, but anyway, the head honcho) would go to management and be up-front with them -- as early as possible. Transparency worked. We'd go to them with our realistic schedules of how long to get it done, giving other departments (marketing and sales, primarily) time to adjust their plans accordingly. It was never really an issue, because everyone was clear and honest.

And it cut both ways -- management came to us on our second project and said come hell or high water, this product has to hit fiscal. And we knew that 9 months before the end of the fiscal year. And we got it done, and it was everything we wanted it to be -- we put the hours in for upper management that time. Many times, upper management stepped in with more money (time or people or both) to make sure we could make a great product. Many times, the team stepped up and put in the hours to make the schedules we committed to.

The one project I didn't ship was misleading people in both directions (I was not managing on that project). That one was cancelled, at a very substantial cost to the company. In the end, when the team went to them with an honest appraisal of what could and couldn't be done and when, it was too late -- too much "trust capital" had been squandered, and even if a good financial case could have been made for finishing the product, I don't think upper management believed in what we were putting forward.

So, I guess I'll go with D (though the reasoning is partly borrowed from B). Transparency and honesty work -- I think they work even over the course of a single product (with the longer term cycles we have in this industry). The longer that relationship is going to work -- a single 18 month product or several (totalling about 7 years in the case of my career there), the more transparency and honesty win out.


I won't judge what's universally right or wrong, but I definitely know what I want for myself, as a manager and as a worker: a challenging but honest environment.


B) This kind of short-sighted "management" is exactly why so many people leave the game industry, and that's why this month, I'm leaving it too.

When I develop software, I want to work in a professional environment, and game development is definitely not a professional environment. It's kind of a vicious circle: all good people leave this industry, and the ones who have no clue of professionalism or decent software development stay behind.


Coyote: people get used to bonuses, and they become ineffective. It's like coffee or sugar in the studio: when you introduce them for the first time - it makes people happy; when you have it all the time - nobody notices that; when it's gone - beware for riots! :-) Motivation should come in a random forms.

To get back on topic... Parkinsonian schedule seems as a good way to have a backup in case a project slips the schedule. But as many already mentioned, it works mostly only for the first time and might backfire. Myself, i believe it doesn't help in the long term. The problem lies in how we approach the game development itself. Before we even start doing the game, we fix the budget, scope and time, and later end up being late. We have to losen one of those ends... No tricks like Parkinsonian schedule will help to prevent overtimes and project slips.


The rewards don't work IMO.

First off $200 a week is not worth my time. I'd much rather have more time off than $200. In fact if the average price for a programmer is $100k a year that's $50 an hour. $200 is only worth 4 hours by that measure.

If you raise it to some large amount of money, say $25000 for each week it's early, then we have new problems. (a) If we miss the dealline all work is going to effectly stop. Why keep trying if the rewards are gone. (b) If we think there is no way we'll meet the deadline we'll stop. Why kill ourselves for something impossible? (c) you'd hope everyone will work their ass off but if one or two don't there will be far more bad feelings and related reprocussions on the team than otherwise.

I haven't read the book but my gut says just schedule and plan better in the first place and do the manage by walking around method.

I think most game dev teams manage by the "next to zero management" method. Some designers write some docs that few if anyone reads. Sometimes there's a meeting or two to talk about what people are doing. Otherwise most people are left on their own to figure out what to do. They have a general idea, maybe even a task list but otherwise they are on their own.

In a "manage by walking around" studio, someone, usually the *director*, decides what he wants to see implemented today. He then walks to each individual person needed to accomplish that task and talks to them, asking them what they need to do that task, how long it will take, what are they waiting for and if they don't already know who is working on the parts they are waiting on. They then walk to those people and continue. If the director comes to point where all that's left to do is wait he either works on something else for a few hours and then walks around again, or, figures out something the people not involved with the first task can or should do and walks over to them and starts the process again.

I have a feeling this works for the same reason some people claim pair-programming works and that is, it's hard to slack (check e-mail, browse the web, etc) when someone is directly waiting on you vs the more typical style which is having some list of 10-50 tasks and some deadline 2-8 weeks away. In the first case the director is expecting results asap, usually the same day if possible. In the normal case no one is really expecting results until the deadline.

Hugh "Nomad" Hancock

From past experience, this works in theory, but I'm just not that good at this sort of lying - I can never manage to carry it off. I always end up telling people the real deadline.


If employees don't realise they're being lied to, then they'll think their manager is either incompetent because he can't do a reasonable schedule for the amount of work to do, or a jerk because he's not willing to do it.

If employees realise they're being lied to, they'll think their manager is a lying jerk who's trying to get them to do unnecessary overtime just so he looks good.

Neither situation seems good for morale, frankly. No plan that involves lying to your employees so they work unnecessary overtime would, I guess. If you don't care about keeping people in your organization and just want to get the most out of them, I guess that's fine. But I think you get better results long-term if you keep the same team happily working together for a long time.

Michael Hough

I've been on projects that have slipped and slipped again, and... you spend a lot of time hacking stuff together quickly then tearing it out and doing it right.

There's no guarantee that you'd've actually done it right if you had the schedule, and (as much as I hate it) things do go quicker when there's the feeling of urgency.

As a counter to your mother's day example: I was having trouble getting up early so I set my clock forward half an hour; after a few days I'd learned the offset and mentally subtracted. The only real solution to that one over the long term--to extend your analogy--was to go to bed early. So: option B!

Jamie Fristrom

Unfortunately, my copy of *Critical Chain* is buried in a box somewhere. I do like the book, but at the beginning of one of the last chapters he says something like, "We've already discussed why it's important not to tell the team what the real deadline is." Or something like that - which ties in with his theory that part of the reason his system works is because it avoids student syndrome. So, yes, parkinsonian mgmt endorsed.

Matt Severin

In my experience, the decisions you make when you think you have 9 months to finish are very different from the decisions you make when you have 12 months.

By saying that you have 9 months, certain corners are cut, features are cut and some changes become irrevocable.

Once you hit that 9 month point, the people who said you had 9 months to finish generally come and say, well, since you have an extra 3 months, why don't you do X, Y and Z. Often these things are no longer possible because of decisions made to meet the 9 month deadline.


I have worked on projects that used that type of scheduling. It does work, but the effects on morale are staggering and not anything that I would willingly want to introduce into any studio that I want to be at for any length of time. I personally don't like any strategy that involves lying to your people to get them to work insane hours. They will figure it out, and when they do, one of the first things they are going to think is, 'What else are they lying about?' Once that starts, you end up having more malcontents just sitting at a desk collecting checks and for what? So you can make a stupid deadline that probably would have been made anyway if you had just been honest with them and told them the reasons why they needed to put in some extra work to get things done?

I've had to tell people that we needed them to stay until something was done, and you get a lot more respect if you're up front with people and let them know what happened and why they need to stick around than you do by just yanking them around or giving them false information. The work still gets done either way, but a team that is built on openness and respect will pull together to help each other out a lot more in any other difficult times that you might have later on than a team that is tired of working 60-80 hour weeks because of the constantly shifting deadlines and blatant lying by management. If you just want to have a team of unhappy, resentful, and less cooperative shells that churn out boxes to put on shelves and dont mind replacing them after every couple of projects, go ahead and say whatever you want. If you actually want to build a team of quality people that sticks together because they care about the games they make as well as each other, be up front and respect them enough to tell them the truth.


i've worked under project managers and as project manager. i trust the truth; however, i pad a schedule in direct relation to the reliability/maturity of the resource and the size of the task/project. i'm honest about the padding if asked, and sometimes even if i'm not.

some people are just confused.

recently i was scheduled to get a number of things completed by thursday. later, the scheduler said it could carry until monday. i said, "i thought that was a HARD deadline." he replied, "it is, but we can take until monday."


The one thing I noticed about the milestone schedules at my company (which are openly posted for all to see) is that there is more time scheduled for alpha and beta compared to colleagues at other companies I've talked to. I've heard of beta periods/cycles that are supposed to last just one month. Unless you have some miracle dev team that either eats bugs for breakfast (and are very hungry) or can somehow make bug-free games, I don't know how you are going to fix all your bugs in that period/cycle of time. Getting all your bugs fixed is one of those things that holds a game back from getting approved by Sony/MS/Nintendo. Similarly, at alpha the game is supposed to be "finished" / playable from beginning to end but lacking polish. I've heard of one month alpha periods/cycles. It baffles me. Do they seriously expect their team to polish all the art and design in just one month? And when you slip on your alpha and you only have one month scheduled for beta, you're team will be crunching hardcore or have to push back their ship date which is usually costly and could indirectly affect potential royalty earnings. Either way, they're screwed. I would say 'D.' Instead of lying about the deadline, use those buffer months to schedule longer alpha and beta periods/cycles and most importantly, stick hard to those alpha and beta definitions: "finished" / playable from beginning to end but lacking polish for alpha and Done but with bugs for beta. As long as I know what's expected of me for the next milestone, I'll pace myself to achieve that goal. If I'm bad at pacing, then I should hope my lead is on top of things.

Another thing is your team has to have the discipline to resist feature creep or be really smart about it. Since the game is "finished" at alpha, that should also be your deadline for new features. Employees should be internally motivated to work hard before that deadline if they want to get some of those extra features in because they should know there is a good chance they will be told 'no' after alpha. of course, some will get to slip in but it's a much more controlled environment at that point. things usually will need some sort of managerial approval. Mixing up your MAKE, POLISH, and BUG FIX cycles gets you into the most scheduling problems.

Related to feature creep, you probably want to have lots of early focus testing and what not so you can schedule those fixes and new features well before your alpha deadline as to keep your cycles from overlapping. This is another thing I don't always see scheduled. A lot of focus tests happen 3 months away from the ship date and it's pretty pointless at that point because if something is seriously wrong, there won't be time to fix it! Crunch time!

The comments to this entry are closed.

Jamie's Bragging Rights

  • Spider-Man 2
    The best superhero games of all time Game Informer
    Top five games of all time Yahtzee Croshaw
    Top five superhero games of all time MSNBC
    Top 100 PS2 games of all time Official Playstation 2 Magazine
    1001 Games You Must Play Before You Die Nomination for Excellence in Gameplay Engineering Academy of Interactive Arts & Sciences
  • Schizoid
    Penny Arcade PAX 10 Award
    Nominated for XBLA Best Original Game
    Nominated for XBLA Best Co-Op Game