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.
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.”
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.
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.
How could I have forgotten this one. Double if that “pet” is an idiot.
Triple it if the idiot is also a relative.
But you repeat yourself.
Yeppers.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
Amen Brother @leahcim! Preach it!
We used this stuff:
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.
I remember Balsamiq coming out a year into my career, and me complaining that they were on to my “vapourware first” strategy.
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.