Time, budget and scope
Every project, whatever life cycle approach it uses, has to cope with the triple constraint of cost, time and scope. In your case time and scope are fixed. You say nothing about cost, but as you've inherited this project from your partner, I fear that there might be a fixed (or at least capped) cost as well.
The unexepcetd risks
These constraints can make project difficult and your life miserable. But constraints by themselves don't kill project. It's risks that kill projects : risks that were not taken into account when budget, schedule and scope were defined, or risks that occur and make the constraints unsuitable.
Following risks lead frequently to failure:
- risk of quality: If you find out at the end of a project that there was a fundamental misunderstanding about the requirements or the customer's expectations, the cost and time needed to correct such errors can lead to an expensive total failure!
- tunnel effect without feedback: If you enter in a longer activity, it might be like a tunnel: you might find out at its exit exit that you're in the wrong place and that the project was completely underestimated. The more time past in the tunnel, the higher the risk, and the unhappier the customer when you'll tell him the uncomfortable situation.
- self-fulfilling prophecy: with longer timeframes, there is a risk that tasks take all the planned time including margins that you've added in the schedule. For example people might take time to draft and redraft a perfect design document. But this precious time might lack in the end. In traditional project management, the critical chain (not path!) methodology could address this issue. But short time-boxed goals used in agile methods reduce such effects in a much more efficient way.
An agile approach is in my view the best approach to anticipate and master the biggest project risks. It allows to address uncertainty early, to get constant feedback and tangible progress, and to react as fast as possible in case of any issue.
So agile is not the problem, it's part of the solution.
Additional remarks (sum up of comments)
For your project at 70% of completion, I believe that techniques such as a precise and transparent backlog, frequent short terms objectives with a weekly iteration cycle, and daily short standups should help to keep focus and get back on track. And transparency about achievements and work to do could restore trust.
At this stage of progress, it's difficult to add many new resources. It might also be counterproductive to start to learn a fully new approach with completely new tools. Adopt the agile core principles with pragmatism.
Final remark: it would be worth to get an understanding of what would happen in event of late delivery: will the company fail some legal obligations and go bankrupt ? Will there be penalties ? And same for scope: among all your features/user stories, are there some that are less critical that could in worst case be delivered after the go-live of the core functions ? All these could be useful for negotiation and damage control if in the end it would be required.