Configuration Management Planning: What To Do Before you Start

really wants to be doing this.  The myth is that developers don't want tools and processes - they just get in the way.  The fact is that developers don't want tools and processes that just get in the way.  Most processes and tools get in the way a bit but provide just enough payback to convince developers to use them. 

Your processes and tools need to make sense.  If they're not adding value to the users, take another look.  It's not good enough to say: "we're a team, you're helping the downstream process by using  them".  A great number of them aren't interested in downstream process - which may be a separate problem.  Good tools and processes should benefit the users as well as the rest of the team.

Using change-based CM instead of file-based CM cuts down the number of steps the developer must take, and supports a simpler user interface.  But not if the "change" concept is just glued onto a file-based CM tool.  Change-centric CM tools manage change without having to keep revisions front-and-center. Similarly, an intelligent context-view mechanism helps to simplify things

Do your CM plans include the overloading of branches so that, besides parallel development, branches are used to track promotion states, releases, change packages, etc.  If so, try to drop the baggage.  Make sure your tools and processes deal with items such as branches, changes, builds/releases, baselines, etc. as first class objects on their own.  A set of labels does not convert a branch into a build definition.  Builds have a state flow all of their own, very different from branches.  The same goes for changes

And don't confuse a change with a feature.  Any number of changes could be required to implement a feature and any number of features might be implemented by a change (hopefully not though).  Similarly, you should have a process managing your 100s of features which is distinct from the process handling your 10s of 1000s of problem reports.  They are very different beasts.

Look carefully at the main trunk vs trunk per stream scenario.  Although a "main" trunk sounds simpler, it doesn't match reality and so is much more complex than a branch per  stream scenario.  Wrestle with this problem ahead of time - don't commit to one way only to find out too late you made a mistake. There are many CM issues that have to be addressed, and they have to be addressed objectively by looking at the way you expect things to happen.

Get your CM requirements down clearly.  It's not that you need a way to compare the features and problems fixed in one build to another.  It's that you need that at a touch of a button.  You can't be expected to make timely decisions if your information takes hours or days to come by.

I might challenge you to look back at some of the past CM journals to identify better ways of doing things.  This is generally quite different from the way most projects do it.  Do you want your CM costs to be 5% or 15% of your project costs - that's quite a difference  off your bottom line.

Customization
The most common high level requirement we found in our initial requirements gathering for building a CM tool was that the project needs to be able to customize it to their own processes. Not a problem for some solutions: they just throw in a compiler, a pencil and an eraser - voila, it's customizable, NOT!

Your process is going to change and evolve.  As you understand your business better.  As you go through mergers.  As you understand your development better.  Make sure it's  easy to change.  This is a precondition.  It doesn't have to have a voice recognition feature with artificial intelligence that converts your tools and processes to match your verbal requests.  But it does have to