CM: The Nerve of Your Life Cycle Management

the activity/task record. Take a WBS (Work Breakdown Structure) for a specific project, typically a new product release. All of the activities are clearly identified. Ideally they have a clear set of objectives/deliverables and are typically assigned to a single person or small group for implementation. Some organizations break the activities down into fine granularity activities (often called tasks). Others leave them in bigger clumps. We number our activities using a dumb numbering system (a.1200, a.1201, etc.). The WBS identifies the activities that will be executed to transform the product from one release to another. The incremental specifications document the transformation from one release to another.

So we attach our incremental specifications to these activities. In effect, the WBS becomes a live growing super-change specification for the release. If you want to know what the change is, or will be, as a result of a give project, take the appropriate part of the WBS and extract the documentation for it. From a design perspective, extract the incremental design specs. From a functional perspective, extract the incremental functional specs.

We typically will work in one of two modes - different activities for creating the specification and for doing the design and implementation, or one activity to cover both. In the former case, we just select the "design" or "feature" activities to get the design or functional changes respectively. In the latter case we either have a single document with both feature and design sections, or we have separate functional and design documents attached to the same activity.

We have no need to implement a naming policy (the activity id suffices), and no need to make sure activities are referencing the right document identifiers. But, we still have a need for some CM. We need to track revisions of each activity document, through to approval. But we don't need to group activity documents together into change packages - each document pretty much stands on its own. We don't need to group them into a separate navigation hierarchy - the WBS does that already. We're not concerned about baselines - the latest version of the WBS documents will give us the most accurate incremental documentation, and last week's collection is really not of much interest to us. So we're concerned with version control, some approval management and automatic identification of the documentation, through the activity id. But we're not concerned about branching. We're not going to create a release 1 version of an activity and a different release 2 version. We may have two different activities dealing with the same area in two different releases, but each describes a separate feature or design. No need to deal with branching.

More Documentation

Some of our documentation falls into another, more generic, category. Things like status reports, technical notes, sales feedback, etc. We call this general documentation and have a specific Document Management component to deal with it. We're concerned here with document identification, and in some cases with version control. A sales feedback document may be a one-time contribution. We want to identify it as sales input and so we use a prefix such as SAL- and then ask our CM tool to number all such documents sequentially. Similarly, we may have a TNO- prefix for technical notes and a PSR- prefix for project status reports. We add a new prefix as we find necessary and let the CM tool do the number assignment. We perform revisioning of the documents, but generally hide most of this from the user in the normal course of events, other than the version identification tag. We allow hierarchical