CM: THE NEXT GENERATION: Configuration Management Planning

Requirements Change Management.  How and when are requirements allowed to change?  Does the development team work to a requirements baseline until the release is out the door and then work on changes, or are your requirements incrementally modified throughout the design and implementation cycles?  There are differing opinions on what the best practice is here, but your CM Plan should allow the flexibility required for your Product Road Map(s). What tools and methods are you using to track change requests and changes to the requirement baseline?  What level of traceability is required - do the tools support this - do your processes support this?  Who approves changes (e.g. the customer or the market representative) and what is the formal procedure for establishing a "contract" with the development team?

Requirements Allocation and Project Management
The next area of your CM Plan has to deal with how Requirements and Requirement Changes get mapped onto Development Team Tasks.  Presumably the development team is working towards the next release.  Some requirements are targeted for that release, while others are targeted for later releases.  The requirements management tools should be able to help you to sort this out.

Whether you allocate Customer Requirements to Product Requirements to Design Requirements, or create functional specification tasks which map back to the Customer Requirements and which specify the Product functionalty, and then design tasks which map back to the functional specifications, is mostly just a matter of terminology (important terminology though).  The key difference in these approaches is usually centred around the tools.  One tool set may deal with requirements, and not with tasks, while another may deal with both requirements and tasks.  In the former case, a separate project management tool is necessary to manage your tasks.  In the latter case, it's integrated.  I prefer the latter because Customer Requirements are not fully under the Product Team's control.  Product and Design Requirements are, subject to satifying the Customer Requirements.  As such, you need different tools: customer requirement management, vs. product development tools.  The allocated "requirements" map directly to tasks that have to be tracked, scheduled, prioritized, etc.

Regardless, features will get assigned to development managers who in turn identify the tasks required to complete the feature.  Development managers also need to prioritize and assign these tasks to minimize impact on resources while also minimizing the risk to schedule and to quality.  You have to make sure, through all of this, that traceability is maintained.

How do these tasks map to Source Changes
A task may be easy for one developer to complete in a short time frame, or may require extensive work over a longer period of time.  The developer should be able to take the "feature tasks" and map them onto one or more change packages, or updates as we'll refer to them, which will be used to complete the task.  Sometimes more than one update is required to ensure a smooth upgrade path.  Sometimes the more risky parts are required earlier in the process to allow time to absorb the risk.  Sometimes part of the task has to be completed by a different developer.  In these scenarios, multiple updates may be required to complete a task.  All should be traceable to the task and should specify any dependencies upon related updates.  Does the developer have the flexibility to decide upon update packaging, or is this a directive from the line manager?  Your CM Plan needs to clearly specify these capabilities or you may risk ending up with processes and or tools that are inadequate.

Working with Change Packages/Updates
Your tools need to support change-based operations