The sound of one Schedule-Chicken clucking

Schedule chicken! If you haven't heard of it, it goes like this:

1. BOSS: OK, we have system test coming up next Tuesday.
2. MGR1 (sweating): We're on track for Tuesday (thinking: if a miracle happens).
3. MGR2 (avoiding eye contact): 90% complete; we'll be done next week.
4. MGR3 (to MGR2): But my guys tell me the API isn't even checked in yet! You were supposed to have that 2 weeks ago! With just a week to go, it's not possible...
5. BOSS (looking around): So when can we enter system test?
6. MGR3: Two weeks after his (indicating MGR2) APIs pass unit test.
7. MGR1 (silently): (Whew! I have 2 more weeks now!)
8. BOSS (to MGR2): So you'll be ready next Tuesday, right?
9. MGR2: Thursday
10. BOSS: But you said you'd be ready for system test next Tuesday, which was the system test deadline
11. MGR2: I said "next week".
12. BOSS (to himself): How can I get these guys to quit lying?

How indeed? Let me start by saying that the answer is not for BOSS to stand up and yell, "Will you clowns quit lying?" or threaten to fire the next poor fool he catches doing it. Unfortunately, BOSS (and the system he uses) are a major parts of the problem, because his subordinates have a perverse incentive to play the Schedule Chicken game.

Before we can figure out how to get rid of it, we have to start with "where did this come from?" Here are a few observations.

• #1: How did BOSS (or whoever) decide the system-test date? Why are we talking about dates in the first place? In other words, one issue is the whole focus on "meeting" a milestone.
• #2, #3: MGR1, MGR2 make completely unverifiable (and unfalsifiable) statements! Note that BOSS doesn't challenge them. Information about who's really not finished won't surface 'til system test actually starts -- or when it doesn't.
• #4: This is the first objectively true or false sentence that's been uttered. These accursed milestone meetings are filled with lies, but hardly anything falsifiable.
• #4 again: Why are we only talking now about something that's 2 weeks late? Shouldn't this conversation have happened 2 weeks ago?
• #7: Why does MGR1 think he has more time just because MGR2 is late? Why has BOSS trained him to think so?
• #8-#11 Deliberate deception! Probably driven by an overly competitive atmosphere
• #12: I'm going to say that all this lying is strongly encouraged by the environment. The focus on when (mistake #1) something will be ready (mistake #2) is a source of all kinds of trouble.

It's true that BOSS has to be concerned about the when question, but why do we pay BOSS the big bucks? Because his job includes this onerous task:

• translate what I need to know into terms that will produce the desired behavior in MGR{1,2,3}.

It's also true that BOSS has to predict the future. But we pay him to predict the future, and not just by rolling up unverifiable (and unfalsifiable) predictions from MGR{1,2,3}. Where's the value-add in that? No, what BOSS should be doing is getting factual data about the past and present from his subordinates. Things like:

• Have the unit test specs been reviewed and approved by <insert Test Spec Reviewer's name here>?
• What % of the unit tests have been run?
• What % of the unit tests have passed?
• How many staff-weeks (or staff-months) have been spent out of your budget for this task?
• How much of the overflow buffer (or "contingency account") has been spent?

That last one takes some explaining.

We're all optimists, aren't we? That's why our estimates are always too low. "Sure, two weeks," we say, but that assumes things go as planned. Really now, how often does that happen?

If BOSS pads the schedule, then workers will do the "student syndrome" (wikipedia) thing and not start 'til 2 weeks before it's due. And things don't go as planned, and even the padded schedule is missed.

How do you fix that? The key insight is in item #5 on this post: by tracking other things than what you track now:

• effort estimated (budget)
• effort expended (out of budget) -- not % but actuals
• how much is left in the "contingency account" or "buffer"

Of course there's more than that required to fix the Schedule Chicken game. But it's a great start.

Not "How close to 'done' are you?" (answer: 90%! Always!)

But "What % of your unit tests have been run? Passed? How much (not what %) of your budget is used? How much is left? How much is left in the contingency bank?" Track all of those. That's where you add your value.

And that's also why there's not enough money in the world to get me to do that job.

And by the way

Rothman's article on student syndrome (which came up in a google search while I was writing this) is brilliant. Her consulting group's homepage is here but don't hire them unless you're prepared to do what they tell you.