This looks like it's going to be a very good series of articles.  I'm always looking for ways to improve how we manage database change.  We are a small team, with myself (DBA and actually lead developer too), and 2 other developers.  We maintain 3 separate environments (Development, Beta and Production). 

Currently I am the only person responsible for any database changes - schema, stored procedures  and permissions.  I've implemented a fairly manual approach, but I use Visual Studio.NET with a database project to manage "groups" of changes.  VS.NET also will do some automatic scripting of schema changes, but you are on your own as far as stored procedure change scripts are concerned.  The drawback is that all "rollout" status of each DB project, as well as any interdependency between projects (project B requires project A be rolled out first) is all completely manual, and I track it all in an Excel spreadsheet for now.

This system is effective for our needs now, but as the team grows, I'm sure we will need to make some changes.