CM occurs at several levels within a workplace. CM is often thought of as occurring at the project level and focusing on what tasks must occur to deliver a release package. This usually involves build, package, and deployment tasks and includes change control and issue tracking tasks. These CM tasks fit nicely in an engineering project plan, with most occurring at the development or release phase of a project. Many CM tasks and activities, though, may not fit so neatly into a project level plan.

As an example, often times CM infrastructure tasks (e.g., application level CM tasks) are intermingled with project level tasks in an engineering project. The CM infrastructure tasks may interfere with the ability to get the release out on a timely manner. In this case, it is suggested that you have a separate CM effort.  Its only goal is to establish the deliverables, known as a CM infrastructure, that are independent from the engineering project whose goal is to create a set of deliverables known as a project release.

If the CM infrastructure tasks get completed in time for the engineering project to use them (a procedure, training, code repository), then they can be used. However, an engineering project should not have to wait for the CM infrastructure tasks (at the application level) to get completed in order to get the release out. It is advisable for the application owner to provide the CM professional(s) with lead time to build an appropriate CM infrastructure for the application lifecycle so that when project releases are ready to be developed, a functional set of CM procedures and technology are available to control that work.

Three CM Levels
In Mario Moreira’s book titled, "Software Configuration Management Implementation Roadmap," a structure for the level where the CM tasks can be aligned is presented. This includes the following levels:  application, project, and the organization.

At the application level, the CM tasks build or improve a CM infrastructure. CM tasks at this level do not directly involve getting a project release out to market (e.g., to its destination), but involves CM tasks focused on building the infrastructure and processes that can support an engineering project lifecycle.

At the project level, the CM tasks help a project create and deliver a release to the marketplace.

At the organization level, the CM tasks define CM consistency across a workplace such as standard policy, budget, personnel structure, and terminology.

Defining the CM Levels
Many people within a workplace use the terminology of the CM levels interchangeably. For example, people constantly use the term “project” and “application” (or “product”) synonymously when, in fact, they are very different. Below are brief definitions of the levels, but it is important to define these terms for your workplace.

An organization may be:

·         An entire workplace if small with only 1 division head or area of focus.

·         A division or sub-division of a workplace if large enough and/or the establishment has multiple division heads with different market or product sector focuses or operates relatively independently from other parts of the workplace.

An application may be:

·         An accumulation of deliverables that make up a functioning system in a full state of operational readiness (otherwise known as “in production”). This can be running on a server, on a client, or packaged on media.

·         An application lifecycle is the lifespan of the application from the first release in production, through the last release, and until users are no longer using the application.

·         An application may be called a product if it includes that application. However, some Products are a collection of Applications.

A project may be:

·         A set of tasks/activities whose aim is to deliver a changed (new/modified/deleted) set of functionality (otherwise known as a release).

·         A project lifecycle starts in the planning and requirements stage and ends when all project tasks are completed and the deliverables are released into production.

Benefits of the CM Levels
The CM levels provide a structure that will allow you to best align the CM tasks to where you get the most benefit. To determine where you will get the most benefit, identify the target audience of the CM task.

Before beginning a CM implementation effort, it is important to determine the level since it will improve your chances of successful implementation and deployment. To identify the level, consider the following:

Identify if the CM task and its deliverable is expected to live the duration of an organization, an application, or project. With the results of the bullet item above, who in the organization level, application level, or project level is the primary beneficiary of the task or deliverable and who may help the SCM professional best ensure adoption of the deliverable or completion of the task?

For example, the CM implementation involves establishing a CM policy. First, identify if the CM policy is to live throughout the life of the organization, an application, or a project. Then identify who the CM professional needs to work with to get this accomplished. If the CM policy is only for an application (application lifecycle), then the CM professional should work with the owner of application (a.k.a., product manager) and the CM implementation should be conducted at the application level. However, if the CM policy needs to live the duration of an organization, then the CM professional needs to work with senior management to ensure adoption of the CM Policy within the entire organization.

Below is a summary of possible targets in the organization, application, and project levels based on the life or usage of the deliverable and primary beneficiary.

The identification of the target-level will help maximize the time spent on the task and increase the chances of success. This should be one area of focus when approaching a CM implementation.

Examples of Tasks as the Organization, Application, and Project Level
What are some examples of CM tasks at the appropriate level? The following provides examples of tasks grouped by the three CM levels. Keep in mind that some tasks could fit into more than one level. Also, each set of tasks is not meant to be an exhaustive list. CM Level: Organization

·         Determining CM awareness

·         Assessing CM risk (at the organization level)

·         Evaluating support and sponsorship for CM

·         Defining an SCM budget

·         Establishing a CM personal structure

·         Defining an organizational level CM Plan

·         Defining common CM terminology

CM Level: Application

·         Assessing an application’s CM needs

·         Selecting a CM technology best suited for the application

·         Defining an application level CM Plan (if none exists at the organization level)

·         Establishing a CM environment for an application

·         Establishing CM processes for an application (checkout/checking, build, release, change control, problem management, etc.)

·         Performing CM training for those that work on the application

CM Level: Project

·         Getting CM tasks into the project plan

·         Baselining the code for the new development

·         Establishing the appropriate branching structures

·         Compiling the code

·         Creating a release package with deliverables

·         Attending change control board (CCB) meetings

Summary
In our lives, we are typically very busy. It is important to maximize the output of any task we perform. By identifying the right audience and therefore the right level, may help us to derive the most benefit from a task. This is particularly important in the lives of CM professionals who are inundated with work requests. The more we understand the level we need to work in and people we need to work with, the greater the chance we will have in completing the task successfully.

References

1. Chapter 1, “4. Examining the Target Levels”, p3-5, by Mario E. Moreira, 2004, John Wiley & Sons, Ltd Publishing.

2. Chapter 1, “4. Examining the Target Levels”, p3-5 of the “Software Configuration Management Implementation Roadmap” by Mario E. Moreira, 2004, John Wiley & Sons, Ltd Publishing.

3. “Approaching the Implementation of CM”, by Mario Moreira, CM Crossroads, February 2004