CM: THE NEXT GENERATION of Quality in your Configuration

artificial dates for starting and ending a stream's tenure in the main branch.  It also
requires three different processes for dealing with a development stream: before, during and after it's tenure as the main branch.  Stream-based main branches are simpler - one main branch per stream means the process for that stream is always the same and there are no artificial "start" and "end" dates.  This in turn leads to easier automation of the CM process.

Nightly Build Automation.  
If your process and/or tool does not allow you to fully automate your nightly (or other) builds, they could use some refinement. What's going into the build, what tools are being used, where are the results being placed and who's being notified on errors/completion. Your tools and processes should allow this to be fully automated.  Perhaps "what's
going into the build" is most difficult.  Some simplify by using "whatever's submitted to the repository".  This is dangerous as it requests users not to submit completed code into the repository if they don't want it going into the build.  A change promotion model works
better - all changes at a given promotion level or higher go into the build for that promotion level.  You may have builds at various promotion levels.  If your tool permits and your project is very large, you may even perform incremental builds automatically.  If you can't do automatic nightly builds, take another look at your CM process and data/tools.

This is a partial list, but a good starting point for introducing quality into your configuration management process.

What Else

The difference between levels 4 and 5 of the Capability Maturity Model (from the Software Engineering Institute at Carnegie Melon University) is that a level 5 process is continually optimizing itself.  If you want to achieve that level, you need tools that permit you to optimize your process.  The easier it is to optimize, the faster you'll move along the Quality curve.  There are three things to look for to support your process optimization efforts:
 
(1) Easy to customize the solution.  Whatever solution you select for CM, it must be easy to
customize to meet your needs.  You have a process in mind because of your requirements.  If the tools can't support that process, you'll either never get there or you'll spend a significant portion of your time either doing things manually or building your own tools.  Neither is recommended.  Make sure your CM solution is easy to customize to
your needs.

(2) Easy to incrementally add customizations.  This is not a lot different from the previous one, but the fact is, your needs are going to change.  Not only that, but you might want to start using your new solution before it's fully customized to meet all of your current requirements.  In both cases, you'll need to customize your solution incrementally.  Ideally, you can create a customization, apply it, and roll it back if it creates unwanted side-effects.  If you have to take your user base off line when you do a customization, you'll either be working a lot of late hours, or reduce your customization flexibility.  On top of that, consider the case where you have your process and tools replicated over multiple sites.  Ideally
you can make a change to all sites at the same time.  Better yet, you can use your CM tool as the repository for your customizations so that when a change is made, it is replicated at all of the sites.

(3) Integration of Data and User Interface.  Customization of process is going to be very difficult if your CM data is scattered among several repositories and/or if your user interface is different for each part of the process.  Yes the buttons and actions are going to be different, but if you need different tool-level expertise to customize each of the different management areas, you'll have a