Manager In A Strange Land: Parkinsonian Scheduling

Wow - lot of comments on the last post, maybe partly because of its Socratic nature?  Think I'll try to keep that going.

Almost two decades ago, I temped at a mevatron factory.  One day, one of the managers and I were having beers on our lunch break, and he said, "I just tell 'em I need it in a week when I really need it in two!  They never have it done in a week, but it's always done when I need it!"   He was really pleased with himself.

Years later, a producer friend of mine wrote a short paper on how to manage videogame development - he said basically the same thing.  Since games are always late, tell your team it needs to be done before it really needs to be done.

I can't find the article right now, so I won't name names, but I read a quote from the CEO of a not-terribly-succesful-lately-publicly-traded game company, which said the same thing.  Tell the team to get it done before you need it.  They'll slip but they'll get it done on time.  "Sounds crazy but it works," he said, or something like that.

(I later met a programmer from that same company - he crunched his ass off to meet a tight deadline and then, he claimed, the product sat in the warehouse until they were ready to release it.  Sounded like he was just a little bitter; he quit working for them.)

There's a name for this management technique:  Parkinsonian Scheduling.  After Northcote Parkinson, author of *Parkinson's Law.*  *Parkinson's Law*, by the way, is a pretty good read, and there's some very quotable stuff in there.  Most people incorrectly think that Parkinson's Law is "work expands to fill the space allotted for it".  That's not actually true - that's a postulate that Parkinson accepts as a given, which he then uses to go on to prove his actual Law - which is that hierarchy in an organization will indefinitely expand.

So calling it Parkinsonian Scheduling may be something of a misnomer.  But there it is.

I have to admit, Parkinsonian Scheduling does seem to work.  Just yesterday the clock in our hotel room was wrong, and instead of being half an hour late to a mother's day brunch we were half an hour early.  When under the gun like that, you really find out what your priorities are, you work overtime if you have to, and then if you slip anyway, you feel relieved when you find out there was that extra hidden buffer in the schedule.  The only time you lose is when people, like my acquaintance whose game sat in the warehouse, actually hit your unreasonable date and then feel betrayed.  And by then they've already served their purpose.  (In this unpredictable game development world, you never know if there's even going to be a second project, so I'm usually an advocate of always taking the short-term-gain for the long-term-loss.)  Even acclaimed management books like *Critical Chain* endorse it.

On the other hand, IT'S JUST PLAIN LYING.

So now we come to the Socratic portion.  What do you think?

A)  The means justify the ends.  Parkinsonian Scheduling works.  And people lie.  I'm telling my crew the game's due tomorrow.

B)  Parkinsonian Scheduling is short-sighted.  I want to retain my talent.   And I wouldn't want to work for that kind of manager.  And with software development, if you push people to hit a date they skimp on quality - they may hit your date but it will be a really buggy product.

C)  I don't care if it works or not, lying is wrong.

D)  Other?

Comments

[Coyote]

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.

[Jacob]

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.

MSN

[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.

[Jare]

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.

[Koen]

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.

[JJ]

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.

[greggman]

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.

[Pag]

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.

[Despayre]

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.

[davidicus]

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."

[Nat]

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!