< Back
Page 6 of 6
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter is from the book
Notes
- From: Richard Sargent, 72762,3342 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project, Msg #159427, reply to #158778 Date: Mon, Jun 24, 1996, 2:22:20 AM Ed, A colleague of mine passed along this paraphrased quote. I think it applies here. The definition of (corporate) insanity is doing the same thing again and again, and each time expecting different results. I have no idea who originally framed the assertion, but it's gold! Richard Sargent 5x5 Computing Solutions Inc.
- From: Dave Kleist, 70730,1613 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project, Msg #158064, reply to #158015 Date: Tue, Jun 4, 1996, 7:28:03 PM Ed, >> 1. Why would anyone in his right mind agree to work on a "death march" project (defined in the terms above)? << Because it's rarely printed as part of the want ad. Not much sense in saying, "Are you interested in working incredible hours for no additional benefit beyond your hiring salary? Does the idea of working endlessly on obsolete technology while 'waiting' for a slot to open up on that exciting GUI/DSS/warehouse/HTML subproject really entice you? Do you define three-tier architecture as an opportunity to hear what other project members will work on without your help?" Seriously, death march projects are rarely billed as such, and it takes a lot of work when being hired from the outside to discover if your hiring company is prone to creating death march projects. In addition, death march projects only look that way. While they demand the hours, every hour is not productive. After a while, peo- ple find ways to do the things they being deprived of (pay bills, run errands). It just isn't billed that way. The environment still sucks, people hate it. And, how accurate are those hours that are being billed? Where do they come from? Got any contractors? Ever heard of "nuisance hours" or "annoyance hours"? You know, where a contractor overbills because they can't stand some of the people they are working for. (Let me say right now that I've never done it and never will do it, but know people who have). The lead or manager does what the con- tractor thinks is stupid, and the contractor takes revenge (in their own quiet way). And, what about overhead? Are all hours to be marked to the project, including corporate and department meetings, training, etc.? >> 2. If a colleague of yours was about to take on the task of man- aging a death-march project, what is the ONE THING you would advise him/her to do? << Try to craft an exquisite exit clause in the contract <VBG>. Seri- ously, one of the reasons for a runaway is the inability of someone to hear reality, usually upper management (either side, IT or busi- ness). Someone taking over a death march has got to find an angle for them to get some manuevering room (functionality, cost, time) in at least one aspect or they are doomed. >> 3. Conversely: what is the ONE THING you would advise your col- league NOT to do, under any circumstances, when embarking upon such a project? << Acknowledge that it is going to be a death-march. Doesn't sound honest but admitting that it's going to be a killer can be demoral- izing for two reasons: one, people don't like to hear that the next 6-12 months could be hell; two, management usually underestimates the negatives. Not much hope if you know right out of the gate that it's going to be ugly. I had friends who worked on one project that had management openly admitting that there was going to be road- kill on the project. Oddly enough, they had trouble recruiting internal replacements once the turnover kicked in. Seriously, admitting upfront that it's out of control is already saying very little for one's management skills. If you ask, some- times staff will volunteer ways to help keep it from becoming a death march. In the death marches I've seen, the one thing that I've seen common to them all is a lack of empowerment among the staff. - Dave
It should be emphasized that while the dot-com startups are probably the most recent, and perhaps the most extravagant, examples of this phenomenon, they are by no means the only ones. The software industry has spawned startup companies since the 1960s, if not earlier, and it will continue spawning them as long as smart people have intriguing ideas for exploiting new technology.
"X" used to be eight for many years, then it shrank to six. With the Enron/Worldcom scandals, the number seems to be shrinking steadily. Perhaps one day there will be only a "Big-One" accounting firm!
See my book, Byte Wars: the Impact of September 11 on Information Technology, for more discussion of this point.
From: Kevin Huigens, 74762,2726 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project Msg #158577, reply to #158015 Date: Mon, Jun 10, 1996, 9:13:16 AM Ed: At our weekly staff meeting, my team and I had a brainstorming ses- sion on your 3 questions. Here's our answers: 1. Why would anyone in his right mind agree to work on a "death march" project (defined in the terms above)? Everybody wants to feel wanted Perceived opportunity Perceived money gain Can't afford to lose job Brought in from the outside to lead the project Willing suspension of disbelief Don't care whether project fails, get to work with cool technology On-the-job-training on new technology Eternal optimism Challenge Plain stupidity Chance to prove yourself To get the job done It's the only project Your friend is running the project Your brother is running the project (It'd take more than friendship) Your boss said so You have no other life Nothing better to do Stock options Existing pay vs. expectation of raise Love is blind Resumé-building Ignorance Comeraderie Expectations for how long it will take are too low 2. If a colleague of yours was about to take on the task of managing a death march project, what is the ONE THING you would advise him/ her to do? Leave me out Run! Keep your eyes open Ask "What's the pay?" Get a lot of rest before you start the project Make sure you can trust all of your co-workers Realize the developers aren't your enemy, the managers are Try to get management to understand the ramifications of the project Communicate. Communicate. Communicate. Keep the team small Hire new graduates Keep the team intact Manage scope Review the design Focus is a substitute for time Make sure testing plan is ready when it's time to test Make sure you have a test plan Make sure everybody knows what to do Documentation is critical Don't rush to code Keep documentation updated and current Everyone should have access to documentation Have regular weekly progress meetings Have daily progress meetings All code works before you leave at the end of the day Keep plenty of good coffee on hand Make sure team is happy Make sure team has everything they need Use management by walking around Make sure everyone understands what they're doing 3. Conversely: what is the ONE THING you would advise your col- league NOT to do, under any circumstances, when embarking upon such a project? Don't plan a wedding Don't have unclear areas of responsibility Don't allow design changes lightly Don't assume 1st version is final Don't become irritated or angry Don't lose your cool Don't let others lose their cool Don't forget to back stuff up Don't expect everyone on the team to be dedicated Don't get too personally involved in success or failure of the project Don't rely too heavily on 1 member of the team Don't allocate resources lightly Don't assume team members understand the entire project Don't overcommit Don't underestimate Don't refrain from asking questions when you don't understand Don't start the project Don't start the project if you haven't got the money to finish Don't commit to unreasonable dates Don't be afraid to quit if you feel management is unreasonable Don't be too hard on overworked, underpaid workers Don't let meetings last > 1.5 hours Don't be afraid to bend the rules Don't forget to have a life Don't sweat the small stuff Don't be afraid to let management know you need something Don't be afraid to stand up to management Don't forget to keep your resume updated Don't accept as gospel info from so-called experts Don't forget that management doesn't understand how to develop software Don't forget that shortcuts just defer work, they don't eliminate it Is that enough for you? Kevin
From: Dave Kleist, 70730,1613 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project Msg #158064, reply to #158015 Date: Tue, Jun 4, 1996, 7:28:03 PM Ed, >> 1. Why would anyone in his right mind agree to work on a "death march" project (defined in the terms above)? << Because it's rarely printed as part of the want ad. Not much sense in saying, "Are you interested in working incredible hours for no additional benefit beyond your hiring salary? Does the idea of working endlessly on obsolete technology while 'waiting' for a slot to open up on that exciting GUI/DSS/warehouse/HTML subproject really entice you? Do you define three-tier architecture as an opportunity to hear what other project members will work on without your help?" Seriously, death march projects are rarely billed as such, and it takes a lot of work when being hired from the outside to discover if your hiring company is prone to creating death march projects. In addition, death march projects only look that way. While they demand the hours, every hour is not productive. After a while, peo- ple find ways to do the things they being deprived of (pay bills, run errands). It just isn't billed that way. The environment still sucks, people hate it. And, how accurate are those hours that are being billed? Where do they come from? Got any contractors? Ever heard of "nuisance hours" or "annoyance hours"? You know, where a contractor overbills because they can't stand some of the people they are working for. (Let me say right now that I've never done it and never will do it, but know people who have). The lead or manager does what the con- tractor thinks is stupid, and the contractor takes revenge (in their own quiet way). And, what about overhead? Are all hours to be marked to the project, including corporate and department meetings, training, etc.? >> 2. If a colleague of yours was about to take on the task of man- aging a death march project, what is the ONE THING you would advise him/her to do? << Try to craft an exquisite exit clause in the contract <VBG>. Seri ously, one of the reasons for a runaway is the inability of someone to hear reality, usually upper management (either side, IT or busi- ness). Someone taking over a death march has got to find an angle for them to get some manuevering room (functionality, cost, time) in at least one aspect or they are doomed. >> 3. Conversely: what is the ONE THING you would advise your col- league NOT to do, under any circumstances, when embarking upon such a project? << Acknowledge that it is going to be a death-march. Doesn't sound honest but admitting that it's going to be a killer can be demoral- izing for two reasons: one, people don't like to hear that the next 6-12 months could be hell; two, management usually underestimates the negatives. Not much hope if you know right out of the gate that it's going to be ugly. I had friends who worked on one project that had management openly admitting that there was going to be road- kill on the project. Oddly enough, they had trouble recruiting internal replacements once the turnover kicked in. Seriously, admitting upfront that it's out of control is already saying very little for one's management skills. If you ask, some- times staff will volunteer ways to help keep it from becoming a death march. In the death marches I've seen, the one thing that I've seen common to them all is a lack of empowerment among the staff. - Dave
From: Steve Benting, 72410,477 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project Msg #158362, reply to #158015 Date: Fri, Jun 7, 1996, 12:59:21 AM Ed, As long as you're asking... >>1. Why would anyone in his right mind agree to work on a "death march" project (defined in the terms above)?<< Because it seems to be a well-thought-out project this time. You've got someone leading who has a real sponsor in management, the project plan appears to be solid, the people involved all appear to be good. Hell, you *want* to work on this thing. Then it collapses because your sponsor gets taken out in a political strug- gle, the project plan turns out to be built on assumptions that are incorrect, and one or two key people turn out to be flaky. You can learn to watch out for them, but sometimes you misjudge. And you don't want to believe that it's happening again. (I'm assuming some things here. I've only been involved on one large project, but it certainly went down hard. Delivery date was October, '94 and later moved to March '95. I was working on the contingency plan toward the end and left after most of the team in January '95. The new sys- tem still does not exist. The company is now in the process of pur- chasing someone else's system that doesn't have half of the functionality they originally required.) >>2. If a colleague of yours was about to take on the task of man- aging a death-march project, what is the ONE THING you would advise him/her to do?<< I would say to take care of his/her people as much as possible. Kick them all out of the office on Friday nights and try to make sure they're getting sleep. (Those months of 12-hour days six days per week can just burn out the developers, making them either quit or make too many mistakes.) No matter how badly the work needs to be done, you've got to take care of your people. Sometimes getting the most out of them requires sending them home. (If you know the project's in trouble when you start, you've got a long haul ahead during which you'll need good people.) Also, make sure that you've got the best salary scale possible. It won't make all the difference, but it should be cheaper than attri- tion if it's enough to keep some people on. >>3. Conversely: what is the ONE THING you would advise your col- league NOT to do, under any circumstances, when embarking upon such a project?<< Don't let anyone put serious pressure on the employees besides you. Run interference to keep the developers free from others who are trying to ask them to run that 2-minute mile. (We had a devel- oper working for us when I was the IS Manager -- and before the aforementioned project was started -- who was writing a new commis- sions system. The Sales VP came down to tell her that until she completed this system, her -- the sales manager's -- salespeople couldn't pay their mortgages. My VP quite rightly threw her out to let the developer work in peace.) That's not to say that you can't push those employees yourself, but you have to have some control over the stress levels in the organization if you're going to keep them going. >> I'd like to solicit input, feedback, war stories, case studies, good jokes, etc.<< This must be where I tell you about how, on that infamous project, the new President explained to me why he wouldn't sign off on requirements when asked to. (Needless to say, scope creep was a major factor in its death.) He was a down-home type who thrived on people taking his southern drawl as a sign that they were dealing with a country bumpkin. He had also just orchestrated the removal of our sponsor -- the previous President -- by killing the project. His reason for the management group's refusal to sign off on requirements was that my VP was "going to hold our feet to the fire" with that document. In other words, he wouldn't agree to sign the document because he would have to live with it later! At this time, I knew I really needed to get out of there, and quickly... Steve
From: S. Marsh Roberts [ICCA], 70007,4251 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project Msg #158111, reply to #158015 Date: Wed, Jun 5, 1996, 5:31:15 AM Ed-- >> 1. Why would anyone in his right mind agree to work on a "death march" project (defined in the terms above)? It's understandable that an inexperienced software developer (or someone who hasn't had the pleasure of reading Scott Adams' "The Dilbert Principle") might be bamboozled by management's claim that the death march is an anomaly, and that the superhuman efforts are going to revolutionize the human race, defeat Communism, cure cancer, etc. But after you've heard this pitch two or three times, it sounds like a broken record. So why do we get sucked into this again and again?<< The "heros" are needed, wanted, desired. They are certain of their place in history, if only they can keep this project from outright sinking under its own weight. The same people take on EMT work and enjoy firefighting (liter- ally). If you only win once in ten times, but everybody else lost all ten, wouldn't you be a hero, too? >>2. If a colleague of yours was about to take on the task of man- aging a death-march project, what is the ONE THING you would advise him/her to do? (The "one thing" motif was suggested by Jack Palance in the wonderful movie "City Slicker", starring Billy Crystal)<< I'd encourage him to keep his sense of humor. It may be gallows humor, but it's all that such a group has. <sigh> >>3. Conversely: what is the ONE THING you would advise your col- league NOT to do, under any circumstances, when embarking upon such a project? << I would encourage him (and excuse me, it would be a him in 99/100 attempts) to not invest in options or get a large mortgage. You can only take high risk in one arena at a time, without risking a total wipeout of personal assets. I once said that I would be willing to take a certain job whose incumbent tended over a seven year period to last no longer than a year. I figured that three months' salary would provide enough sav- ings to recover from the inevitable. Sharon
From: Paul Neuhardt, 71673,454 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project Msg #158349, reply to #158015 Date: Fri, Jun 7, 1996, 12:20:19 AM Ed, << 1. Why would anyone in his right mind agree to work on a "death march" project (defined in the terms above)? >> For me, it was ego, pure and simple. They told me that they just KNEW I could help prevent the project from becoming a death march. I was made the "technical project manager," given ego boosts on a regualr basis, then hung out to dry along with the rest of the team. Left, right, left, right, left, PLOP! (The really embarassing thing is, I let these same people do it to me AGAIN just one year later. Once I began to feel myself falling into the step of the death march, I ran like hell for the door. Me, and about 60% of the rest of the staff. BTW, It's been four years now since I first got suckered in, and neither system has ever seen the light of day, nor will they.) << 2. If a colleague of yours was about to take on the task of man- aging a death march project, what is the ONE THING you would advise him/her to do? >> To quote those mad englishmen in "Monty Python and The Holy Grail" I would say "RUN AWAAAAAYYYYYY!!!". It sounds like a flip answer, but it isn't really. Some of the most damaging effects of a death march project are psychological. Lower self esteem, depression, anxiety and sudden mood swings are all behaviors I have witnessed (and sometimes experienced) during these projects. I've seen at least one marriage break up in no small part because the partner involved in a death march let it consume her so totally that she bacame an entirely different person, one whom her husband (and most of the rest of us) had no desire to be around. I know another woman who, when a three year "death march" ended with the project being cancelled, said that it was the only experience in her life that even approached the heartbreak she felt when she miscarried during the sixth month of pregnancy. Now that's trauma. If you can get out, go. << 3. Conversely: what is the ONE THING you would advise your col- league NOT to do, under any circumstances, when embarking upon such a project? >> If you can't beat 'em, this is one case where you do NOT want to join 'em. Do not let yourself become too emotionally attached to the outcome of this project. Like POWs on death marches, think about anything else but the march in order to survive. Try to go to work, grind out your day's brick for the wall, and go home. If you want stimulation and personal reward, read a book, join a social club, volunteer at the local animal shelter or buy a kiln and throw some clay pots. Do anything to keep your mind off of work as much as possible. The moment you get to attached to the project, the guards with the rifles win and you, the lowly POW, lose. Paul
From: Al Christians, 74031,316 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project Msg #158029, reply to #158015 Date: Tue, Jun 4, 1996, 12:04:05 PM Ed Sounds like you are going to have a lot of fun this summer. 1. Why would anyone in his right mind agree to work on a "death march" project? Since you mentioned "City Slickers", the movie that used such regrettable sexual stereotypes, I am somehow prompted to reply "testosterone", which is about the same as "because it's there." There are plenty of jobs that raise the 'why?' question. Under- ground mining, cowboying, logging, smoke jumping, jet fighting, submarining, even high-rise window washing all have serious draw- backs far beyond what you describe for software projects, and yet all these have practitioners whose sense of self is linked to their profession. But if you really think that reasons are needed, here are a few: a. We think we learned so much in the last experience that it would be a waste to not find a project on which it could be applied. b. We know that some of our colleagues are going to be suffering, and we don't mind doing our part to lessen their burden. c. It's like a lottery ticket -- despite the odds, we can imagine the possibility of large rewards if we win big. d. The high level of urgency that arises during these difficult projects redistributes power to those who know how to resolve the crises, i.e., us, and we like power. > 2. If a colleague of yours was about to take on the task of man- aging a death march project, what is the ONE THING you would advise him/her to do? Remember that the people who love him/her, love him/her for reasons that have nothing to do with the project. > 3. Conversely: what is the ONE THING you would advise your col- league NOT to do, under any circumstances, when embarking upon such a project? Since "this is the way it's been for a long time, and this is the way it's gonna continue to be," don't try to work at a pace that you can't sustain healthfully for a long time. Al
From: David Maxwell, 100342,3620 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project Msg #158991, reply to #158015 Date: Mon, Jun 17, 1996, 4:53:16 AM Ed As I talked on another thread the other day, projects are like a marriage. We tend to start of naiively and full of hopes and slowly as reality sets in, we have to reassess our expectancies within the relationship. There are many reasons apart from *logic* that attract people together into a marriage and it is the same case with projects. With a predominantly youthful workforce, it is likely that the "death-march" project will occur again and again as a training ground for managers and developers alike. And, as I know from personal experience, I often repeat the same mistake many times before the penny drops. Niezche, the German philosopher in the last century said that "society is governed by mediocrity". What he was presumably imply ing here is the central, conservative-stream will tend to dominate behaviour and control events. This central-stream is hell-bent on preservation from the extremes and will draw the blinds on anything that threatens their positions. What we are really asking for in IT is a radical re-shaping of the way projects are managed, with open vertical and horizontal communication.. and an openness to radical- ism. This is very threatening for the central core of the typical task, role, club organisational culture. An Organisation with a cuture of existentialism has a much better chance of developing good projest on a regular basis but these Organisations are still a rarity. An old girl-friend of mine who is in a leading position in one of the Major Business Schools regularly seeks advice from me as to how to overcome the deluge of internal politics and methods that are stifling their practices, certainly a case of not practicing what they preach! In addition, Computer Science departments the world over are paying scant regard to People and Management issues as the Lecturers themselves are, in general, inept outside of the techno- logical framework. So perhaps it is inevitable that, with an inappropriate education and cultural backdrop, we can expect "death march" projects to con- tinue to be the norm... But looking at it from another perspective, these "death march" projects are the essential grist-for-the-mill for the few success stories that make the whole show worthwhile. David
This scenario is far more common in North America than it is in Western Europe or the Pacific Rim countries that I've visited. While companies all around the world have engaged in re-engineering projects, it's less common, outside North America, to see the "radical" re-engineering projects that eliminate large numbers of employees. And for the same reasons—cultural traditions, social policies, government regulations— there are fewer death march projects in these countries. The work force, especially in Western Europe, is far more likely to be shielded from excessive overtime, and is far more likely to adamantly refuse to give up sick days, vacation days, holidays, personal days, and other forms of time off. Whether this is a good thing or a bad thing is outside the scope of this book.
From: Rick Zahniser (SL), 70313,1325 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project Msg #158437, reply to #158015 Date: Fri, Jun 7, 1996, 10:57:25 PM Ed, >>why do they do it??<< I think they do it because, as Al, suggests, they think they're better than others who have tried. And, sometimes they really are! (That doesn't eliminate the death march. In fact, it probably pro- longs it.) I've told you before, I think everyone should be on at least one of these projects. However, there are some other things that you should do at least once: + Spend a night in jail. + Get commode-hugging drunk + Raise a boy + Raise a girl + Start your own business + Climb Mount Fuji (The Japanese have a saying: "He who fails to climb Fuji-san is a fool. He who climbs Fuji-san twice is an even greater fool.") One thing to do: Get a good manager, who is empowered to do the right things. One thing not to do: Kill yourself when the project goes south. Sr. ric
Science fiction aficionados will recognize the similarity between Zahniser's advice and the wonderful aphorism from Robert Heinlein in Time Enough for Love: the Lives of Lazarus Long (Ace Books, re-issue edition, 1994): "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
< Back
Page 6 of 6