Configuration Management VS Change Management - Who's in Control

On the one hand, Configuration Management has a wide range of definitions - on the other hand, Change Management covers a number of organizational functions.

Change Management

Consider Change Management, to start. I consider Change Management to be primarily a Product Management function. On the development side of things (i.e. ignoring the marketing functions), Product Management (PM) deals with the following:

• Identifying what constitutes a product family and its products
• Identifying what goes into each release of a product
• Prioritizing in the case of fixed budget and delivery dates
• Signing off on what goes into a product release

From this perspective, it is the Product Management team that has to manage changes to the product. It is the Development Team, including Project Management, which has to ensure that the changes are done within the priorities and constraints dictated by Product Management and orchestrated by Project Management.

Product Management defines the workload - Project Management deals with the workload.

Product Management is responsible for the requirements. Project Management may negotiate to ensure that the requirements are reasonable, but Product Management represents the customer and/or market which manages changes to the product definition. Close to release time, Product Management should also be involved in determining which problems are going to be fixed and which are not, because fixing problems have an inherent risk of destablizing a product and at some point the risk is unacceptable.

So, from my perspective, managing Change has to be done first and foremost at the Product level.

However, within the development team, there is another layer of change management, often refered to as change control. It's a crucial function, and ensures that change is controlled, and that there is traceability of changes to the requirements. From checkout policies, to change packaging and change dependencies. This aspect of change management is definitely part of CM (Configuration Management), at least in my books.

There is also an in-between layer of Change Management which, I would argue, rightly belongs under Project Management. That deals with which changes are going to go into which builds. It also deals with when the most risky changes should be applied to the product, how much change should be absorbed before full verification and/or regression testing, etc. This is part of Project Management. It deals with how we organize the workflow most effectively to complete the workload. Is this part of CM? Well, it certainly must be be supported by the Configuration Management tools and process.

OK - quick review. The three main areas of Change Management are:

• Product Management - what changes go into each release of the product.
• Project Management - controlling the flow of changes to maximize chances of successful delivery of each release, on time and within budget
• Change Control - ensuring that each change follows packaging, traceability and checkout guidelines.

Configuration Management

How do we define Configuration Management? Unfortunately this is not as easy - there isn't a hard and fast definition - or rather, there are a number of them.

Is CM part of Project Management? Well this largely depends on your definition of CM. For example, whether or not any delta compression is used on source files is not really a project management issue. I've been on large projects where the delta compression was slipped in one day to conserve disk space - no bearing on manageing the project.

Similarly, Project Management may identify when a baseline should be created, but should not deal with the CM function of creating it. I think this should always be an automated function based solely on change selection. Others have differing