|
Home | Login | Recent Changes | Search | All Pages | Help
BadSmellsInProjectsSee also: RescuingProjects I just came across (again) Jerry's article in Contract Pro on recognizing a project in trouble. Good set of clues to look for. EstherDerby 030202 The article was originally published in CP July/Aug 1999. (Perhaps it will show up on the articles page....) Esther 030602 And would you happen to have the clues handy? I seem to have misplaced that article. DonGray 030302 Maybe I'll contribute it to the AYE Articles on our website. - JerryWeinberg 03/03/02 An interesting spin on this would be recognizing projects in trouble - while interviewing. I'm currently helping Johanna on the Hiring book she's writing, and the other side of the coin might be interesting, too. This is kind of like the old Spy Vs. Spy in MAD Magazine. MAD Magazine has always been one of my inspirations when nothing else works. Great jiggles. BobLee 03/06/02 1) description of scope and/or schedule change dramatically in the time between first interview and second interview, especially when interviews are less than one week apart. 2) hiring manager seems unaware that the rapid change in scope / schedule is a warning sign. 3) hiring manager says some varaint of "We should have started this a month ago." Especially when the response to "Will the delivery date be moved to account for the late start?" is a blank stare. 4) hiring manager rushes in to the interview 15 minutes late... especially when it's because he/she was handling a crisis. 5) one or more staff memebers interupt the interview because of various problems. 5) senior managers interupt the interveiw a) to deal with a crisis b) because they have a habit of interupting others 6) hiring managers beeper goes off (increase size of red flag by an factor of 2 for each separate beep) 7) hiring manager takes phone calls (desk or cell phone) during the interview 8) hiring manager stays on the phone to solve some crisis after #7 9) hiring manager uses phrases like "just make it happen," or "failure is not an option," or "he's the best we could get" (in the tone of an appology). 10) you are being interviewed to take over a project mid-stream Ok, that's it for my list before breakfast. I'll come up with others after my second cup of coffee. -Maybe these are the ones you can recognize even in your sleep:-) EstherDerby 030702 11) you are being interviewed for the project manager position. the interview is scheduled after normal working hours on Tuesday and they want you to start Wednesday morning. (Thanks to Bob King for this one) a) Or interviewed as architect, EstherDerby 032502 A random thought, I'm a tester whose job is finding and reporting problems. For my tests "complete success is not an option". :) MikeMelendez 020307 Thank you, Esther - you've described the boss I had in 1998 when I simply voted with my feet. He loved all those red flag perks! Sometimes I think it's the sanest thing I ever did. BobLee 03/07/02 Ask each of your prospective teammates to draw a diagram of the system. If each draws a different picture, with themselves in the center, take that as a Very Big Hint. I missed that clue early in my career, and the resulting experience fueled my desire to learn to lead projects, if only to avoid ever finding myself in the same mess again. --DaveSmith 3/9/02 I had lunch with a friend of mine the other day... she'd recently started a new contract managing a project for a local company. Well, she thought it was managing a project. Turns out they expect her to manage three projects, one of which is quite far from its desired state. At one point she said, "A person would only work for this company if they were clueless or desparate." Well, I know she's not clueless, so she must have been desparate. As an indpendent in an economy that doesn't quite seem recovered, I can sympathize with feeling the pressure to take a far-less-than-ideal job. I took a whacky assignment a few years ago becuase my bank account was dwindling faster than I could stomach. So even if we can smell the bad smells, we may take the gig anyway becuase we are fearful of ________________ (fill in the blank). What are the fears that push you to take a job that smells bad, or is not a good fit? What strategies have you used to keep desparation at bay? EstherDerby 033102 I've caved in to "Emperor's New Clothes" fear at least once. I got talked into a Death March that way -- "It's just a minor change this version..." [It was an 85% rewrite, estimated as a 20% change.] It would have been seen as disloyal not to help out. I did a lot of thinking during and after that one. BobLee 3/31/02 Bob, can you tell me more about the "Emperor's New Clothes" fear? Were you afraid that your perception of the project was wrong? EstherDerby 040102 I was tech lead on Legent's ENDEVOR/WS (workstation - ie: fancy name for a PC) a conversion port of the ENDEVOR/MVS configuration management system. The existing mainframe system was extremely rich in functionality: it had an SVC exit that captured all include members as actually read by compilers and linkage editor, so we were able to record and compare compile-time delta of software subcomponents. Porting ENDEVOR/MVS to the PC in 1989 meant some serious shoehorning and some serious assumption analysis. If you recall the history of PCs at that time, the commercial world was DOS, OS/2 and if you wanted low-end GUI, Windows 2.0 [ugh!] We had to pick the features that made sense, and drop many of the rest. We were developing a common source core for DOS, OS/2 and Win 2.0. I signed on to do the portability infrastructure - file system calls, operating system feature calls, B-Trieve interfaces, etc. We had to retrain a lot of mainframers in that source lines aren't 80-characters with 8 sequence numbers in columns 73-80. Then we had to show them that PCs supported empty lines as "merely" CR/LF. That didn't make transmission between MVS and PC pretty. Then there were the ASCII - EBCDIC wars. If you've never been there, you're lucky. The fundamental syntax characters in the C and Pascal languages didn't all map neatly to 3270 terminal keyboard characters: curley braces, brackets, backslashes and logical-or '|' were pretty ugly viewed from a mainframe terminal. Well, we pruned and weeded and came up with a cut-down design. When we got it all coded, we ran into the DOS 640K limit. We folded and fixed and pruned again. Then we discovered that network drivers ate us out of that stuff, too. I remember getting my file system tooling built, ready to test, loading it with the debugger and discovering 45k of memory left! The DOS version had to be built with Phar Lap's DOS Extender to exploit over a megabyte. I had to wrap our DOS B-Trieve access with Bob's own version of "Thunks" (anyone remember 16-bit / 32-bit "thunking"?) Got that working. OS/2 was already exploiting big memory (phew!), but Windows 2.0 was killing us. Win 2.0 was fully 16-bit and wouldn't cope with "Large-model" applications - you were supposed to fit into under 64k or you wouldn't load right... We were saved when Win 3.0 came out - just as we had exhausted the bag of tricks. I learned a lot that I don't want to repeat. I don't believe that ENDEVOR/WS sold many copies - probably not enough to break even. But it got wierder in the next version. One of my peers on ENDEVOR/WS 5.2 (never call a first round 1.0) had some ideas for enhancement - some his own, some from the field. The Legent management promoted him to Project Mgr. and said "Make it so, Mr. Bohnert!" I was in the hospital with an appendectomy when this got rolling, but when I got out, the Emperor's new clothes were in full scale development. Scope creep was rampant. We were going to further port to UNIX workstations, [to earn the "WS"?] and everybody knows how uniform UNIX are. To help with the port, a cadre of ex-Cadre developers [original developer of Clear-case, Requisite-Pro, etc.] were brought on board. They had literally zero concept of IBM mainframe development, of our co-existence with mainframes being our only legitimate selling point, nor it turns out with "mere" PCs under DOS, OS/2 or Windoze. Since they arrived early, new PM decided to have them perform the requirements analysis for the ENDEVOR/WS 6.0 "upgrade". 85% of the 5.2 code base was altered, the look & feel changed radically, the processing got 4 times slower and similarity to our bread-and-butter mainframe ENDEVOR/MVS evaporated. Gold plating and scope creep ate calendar and 2.5 years into a 9 month estimate, we knew we were in serious Death March. Estimated completion moved out 1 month each elapsed calendar month - we were spinning our wheels. We had to completely overhaul the zany scope creep, hold to features and play Death March for 5 more months to get a releasable but crappy release out. We immediately began planning a performance clean-up, but I was burned out. It took me a year to climb back into productive state of mind. 3 years to produce something to be ashamed of really rankled. Nobody wanted to point out the Emperor's new clothes for 2.5 years, and everybody fell into that "I've got so much invested, I'll just finish it." fallacy. Good money after bad because the project leader hadn't learned to say, "No." BobLee 4/1/02 [I'm just another April Fool.] Well, it's frustrating isn't it and very human. Elisabeth Hendrickson wrote a nice article "Going Down With the Ship" for stickyminds.com http://www.stickyminds.com/sitewide.asp?function=WEEKLYCOLUMN&ObjectId;=3282&ObjectType;=ARTCOL Inabiltly to say No, hear "bad" news and over-investment isn't unique to the software world (nor to our century). EstherDerby 040302 Elisabeth's article was fun. We're not all crazy, we're wired that way. People incapable of optimism die out in evolution - why reproduce? BobLee 4/3/02 Many projects are undertaken in a swell of optimism and enthusiasm. This devolves into management pep rallies and exhortations to "think out side the box," "be creative," and have a "positive mental attitude!" Then comes the call for "can do attitude" and finally cries that "failure is not an option." Some percentage of projects actually do produce something under these conditions, though I think the human cost is often too high. EstherDerby 040602 Even worse that swell of optimism projects are CMM Level 2 swell of process, duty and commitment projects that get to the same place even uglier. I think the common denominator is lack of balance - Aikido management stance. BobLee 4/6/02 Can someone figure out a way to put smells on this wiki? I can put pictures, but I think this smell discussion would go better if we could scratch and sniff our screens. - JerryWeinberg 2002.05.21 Jerry, I tried to scradch add sniff, bud I dink I god a code. - BobLee 2002.05.22 SteveSmith on 2005.04.11 wrote in OnEnterpriseSoftware: "I have experienced products whose authors consider them technical masterpieces." That is certainly indicative of a project smell. CharlesAdams 2005.04.11 A related smell is when key people draw different diagrams of the system, each with themselves in the middle. --DaveSmith 2005.04.12 Ow! That hurts. I may not be much, but I am all I think about. Another smell is when organizational diagrams do not conform to reality. It is interesting to put together a chart of the true connections within an organization. -- CharlesAdams 2005.04.13 I've seen projects where there's no diagram of the system at all, never mind with different people in the middle. -- JohannaRothman 2005.04.13 Wow, were you on those projects, too, Johanna? :) On one such, quite a large integration, I diagrammed how all the systems fit together, because I needed a picture to understand how to test. Since it was the only one anyone ever saw, my diagram became the project standard. Some time later I thought, oh well, what the hell, and drew the diagram of what I thought the next release should look like. My client loved it! It's pretty funny when the test manager becomes the "architect". -- FionaCharles 13-Apr-2005 Fiona, what is wrong with the test manager being the architect? At least you have a perspective of the end user in sight unlike me when I was only interested in developing software. I have a naive view on software. I believe that anyone working in the field should have the opportunity to work in every area of software development. Having experience in QA, CM, Test, onsite customer support, project definition, project wrap up, as well as what a lot of developers consider the juicy stuff gave me enough humilification to remind me that I am not the all powerful Oz. I am one of the little guys behind the curtain. -- CharlesAdams 2005.04.14 Diagrams also reduce ambiguity due to overload words. My current project has drivers, another driver, ports, and connectors. These are all software components related to passing information. My original ascii art diagram has been visio-ed, expanded and placed on the support wiki. --DonGray 2005.04.14 Charles, in principle I agree with you. But in practice on this project, there should have been someone whose day job it was to be the architect -- partly as a matter of focus, partly training and experience. I'm not qualified to architect a solution, and although it was fun to take a crack at it, the project needed a pro. Also, I already had a demanding job. I had no issues documenting the existing solution graphically, though, and the diagram highlighted some integration problems that could and should have been found earlier. It's one way to do an architecture walkthrough! --FionaCharles 14-Apr-2005 Fiona, agreed. You last statement is wonderful! -- CharlesAdams Perhaps the worst smell in a project is the odor of people defending themselves and blaming others to divert blame from themselves, rather than just getting to work and solving the problems as they come up. As soon as a critical number of people start doing that, the project smell is so bad that the only thing to do is bury it. Reminds me of a few years ago when a group in England tried to make the Guinness Book with the world's largest meat pie. It was BIG, but it went bad before they could eat it. They had to bring in a bulldozer to bury it. - JerryWeinberg 2005.04.17
Updated: Monday, April 18, 2005 |
