Notes:
There are a lot of aspects to change management, and I seem to have been involved in addressing all of them.
As details of how the system will integrate into the organisation there are always isssues that arise. Many of these will lie outside the scope originally envisaged. Some mechansim needs to be in place to manage the changes: it would be unrealistic to pretend that they don't happen (or to insist that they are the customer's problem).
Beyond ensuring that scope changes were dealt with intentionally I've not achieved much here: any propagation of the changes into requirements and design has been done on an ad-hoc basis.
Requirements too can change, either because the scope has changed, or more commonly, because understanding something new illuminates a defect in what has been done before. The way in which requirements are expressed can also change as a result of the design process – which often identifies dependencies that are not otherwise apparent.
It is uncommon for design work to be postponed until the requirements capture process has been completed. (And such a postponement leads to difficulty validating the requirements process.)
Anyway, if design has commenced before they change then both scope changes and requirements changes can lead to changes to the design. Also, the design process itself frequently leads to changes.
Similarly, changes to scope, requirements or design may require changes to the code.
The propogation of these changes is also being done without structured procedures. (The projects are small enough that individuals can trace these changes through.)
I gave some details of how software version control was managed last year, and this has been formalised by a paper on my website (http://www.octopull.co.uk/VCS/) which describes a number pf patterns of using CVS to support the development process.
One thing that was left outstanding at the end of last year's presentation was the management of database changed. This has now been addressed by the writing of a utility that exceutes SQL scripts to update the database and a policy of writing all changes to the database as additional scripts to amend the existing structure. (I am going to write this up sometime – honest!)