For all the talk about not wanting to do big bang redesigns, that's still pretty much what we all do. I'm a practical guy, and I've done my share of down-to-the-minute, global, big bang launches when they were necessary. But for now let's all agree that ongoing changes are preferable (another blog post will cover the advantages of ongoing changes). Why do we keep doing big redesigns?
The pursuit of the shiny
Some Big Thinker inside the organization or outside defines some shiny and immensely desirable vision for the new site, and this is often more an emotional appeal than anything else. But everyone knows this would mean a Big Change. There's no way around it! We're just going to roll up our sleeves and get it done. Now, often you'll be aiming for a castle with a moat but get a tee-pee with a puddle by the time you launch, but conceptually everyone desires this ambitious vision and throws themselves at the task (or perhaps over the cliff).
Incentives to plant flags
Let's face it: most everyone wants to Get It Done in order to claim victory. System integrators want to complete their statement of work, get paid, and slap another client logo on their site. VPs want to claim victory. Everyone just wants to move on from what's perceived as a painful task (which is more painful when big bang).
Ease of understanding
Anyone can look at the current site and see the problems. And everyone thinks they understand (again, at least emotionally) where they want to go. But even if they don't completely understand where you're headed, one thing is for sure: one day it will be like it is now, and another it will be improved. Nice and tidy to understand (again, at least it seems that way at the beginning).
Pent up demand
Often as a result of the Big Bang mentality, a website gets little attention in between redesigns. That means after the hacked-together system is no longer viable, there is such a pent up demand that it's hard to phase in changes. See Product Managing Your CMS: Defining the Work Program.
Hand-offs
Almost always, the approach goes something like this: 1) Tell us (tech team) what you (site owner) want. 2) We tell you what you'll get. 3) Find out midstream can't get there. 4) Deliver less than step 2. This is because the details of how to get there aren't thought about in design. But there mere thought that this hand-off occurs back and forth means that there's an incentive for these to happen less frequently. See Developers: Don't Miss the Opportunity and Focused Team Engagement and the Alternatives.
Need to demonstrate something
Sometimes what is needed is purely backend, like better content management. But sometimes organizations feel that more needs to be demonstrated, so before we know it the project is even more complex than it needs to be. See the new self-evaluation tool to help gauge the distance you are attempting to travel in your transformation (less distance is lower risk).
