Don't get into the situation where you have to have a team to do tool integration. Even worse is to have to outsource the same. If you have different groups picking their own management tools for the various functions, that's where you'll be headed. Instead, collect requirements and look around. You'll find that some do-all tools might not be the best in each function, but they're generally the best in some functions and have an added value of an integrated architecture. If traceability is important, integration is important.
Configuration Management Process
It pays to understand your process. Don't just throw existing tools in front of your team along with a handbook. Go through each part of your CM process. Ask yourself: Is this the way the user really wants to be doing this? The myth is that developers don't want tools and processes, as 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 and 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