Well, the conditional probability of your project succeeding given the information in the question - isn't good. However, it's far from impossible to succeed and there are different degrees of failure, and you probably have a fair amount of control over the degree of success.
In addition to the ever present risk that you just don't implement very well, you have to manage things that are probably bigger risks.
Developing without requirements is a really big risk. Do everything you can to find out the requirements. It doesn't have to be very formal necessarily, but get as much feedback as you can about what they want. Try to understand their goals, rather than only what they say they want, since you may at times have a better idea how to realize those goals than they do, and knowing their goals will help considerably in guessing when you have to guess.
Fail as quickly as possible. There will be times when you are wrong about what they want (or they will - sometimes what they asked for won't be what they want), so fail as cheaply as you can. A question is cheaper than a screen drawing, which is cheaper than a spec, which is cheaper than a prototype, which is cheaper than a fully implemented UI connected to a mock model, which is cheaper than a full implementation.
Do things in order of priority. When time suddenly starts running out on you it may be possible to get by having only 30% done if it's the right 30%. This probably means your pet features won't make it. Note that 30% of the features 100% done (tested, documented if documentation doesn't get tossed, build-able, deploy-able, etc.) might work, 100% of the features 30% done is a boondoggle. Finish all of each feature. If you are working with outside QA, documentation, marketting, whatever, get them in as soon as possible since that's effectively part of being 100% done.
Usually the actual development process isn't too hard to work out on a team of 3. It's working with everyone else that usually is tougher.
Sadly, one more thing I'd be remiss not to mention - cover yourself. Get what you can in writing, and when you have a verbal discussion send an email summarizing what you believe was agreed upon. You are going to be really busy trying to get this project done, and if it isn't a success and people start looking to hand out blame (hopefully your company doesn't do things this way), you won't have as much time to play politics as most of the other people involved.
Something more productive you can do to cover yourself is to set realistic expectations and try to keep everyone up to date on your progress. Don't try to hide problems. Give management the chance to change direction if things aren't going as planned.
That's a bit of a grab bag, but there are books written about this stuff. You could start reading some of them if you have time.