CM: THE NEXT GENERATION: Configuration Management Planning

If you're planning a CM project, it's time to put together a CM Plan.  A CM Plan can take on many forms and the CM Crossroads site is a great place to investigate what goes into a plan.   In this article I'm going to concentrate on a number of areas that need to be addressed in your plan in order to follow some SCM Best Practices.

What's Your Product Road Map
You may be putting together a CM Plan for a project, or for an entire organization.  One of the first things you need to do is to consider which products (including process products) are going to be managed under your CM Plan.  Then you need to look at  the products and for each identify the product road map.  If you're creating software for a one-time event, such as the display controller for the celebration of a new millenium, you may only have one release of the software to worry about. Your product road map will be a straight line targeted towards the millenium celebration. 

But most software will have an ongoing sequence of major releases, with perhaps some milestone releases in-between. A product road map for something like Microsoft's Windows OS might look something like the one below, with the dotted line representing "today":

This roadmap, which will grow over time, gives an important framework to the product team. This is an important step. 

You'll want to identify the expected release lifetime, from a support perspective.  You'll likely want to address your methodology (Agile with iterative customer involvement vs. Releases with feedback loops for acceptance and for next release requests).   How often are you going to have releases?  All of these questions should be answered to help frame the context of your CM Plan.  And they should be examined across all products to which your CM Plan is going to apply.  In other words, your CM Plan has to set the parameters for its valid use.

Requirements Management
Requirements are an integral part of CM.  For software, proof of satisfying the requirements forms the basis of your Functional Configuration Audit (FCA).  So just as important is your Test Suite Management, but will address that later.

If you're starting a project, or even continuing one that wasn't managed well, make sure you know where your requirements are coming from.  If you have an Agile process, your requirements may start off as customer requirements and be converted into product requirements over a series of iterations with feedback.  Perhaps your design team has all the expertise necessary to get the first release out, or perhaps your requirements are dependant primarily upon the competition (e.g. It has to do X,Y,Z and do everything the current market leader does).  Some of your requirements may come from industry standards.  You need to identify your valid sources of input and have a mechanism in place to capture such input.

Your Requirements should form a hierarchy for each product.  Products may share portions of the hierarchy, you have to have a root point under which you can collect requirements so that you may identify what your entire set of requirements are and ensure reasonable completeness.  Identifying the correct set of requirements is perhaps a bit off topic here, but, you do need to manage this set so that you can assess it for completeness, correctness, etc.  How detailed each requirement is may be a project decision, but your CM Plan must specify sufficient detail of management so that a Requirements Traceability Matrix, and an FCA are both within your grasp.

Equally important to collecting your requirements is