When upper management/C-suite promises a delivery date to the external customer and then hires/assigns a project manager who then has to do his planning work and hire/assign the team. (By the time the business analysts had a grasp of the requirements, the project was months overdue.)
This one might just be a pet peeve of mine: When the project is going along mostly as it should and then you come to close to the go/no-go decision on whether to implement on the agreed delivery date and a high level (C-suite again) person starts proposiing alternative solutions. Like “have you considered…?” Hell yeah, we considered that and all the other options months ago when we started the project. Shut your gob and give us the decision.
Agree about the PTSD. Each of has lived every one of our suggestions and most of everyone else’s. It’s just after lunch here as I type but I feel the need for a good stiff drink coming on. (And no, it’s not a work day for me).
Oh, yeah… Ow… PTSD indeed! Grin! In my own cluster-muck example, we did have significant “mission creep” well into the later stages of the project. We’d already designed and started construction, and people would come in and start wanting to change where the bathrooms would be.
I am also having flashbacks, and I started this. :headdesk: More items:
Leadership blocks people from leaving the project (so they leave the company instead)
Micromanaging
Client or leadership thinks they are the best, when they aren’t, and no evidence can change their mind
Client is the only person who does something a certain way, and thinks the industry-standard way is stupid
Leadership does not want to hear bad news
You get a feeling of deja vu from other bad projects you’ve been on
Mistakes are punished, rather than dealt with
No succession plan for key people
Junior people are suppressed or only given scut work, and have no opportunities to advance
The Widening Gyre: The only constant is that directions and assignments change, and frequently
People have too little work to do
Teams run out of work before the contract ends
Time wasting all hands meetings
Leadership double booked (or worse!) for most meetings
Leadership on their phones during meetings
(The above 2 mean that said meetings accomplish nothing)
My old boss once fired a guy for not being in two places at the same time. She sent him off on a fact-finding mission, then called an all-hands mandatory-attendance meeting, and canned him for not being there. A true Dilbert day.
I got to the end of this sentence and suddenly 50 ways to leave your lover started playing in my head. But recast by Weird Al Yankovich as 50 ways to leave your project.
Perhaps we can defuse our collective PTSD by working up the lyrics right here?
Wow. This actually happened? YouTube response videos? I’m so sorry.
I did have one project lead call my team a bunch of haters. He had what was, in theory, a very good idea. But it relied on a bunch of assumptions that were mostly-to-entirely wrong, so it wouldn’t work at all.
When the team pointed out the assumptions were wrong (and then tried to brainstorm ways to make it kind of work with a drastically limited scope and lengthened timeline) he threw a tantrum, called us all a bunch of haters, and stormed out.
Management gave the go-ahead anyway. It took 6 times longer than originally planned to deliver anything at all (and never delivered everything promised), and pissed off a number of our partners and clients who had relied on it working in the timeline the lead had promised.
You just slip out the back, Jack Make a new plan, Stan You don’t need to be coy, Roy Just get yourself free Hop on the bus, Gus You don’t need to discuss much Just drop off the key, Lee And get yourself free
The, the lyrics aren’t helping.
Management throws project lead under the bus when the supplier denies sending an email with bad info in it. (I keep a copy of that email)
Management takes key workers and puts them on other smaller projects, and doesn’t replace them with anybody.
Somebody already mentioned management not listening to or ignoring input from project lead about what’s needed for success.
It’s a very common thing if you’re working on some YouTube or Internet related thing as part of a loosely connected group and the person in charge clearly has no idea how to properly manage a project.
You’ll know, if you avoid drinking the Kool Aid. You can tell when every review talks about making up the delay in the next quarter when everything will be fine.
One thing I noticed is that the Project Management software we used couldn’t handle the natural problems of a project of our type. We were designing something new - really new - and there were areas where we were guaranteed to screw something up and have to rework it. The examples in training were things like building a house or putting on a play.
Actually the latter example would have worked if the author, during rehearsals, totally rewrote Act II with new sets, five new roles which none of the cast were good for, and decided to bring in elephants.
That was pretty much how our project went.
@Voyager: Part of the reason traditional Project Management practices (as reflected in apps like Microsoft Project) are so effective at some sort of projects and so utterly ineffective at software dev is exactly as you say about your hardware dev project.
Traditional PM works when you both know exactly what to do and how to do it. You just need to track the details and optimize the sequencing and resource allocation.
In software ultimately the project won’t sit still long enough to be planned. It’s all in effect R&D beginning against against a partly known problem space with a barely understood solution space. Just like in true R&D the knowledge state has to just evolve. Which is what “Agile” development processes done right* attempts to capture.
It recognizes that planning beyond broad outlines is a fool’s errand and we just gotta learn as we build, build as we learn, and it’ll be done when the sponsor says “I’ve spent as much time/money as I’m willing to and I’ll settle for whatever we’ve got today as being good enough to release now.”
Followed immediately by continuing to work forward towards tomorrow’s release and the next and the next.
It also totally accepts that rewriting Act II isn’t a mistake to be avoided. It’s an inherent part of the process that must occur on the way to the goal state.
* Agile done wrong, though vastly more common, is simply a different way for management to pretend something is a process when it's simply a clusterf*** of CYA, incompetence, sloth, politics, and corruption.