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.