# Signs of a Bad Project **URL:** \ **Category:** In My Humble Opinion\ **Created:** [August 2, 2020, 9:44pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113 "2020-08-02T21:44:33Z")\ **Posts on this page:** 20\ **Page:** 5
**Author:** ![Mangetout](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/mangetout/32/19_2.png) [@Mangetout](https://boards.straightdope.com/u/Mangetout)\ **Post date:** [November 26, 2020, 9:51pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/82 "2020-11-26T21:51:55Z")
Yeah, I had it on a project where there was a series of actions in a critical path - and those actions all had very finite timescales that could not be compressed (for example, a test shipment of a parcel, which takes as long as it takes to get there - no way to shave time off it). We got to a point in the project where there was no more contingency left, and it was inevitable that we would fail to meet the target, even though that target was still a couple of weeks away. The right thing to do would have been to admit that the project was in exception and look for opportunities to replan the delivery - this would have been unwelcome news to the customers, but it could have been done. Instead, the guy at the top just says “Well, try harder!” and continues promising the customer that we will deliver on time. Of course, we didn’t deliver on time - it was inevitable. The customer was furious. Fingers pointed all over the place and my early warning that the project was in trouble was remembered as pessimism and negativity, which must have been the reason why it failed. ---
**Author:** ![carrps](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/carrps/32/2957_2.png) [@carrps](https://boards.straightdope.com/u/carrps)\ **Post date:** [November 26, 2020, 11:06pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/83 "2020-11-26T23:06:56Z")
Man, this thread is giving me nightmare flashbacks. I’m soooooo glad I’m retired. I was on “The Project from Hell” back in the 90s. It was so called for two reasons. One, the obvious. Two, because an incompetent manager had been implementing a corporate benefit program incorrectly for years. The company would be subject to millions of dollars in fines if it was discovered before the entire thing was corrected and all the programs re-coded. It was a deep dark secret. The corporate lawyer kept thinking it would take 2 or 3 months. For me, alone. It ended up taking two years. We had at least 8 analysts/coders cycle through, and they brought in Arthur Andersen to manage. I still have PTSD. Oh, and one item to add to the list: if anyone with any power is involved and is an upper management “pet.” ---
**Author:** ![Asuka](https://avatars.discourse-cdn.com/v4/letter/a/dec6dc/32.png) [@Asuka](https://boards.straightdope.com/u/Asuka)\ **Post date:** [November 26, 2020, 11:24pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/84 "2020-11-26T23:24:36Z")
When you’re called in to work on a holiday to “catch-up” then arrive at work to find that IT, maintenance, and other building services were never called in so you spend the first 2 hours of your day having to boot and set-up everything yourself wasting everyone’s time. ---
**Author:** ![amarinth](https://avatars.discourse-cdn.com/v4/letter/a/3be4f8/32.png) [@amarinth](https://boards.straightdope.com/u/amarinth)\ **Post date:** [November 27, 2020, 2:10am UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/85 "2020-11-27T02:10:41Z")
> [@Mangetout](#): > > **Hope, as a Strategy** - for example when a previously recognised milestone has been overrun and the work expected to be complete at that point has not begun - when there is not enough time and resource to feasibly finish on time, but that end delivery time is still a fair way off, it can be really difficult to convince people that the project is off track - there is a tendency for people just to hope and assume it can be clawed back, even when it definitely can’t Hold it, you’re telling me that “hope” isn’t supposed to be my project strategy and risk mitigation plan? huh. TIL. For a large number of projects that I’ve been handed, that really was the only option left by the time I got there. > [@carrps](#): > > Oh, and one item to add to the list: if anyone with any power is involved and is an upper management “pet.” How could I have forgotten this one. Double if that “pet” is an idiot. ---
**Author:** ![BippityBoppityBoo](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/bippityboppityboo/32/5745_2.png) [@BippityBoppityBoo](https://boards.straightdope.com/u/BippityBoppityBoo)\ **Post date:** [November 27, 2020, 2:23am UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/86 "2020-11-27T02:23:15Z")
> [@amarinth](#): > > Double if that “pet” is an idiot. Triple it if the idiot is also a relative. ---
**Author:** ![LSLGuy](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/lslguy/32/5813_2.png) [@LSLGuy](https://boards.straightdope.com/u/LSLGuy)\ **Post date:** [November 27, 2020, 12:39pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/87 "2020-11-27T12:39:31Z")
> [@amarinth](#): > > Double if that “pet” is an idiot. But you repeat yourself. ---
**Author:** ![carrps](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/carrps/32/2957_2.png) [@carrps](https://boards.straightdope.com/u/carrps)\ **Post date:** [November 27, 2020, 4:35pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/88 "2020-11-27T16:35:28Z")
Yeppers. ---
**Author:** ![msmith537](https://avatars.discourse-cdn.com/v4/letter/m/d9b06d/32.png) [@msmith537](https://boards.straightdope.com/u/msmith537)\ **Post date:** [November 28, 2020, 10:30pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/89 "2020-11-28T22:30:09Z")
> [@JcWoman](#): > > Another screwy thing I’ve seen is when someone high up decides that “We Shall Use $methodology” (either Agile or Waterfall, I’ve seen it both ways) but then at the same time requires processes that go against that chosen methodology. Like one place that said “We Are Agile” but insisted on having approved and finalized requirements before development started. Well, on my current project, my client insists “We Are Agile”. So in their mind, they can provide the necessary requirements “just in time” for the next 2 week sprint. My company is basically “iterative waterfall with Agile window dressing”. For all our “agile” talk, it’s basically just the same old phased “initiate, requirements, design, build, QA, UAT, production release” with Jira boards and demos and status updates every 2 weeks. Anyhow it’s fun trying to run both methodologies at the same time. ---
**Author:** ![LSLGuy](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/lslguy/32/5813_2.png) [@LSLGuy](https://boards.straightdope.com/u/LSLGuy)\ **Post date:** [November 29, 2020, 12:14pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/90 "2020-11-29T12:14:26Z")
> [@msmith537](#): > > … > they can provide the necessary requirements “just in time” for the next 2 week sprint. > … If those are fully fleshed requirements this has some hope of working, albeit at the expense of your sanity. It sure seems to be the way a lot of modern IT is run. IOW “Big waterfall scary; 1000 tiny waterfalls safe.” OTOH, if what they deliver JIT for the next sprint is vague notions about possible user stories, use cases, feature-ish brainstorms, … well you’re not getting much done in _that_ sprint. Except maybe fixing some leftover debt from the last one. Assuming that’s allowed. ---
**Author:** ![Morgyn](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/morgyn/32/3041_2.png) [@Morgyn](https://boards.straightdope.com/u/Morgyn)\ **Post date:** [November 30, 2020, 3:11am UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/91 "2020-11-30T03:11:57Z")
> [@leahcim](#): > > I.e. “I lied to the client to make the sale and get my commission, and now that lie is your obligation”. > [@LSLGuy](#): > > It’s amazing to think how different the world would be if sales commissions were based on the end-to-end profitability of the deal, not the sticker price of the deal. I’ve worked at more than one company where the sales team over-promised, leading to a lot of (unpaid) overtime for the developers. The company I’m working at now is putting a stop to it. Salespeople have been told not to over-promise, they’ll be trained on what our products actually do so that they don’t over-promise, and if they over-promise anyway, the product managers (who control development) can tell them “no” and the sales person gets to explain why the new shiny stuff they promised a customer won’t happen. I have a small hope this will work. The question is whether the new CEO can enforce this on people who have been accustomed to the _ad hoc_ processes since founding. ---
**Author:** ![LSLGuy](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/lslguy/32/5813_2.png) [@LSLGuy](https://boards.straightdope.com/u/LSLGuy)\ **Post date:** [November 30, 2020, 12:38pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/92 "2020-11-30T12:38:51Z")
> [@Morgyn](#): > > new CEO IME if the CEO was/is a salesman, the effort will fail for lack of follow-through against the predictable resistance. If the CEO hails from another tradition, be that finance, ops, engineering, logistics, etc., there’s a decent hope of success. ---
**Author:** ![snowthx](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/snowthx/32/10660_2.png) [@snowthx](https://boards.straightdope.com/u/snowthx)\ **Post date:** [November 30, 2020, 7:23pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/93 "2020-11-30T19:23:44Z")
> [@Mangetout](#): > > **The project manager starts doing some of the supply tasks within the project** ; that is, a project manager whose explicit role is defined as managing projects, rolls up sleeves and starts writing code or designing user interfaces, or testing things. Totally agree on this one. If the project manager becomes the “doer” for anything related to delivery of the project, and especially critical path items, the project is in major trouble. This is one thing I tell young PMs to watch-out for and not be pressured into doing. A PM should never be a “doer” on a project; their role is to organize the work and work structure, manage expectations and communicate, manage risks and changes. ---
**Author:** ![msmith537](https://avatars.discourse-cdn.com/v4/letter/m/d9b06d/32.png) [@msmith537](https://boards.straightdope.com/u/msmith537)\ **Post date:** [December 1, 2020, 7:23pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/94 "2020-12-01T19:23:08Z")
> [@LSLGuy](#): > > If those are fully fleshed requirements this has some hope of working, albeit at the expense of your sanity. It sure seems to be the way a lot of modern IT is run. IOW “Big waterfall scary; 1000 tiny waterfalls safe.” Nope. We actually stopped the project because the client hasn’t made the necessary business decisions to even have fleshed-out requirements. In their mind, we would have the team build some software, then they would iterate on what they liked and what they wanted to change. I mean we can do that if you have infinite budget for all the rework. Also, they seemed to think that our product was a packaged CRM software like SAP or whatever instead of a custom development platform. I kept getting questions like "what are the standard “fields” or “what’s a typical configuration”. There is no “typical”. It’s basically whatever you want to build with it. ---
**Author:** ![msmith537](https://avatars.discourse-cdn.com/v4/letter/m/d9b06d/32.png) [@msmith537](https://boards.straightdope.com/u/msmith537)\ **Post date:** [December 1, 2020, 7:32pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/95 "2020-12-01T19:32:51Z")
> [@Morgyn](#): > > > [@leahcim](#): > > > > I.e. “I lied to the client to make the sale and get my commission, and now that lie is your obligation”. > > > [@LSLGuy](#): > > > > It’s amazing to think how different the world would be if sales commissions were based on the end-to-end profitability of the deal, not the sticker price of the deal. > > I’ve worked at more than one company where the sales team over-promised, leading to a lot of (unpaid) overtime for the developers. > > The company I’m working at now is putting a stop to it. Salespeople have been told not to over-promise, they’ll be trained on what our products actually do so that they don’t over-promise, and if they over-promise anyway, the product managers (who control development) can tell them “no” and the sales person gets to explain why the new shiny stuff they promised a customer won’t happen. > > I have a small hope this will work. The question is whether the new CEO can enforce this on people who have been accustomed to the _ad hoc_ processes since founding. It won’t. At the end of the day, salespeople are “coin operated” as my last boss used to say. They will do whatever is required to meet their numbers and drive revenue. What the salespeople will “explain” is that the client wants to give the company money and product management is not letting that happen. So the pressure will be to have development / engineering work longer hours, work weekends, add new product features, whatever it takes. Or the PM gets beaten up every time he/she has to deliver bad news. ---
**Author:** ![LSLGuy](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/lslguy/32/5813_2.png) [@LSLGuy](https://boards.straightdope.com/u/LSLGuy)\ **Post date:** [December 1, 2020, 7:51pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/96 "2020-12-01T19:51:52Z")
> [@msmith537](#): > > Also, they seemed to think that our product was a packaged CRM software like SAP or whatever instead of a custom development platform. I kept getting questions like "what are the standard “fields” or “what’s a typical configuration”. There is no “typical”. It’s basically whatever you want to build with it. That’s some world-class failure to understand what they bought. Said another way: They were sold something very unlike what your employer actually had available to sell. Sounds like your sales force at this outfit is as bad or worse than the sales force at your prior outfit. The key thing on fixing the culture as @Morgyn hopes is that > [@msmith537](#): > > …They will do whatever is required to meet their numbers and drive revenue… Needs to have “numbers” be denominated in profit, not revenue. Mr. CEO needs to say: I don’t need you to drive _revenue_. I need you to drive _profit_. That’s what I value and that’s the only thing your commission will be based on. In that milieu, they can be as coin-operated as ever but instead of being a force vandalizing their own employer, they’ll be a force for success. It can be done. But usually only from a greenfield; it’s not an easy transition to make. ---
**Author:** ![Voyager](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/voyager/32/133_2.png) [@Voyager](https://boards.straightdope.com/u/Voyager)\ **Post date:** [December 1, 2020, 8:08pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/97 "2020-12-01T20:08:33Z")
> [@msmith537](#): > > Nope. We actually stopped the project because the client hasn’t made the necessary business decisions to even have fleshed-out requirements. In their mind, we would have the team build some software, then they would iterate on what they liked and what they wanted to change. I mean we can do that if you have infinite budget for all the rework. On the other hand, if the client doesn’t know what they want, some scaffolding might help them make up their minds. The alternative is to force them to write requirements which are 90% likely to be wrong. For my last project - which was successful - I had some requirements meetings and soon discovered that since this was the first time they were doing this job, they were not able to give me requirements even close to precisely. I architected the software to expect changes. And got them. It helped that I was also a subject matter expert. Even so, stuff that I would have bet my car on being true turned out not to be. It might be nice if requirements in requirements documents came with a probability of this requirement being right. Not that you could trust what the client wrote, though. ---
**Author:** ![leahcim](https://avatars.discourse-cdn.com/v4/letter/l/b4bc9f/32.png) [@leahcim](https://boards.straightdope.com/u/leahcim)\ **Post date:** [December 1, 2020, 9:03pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/98 "2020-12-01T21:03:16Z")
> [@Voyager](#): > > On the other hand, if the client doesn’t know what they want, some scaffolding might help them make up their minds. The alternative is to force them to write requirements which are 90% likely to be wrong. In my early career, I learned that for a certain type of client, the best development strategy was to make an empty GUI as the very first thing, with no backing functionality at all. Because “what do you want to appear on your screen?” and “what buttons should you be able to press?” get a lot more concrete answers than, “what do you need your software to do?”. Only once the GUI was iterated through to something acceptable, do we try to figure out what the actual requirements needed to be to make that GUI work. ---
**Author:** ![LSLGuy](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/lslguy/32/5813_2.png) [@LSLGuy](https://boards.straightdope.com/u/LSLGuy)\ **Post date:** [December 1, 2020, 9:10pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/99 "2020-12-01T21:10:41Z")
> [@leahcim](#): > > the best development strategy was to make an empty GUI as the very first thing, with no backing functionality at all. Because “what do you want to appear on your screen?” and “what buttons should you be able to press?” get a lot more concrete answers than, “what do you need your software to do?”. > > Only once the GUI was iterated through to something acceptable, do we try to figure out what the actual requirements needed to be to make that GUI work. Amen Brother @leahcim! Preach it! We used this stuff: > **[Balsamiq Wireframes - Industry Standard Low-Fidelity Wireframing Software |...](https://balsamiq.com/wireframes/)** > > Balsamiq Wireframes is the industry standard quick and easy low-fidelity UI wireframing tool. It makes work fun! Because real quickly we learned that if we used actual HTML or WinForms or whatever for requirement gathering mockups, our own sales force would assume it was a finished functional product and sell it to somebody else next week for delivery next month without telling us. :smack: This stuff, particularly in the older iteration we had back then, is obviously cartoonish enough our BA’s denials that it really worked was usually taken at face value. By both the customer and the salescritters. ---
**Author:** ![leahcim](https://avatars.discourse-cdn.com/v4/letter/l/b4bc9f/32.png) [@leahcim](https://boards.straightdope.com/u/leahcim)\ **Post date:** [December 1, 2020, 10:33pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/100 "2020-12-01T22:33:09Z")
> [@LSLGuy](#): > > Amen Brother @leahcim! Preach it! > > We used this stuff: > > [Balsamiq Wireframes - Industry Standard Low-Fidelity Wireframing Software | Balsamiq](https://balsamiq.com/wireframes/) I remember Balsamiq coming out a year into my career, and me complaining that they were on to my “vapourware first” strategy. ---
**Author:** ![Voyager](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/voyager/32/133_2.png) [@Voyager](https://boards.straightdope.com/u/Voyager)\ **Post date:** [December 1, 2020, 10:54pm UTC](https://boards.straightdope.com/t/signs-of-a-bad-project/917113/101 "2020-12-01T22:54:50Z")
> [@leahcim](#): > > Only once the GUI was iterated through to something acceptable, do we try to figure out what the actual requirements needed to be to make that GUI work. Exactly. I also discovered that the typical user thinks that it is hard to implement really easy features, and easy to implement very hard features which they won’t even use half the time. EDA software (electronic design automation) comes with a GUI, which as far as I know is only used during trade show demos or classes. Real users use the command line, usually embedded in a Perl or Python script. I wonder how much development effort was devoted to something no one ever used. [Previous page](https://boards.straightdope.com/t/signs-of-a-bad-project/917113.md?page=4)