Changes: The Crossroads Between Project CM and Product CM

you to track several products in a single repository. This allows easier code sharing and administration among other things. But the fact that multiple products are being managed in a single repository means activities, defects, requirements, files, changes, etc. all must be identified with the product to which they belong.

With multiple products, your context (or view) of the repository would typically be restricted based on the product context setting. So if your product context indicated MyProd, you would want to see only problem reports assigned to you for that product. If your tool has the capability, you would be able to select multiple products into your context to see all problems in any of those products. A typical scenario would be when one product is built on top of other products (e.g. third party products). In this case, the CM tool should support a product/sub-product hierarchy. Some systems can be quite complex to navigate and a clearly visible product/sub-product hierarchy is essential.

In a product/sub-product scenario, you will have users that wish to make changes to sub-product files from the view of the product, while others will want to change the same files from the view of the sub-product. The CM tool would need the ability to map these different views onto the user's workspace. Some shops will have two or more separate products sharing the same sub-products. It would be helpful if it could opitonally prevent changes from spanning products. If the tool supports automatic baseline generation from changes, it could also support an option to do so in the product proper only, or right through the sub-product hierarchy as well.

At the Crossroads - Change Management

Ideally, a Change (aka Change Package, aka Update) is the focal point that brings Project CM and Product CM together. Products are modified through changes. Project activities are implemented through the same changes. Defect corrections are made through the same changes. As such, changes provide the traceability links between your project plan and your product implementation.

Please note the distinction here between a change request and a change. The former belongs in the realm of requirements or product feedback. The latter reflects activity currently in progress or completed which has addressed an activity spawned from requirements or product defects.

The change is the point of convergence. On one side of the change (i.e. before it is defined) is the planning and specification data. On the other side is the set of modified configuration items. When two builds are compared, ultimately, it is the set of changes which need to be identified. These in turn identify both the changes to the product and the problems, activities and requirements addressed between the two builds.

A CM environment properly centered on Change Management will not only bring change management front and center, it will give you instant access to both your Project Status and your Product Views.