Plan Configuration Management

(Activity) for Tier: Product

PURPOSE

The Configuration Management (CM) Plan describes the configuration management objectives, resources, and activities that must be performed during the project’s life cycle. The purpose of the Configuration Management Plan is to describe how configuration management (CM) will be conducted throughout the project lifecycle. This includes documenting how CM is managed, roles and responsibilities, how configuration item (CI) changes are made, and communicating all aspects of CM to project stakeholders. Without a documented configuration management plan it is likely that CIs may be missed, incomplete, or unnecessary work is done because of a lack or version and document control. While a configuration management plan is important for all projects, this is especially so for software and other information technology (IT) projects.

WHEN

During project planning, when new CIs have been identified, or when configuration of an existing CI needs updating.

PARTICIPATING ROLES

INPUTS

Todo

need the ASG to define the inputs for this activity

ENTRY CRITERIA

Todo

need the ASG to define the entry criteria for this activity

SUB-ACTIVITIES

  1. Establish Project’s Configuration Management Approach

    • Document the scope of the project Configuration Management Plan (CMP). Establish clear boundaries for configuration items the project considers to be under the project’s ability and authority to control.
    • Document the objectives of the project CMP.
    • Identify and document the relationship of the CMP to other project plans, noting any specific dependencies those plans have on the CMP or CM processes.

  2. Establish and Document the Project’s Configuration Management Systems (CMS)

    • Systems and repositories where configuration items will be stored.

      • Describe the system or repository.
      • Describe the physical/virtual location of the system.
      • Describe the system’s version controls.

      Note

      Company Policy Requires the usage of a GIT Repository for source code.

    • Specify standard data management practices

      • Uniform standards for the form and medium used for similar data
      • Adequate means of retrieval and access
      • Security procedures where needed
      • Privacy requirements where applicable
      • Appropriate archiving and archive retrieval considerations

    • System for documenting change request submission and approval.

      • Describe the system.
      • Describe the physical/virtual location of the system.
      • Describe the submission and approval process of the system.

      Note

      Company Policy Requires the usage of GIT Pull Requests for source code change submission and approval.

  3. Establish and Document the Project’s Configuration Management Controls

    • Establish and describe the system for submitting, evaluating and approving changes to formally controlled CI baselines.

      • Establish and describe the project Change Control Board (CCB) or, if the project has no CCB, the change approval authority. Provide references back to the Project Plan as appropriate to ensure the proper stakeholders are consulted and involved.
      • Establish the method used to document and track change requests.
      • Establish Git repository branch policies for managing code changes within Azure DevOps

    • Establish auditing for project configuration items. These can include:

      • Physical Control Audits (PCA)
      • Functional Control Audits (FCA)
      • Configuration Management Audits (CMA)

  4. Identify and Document the Project’s Configuration Management Baselines

    • Identify the baselines to be managed by the project. These can include:

      • Documentation
      • Formal configuration items
      • Product
      • Requirements specification
      • Project Environments (e.g. Integration Server, Staging Server, Production Server, etc.)
      • Git repositories and the branches under formal control

    • Provide a description of each of the project’s baselines, which should include:

      • A brief overview of the baseline
      • The configuration item(s) that will make up the baseline
      • At what point in the project life cycle the baselines will be established
      • The approval authority (i.e., group or role(s)) responsible for approving the baseline

  5. Identify and Establish the Project’s Configuration Item List

    • Configuration items held under project control should typically be work products that are utilized across roles as inputs or outputs of other processes or are dependencies; configuration items expected to have a high change rate; or those configuration items which are vital to project success.

    • All external system interfaces must be included as configuration items. The project must define a control authority and define it in the CM Plan. For example, a project may select the Backlog Refinement or other activity as the control authority and manage it as an informal or formal control type.

    • Identify the attributes the project will track against their configuration items. At a minimum these shall include:

      • Name of the configuration item

      • Description of the configuration item

      • Storage location or repository of the configuration item

      • Level of control

        • Formal
        • Informal

      • Role who has authority to change the configuration item baseline

    • Document formally controlled configuration items.

    • Document informally controlled configuration items.

    • Create or modify team procedures as needed.

      • Incorporate or reference standard data management practices.
      • Incorporate or reference configuration management controls where applicable.

  6. Document Configuration Management Plan

    • Capture all information created or revised during execution of this activity in a form and format that makes it readily available to all team members for review and use.

      Note

      A company-defined ISI Configuration Management Plan (CMP) template is available, but not required as the form/format, for documenting a project’s configuration management. A link to this template is available in the See Also section of this process.

    • As needed, create or update team norms and standards for documenting and performing configuration management in order to ensure consistency and quality over time.

  7. Gain Stakeholder Commitment

    • Provide the project’s CMP to all relevant stakeholders for review and comments.

    • Revise the CMP as needed to achieve a team commitment to the final version.

    • As needed, create or update team norms and standards for attaining a team commitment to the CMP. This must include:

      • how team members participating in the review of the plan will be identified
      • the criteria that will be used for the review
      • how the results of the review will be documented

    • Documented results of a review must include identification of participants and a description of any changes needed, to include noting if no changes are required.

EXIT CRITERIA

Todo

need the ASG to define the entry criteria for this activity

NEXT ACTIVITY

Process Guidance Version: 10.4