Our most important project

I've had a couple of experiences with introducing Agile on "our most important project", and they've been both a fascinating mix of a genuine desire to run the project differently (to avoid past problems) and the fear of introducing risks by changing the status quo. As Tom De Marco says in a lovely line in Peopleware: People don't like change. I'll say that again - people don't like change..
So what to do?
First let's take a moment to put ourselves in the project team's shoes, and appreciate how profoundly scary it can be to work on a high-profile project, with all the weight of expectation and oversight it entails. Because on top of all the existing pressure on people we're adding the burden of learning to do things in a different way (which may be overwhelming), and removing the comforting thought that "it's ok, we've done this before". On what basis can we be confident that this is the right team, the right project, and the right time to introduce change?
Second let's stop and think about ourselves a little. Do we have the support inside (and outside) the organisation that we need? Are we in the right state of mind to cope with actual or potential failure, and any nay-sayers who might try to shoot us down or the ideas we espouse? (An early "thanks, but no thanks" to the engagement may save a lot of pain later on...)
Assuming we believe that everyone is prepared for the challenge then I'd argue that the final thing to do is to seek out and connect with the positive drivers for change that already exist. Approaches such as Appreciative Inquiry should allow us to envision this project's future (Agile) success and tie it together with those past times when things have gone well. But if we can't, then perhaps that is the strongest possible signal that "our most important project" should be run in the same way as usual.