Configuration Management Planning: What To Do Before you Start

support your processes and allow them to evolve.  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.

Multiple Sites

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 function of the common repository instead of on a  function by function basis will give you fewer worries.

And then there's the question: what is multiple site management?  Do I split up branches by site?  What about projects, problems, requirements?  There's the distributed data solution, and then there's the replicated data solution.  There's also a distributed access to central data solution.  Look at these carefully.  Make sure that you don't have to put sensitive data on a contractor's site.  Make sure that you can deal with all of the ITAR Data Segregation requirements you need to.

We've looked at some of the details and it's obvious that process and tools are a very key component of your CM planning. That means you need to do your research up front.  You don't have to do tool evaluation or selection.  You don't have to decide on CMM or RUP.   You just have to know what's available.  What technology is available, how aggressive
can you make your objectives.  You might have to decide between a high capacity truck and a fast car, but you might find that there are next generation solutions that give you the best of both.  IT progress is too rapid to assume that last decades's solutions are more or less the same today.  Would you look at last year's medical progress if you needed a cure today?  Spend time to get informed.

Visit CM Crossroads forums and get feedback on today's thinking.  Agile wasn't
here yesterday, now its all over the map.  If you don't have time, bring in some experts to help you.  When you plan for CM, you're not just doing another feature, you're building corporate backbone.

A Word on Databases
It's a no-brainer to go with a Relational DBMS for your CM/ALM solution, right?  There's no other standard.  Well, I know of at least a couple of other solutions that deserve consideration.  The problem with a pure relational solution is that it does not match the real world.  In the real world of CM and ALM there are hierarchical constructs: WBS, Source Tree, Org Chart, Requirements Tree, to name a few. 

There is a need to have one record point to an arbitrary number of other records:  requirement allocation, reasons for a change, files modified by a change, include