I've rarely had a task assigned to me that was well-defined enough to even know if I completed it. Usually there is good intentions, but the people above you just don't have time to dig into the details of what it is they think they are assigning to you. This also means that they can't really check up on you too well, either. The trick is to just dig in, do some research, do stuff (ideally stuff that genuinely needs doing, that you can accomplish, and is related to the "task" you have been given), and report on it confidently. Eventually people will consider you an expert on that issue/area and will defer to you about what needs to be done. Once you hit this point, you can make a list of "nice to haves" in this area, throw them on the backlog, and declare yourself done. If you're recognized as the main expert on that subject, it will be tough for people to argue with you.
I think the difference here is that a 'bad' project will often be very specific. You will have a very particular outcome that you must achieve to finish, and you know what it is. ("Migrate our database from NoSQL to a relational database!" etc.) But you don't actually have the skills to perform the task, or the support to even get started in the right direction. You don't even know what questions to ask, or who to ask them to. You're just ... lost.
It's also possible the project is simply too hard -- maybe doing it right would take an experienced engineer two years; but since that approach seems like obviously too much work, you flail around assuming there must be some alternative.
This is, sadly, pretty common for junior programmers and people who are new to a team.
