Home | Login | Recent Changes | Search | All Pages | Help
ScheduleGamesI'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:
Do you have any other schedule games? -- JohannaRothman 2004.01.21 I don't have a catchy name for this yet. And I know that 10 weeks is too long for a single task. But it looks like this: week # - % complete --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
-- 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!"
MikeMelendez 2004.01.22 More scheduling games, offered hoping you'll remember to mention my name if you use them.<g>
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:
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) A thought: I vaguely recall hearing "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." The idea is estimating research is hard. 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.
-- 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. My most recent experiences have led me to the Gilligan?s Island metaphor for large software projects. First a small group of strangers (the project team) are inexplicably drawn to a cruise (project) in what is supposed to be a three hour tour. They hit bad weather (?chaos?), get lost, then hopelessly shipwreck on a desert island (?a place where they have the barest of resources and have to rely on their cunning and ingenuity to set sail and get back on course?). The skipper, an expert in seamanship, represents the project leader. Well versed in sailing, he lacks specific knowledge of the island and the particular waters he is near. Often, the leader has an assistant, who we call Gilligan, to draw maps in the sand, type up meeting minutes and revise schedules. Gilligan is a trustworthy first mate, well-intentioned, but often makes mistakes that lead the team into unforeseeable trouble. The subject matter expert, aka the professor, is well respected for his knowledge and skill as he toils away the hours with one goal in mind: get everyone off the island and home safely. He twines logs together into a raft only to watch it get torn apart by the tides (?Upper Management?). When not conceiving of ways to get off the island, the professor looks after his fellow teammates as he concocts medicines out of palm leaves and synthesizes radios out of the silicon in the sand. Lets not forget the project sponsors, Lovey and Thirston Howell III, who are continually frustrated?no matter how much money they invest in the island or how often they bribe the shipmates, they are no closer to getting back to where they once were, let alone improving their lot in life. Ginger, the drama queen, livens up an otherwise dreary stay on the island with her need for attention and passion. (Do you recognize her from any of your projects?) Last but not least is the girl next door, Mary Anne. Quiet, unassuming, helpful and cooperative, undaunted, she is the quintessential team player. 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 Yes to your relevancy question Ira. The inability of project managers to recognize their state is a prime contributor to schedule games. I wasn't thinking of the (in)ability to recognize state as part of the schedule games, but you're right - it's a huge part. -- JohannaRothman 2004.01.28 "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 When I see a schedule that's laid out in detail far into the future, I know its a fiction. The project manager may be: -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 Update (since I forgot to update the wiki when I wrote about schedule games on my blog): I have named 11 schedule games I've encountered in my work. Here is the acknowledgement page: http://www.jrothman.com/weblog/2005/05/acknowledgements-for-schedule-games.html 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 Thanks for adding the links, Johanna. I read the blog entries and really enjoyed them. I send a link to this thread out to almost every project manager I deal with (and an assortment of other people,) and I have ever since it started. I probably send this one out more often than all other threads combined. I had to explain "Bring Me a Rock" to someone on my last project. The long explanations in the blog will help. SherryHeinze 2006.04.06
Updated: Thursday, April 6, 2006 |