The requirement for devs to communicate with each other before checking in diffs scripts is the fundamental problem in the process and what makes it resource intensive and prone to error.  It also leads to the exponential problem I referred to in my earlier post - as the number of developers in the team increases the amount of communication required increases expontentially.  This means that either more time and resource needs to be allocated to the process or, as is more often the case, time and resources are not made available and shortcuts are taken to hit deadlines.

Consider the scenario where you have a team of 10 developers working remotely or across several time zones and this becomes nearly impossible to do reliably. 

The main problem with your approach is that it doesn't use the source control system to control the order of changes and prevent multiple updates to the same database object.  As the changes are hidden inside the myriad diff scripts that the developers create every check-in works fine and you don't encounter any problems until (if you're lucky) the scripts are run against the QA environment or (if you're unlucky) during the testing phase itself or (if you're extremely unlucky) in the live system.

Finally, yes, my company sells a product (that can be found by typing "database change management" into any search engine ) but that doesn't invalidate what I am saying.  I was hoping that this topic might bring out some processes that were beyond what we vendors are hawking and so I was slightly disappointed to see a description of a process that I have seen many times before and has some fundamental problems in deadline driven projects.