You are planning to commit to a fixed price contract to "evolve" something with little or no requirements stability? Fixed price + uncertain requirements are a bad combination. This should be a danger sign and no, agile is not some silver bullet that is going to magically make this problem easier for you in 2011. The whole project is risky - adding a commitment to "switch to agile" doesn't make it much worse than it already is. Sorry.
Not sure what your customer expectations are, but take a look at the Agile Manifesto. If you think that your future project might benefit by shifting focus from the items on the right, to the items on the left, perhaps some agile practices can help you.
From your question, it sounds as if no one on the project team has any experience with agile development and you don't plan to pay for training. Another danger sign. You need at least coach or a mentor - a person who really understands the process model you are trying to implement. If you send one of your own people to get this kind of training, you have the advantage of having a mentor with excellent understanding of your organizations needs and constraints. You may still benefit from outside consultants as home-grown mentors can have less objectivity than a consultant.
Rather than switching to agile (or not) because it someone on this page says you should (or not), I suggest you examine closely the problems you experienced last year and create strategies to eliminate or minimize them. For example:
- How was planning, budgeting and providing other estimates troublesome?
- Did the project deliver on time and on budget? Did you have a budget?
- Can you say that you know exactly how many hours of effort it took to accomplish the project?
- Do you know exactly how many requirements you started with and how many you ended up with?
- How many requirements were implemented? How many deferred?
Consider a reflection workshop or a retrospective. Do this regardless of whether you accept your fixed price job or not. Sounds like you have something to learn from a past project that was harder on the team than you would have liked.