a. Treat this project as if it were your sick child on life support.
b. Treat this project as if it were a gazelle being ripped apart by a pride of lions.
If you choose (a), do anything and everything you can to save it. Be open and sincere and stop at nothing.
If you choose (b), prepare a resume and run the other way. No sense risking your own well-being on a lost cause.
The worst thing to do would be to make any choice in between these two.
Unless you're in a tiny company that will literally go out of business if the project isn't complete, there is a valid middle ground: cover your ass to avoid blame, pitch to the PM to get the schedule extended, salvage as much as you can, and move on and do better next time.
In the meantime, take a better job if one turns up. But don't be lured into extreme action by magical thinking. If a failed project is inextricably linked to your personal well-being, you're in the wrong business.
Taking a better job is fine, but halfway a project it might kill the project when some of the top guys decide to leave. It might even be worse when the architect of the legacy-system decides to leave with knowledge of all the undocumented business rules.
It's so important, that a project is well managed, because a lot of the aspects of building something new are extremely satisfying to work on. However with mismanagement it's easy to demoralize the team.
Exactly. The world is pretty small and you shouldn't step on somebody's toes unless you absolutely don't see another way out.
The sensitive thing to do here, is to make sure you've got your ass covered and if this is a persisting problem or you feel like you can't work there anymore, then you quit after the current job is done. And hopefully you can leave with a good recommendation.
Like @angdis said elsewhere in this discussion, projects "fail" all the time, but the OP is talking about a specific kind of failure. Notice how many commenters mention "finger-pointing" and "paper trail". When you find yourself in a situation where that becomes important, it's time to consider leaving and it's always better to leave on your own terms.
Unless you're deeply invested in that project or that company, it's usually better to start looking for a place where projects fail more gracefully than this.
It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B".
"Team B" usually finds many deficiencies at work in the code. For instance, people frequently bungle the design of 10-table databases, so perhaps there are dragons in the 100s of tables.
"Team B" sometimes delivers the product, usually late. Sometimes it doesn't.
That's life. The Gartner Group says that 2/3 of all IT projects fail and I think that's about par for the course.
First: why is that? Are there good reasons for this, and does this happen for those reasons?
Now, knowing nothing about the company, if I learn that every other project suffer a change of team before going into maintenance (officially and actually), then it's substantial evidence that something is wrong with management.
Whether one should quit of course depends on how wrong.
To get high performance without burnout it is necessary to switch from complete engagement to complete disengagement every few hours.
The Serenity Prayer from Alcoholics Anonymous is asking for the right thing here, even if you aren't religious.
"God grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference."
It's great to be passionate but it's also important to be detached about things you can't control.
One detail that is missing from this story is the nature of the deadline. Lateness is endemic in software development, and successful projects often get delivered years after they were promised. Late doesn't necessarily mean "failed."
You can't go wrong learning more about project management so you can have a more correct understanding of the situation.
Whatever you do, keep your honor. Being ambiguous about wanting the job gives you the unique freedom to refuse any order that you truly don't want to carry out.
This is fantastic advice, and one of the main things I tried to drill into my team (when I had one), with fairly mixed success. It's very hard to convince people who are attached to a project that they should at any point just go "meh, what can you do?" but sometimes that really is your only option. Advice for any startups in this situation - if you really have to impose some awful condition on your workers, make sure you explain it fully to them. It's easier to accept something you don't like being imposed on you if you understand it, even though you don't agree with the reasoning.
Another really tricky fine line is, having done this a couple of times, to then stop people going "meh, screw it" when they really can control the outcome, but just don't feel like it for whatever reason.
The worst thing about staying to turn things around is that often the failure is set up from the beginning by those in leadership. Your reward for working your ass off to make the project succeed is probably going to be to make someone look good who was responsible for digging the hole that you helped to pull everything out of.
Unless the game board is set up so that you benefit heavily from your hard work (equity, bonuses rewarding the risk and effort) - there's little upside to killing yourself besides some opportunity for personal growth.
Even if one of us calls it right, which is sheer luck with so little information, the OP clearly has most to gain from experience.
That is the only way to learn to correctly identify problems, and perhaps more importantly, what is the best way to deal with for you personally.
But even assuming this, choice (b) is only local optimization. One could consider instead doing (c) - to try as hard as possible to convince the management to shut down that project ASAP, and thus saving the company many man-hours of wasted work. The global gain will be much greater then. Of course if management is stubborn and you're still sure the project will fail, then you're back to option (b).
The severity of the consequences determines what approach is best to take-- and there are many choice in-between working like a mad-man and dropping everything interviewing for a new position.
a.) If you're sure there's a path to success and you're invested in getting there, do whatever you can to achieve that goal--understanding that one of the possible outcomes is to be told to pack your things and leave. Now. The likelihood of this outcome obviously depends on the exact situation.
b.) Accept that things are not going to end well. Do your job, keep your head down, and start seeking alternatives ex post haste. In some situations, seeking alternatives ex post haste may, in fact, involve fleeing (especially in a short time horizon such as this one) but I've certainly been in situations where the writing was more or less on the wall but more in the vein of a long ponderous collapse.
Fresh gazelle is delicious. Try not to overeat. There's a whole heard, and the pride will catch another one tomorrow. It's all a matter of perspective.
I would disagree there.
A good manager might take the situation well - they may have been misinformed by others and think things are far better than they are.
If that isn't the case there may be the option of going above the managers head, though this has to be considered very carefully. In may case once it went rather well: the person above me had grossly misreported things above him. We are still dealing with some of the legacy of that period, but getting through it (and that person is no longer here). Of course depending on local politics this could go very badly, so I'll repeat: consider this sort of action very very carefully before taking the step.
In my case saying "things have been X bad for a while, if things don't change either we are going to fail badly very soon or I'm going to burn out inside a couple of months" got the message across (it turns out an honest assessment was appreciated and that not losing some of us through walk out or burn out was important enough to warrant rearranging some plans and expectations). Of course I'm lucky: the Powers That Be here are sensible and I've been here over a decade & proven myself a good few times over so my word carries some weight - a relative new-starter under a less receptive hierarchy would not fair so well.
If there really are no options for plan A for whatever reason, no end of time/overtime will fix the problem and there is no way the management can be made to appreciate the scale of the problem, that leaves plan B: get ready to jump ship.
That being said, decisions like reversing project directions or pivoting are usually huge multi-party decisions not up to a single person (unless it gets escalated to the very very top).
A politically savvy employee would be able to make it work. Albeit, after saving the project (or making an admirable effort that catches everyone's eye), that employee would probably be marked by management for a management role. ;)
You are the lion and the resources of the company are the gazelle. It's time to feast!
It's really a good time to:
1) ask for a raise for more "effort"
2) ask for more budget
3) that new computer they've been holding out on.
Ya, you can ditch that 17" laptop from 2006. ;) Just ask!
We know that throwing resources into the game this late doesn't work, but it's good to have that extra budget for later just in case you wildly do succeed.
IMHO the best thing to do is to express your concerns and from there on just do your job without investing any extra effort. You can't be reluctant cause this will be received as not caring, neither invest the extra effort because usually the reason projects fail is not incompetent programmers but wrong specifications. Let someone else take the blame.
On the other hand, it sounds like a depressing situation to be in, so I'd prefer your option (b).