On the flipside, I owned a very large chunk of backend data testing, and while it would make no sense to have requirements documents when development started, I often found in the agile process that requirements documents still were not complete well into our testing deadlines. Since my department did a lot of reporting into statutory authorities, this was always a stressful time.
Ironically, a major problem at a previous company of mine was that sales guys would try to reclassify new feature requests (that they had promised to clients) as bug reports so the dev team could be compelled to “fix” them, thus bypassing the planning process. I.e. “I lied to the client to make the sale and get my commission, and now that lie is your obligation”.
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 have another one (or two) to add:
When your project managers are too hands on. Which is a nice way of saying they’re micromanagers. This morning I’m “enjoying” the two PMs I work for reviewing parts of a requirements document (because they can’t wait for the whole thing to be finished). They apparently changed their minds since they first dictated the solution for one part a few months ago and had us change something. Which leads to the second issue about methodology:
We’re waterfall. But they don’t like us having too much free time between releases, so while we wait for the scope of the next release to be decided on they have the developers start analyzing the change requests we think will be in it, and for the QA people to draft their test plans for same. Put another way, the way we do our releases is to do development and test plans first, followed by requirements and design documents second. Ass backward and no apologies given for any rework that results.
Kind of going back to the first paragraph, we’ve been going back and forth on the wording of a couple of requirements because they want them high level, leaving details for the designs… except when they want the details in the requirement. After every few emails back and forth they tell me to send them the updated requirements again, which means copy-pasting out of the requirements document and into an email reply. One of the revisions was because I corrected a line as per their wishes but I did not copy his exact wording and paste it into the document. It said what he wanted it to say but it was not his exact words, so I had to fix it.
We should have just done all this in a meeting and gotten it hashed out one time, but it took a certain level of tooth grinding for me to realize that. And it’s the freaking project managers who are causing this.
I just have zero patience for this crap anymore.
Better. If Excel is the only project planning tool. And anytime someone tries to edit, it says that the same person already has it open.
Project includes a specific date in the project name. Our development project just got a plus sign put at end of the name of the project, to indicate that it will not be completed this year.
Made me snort. LOL!
I found another one while cleaning out old papers: High turnover of project leaders. At one PTSD-inducing client, top leadership kept playing musical chairs with the leaders of individual projects. The old paper I found listed 4 high-turnover projects and the tenure of the various leaders. The average tenure over all 4 projects was under 5 months for each PM, before being replaced by the adminisphere. These were on-going projects. None of them finished while I was there, or even scheduled to switch from significant phases (e.g., from development into production into maintenance).
When the plant engineer overrides the project engineer to save money.
Where I work the plant engineer was given an award and promoted for how much the project cost under the initial estimate. He saved cost by change ordering controllers (PLCs?), relays, sensors, etc… to soon to be obsolete parts and the suppliers were more than happy to sell them to him.
6 years later the machine maintenance department is buying parts off of eBay to keep the line running.
TruCelt, I have seen that video, and been in that meeting IRL. 
I remember a thread about this video, but my search-fu is quite weak tonight.
#1. When management hand out ‘Project xxxx’ polo shirts.
Well, from what I’ve seen at my new job, here are some signs:
- Projects sold without clarifying scope, without even the input of sales engineers, or even the client having an understanding of how the product actually works
- SOW signed with resource requirements, budget and timelines not apparently based on anything
- Lack of clearly defined project management methodology (combination of agile and waterfall)
- No technical resources to work on the project
- Everyone working on the project has been with the company less than a couple of months
- Over-reliance on outside contractors
- Sales too involved in the day to day delivery of projects
- Head of Professional Services trying to oversee every single project
- Lack of any mechanism for the PM to get project financials
- Lot of “seagull managers” (swoop in randomly, shit on stuff, leave) involved
Complete micromanagement to the minute, including taking people off one section and putting them in another when the first section isn’t even done yet but they assume it will be done soon so no time is wasted “transitioning”.
I am keeping this one! Thanks!
Sounds like a recent “Star Trek Lower Decks” episode. 
ETA: So it’s truly universal.
There’s an old saying (mistakenly ascribed to Abe Lincoln most of the time):
“If I had six hours to cut down a tree, I’d spend the first hour putting together a backlog of all the strokes I think I’d need. Then after hold a backlog grooming session to assign each stroke “story points” of relative effort. The a sprint review to prioritize each stroke and assign them to 1 hour “sprints”. Then at each hour I’d hold a sprint review meeting to assess progress, then a retrospective to evaluate what we can do better going forward, adjusting our backlog taking into account velocity…”
Yeah, that’s definitely a Mark Twain quote.
In my company, we run out of budget and time halfway through the tree, so cutting the other half of the tree is re-scoped into Phase 2.
The key identifiers of bad projects in the business context I just left (these are doubtless only a tiny subset of the many reasons a project can fail):
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.
The project becomes a game of argument tennis between two or more stakeholders, who cannot agree, but expect the project manager to not only mediate, but adjudicate (and they all expect that decision to be made in their favour)
Thousands of tiny changes - basically scope creep, but an ongoing habit of it - people make decisions, then change them after work has begun, and nobody bothers to calculate the sum of all these changes, or figure out if they are now all intercompatible in their changed form
Untested assumptions - for example I’ve seen cases where everyone assumed that mains power would be available for installation of equipment, but nobody had specified it. Recognising that something even is an assumption is hard
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
This is much like writing a goal which requires a 10 pound project to be crammed into a five pound bag, and then calling it a “stretch goal.” I was on a project where just about every goal was a stretch goal. It was a billion dollar disaster. I got out before it really exploded.