The Dimensions of SCM Planning


There are times when Software Configuration Management (SCM) gets implemented and the results may not be as positive as one would hope. There can certainly be many reasons for this, but some times, it comes down to whether or not due diligence was performed during SCM planning,an important criteria for successfully implementing SCM. Other success criteria include: sponsorship (management commitment to the SCM effort); funding (money to purchase appropriate SCM tools and infrastructure); and personnel (persons trained, skilled, and experienced in the areas of SCM tools and process). However, effective SCM Planning should cover sponsor, funding, and personnel tasks if structured appropriately.

Identifying the Best SCM Level
Even with a focus on SCM planning, we should ensure that the SCM effort occurs at the appropriate level. A way to approach this is to consider that SCM can benefit a company at varying levels. This is what I refer to as adding dimensions (or levels) to SCM planning. By identifying the primary benefactor of the SCM task or SCM effort; who you have to work with to make a task happen (upper management, application owner/product manager, or project manager/staff), and; the repetition of the task at hand, may help you align the tasks or effort to the appropriate level.

The levels in which SCM can be focused to ensure an increased possibility of success include:

·         Organization level: tasks targeted toward upper management that benefit the organization by ensuring that SCM is at a level that can change the culture. These tasks are usually done once, but may need occasional verification.

·         Application level: tasks targeted toward the application owner or product manager that benefit the application (typically SCM infrastructure tasks) by adding control mechanisms (technology and procedures) that improve the stability of an application. These tasks are usually done once per application.

·         Project level: tasks targeted toward project management (and staff) that benefit the project by ensuring code and release integrity and provide time-to-market advantages of the project’s delivery (or release). These tasks are done numerous times and should be repeatable.

As a brief case study (by using the above as a guideline), when establishing an SCM policy for a company, the primary benefactor is the organization. Therefore, you know that you should meet with the appropriate level of management to get buy-in and approval for that policy. If you want to implement an SCM infrastructure (tool and procedure) for an application, though, the benefactor is then the application, so therefore, you would want a specific SCM effort to implement the SCM infrastructure. Many times, I’ve seen an SCM infrastructure tasks get included in a development project plan (during the lifecycle of a development project). The SCM infrastructure tasks impact or takes a lower priority than the development project tasks. This is because the SCM infrastructure tasks are not project level tasks focused on the project lifecycle, but are “application” level tasks focused on the application lifecycle.

With all of this in mind, by aligning SCM tasks to the appropriate level, the chances for a more effective SCM implementation may increase.

SCM Tasks Recommended for the Organization Level
This section provides an overview of SCM tasks that have more value at the organizational level. While the SCM tasks listed are in an order, it is not hard-and-fast so feel free to modify (add, change, delete) as appropriate.

The primary SCM role best suited to implement these tasks is the SCM manager (if one exists) or an SCM champion (someone who is versed in the area of SCM and is committed to provide leadership in this area). This person will primarily work with management to complete the tasks and should be prepared; this will ensure that meetings with management are as effective and productive as possible. The SCM tasks at the organization level may include (but are not limited too):

·         Raising awareness of software configuration management: establish a common understanding of SCM within the organization and to ensure people are aware of the effort being proposed.

·         Determining management commitment and support: determine what level of management commitment exists.

·         Establishing an SCM group or function: establish dedicated personal to improve your chances of a successful SCM implementation at all levels.

·         Determining an SCM budget: establish funding for SCM ensures that there is a future for this field within the organization.

·         Creating an SCM policy:  establish a standard set of guidelines for implementing SCM within an organization.

·         Establishing the SCM terminology: develop an SCM glossary or set of terminology that can be commonly used throughout the organization.

Note: If there is no focus of SCM at the organization level at this time, then many of these may be addressed at the application level. Also, the SCM tasks in the organization level are, in many cases, a one-time-only task and specifically not intended to be rapidly repeated. However, it is best to periodically verify commitment and funding, and continue to raise awareness at the upper management level. SCM Tasks Recommended for the Application Level
This section provides an overview of SCM tasks that have more value at the application level. Every application must have a solid and effective SCM technology & process infrastructure. An application may remain viable for a number of years and through many releases. The more effective the application’s SCM infrastructure, the better the chances for traceable and integrity of the configuration items.

SCM manager and SCM engineer
are the primary SCM roles best suited to implement tasks at this level. Participation and cooperation must also occur with the application owner and lead technical personnel, though. Some of the SCM tasks at the application level include (but not limited to):

·         SCM analysis: provide a review of the current environment

·         SCM planning: provide a road map of the tasks and activities needed to implement an SCM infrastructure.

·         SCM tool selection:  evaluate and select the best SCM technology for your needs

·         SCM strategy and design:  define SCM roles and responsibilities (change control board, release engineer, etc.), tool profile, environment profiles, capacity planning, training and procedure definition

·         SCM technical implementation: establish the SCM tool environment

·         SCM procedural implementation: establish SCM procedures

·         SCM training: provide training guidelines for establishing solid SCM practices

·         SCM transition: provide transition support of staff to new SCM technology

Note:The SCM tasks at the application level, in many cases, are a one-time-only task (e.g., you only create one change control procedure for an application) and specifically not intended to be rapidly repeated. SCM Tasks Recommended for the Project Level
The objective at the project level is to define a common set of SCM tasks performed during a project to produce the release. Many of the tasks at this level should use the SCM infrastructure and procedures defined by an SCM effort at the application level. In order to guarantee repeatability and the same infrastructure to guarantee integrity of the product, every project should use the same procedures.

The SCM tasks at the project level are suited for more rapid and repetitive tasks. For example, builds occur, perhaps, daily and the change control board may meet weekly. Due to the temporal difference between the tasks at the project level, they are meant to be separate from the SCM tasks in the organization or application level (e.g., instead, part of the SCM task list which is added to the project’s project plan).

The primary SCM roles best suited to implement these tasks at the project level are the SCM manager, SCM engineer, and release engineer. However, participation and cooperation must occur with the project manager, configuration control board (CCB), lead development personnel, and the test personnel.

The goal at this level is to identify a customizable set of standard SCM tasks for each project (an SCM task list that gets added to the development project plan). This includes defining the appropriate set of SCM tasks per size of project. Some of the typical SCM tasks include (and not limited to):

·         Assign SCM personnel to the project

·         Provide SCM awareness at the project level (SCM tool & procedures used, roles, etc.)

·         Perform the CCB process and activities

·         Version control documents (for internal project needs)

·         Version control code

·         Build the release

·         Branch/merge activities (if applicable)

·         Version control deliverables

·         Perform SCM audit

·         Prepare release notes

·         Package the release

·         Install the release

To define its proper level, it’s helpful to review the SCM task and consider what level benefits the most (organization, application, or project).  Also consider who you work with to accomplish a task (upper management, application owner/product manager, or project manager/staff), along with the repetition of the task at hand. Overall, this may help SCM professionals target their SCM tasks or effort more effectively, thus leading to better SCM planning and, ultimately, to a more successful implementation and adoption of SCM.


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.