Along those lines, ones you have a decent Continuous Delivery system in place, this shouldn't be as much of a problem. You have your downstream environment(s) that are exact copies of your production ones, gen up the change script(s) using your automated tools, then just hand them off to the team doing the changes in Prod. They should have sufficient permissions to do the changes needed and ideally you have at least one downstream environment that's a duplicate of your production environment so the testing and notes about other pieces of the equation can be handled. We've been using the VS2010 DB Projects to store and push our changes and are pretty close to having the ability to just build/deploy all the way up the chain.

As for complete rebuilds, ideally the project hasn't changed too much along the way and/or you've done the appropriate research before starting that you have a pretty good idea of where this is going in the long run so total redesigns aren't needed. 🙂 If not then you have a lot of other problems to deal with in data conversions, rollbacks, new structures, and all sorts of other things. It's necessary sometimes, but it can often be avoided with some good discussions and planning up front. (not to the waterfall point, but enough where you've got a good enough design for most of the objects)