Changes: The Crossroads Between Project CM and Product CM

Product, Project, Program
When we talk about product, we're focusing on deliverables. A product may consist of a single deliverable or a set of deliverables. Often a product will have sub-products which are themselves products which are incorporated into a higher level product. Their development will typically span multiple releases over many years. For example, A space shuttle is made up of canadarm, solid rocket boosters, liquid fuel tank, shuttle. Each of these have many subsystems and sub-products (e.g., the main computers aboard the shuttle, the main engines, etc.). In the end, all of the deliverables must come together to create the first release of the shuttle (i.e., Columbia) and then the next release (Atlantis, Discovery, etc.). Sometimes a product release is an upgrade; sometimes it is simply a template for creating a new version of the product. Often, it’s both (e.g., Windows XP is both an upgrade and a new version of the product).

A project transforms a product, through a series of activities, typically to the next release stream. For example, Chicago took Windows to Windows XP (or was it 2000?). Projects come in all sizes and shapes. The activities are typically collected into a hierarchical decomposition known as a work breakdown structure (WBS). The WBS helps to outline budget, risks, resources and schedule.

A program is a larger effort with an overall goal in mind. For example, the U.S. manned space program (super-program) and individually the Mercury, Gemini, Apollo and STS programs were created to give the U.S. leadership in space technology; Nortel Network's DMS Family of Telephone Switches was a program instituted to put Nortel on the map as a leader in the telecom industry. A program is more far reaching than a large project or a series of product releases. It involves both products and infrastructure, which will sustain a goal over a long period of time.

Project CM versus Product CM
Project CM starts with the establishment of requirements that typically operate on a per-release basis and the translation of the requirements into project activities. These typically form a WBS which through implementation will transform a product from its pre-project form (e.g., release 1) to its post-project form (e.g., release 2). Project CM also deals with traceability issues: the assurance that the project has indeed performed the necessary transformation to meet the requirements.

Product CM deals with management of all releases of the product. This includes all of the configuration items and deliverables, and the relationships between them, as well as the identification of products and sub-products. It deals with issues of build, deploy, and related workspace management. It includes management of product defects and of test suites.

Project CM
Project CM starts with the formal creation of a customer requirements tree. The top level of the tree reflects the purpose of the project. Requirements are typically broken down from there into fixed groups dealing with things such as functionality, performance, environment, etc., and the customer requirements in each area are laid out. The tree will be refined over time as the customer and supplier better understand the customer constraints and supplier capabilities over time.

As requirements become firm, the supplier will use them to put together an initial project plan through development of a work breakdown structure (WBS) detailing all of the activities the supplier will have to perform in order to deliver a solution which meets the requirements. In some cases, the activities cover building a solution from scratch, perhaps with a plan to capitalize on the supplier's own experience and perhaps some previously developed components. More frequently, though, the activities are transforming an existing solution from one stage, typically a release, to another.

Who Does Project CM?
In the early stages, the supplier will need a product management team which acts on behalf of the customer(s), and a project management team which acts on behalf of the supplier. If a solution is being delivered for a single customer, the product management team will likely be a composite of customer and supplier team members. A specific contract might be used in isolation to establish the business case. In a more generic solution, customer representatives in the supplier organization will feed customer input into the product management team. The team must put together a supporting business case to move the bid forward. This will likely involve additional areas such as competitive analysis, market research, and opportunity costs.

In an ideal world, the customer knows exactly what the requirements are. In the real world, the development organization has plenty of input on helping the customer. For example, if the customer is a software development organization and the development organization a CM supplier, the CM supplier might begin with a requirement such as, “To support the extensive merge activity expected, the CM tool must provide an intuitive, high performance merge capability.”  They could then recommend that it be turned into the following: “Minimize the effort spent on merging through CM tools which reduce the need to merge and through strong merge capabilities.”

As well, where there are multiple customers involved for a solution, the supplier will need to evolve an internal requirements tree which has the proposed market segment as the customer. The supplier is trying to get its initial customer(s) to pay for the generic feature development, while the initial customer(s) try to keep contract costs to a minimum.

In order to successfully negotiate this requirements enhancement and clarification process, a CM tool would provide the capability to capture requirements, perform change control on the requirements, and baseline the requirements. It should also allow easy comparisons on both baselines and changes in progress so that customers can quickly review changes against both their initial and subsequently agreed upon baselines.

Development of a Work Breakdown Structure
Product management must negotiate a contract which has a specific set of signed-off requirements. To do so, the project development team will have to be involved. The project manager will work with the development team to establish a WBS. As the WBS activities are enumerated, the development team must take each activity and produce estimates with respect to budget (time and cost) and risk/feasibility. Each activity should clearly show a list of deliverables/objectives which can be verified to meet the requirements. It is helpful, at this point, to have a project management tool which is both multi user capable and integrated with the requirements management tool. Ideally, these are the same tool and it is easy to trace the activities back to the requirements.

Note that whereas it's essential to have requirements under version and change control, the same is not necessarily true of activities. Activities need to reflect the signed off requirements. An activity will have a definite set of objectives which are implemented. There will not be different versions of the objectives each of which are to be implemented. Instead the objectives of each activity must be clearly defined prior to development. Still it may be interesting or even useful to capture revisions of the WBS over time as it evolves. What will be important for each activity is the specification that it spawns. This will need revision control as the specification will undergo change to reflect reviewers' feedback.

At this point in time, the WBS need only be developed to a level which permits the development team to give a bounded estimate of the cost, schedule and risk. This is where the history from earlier projects pays off. If there are no significant risk factors, history may be used to produce fairly accurate estimates. Where there are significant risk factors, history can be used to predict the probability of success and to help bound the cost and schedule estimates. In some cases, activities will need to be broken by the development team down further to more accurately assess risk and or budget.

Project Management
Project management begins in the development team as the contract (with the customer or with product management on behalf of the customers) approaches sign-off. The WBS must evolve into a tree of activities which can be prioritized, ordered (e.g., pre-requisites and high risk items up front), sized and assigned. For a large number of activities (several dozen to hundreds), even a rough sizing with some experience will lead to an overall fairly accurate overall budget. Activities should be broken down until they are in a specified range of effort (e.g. from 2 to 8 weeks in size). Even a vague level of uniformity will permit fairly accurate accounting of progress. If this step is missed, you may have 95% of activities completed but find that the project is less than 50% complete. You then would need to rely heavily on effort-to-date figures, which typically incur some time lag and inaccuracy. Having the activity completion (or intermediate checkpoint completion) automatically signaled to your repository of data will help ensure more accurate reporting (e.g., S-curve reports which project actual completion based on the existing plan, forecast and actuals.

Here is where integrated process and tools are important. If your specifications are tied directly to your activities, your checkpoint status can be updated whenever a specification is submitted, reviewed and/or approved. Your completion roll-ups will reflect these events without depending on someone to fill in their actuals. If your time sheet system is integrated to your project management tools, your actual roll-ups will be more timely and accurate. They will also work with your checkpoint states to help you to identify areas which are over budget and have schedule risk.

The WBS should be broken down to include specification activities, design activities, implementation/unit test activities, verification activities, documentation activities, etc. A good project tool will allow you to look at progress by phase simply by selecting the appropriate types of activities. For example, specification activities would comprise most of the functional specification phase and might have submitted, reviewed and approved checkpoints associated with each. By rolling up the actual checkpoints against the plan early on in the phase, an accurate 95+% completion date can be inferred so that resources may be scheduled effectively.

Relating Project CM to Product CM
The WBS for a project serves multiple purposes. If integrated with the rest of your processes and tools, it will permit a high level of traceability, allow automatic generation of release content documents and release notes, and generation of complete test plans by rolling up the test specs for each activity into functional and non-functional areas. It will allow you to quickly identify which requirements are at risk for your delivery schedule. This in turn permits non-compliance negotiations to occur up front, not after delivery. In many cases customers will be more willing to negotiate away high risk items rather than risk overall delivery.

In a typical scenario, the WBS should be viewed as a transformation mechanism: it transforms one release of a product or product family into another release. Simply, this can be represented by the following diagram.

We've talked about the transformation to this point in time. The WBS was generated by looking at the existing release of the product (the left side of the diagram) and using the requirements tree for the project, spawned activities. The aggregate of these activities, when added to the existing release, results in the planned release (shown on the right side of the diagram). An additional component of the transformation is the generic defect correction (bug-fixing) activity which takes some subset of the outstanding product defects and corrects them so that the product more closely resembles the specifications.

When we talk about the WBS for a development stream, we naturally refer to the stream name. For example, the WBS for the release 2 of a product would normally be referred to as the release 2 project plan. It would transform release 1 of the product into release 2. For this reason, all activities in the release 2 project plan would be tagged with the stream "rel2", for example. If a product road map has been established and some activities need to be pushed into release 3, the tag on the activity is changed, even before the WBS for release 3 exists.

Product CM
Product CM deals with managing a product or set of products. This can occur in several areas: managing several products within one CM library, managing product/sub-product relationships, and managing third party products. Configuration Management deals with managing consistent collections of source files and their deliverables. There are multiple revisions of files and data, typically organized into branches. There are various deliverables which need to be built. There are dependencies both between source files (e.g., includes) and between deliverables.

In most CM systems, branches are used to collect files for a particular release, to collect files into logical changes, to collect incremental files for a patch build or a custom build, to separate promotion levels, etc. More modern CM systems use branches only, or primarily, to organize revisions into release streams. Other first class objects provide additional collection mechanisms. For example, baseline records identify files for a particular release, changes collect files into logical changes, build records collect incremental files for patch or custom builds, promotion models on changes and build records work with the CM tool to provide dynamic promotion level views.

This difference is significant. In one case, development and implementation of clear branching strategies, labeling mechanisms as well as significant merging activity from branch to branch form an extensive component of the CM task. In the latter case, the first class objects (changes, build records, baseline records, etc.) clarify and simplify the CM task. With proper change management and development stream capabilities, branching can be fully automated, merging reduced to transferring non-shared functionality between release streams and labeling can be fully eliminated.

Product CM deals not only with organization of the CM data, but also with support for generation of the deliverables. This implies creation and/or management of build scripts, configuration management of build tools and processes, and support for deployment of files for the build process.

On a related front, product CM deals with the population of workspaces and the establishment of data views. In some tools, such as ClearCase, these two are intimately connected. Other tools tend to distinguish between the tool view and the user workspace. In these cases comparison of the view to the workspace, and associated synchronization and deployment issues need to be addressed.

Managing Multiple Products
A good CM tool will allow you to track several products in a single repository. This allows easier code sharing and administration among other things. 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 optionally 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.