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.
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. No!
Your process is going to change and evolve as you understand your business better, go through mergers, and 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. It does, however, have to support your processes and allow them to evolve in terms of data, user interface, rules, triggers, permissions, roles. Don't settle for: we'll figure out how to change it later. You want to avoid the mess of configuring an unconfigurable tool. You don't want to become the tool supplier, just the process supplier.
If you have to learn some tools in order to create new user interfaces, etc., so be it. If you don't, even better. Most tools will allow some level of customization through an "administrative" GUI, while leaving the rest to your compiler, pencil and eraser. Find out what capabilities lie on what side of this fence. And beware of the open-ended questions such as: Can you do automated approvals? The answer is yes. Find out instead, how much effort is it to do automated approvals, or even better: show me how this is done. If it's a 5 minute thing, great! If it's a 5 month thing, not so great.
Another area of danger is multiple site management. There is often a tendency to look at a version control tool that can support multiple sites and say, OK, well if we use that tool our problems are solved. Not so. Multiple site management means management of file versions, problem reports, requirements, customer tracking data, documents, project management tasks, etc. across multiple sites. If you've got multiple tools doing the separate functions, expect this to be a major issue unless they all have a common architecture for multiple site management. A single integrated tool that supports the multiple site management as a