Since this is a software-related project there are several books available like the the ones referenced by @Tangurena and I recommend Business @ the Speed of Stupid by Dan Burke and Alan Morrison, too. Before making any major changes or having a heart-to-heart with management, I would do the following prep work:
- Update Current Status: Talk to the team and review where they are, what they are working on, and what they are all planning to do over the next few weeks. You really need this information on hand for any real future planning.
- Gap Analysis: Compare the information you received from the project sponsors and summarize all the things your are doing and all the things you are now aware of.
- Phasing or Chunking: Depending on the type of software system you are developing, there might be very clear functionality breaks were you can partial deploy a system (back end vs. front end, back-office vs. client facing, etc.) and you might be able to take advantage of that. Delivering partial functionality that works is better than delivering nothing and you need to have those points identified.
Hopefully, this research has given you a couple of ideas about how to proceed. Now, you need to find out what your management and the project sponsors think in the best thing to do.
- NOTE: Stopping the project should always be on the table. It might be the right decision.
This is not the time to have a meeting and say "You didn't tell us you wanted Feature X so we won't do it" and you'll kill any chance of success if you try to assign blame. I have had success with a "We've apparently had uneven communications in the past about what you wanted and we may have moved forward with misunderstandings but we want to clarify things now" attitude. Blame games, couldda-shouldda-wouldda, and if-only-we-knew conversations rarely fix projects.
Start the discussion with a status summary and then move to the gap analysis. That way everyone know where the team is, where the team is currently going, and what features will exist at the end. Then the actual discussions of scope/schedule/resources/goals can start from a common understanding. If you've found a good functionality break point, you can use that as phase-break to get the project back on track.
For example, you found that the back-end work was much cleaner and has fewer problems or missing features. You could try: "Since the client-facing section might change, why don't we concentrate on finishing the back-end and administration section? We can then re-evaluate the client-facing portion, clarify the requirements, and then start that portion of the project with a better plan?" You can then break the scope statement, schedule, and WBS into phases and restart the planning process for this section phase while the project team continues work on the other phase.
- As a side note, you are probably already at your maximum "burn rate" in terms of people assigned to the project. Make sure to keep them working on something beneficial while doing all of this assessment and planning.
Finally, been there, done that, at least a dozen times over - it's not all bad news. All I can say is that things probably will turn out better than you hope.