Home | Login | Recent Changes | Search | All Pages | Help

ScheduleGames

I'm writing an article about schedule games, because I think many organizations play lots of schedule games, to the detriment of their projects. Here are the ones I know about:

• Schedule Chicken: Everyone sits around the table, saying they are on time. Internally each is sweating, thinking, "there's no way I can make it." Finally, someone decides to own up to a slip, so everyone else can take advantage of it. I'm pretty sure the 90% syndrome is indicative of schedule chicken.
  
  
• Bring me a Rock: You develop the schedule. Someone higher in the hierarchy than you wants a shorter schedule. It doesn't matter what schedule you develop, if it has any time in it, it's too long :-) You need to use your influencing and negotiation skills to determine what the manager really wants, and if there's any way of creating a project that can meet that date.

Do you have any other schedule games? -- JohannaRothman 2004.01.21

week # - % complete
1 - 10
2 - 20
3 - 30
4 - 40
5 - 50
6 - 60
7 - 70
8 - 80
9 - 85
10 - 90
11 - 91
12 - 93
13 - 94
etc.

--DaveLiebreich 2004.01.21 (feel free to remove this comment if it does not fit the topic)

Dave, this is the 90% syndrome. Fits in! -- JohannaRothman 2004.01.22

• Under The Rug: You've been handed a fixed scope and a fixed milestone date. Your protests that the schedule is unrealistic have been ignored. When the milestone date rolls around, some functionality in scope is still not done, but your management talks and acts as if that functionality had been scheduled for a later milestone all along, and declares the milestone a "success". You are exposed as a Cassandra, and your objections about the rest of the schedule have lost credibility.

-- LaurentBossavit 04.01.22

I attended Tim Lister's presentation on Risk Management at the Boston SPIN on Tuesday. That got my mind cooking. I saw you there, Johanna. I apologize for not coming over and saying, "Hey!"

• Schedule Dream Time: The mutually reenforced idea that the scheduled date is meaningful in its own right, rather than just a probabilistic estimate.
  
  
• A Few Good Reasons: We attempt to be compassionate with each other by hiding the real reasons for particular deadlines for fear that the other "can't handle the truth!".
  
  
• Drop Everything!: From Tim's "pants-on-fire" idea and first hand experience. "Don't you dare let me catch you do anything else but work directly on this schedule deadline because it's crisis time!" from the management side. Arranging your schedule to conform in appearance with that idea from the individual contributer side (or from the next manager down). Even worse, actually dropping everything else.
  
  
• If You Could Read My Mind: "Everything's top priority, because we're got to get it all done for the schedule," from the manager. Juggling your effort in an attempt to make your current work match what's currently on the manager's mind from the next level down.

MikeMelendez 2004.01.22

More scheduling games, offered hoping you'll remember to mention my name if you use them.<g>

• The estimate / commitment tango, wherein an estimate, by definition variable, ranged, and contingent, is treated as a commitment.
• Desires as over-arching needs ? a ballad, wherein delivery dates for example, are treated as absolute needs vs. trade-off desires.
• The over-constrained march wherein many schedule demands are made that cannot all be met at once.

All three of these tunes can also be played with different instruments: tools, functions, staffing, as well as schedules. Often they play together in a grand cacophany. Schedule examples of each:

• ?But you said mondo-sys would ship by the 14th, and now you are saying it probably won't.? Was the 14th a commitment or an estimate? Did you forget the ?all other things remaining equal? part? Did I? What about all the stuff that changed along the way??
• ?We absolutely must have mondo-sys, complete, up and running by the 14th.? Why? Will the world end? Sometimes it will, but usually if that's true something else will give.
• ?You have to make the 14th, oh, by the way, the hardware is going to be two weeks late, and that guy we hired to do the work took a different job. No telling when you'll get the help.? In what world does the planned 5 pounds of stuff fit in a sack suddenly reduced to two pounds in size?

I would like to bemoan the state of schedule management in the software industry, much like I'd really like to complain about a world where ?popular music? has devolved to post-MTV schilling of the latest pop-tart du-jour. I can't, actually. With pop music as with scheduling silliness, we get what we deserve usually because that's what we reward.

To be clear ? it takes two to tango even with a schedule. Hence the metaphor. There aren't any white hats and black hats here. Customers, users, demanding sometimes panicked management all want what they want, and are sometimes quite unreasonable about that. Even so, that's just life. Everybody has that challenge with their customers, users, etc.

In software development more so than in other practices when dealing with this icky stuff we eschew clarity, fail to make human connections, ignore others' point of view, hide information, and otherwise do our part to ensure that our customers don't trust us and won't work with us. Every time we over-promise (even by omission) and under-deliver, we encourage schedule sillines among other pathologies. In software we provoke bad behavior in our customers, then reward it. We have met the enemy and it is us.

Me, I buy independent artists, especially those on their own label. I prefer music that stimulates and provokes vs. the latest manufactured pablum. Good music, including the instrumental stuff, has a point of view, takes a position. It's personal, and its quality comes from the integrity and expereince of the person behind it. At work I talk about scheule realities all the time and as humanely as I can manage. Sometimes I get shot up for that.

Sometimes the good guys win. I notice that Ani DiFranco gets national (US) notice these days. Good for her and her self-owned ?Righteous Babe? label out of Buffalo New York. We need more music like this in software schedule conversations. But it's challenging and real, so be prepared for that. It's only life, after all.

-- JimBullock (2004.01.22)

related to that thought: one schedule game might be falsely labeling a particular task as research, so that you don't have to estimate it :-) --DaveLiebreich 2004.01.23

That's good, Dave. Another very common schedule game is falsely labeling a particular task as production, when it's research or investigation. -- JimBullock 2004.01.23

As in this here story :

-- Laurent

It is also hard to estimate the task "fix this bug". If the defect is actually within your own software, you can find it between 5 minutes to two days, but if it appears to be within the operating system or one of the layers of the system, it can be hard to figure out (and even harder to fix.) If you didn't write the software, it can be hard to gain the understanding of what it intended to do versus what it is actually doing.

-- KeithRay 2004.01.24

Hope is Our Most Important Strategy: Commiting to deliver X features by Y date when the organization has never come close to delivering similar scope in a similar time frame.

EstherDerby 01.25.2004

The Vision Thing: When management and developers agree that all the work involved is production and attempt to schedule on that basis.

Rite the First Time: Scheduling on the basis that no bugs will have to be fixed, unless, of course, the testers screw up and find some.

To join Dave, Jim, and Keith's discussion: I believe all schedules must begin with research, unless you're repeating something you've done before in exactly the same way. In like manner, they also end with research.

MikeMelendez 2004.01.26

I believe all schedules must begin with research,

Research is continuous. Some tasks produce deliverables that are part of the product. Other tasks produce only information about doing the work. All tasks produce information. So there are two schedule games that go with these.

• One is the "There is nothing more to learn." game. Every time you do some work, you generate information, so failing to learn something from each and every task is a choice, and a poor one. Worse is of course denying the information that's been produced because the schedule is set in stone.
• The other game is named for a US President: "The Clinton game, or 'It depends on what your definition of 'is' is.'" So when we don't like how the schedule is going, we play with the definition of task completion, or worse, the committed deliverable. So we get to stay on schedule, successfully travelling to this hour's destination by the clever ruse of defining our goal as wherever we got to.

-- JimBullock, 2004.01.28 (I'm just making this stuff up. I've never actually seen any of these games. Honest.)

I suppose that depends on what your definition of "making this stuff up", "seen", and "honest" is. --DaveLiebreich 2004.01.27 :-)

I just read EstherDerby 's "insights" on "Jumping to Conclusions", so I'm going to ask.

Jim, you quote my entry and comment around it. I agree that research can dominate any part of a schedule and that some research, however small, is always a part of every part of the schedule. Do you believe that research always dominates the middle of the schedule, after teams are formed and tasks are clear? If so, I disagree with you.

I'm an individual contributor, though once upon a time long ago (20 years) I was a manager. I've seen every game listed (including yours) more than once. I have first hand experience as a player in a few, though those tend to be repeated frequently. I doubt you are different. So why the semi-self-deprecating remark?

--MikeMelendez 2004.01.26

We agree on the distribution of research across a project. That's an indicator, actually, that works both ways. When you're somewhere in the middle and the progress is still acting like research, you are missing something. If the progress and expectations aren't flailing a bit at the start, you're fooling yourself. Or you are doing operations and calling it a project/

Re: Semi-self-deprecating. Sometimes I attempt some humor, mostly of a dry, ironic variety. Sometimes when I attempt it, it works. Then there is the other case.<g> -- JimBullock 2003.01.31

So what does this have to do with project scheduling? Everything. Did you see the Skipper and Gilligan call a meeting after they wrecked their vessel and demand a return date from the Professor? No. They had the foresight to realize they were in an unfamilar situation and would possibly need to explore the island and its resources and the talents of the crew before drawing up a plan. Many Software Project Leaders don?t even recognize they have crashed, let alone having the patience to realize they need to assess where they are before they attempt to go somewhere else.

Relevant?

IraWeinstein 2004.1.27

"If you can't break down your task into subtasks of no more than x duration (where x is 4 hours or 8 hours or 1 day or something like that), then you are either bad at task estimation or you are doing research."

I've seen this used as cleverly disguised set-up for the blame game in situations where management wants a schedule within the the first week or two of a 12 to 18 month project. Engineers are put in a position where, to avoid being accused of being "bad", they have to engage in an exercise that layers fantasy on top of hope on top of fantasy (which just postpones being labeled "bad"). How can I, with any integrity, estimate how long its going to take to implement some feature six months from know when we haven't yet firmed up middleware APIs, UI infrastructure, etc.? The best I can do is provide a (low) confidence range, which will invariably be fed into tools that only want point numbers. And even if we are spending a month sketching out a design, chances are good that necessary scope changes will unend the resulting schedule.

Work Breakdown Structures, or other graphical representations of estimates, should be color coded. The further out in the future a task is, the bluer (as in "blue sky") it gets, and the deeper a task is under other blue tasks, the more its box should look like a cloud.

DaveSmith 2004.01.29

-writing fiction for the managers above

-working out of a predictive model of project management

-in love with the scheduling tool.

EstherDerby 01302004

- fatally naive.

-- JimBullock, 2004.02.02

If I missed you in the acknowledgements, do let me know.

The posts are in these two monthly archive pages: http://www.jrothman.com/weblog/archive/2005_04_01_mpdarchive.html

http://www.jrothman.com/weblog/archive/2005_05_01_mpdarchive.html

-- JohannaRothman 2006.04.05