functions so that the same process behavior is common to all fuctions, simplifying the learning curve.
Change-Based Configuration Management: If your CM tools don't support change packages, or, almost equally bad, make you use a separate tool (from your version control tool) to define and manage changes, you're practically living in the dark ages. Developers don't create file revisions - that's not natural. They make changes: fix a bug, add a feature, clean up the architecture, etc. If you have to check in 10 files (oops, I forgot one), or do 10 delta/difference operations, or promote 10 different files, or figure out how to merge the changes made to 10 files to a different release - you don't have to wonder why your developers don't like CM. On the other hand, if your developers can scan 20 change descriptions rather than 100 different file revisions, they'll find the CM tool helpful. If your CM managers are managing file revisions in their baselines instead of promoting or rolling back changes, you'd better hope they don't change jobs or go on vacation.
Workspace Management: You have file in your directories. How out-of-date are they? How do they get re-synchonized with the latest development? Are there new files missing from my workspace? Are any of these files checked out by someone else? Which files are R/O and which are R/W? How can I compare my workspace contents with the build that went out last week? The answers should be one click away, or better yet, visually apparent though active workspace functionality.
Rapid Tool Deployment, Data Loading, Evaluation: Some tool vendors are great. They'll come in, do a demo, install their software (maybe even on their own machine that they'll lend you), load in some of your data, and help you through the evaluation, pointing out some key benefits of their solutions. Others will say: it's 5 minutes to download and install. We can do a live web-based demo at your convenience and repeat it for those who can't be present. Click the "load software" button to capture your existing data and the "load problems" button to capture your existing problem reports. Use the Quick Start guide to run through the evaluation on your own data, and at your own pace - our support team is ready to help at any time. I get concerned when the vendor has to come in to do the dirty work. I think: consulting costs, high administration, complexity. If I do it all quickly myself I say: "I get this!"
Reliability, Availability and Disaster Recovery: Your CM/ALM repository is not a developer tool. It is a product team tool, and perhaps even a customer accessed tool. Down time is costly and does not make for a good impression. The inability to access data will preclude you from some potential customers. And what happens to the business should disaster strike, even if it's just a disk crash - sure you can recover from backups... just more down time. This should not be an issue today. CM/ALM apps are serving hundreds of users who need continuous access to the data. Disaster recovery needs to be on warm-standby, not days away. And remember, the weakest link in one ALM function can bring down the whole suite.
Low Administration: How big did you say your CM admin team was? Times $avg-salary? That's expensive. What happens if half of them are off with the flu? Or if a couple of them get hired by a new company? With next generation administration, as demonstrated by a handful of tools today, CM administration should be