Chapter 3

Configuration Identification

Throughout the life of a project, information is needed to help direct and manage the project. Creating, modifying, and storing this information is an important part of the project. This chapter describes what to identify on the project that may be placed under PCM control. The chapter begins by describing what to look for in identifying project information and items that may be under the control of the PCM process. It also provides guidance in structuring the information so that it is more accessible to those who need it. Part of the structuring involves determining what items need to have an assigned identifier and then giving them a unique identification to allow them to be managed as configuration items (CIs).

This chapter includes the following major sections:

3.1 Project Artifacts

From the very beginning of a project, documents and other artifacts are created that help manage the project and provide communications to the project team, stakeholders, management, and others. Some documents and other artifacts describe the project itself and its various characteristics. For instance, the project charter lays out what the project is intended to accomplish and requirements definition identifies the expected capabilities of the final project deliverable. Other information explains the agreed upon relationship between the various organizations that are either a part of the project or that support it. Included here might be contracts with vendors, subcontractors, and suppliers, as well as agreements for support with other groups within the same organization.

The following list has many examples of information that could be under the control of PCM:

This list should not be considered as required information for every project. It is provided simply to illustrate possible documents for a variety of projects. The actual collection varies from one project to another, and in all likelihood includes only a few of these items, as well as additional items that are specific to a particular project or organizational policy.

3.2 Structure

As with any important collection of information, a method of structuring project documents and artifacts under PCM is needed. The most basic structuring requirement is for a filing system that makes it possible to organize the information for efficient storage, retrieval, and use. It may also address other project needs, including:

• Information Format. Project information may exist in two forms: electronic and hard copy; and both need to be structured appropriately for the project. Although the methods used differ, the objective is the same: making it possible to efficiently manage project documents and artifacts with the right balance of accessibility, storage indexing, security, and recoverability.
• Rapid Access. It is important that information frequently used by the project manager and core project team is easily accessible. To facilitate this, some project managers create what they call a project binder (may be either electronic or hard copy.) This binder contains such items as project and staffing plans, contact information, various reports, budget information, and other reference information.
• Broad Availability. It is also important for information used by several members of the project team to be kept in an easily accessible location. A typical method is to have the information in computer-based files with secure network access. Computer-based files permit all members of the team access to the same, current information quickly from any location having computer access, including over the Internet. This is particularly important for a project whose team is geographically dispersed. Care should be used in administering the controls for adding, updating, or deleting the information to ensure that only authorized changes are permitted and that these are made to the correct version of the artifact.
• Secure Access. Some information may be sensitive. For such information, proper access controls can be used to limit access to only those people who have a need to view or change the information. Personnel and budgeting information as well as some correspondence requires special treatment to safeguard personnel and organizational information. Properly implemented access controls can also help ensure data and information integrity.
• Information Recovery. A plan for recovering any project document or artifact that is lost or otherwise made inaccessible is another important element of the information storage plan. A recovery plan defines how the project artifacts are backed up, when and how frequently, and the recovery process for specific items. An example of a specific item is the recovery of an older version.
• Information Retention. Occasionally, situations arise where older information that has been replaced with more current information needs to be referenced. A plan for archiving older versions of information for future reference may be useful on some projects.

For many projects, particularly larger ones, where a lot of project documentation is expected to be produced, it may be beneficial to have a well thought out documentation plan. A documentation plan lays out the details about how the project documentation is to be structured and managed, and it is usually developed early in the project cycle. The plan may identify storage locations for the information described earlier in this document. For documents that will be undergoing revisions, the plan may also describe the progression for document versions from inception to use and from update to eventual archival. It may also note any applicable changes in storage locations as a document progresses from one state to another. The documentation plan may be easily accessible to the project team as well as anyone who is responsible for filing new or changed documents. Access however should be in accordance with the security and privacy policies of the organization. Once created, the documentation plan would be placed under PCM.

3.3 Item Identification

Configuration identification is an organized structure describing the composition of objects within a project. These objects are termed CIs. Standard baseline descriptions of the functional and physical attributes of these CIs are established to maintain control of changes occurring to existing items and new “end items” or deliverables within projects.

Generally, the project processes result in establishing approved baselines and related descriptions in a timely manner. Any changes from the baselines are documented for their effect on unique items and are approved. The baselines reflect the differences from the “as planned” through to the “as released.”

Identification of configuration items emphasizes the final deliverables of the project as well as significant events or effects, and presents both the manager and client or sponsor with recognizable points of achievement. Items selected from the project are at a level significant enough to maintain control and may consist of (1) physical items, (2) documents, (3) forms, and (4) records. These four categories can be subdivided by type and baseline. Examples of significant items are:

• Items that must meet legal requirements;
• Items that must meet health and safety guidelines;
• Items to be sent out to subcontractors;
• Items that have an impact on processes or deliverables outside of the current project; and
• Items that form a large component of the project’s deliverable.

3.4 Taxonomy Scheme

Formal review processes, status tracking, and management of changes require that information describing one CI be differentiated from information describing other CIs. In practice, projects have found that CIs must be uniquely identified for control, processing, and tracking. Unique identification can be accomplished by assigning serial numbers, non-significant numbers or any established and project-approved classification to each CI.

Language usage within an identifier has been shown to reduce identification errors and to allow ease of use. Therefore, the trend is to use a mix of meaningful letters (e.g., denoting type of CI and numbers (such as date, version, etc). Some organizations have identifiers in place for use in all activities.

The complexity and sophistication needed for a cataloging system reflects the project’s size and relationships. The more complex the system is, the more time, resources, and budget should be assigned to the CI portion and taxonomy schemes.

Depending on the type of project and corporate policies, the following identifier types can be considered:

• Intelligent identifier referencing specifics by including within the ID code;
  • Category of item (i.e., physical, document, form, record);
  • Hierarchical association to other items (blueprints, systems specifications); and
  • Version control (original, upgrade, complete change, subcontractor/manufacturer, plant location);
• Date stamp;
• Source of the item (project, subcontract, existing company item);
• Format (if computer based, then word-processing software, version, and platform); and
• Serialization or lot control.