Signs of a Bad Project

Yeah, definitely have that go-bag ready. The sooner you get out the better. When I got started in the biz I had the ups and downs everybody goes through, but life was much simpler in those days, taking twice as long to get the job done isn’t that bad if it only results in being a week late. So I had some experience to look back on when I faced projects measured in months and years. This thread is important, those signs have to be read, and you have to get out before the ship hits the iceberg.

I did learn from these things well, I built my business by being the Pro from Dover called in a couple of years later after the first attempt failed. And finding the solution was usually easy, it was one of the existing simpler plans rejected initially because it didn’t satisfy a long list of arbitrary requirements. And the item so often left off the list or checked off without critical thought was “It must work”. Once so much time and money has gone down the drain the list of requirements becomes much more concise and focused.

So that is something not so easy to reduce to a simple rule, it takes the ability to assess the situation in terms of a team’s productivity potential, and the actual scope of the goal. But you can still look for the common underlying characteristic of bad projects, an initial over-reach. Beware of people who wear telescopes for glasses and think the moon is just past the tips of their fingers.

The project manager makes a list of 25 ways to spot a bad project and posts it on a public forum…

Well, the last “bad” project I had about 2 years ago (which caused me to leave my firm) consisted of the following red flags:

  • Project plans, Gantt charts and risk registries had not been updated in over six months (which made it difficult for the PM AKA “me” to know what I was supposed to be managing to)
  • On my particular work streams, I was at at lest the sixth PM in that role in the past year.
  • When I joined the project, most of the immediate deadlines were mathematically impossible to meet. And yet no one seemed to notice or care.
  • The PMO was run by EY (Ernst & Young). Few projects are made better by hiring the Big-4 to work on them.
  • There appeared to be no consequences for the software vendor constantly missing deadlines.
  • Asking the PM (me) to simultaneously manage two (later 3) work streams simultaneously, each of which could use it’s own PM.

One particularly memorable meeting descended into a shouting match. We (NASA) held a teleconference with Rockwell over the layout of a control room we were co-designing. My deputy branch chief, who was running our end of the meeting, got all bent out of shape over their casual dimensions. He pointed to one console that was labeled, “4 feet” and tried to pin them down on a more exact measurement. Jim kept asking for an exact measurement and their guy just kept saying, “Jim, it’s 4 feet”.

Jim couldn’t take it anymore and began shouting, "Do you mean it’s 4 feet as in - bigger then 3 feet but less then 5 feet - or is it 48.0 inches? After one last, “It’s 4 feet” reply he jumped up, yelled, “This meeting is over!” and and slammed the main phone unit to the ground shattering it forever as we all stared in awe.

Great project.

If the rep at Rockwell genuinely didn’t understand the distinction and the significance thereof, perhaps they should hire engineers there rather than salesbeasts to communicate with their customer who’re all engineers.

There is nothing so frustrating in the world as dealing with a counterparty that not only doesn’t have answers to your questions, but cannot even comprehend the existence of the topic area of your questions.

My BP is up 10 points just typing this. Oooooom! Oooooom!

Ha! I’m not the PM. I’ve seen enough crash-and-burn that I’ve started a collection. My goal is to stay a worker bee, and not be responsible for the train wrecks. Which includes jumping off when I see the other train approaching on the same track. I want to learn how to spot the oncoming smoke in the distance.

I’m actually a software person, and this is very true. The last thing I did before I retired was a data collection system. The stuff I was collecting was new to us. I started by meeting with my users to collect requirements, and I quickly discovered that they didn’t know the requirements. I later found that the requirement they did know were wrong anyhow.
We had an IT department that thought about doing something similar. They never got started, and I was done before they would have written the requirements. Which would have been even wronger than mine, since they were not subject matter experts like I was.
First version was delivered on time and I kept improving it.It had bugs but I told them it was going to have bugs. It was a big hack and a lot of fun. And best of all, people used it all the time.

Another sign of a bad project: When a team member is asked how they are doing, and the reply is “Oh, it’s another day in paradise” or “I’m living the dream” or another ironic response.

“I’m dreaming of a life” was my stock response.

Now that I left administration, and am doing actual meaningful work, my life is better. But it’s hell twice a week when they drag me in on management conference calls to act as “senior director emeritus/institutional memory guy”.

I’m sorry, but that is hysterical, in both he “funny” and “nervous-breakdown” senses of the word. Any chance of a link?

“The problem is all inside your head”, he said to me
“The answer is easy if you take it logically.”
That’s when I knew I’d chew my leg off to be free
There must be fifty ways to leave your project

He said, “It’s really not my habit to intrude,
And I have no understanding of the tech work that you do,
But I’ll repeat myself, until you chuck your food
I’ll never just let you complete your project.
Let’s have a meeting ‘bout your project.”

You’ll get a neat plaque, Jack
I’ll change the game plan, Stan
Nothin’ I can’t destroy, Roy
Just watch the scope creep
Buff your resume up, Gus
You don’t need to discuss much
Just burn your ID, Lee
And get yourself free

Ooh, don’t take any flack, Jack
Dodge that middleman, Stan
Life will hold no joy, Roy
‘til you get yourself free.
Overclock your bus, Gus
You don’t need to discuss much
Turn in your ID, Lee
And get yourself free

He said, “it grieves me so to see you in the weeds
So I’ll assign a pack of interns who can sit and watch you bleed”
I said, “I appreciate that, but could you please get me
the GFE?”

He said, “I had a long talk with our client yesterday
And it turns out what I told you wasted the last thirteen days”
But we’ll make it, if “we” work through the Holidays
They’re re-competing our project.
Give up sleep to save the project.

Just never come back, Jack
Make a transition plan, Stan
Go find new employ, Roy
And get yourself free
They’ll throw you under the bus, Gus
You don’t need to discuss much
Don’t be the stuckee, Lee
Just get yourself free

Beautiful! That’s a keeper!

You might be on a bad project if a traffic light monitoring system is in place, and every light is green.

Scratch that, you’re definitely on a bad project if that’s the case.

That whole thing is beyond fantastic. It’s inspired!

A big tip o’ the LSL-IT-Guy propeller beanie to you good Sir!!

I remembered another one in a trauma flashback: Multiple things are all Priority One!!! Nothing gets dropped from the Priority One!!! list, but things get added. And no guidance on which items might be more Priority One!! than others, or whether any Priority One!!! items from yesterday can be dropped, or from five minutes ago.

You know you’re on a bad project when the job shoppers are leaving.

I agree. Those sorts of guidelines are the useful component of software development models like CMM, the Capability Maturity Model out of Carnegie Mellon (now superseded by something called CMMI). CMM/CMMI are very much a double-edged sword: used properly, it can be very beneficial in its intended role of providing project management checklists and basic methodologies, including documentation templates, that provide for reproducible software quality and incremental improvements. But when abused by PHBs (ignorant Pointy-Haired Bosses out of Dilbert land) it can become a liability of train-wreck proportions. The two biggest risks I’ve seen of falling for CMM as a panacea rather than useful guidance is (a) the rise of a mythical pseudo-religion which holds that software quality can be achieved entirely through a robust methodology and that the skill, creativity, and motivations of software developers are irrelevant (“there are no heroes in software development” is the main ethos of PHBs), and (b) its inappropriate application to smaller projects where it merely becomes a bureaucratic hindrance, and more time is spent in meetings and churning out documents than in actual useful work.

That’s sometimes the case, sometimes not. Ideally project requirements will be well defined and relatively stable and have senior management buy-in. But there are many situations like you describe where this just isn’t possible, and then “agile” development, or RAD (“Rapid Application Development”) techniques might apply. I’ve found prototyping to be particularly useful in those situations. In one case, a client was looking for what was essentially an AI system to front-end and integrate mainframe databases, to create an integrated holistic view of a particular customer’s financial history. No one really knew what this should look like except in terms of the most general principles.

This was an ideal environment for prototyping. We used Visual Basic to create an entire simulated UI that went through a large number of iterations while management and the front-line users figured out what they really wanted. Only when this was well defined did we start working on real code to actually implement the model, with the approved and signed-off UI as the core of the requirements.

Agree wholeheartedly with your post entire. As to this …

The danger I saw the few times we went down that “sketch the outputs” process was that very quickly the outputs grew to something that could not, as a matter of data science, be created from the inputs.

In one memorable example they wanted a complicated pivot-table like thing on 10 different category variables, but had only captured 4 of those categories in the underlying data. When we proposed adding the 6 other categories to the input forms so the data would be there to filter on, the answer was “No, that makes data input too complicated.”

And The. BizIdjits. Could. Not. See. The. Disconnect.

Ultimately, just like civil law only constrains the basically honest, Dev/IT process only constrains the basically intellectually honest and fundamentally capable organizations. If you lack those ingredients, it’s anarchy. Just a different form of anarchy.

Based on my current experience with my new job, the worse sign of a “Bad Project” is that there are two of them at the same time.

Oh yeah. I worked one place where even the developers were assigned to 3 - 5 projects simultaneously. They were in meetings 6 hours/day right along with us business analysts and project managers. That place was completely out of control. One reason it’s an ex company.

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.