I’m wrapping up one project and about to start another. For entirely unrelated reasons (cough!) I’ve updated my list of “Signs of a Bad Project”. I thought I’d share with the SDMB for helpful feedback. My current list follows, but please tell me your early signs that the project you’re on is bad, and it’s time to get a rock hammer and a bible and start tunneling out.
Too many meetings
Meetings too long
Too many status meetings
Too many status reports
Status reports not coordinated, e.g., Weekly, Biweekly, Monthly, Quarterly, Annual all due on same day
Project goals, strategies, tactics not communicated to everyone
No quality standards
Staff allowed to submit poor quality work
Too many review cycles on deliverables to make up for lack of quality assurance
People do not want to join the project
People do not want to stay on the project
People want to leave the project
People openly say they want to leave the project
People leave the project in large numbers, or key people leave
People say the project is bad
Leadership not addressing concerns raised by team members
Leadership does not communicate appropriate delineation of roles and responsibilities
Leadership enables poor performers
Lack of direct feedback
Slogans are more important than work
Leadership says one thing and does another
Leadership is not available to team members
Staff not being managed
I went through a bad project once, and one of the big warning signs was when the professional consultants held a meeting…and one of our people highjacked the meeting and asked very specific detailed questions…and the consultant didn’t say, “Whoa on that, we can do the little details later. For now, let’s sketch out the broad outlines.”
Instead, the consultant got right down there in the mud with our guy, and the entire three hour meeting got into tiny, painful, needless detail.
It was a scary foretaste of the cluster-muck that came to pass. And, no, it never got better. (The company is now out of business and the factory is shuttered. No joy in Mudville.)
The first sign of a bad project is no Risk Management Plan spelled out at the beginning. Because risks ARE there, and some of them ARE going to happen. Better to make your disaster plan before the house is on fire.
Blaming delays on stuff that happened months ago and shouldn’t have mattered. “We moved offices in September which is why we missed the March completion date by 4 months”
Leadership that knows one aspect of the task being worked on, but doesn’t understand how that one aspect works within our programs (see: Workplace rants the past few weeks from me).
Leadership schedules a meeting for the next day, not looking at calendars then rants during half the meeting why someone isn’t there.
Project members who mentally check out.
Project members who don’t say a damn thing during meetings, but then rant about decisions made.
The deadline vs burndown looks worse every day.
You know or strongly suspect the PM(s) is/are cooking the books on the progress reports.
Management is muttering about adding headcount to recover the timeline - Bad
Management is actually adding headcount to recover the timeline - Update your resume !!
Management is talking about mandatory uncompensated overtime to recover the timeline - Quit today.
To me, the #1 sign of a bad project is when there’s no clear guidance/plan/requirements from the get-go, or worse, they’re entirely ignored, and everyone wings it all the way through.
How about Action item lists filled with vague and uncompletable action items. What does “investigate” getting a new thing really mean? Draw up a business case for it? Look into costs? Start a whole new project??
For a year and a quarter I was working on a billion dollar disaster. There were plenty of specs and project management and quality control.
Definitely no one wanted to get on the project, and no one was allowed to transfer to another group. We had sabbaticals - people left the company right before their sabbatical, which shows how bad it was.
Not on the list was an unwillingness of the management to face reality. Everyone knew we were (another) three months late for weeks before it was admitted.
We had goals, which there were awards for meeting. One goal was to verify the high level design, another was to do detailed implementation of this design. The verification was late, and not working, but that didn’t stop the detailed design people from implementing a likely faulty high level design.
Yet another thing - a group which screwed up their section, and finally fixed it more than a month late got rewarded with a trip to Disneyland. Groups that did it right the first time got no rewards.
When I left after five quarters they had mad one quarter worth of progress.
There is no analysis to support the expected return of the project
No interim reviews of the assumptions supporting the expected return to see if they still hold
No understanding by the project team of the expected return of the project
No post audit of the project to determine if the expected return of the project was met
No learnings on how to better make assumptions about project economics so that bad projects aren’t repeated.
Basic project management deliverables are missing or mis-managed…
No scope defined. And when I say “defined”, I mean written down and approved by a manager or Director. Without everyone aligned on what the project is supposed to deliver, you are in trouble.
Missing or MIA project sponsor/owner. Someone needs to be accountable for the project’s deliverable, and that person needs to be highly engaged. If they are drifting in and out of activities, or not present, you are in trouble.
No plan. No road map for everyone to follow means you will be herding cats the whole way.
Oppressive project structure. As mentioned, too many meetings that overlap in scope mean each one adds less value, and takes people away from “doing” work toward the project goals. Too much oversight can also weigh-down a project team (overly complicated Change Control, for example).
Roles and Responsibilities are not defined (written down), so everyone is trying to do everything all the time.
How to get things back on track? Take time to define the scope of the project deliverable(s), ensure there is an owner of the project’s product that will have to live with it after the project ends, build-up a plan with the team (even if just high-level to start with - milestones, for example), and define what everyone is expected to do.
At the most basic level, successful projects provide just enough structure to deliver things in a predicable, drama-free environment.
At our company, you can tell a project is in trouble when the development team desperately tries to reclassify any bug reports as requests for new features (so that fixing them is Somebody Else’s Problem).
No clear project benefits (“why are we doing this? does it save money? does it make money? does anyone want these features? is it faster? is it more robust? even if everything goes perfectly, will we be better off at the end of the project than we are today?” “don’t know. no. no. no. no. no. no”)
The schedule is a fraction of any of the estimates of the people who are doing the work and significantly less than the last project of a similar size and scope
The schedule is realigned on a daily basis when no one hits the targets because they were unhittable.
PMs and project teams are incentivized to lie about status and rewarded when pseudo-milestones are hit.
Multiple hour long+ daily meetings with all of the same people in attendance
When critical, project derailing issues are identified early on, management pooh-pooh’s them away and presses forward without any real mitigation or resolution.