A project baseline is the fundamental CM technique for release management. Configuration management has historically been about managing the acquisition of new products. To that end, a set of baselines is defined corresponding to various milestones in the product development cycle. These baselines reflect different expressions of the final product and include the functional, allocated, and released baselines.
Each baseline serves as a jumping-off point for subsequent changes in two different ways. First, a baseline serves as a snapshot of one particular aspect of the product development process in time. A software release is a frozen image of one particular software configuration. A subsequent release will be built on the earlier baseline, with the addition of certain changes. In addition, a baseline serves as the end result of one phase of the project development cycle. While the frozen requirements 1.0 serves as the foundation for requirements 1.1, it also serves as the starting point for design 1.0.
There is an obvious analogy between project baseline and the waterfall development model-the different phases of waterfall correspond to different baselines. There is no requirement that one accompany the other. The list of specified baselines can be defined in a manner compatible with other goals of the project-including intermediate baselines identified as milestones, and the short cycles of Agile development. The content of these baselines is notoriously fluid, which has led to the booming market in books on Agile project management and Agile software development.
A single project using project baseline may partition itself into subprojects as appropriate. Baselines can be set for individual sub-projects or across the entire program but, obviously, subproject baselines will increase the management load.
A project baseline has the advantage of being obvious. In an environment where formal project management techniques are used and with an organization that is divided into functional units (development, QA, etc.), the creation of baselines that correspond to defined milestones within a team and to releases between teams is an obvious step. The project baseline approach is harmonious with a highly structured organization and fairly obvious to all members of the team.
Because project baseline derives from formal project management, it is not tightly coupled to any particular software development approach. This high degree of abstraction lets project baseline serve any kind of development project, software or not. A combined hardware/software effort, a circuit board, or a commercial shrink-wrap software product can all be managed using the same approach. This abstraction leads to another advantage-independence from any particular technology. Project baseline can be implemented using the latest and greatest tool suite, but it can also be done with a stock of loose-leaf paper and a #2 pencil.
The last advantage of project baseline is independence. The formal nature of the technique means that the development activity can take place independent of the configuration management activity. This means that a single CM specialist can support a large development project, or support more than one project. By focusing on the interface between development and CM, and the delivery of agreed-upon baselines, there is no need to tightly couple the two activities.
Probably the biggest single disadvantage of the project baseline technique is independence. In my travels, I have encountered several clients with a separate, formal CM team that is totally disconnected from the development activity. As a result, the development team generally doesn't see any of the benefits of CM, and the CM team generally has no idea what is happening within development. Because of the long intervals between baselines, and the pressure for the CM activity to be more efficient (by supporting multiple projects, or using fewer personnel) the records maintained by CM tend to become very coarse-grained. This reduces the value provided by CM, and can hamper certain project management activities. It can also lead to a loss of respect for the CM team or the CM function. This sometimes results in development managers building their own private CM activity, followed shortly by reorganizations and terminations in the old CM office.
Because of the high level of abstraction, project baselines tend to treat the development process as a black box. This can disconnect the CM activity from other development activities, as mentioned above. In turn, this lack of connection and communication leads to reduced transparency and reduced traceability. CM activity, properly a part of the project or program management office, cannot provide the kind of status and traceability information needed by other activities within the PMO. Naturally, the other PMO activities will pursue their information through other means. This results in a CM function that is disconnected from both development and project management, and the fallout of a messy, informal network of connections that supply the various project managers.
There are no particularly onerous prerequisites for implementing project baselines. Instead, it is important to choose an implementation approach that is as simple and supportable as possible across the entire organization. It makes little sense to have multiple, slightly (or completely) incompatible implementations throughout the enterprise. Project baselines provide value, in part, by encapsulation. There is no good reason for different implementations, except to correct errors, and those should be corrected everywhere.
The other significant requisite comes from the periodic, black-box nature of the project baseline technique. Delivering baselines requires a concrete result; this usually leads to a requirement to export or externalize all the elements of the project. This can, at times, be satisfied by a bill of materials that details the exact revision numbers of the individual files or specific label in the system. The complexity of the baseline mechanism will tend to increase, though, as the complexity of the project increases. Hardware and firmware projects may have to include a hard copy of the components.
Projects with a heavy database component may have to render all database changes as a set of executable scripts (that are rarely ever executed, leading to the obvious reliability problems), but project metadata may not be expressable in any reasonable fashion. The point is that some kind of archive is required for storing the various baselines and, given that different baselines may be expressed in different ways-as source code, design documents, requirements specifications, circuit layouts, etc., the archive needs to be fairly general-purpose.
