CM: THE NEXT GENERATION - Evaluating and Selecting CM/ALM Tools

a non-issue.  If your tools require constant tuning, partitioning, recovery, or any other sort of administration, ask why.  You should be able to manage a couple hundred users with less than a full time administrator.  And you should be able to train your administrators in less than a day.  If not, you don't have a good Administration user interface for your tool suite, or else you have too many different administration user interfaces for the different functions (version control, change control, problem tracking, requirements management, etc.).

Customization to Corporate Processes: I know of one CM/ALM vendor that has everything pre-packaged and working very nicely - just don't ask for changes please.  Of course they're willing to provide them for a per diem fee - how many diems did you say that would take? Next generation customization of CM tools has a long way to go in the industry at large, with perhaps a couple of exceptions.  Don't look so much at how closely the tool fits your process.  Your process will change. Even if it doesn't, it will be different in another part of the organization.  Yes, good out-of-the-box process is an important criteria.  But easy to customize tools are even better - especially if you can use the same customization tools across the entire suite (and I don't mean a C compiler).  Customization of Process, Data Schema, Guidance, and User Interface.  If you want continuous improvement to meet your evolving agile processes, this is a key consideration.

Build Automation, Release and Deployment Management: The assets are in the repository, now I need to get them out.  I want to automate builds so that I can run them frequently.  In fact, I want all team members to be able to run them easily. I want to be able to deploy, not just to web sites or customer areas, but to my own testing and production machines, not to mention individual developer workstations so that they can do adequate "unit" testing of their changes (unit = change package here).  Managing builds, releases and deployments goes much further still.  I want to know what's the difference between what's currently deployed and what I'm about to replace it with - problems fixed, new features, how many changes, functional audit results, etc.

Establishing Contextual Views of CM/ALM Data: A local company I spoke with was doing 2500 builds nightly.  Not a big problem - it was all automated.  Now, one of the builds has a problem.  How do I zero in on the build?  How do I put myself in the context of the build so that I can rapidly ask - what's changed since the last successful build?  What high-risk problems were addressed?  What version of that file was used for deployment?  These are all context-specific questions.  The context may be a build, it may be the latest view of a product development stream, it may be a baseline or something more custom.  How easy does the CM/ALM tool let me select my context?  Does it help restrict my queries based on the context?  Does it figure out where I need to branch from?  Does it fill in the context sensitive portion of my forms and dialogues when I click an "add" button?  Does it automatically capture information so that I don't have to remember to label that data?

Be Not Afraid
Evaluating is a daunting task.  How many dozen tools are there?  And each vendor says it's tool is the best!  The first temptation is to stay away from anything that does more than I think I need.  Resist that temptation.  Especially